#gc_k8sday "Google Cloud Kubernetes Day"に行ってきました

3/26 に開催された「Google Cloud Kubernetes Day」に当選したので参加してきました。
最前列でひたすらメモったので放出しておきます。

Program

こんなプログラムでした。

  • 開催挨拶
  • Keynote: 「Kubernetes/Container による開発」の導入難易度とメリット
  • Session1: コンテナ開発プラットフォームに GKE を選択すべき 7 つの理由
  • Session2: GKE を用いたレガシー システムからのリプレース事例
  • Session3: コンテナによる開発と運用の進化
  • Session4: FreakOut の広告プロダクトでの GKE 活用事例と GKE 新機能の導入について

詳しくはイベントページをご参照ください。

Memo

以下メモです。
あまり整理できていません。
あとところどころメモが追いついていない。

資料は参加者のみ後日送付だったので載せられません。

Keynote

「k8s/container による開発」の導入難易度とメリット

  • 普段
    • オンプレで GKE っぽい k8s 基盤を作ってる
    • K8s を使ったシステムのアーキテクトをしてる
  • 著書
  • CA と k8s の関係
    • 2016 年頃から k8s 採用、かなり早かった
    • GKE やオンプレでの使用が多い
    • オンプレの場合は GKE インスパイアな仕組みを作ってる
    • 新規事業がたくさん立ち上がるが、ほとんどのケースで k8s やコンテナを活用
    • レガシーもある、k8s/コンテナへの移行を進めてる
      • “CA k8s"などでググると記事がある

What’s k8s?

  • コンテナをオーケストレーションするシステム
  • 元は Google 社内の Borg
  • 現在は CNCF が中立的にホストしてる
  • コミュニティによって改良されている

This is k8s era

  • 時代は k8s
  • 手のひらサイズの k8s クラスタ持ってますよね?
    • 持ってない人はヨドバシとかで RPi 買ってください！
オーケストレーションとは?
  • Classification of “Provisioning”
    • Bootstrapping
      • サーバー準備
      • OS インストール
    • Configuration
      • サーバーセットアップ
    • Orchestration
Baremetal Era
  • 温かみのある手動 Provisioning
    • 台数増えると辛い
    • 自動化を始める
  • Net boot
  • 自前 Shell Scripts
  • CA でもまだ残っている
  • 各社秘伝のコードになりがち
Cloud Era
  • Terraform, Chef/Ansible/Puppet/Salt, Fabric/Capistrano
    • 構造化される
    • 再現性高くない
    • 構築に時間かかる
  • イメージ化する
    • Packer, Cloud Images, OpenStack Heat, AWS Can
    • イメージ化による高い再現性
    • あまり簡単ではない
    • IaaS ロックイン
Cloud Native Era
  • イメージ化=>Docker
    • 容易
    • 軽量
    • 高速な起動と停止
    • 高い抽象度と IaaS 非依存
    • 宣言的な API と Code
    • 新しい考え方が必要

What is Cloud Native?

  • 定義がある
    • CNCF が出してる
  • どんな定義?
    • 疎結合なシステム
    • 復元力がある
    • 管理しやすい
    • 可観測である
    • 堅牢な自動化により、

Cloud -> Cloud Native

  • Cloud Native Trail Map が参考になる
  • 容易なイメージ化と再現性 by Docker
    • アプリと実行環境のイメージ化
      • =>再現性の高い環境
    • アプリケーションのビルドもコンテナのビルド時に実施
    • OCI v1.0 によるポータビリティ
      • 規格でフォーマットが決まっている
    • ローカルでも同等の動作が保証される
  • 軽量なイメージ by Docker
    • VM イメージと比べて軽量
    • 単一プロセスのみ稼働させるため、軽量 OS を選定しやすい
      • しかしサイドカーとか
  • 高速な起動と停止
    • VM の起動停止より高速
      • VM は OS、コンテナはプロセス
    • 起動が高速だとスケールアウト早い
    • 障害時の復旧が早い
      • Provisioning やり直す場合の時間比較
  • Containerization まとめ
    • 軽量なイメージ化と再現性/軽量なイメージ/高速な起動と停止
    • そんなに難しくない
  • オーケストレーション
  • 高い抽象度と IaaS 非依存 by k8s
    • LB や Storage なども抽象化
    • 利用者から見ると IaaS 固有の知識がほぼ不要
    • ベンダーニュートラルな実行基盤
  • 宣言的な API と Code by k8s
    • 構成情報を yaml の manifests で宣言的に記述して API に登録
    • e.g. 複数コンテナの管理
      • replicas: N を指定するだけで良い
    • E.g. LB との連携
      • 転送先ポート番号と対象コンテナを指定
      • ラベルという抽象的な概念で管理できる
    • Control Loop と Reconciliation
      • Control Loop
        • 現在の状態を観測
        • 現在の状態と理想状態を比較
        • 差分に対処する処理を実施(Reconciliation)
  • 洗練された自動化 by k8s
    • セルフヒーリング
      • ReplicaSet ではコンテナの Replicas を維持し続ける
    • アプリケーションのアップグレード
      • Manifests のイメージバージョンを書き換えるだけ
    • コンテナ単位のヘルスチェック
    • コンテナ起動前の初期化処理
    • コンテナ停止時の SIGNAL
    • コンテナ開始直後〜
  • 豊富なエコシステムと拡張性 by k8s
    • MySQL Cluster on k8s
      • Manifest を登録すると MySQL クラスタが作られる
    • CI/CD on k8s
    • Serverless on k8s
      • K native
    • Service Mesh on k8s
      • いすてぃお
      • Istio
    • Managed Service via k8s
      • K8s から外の managed service を制御する
      • シークレットとかを k8s に持ってくれる?
    • YOUR FEATURES w/ k8s
      • 自分で書けるよ！
      • そんなに難しくない
      • Control Loop をうまく使うツールが色々提供されている
  • 導入難易度
    • アプリケーションアーキテクチャ
      • 多少細分化が必要
      • 基本はマイクロサービス
      • いつでも停止できるよう SIGTERM のハンドリング必須
      • 頻繁に停止する
        • ノードのアップグレード
        • コンテナイメージのアップデート
      • Service Discovery 経由での通信
      • ネットワークの一部制約
        • Source IP が消える
    • セキュリティと分離性
      • runC では kernel が共有されている
        • gVisor のような分離性高いランタイム使うと回避できる
      • ネットワークの分離性
        • GKE ではネットワークポリシー使うべし
    • K8s 学習コスト
      • 学習コストは小さくない
      • CA 内のアンケートでは「今後やっていきたい」が 100%
    • K8s クラスタ運用のつらみ
      • GKE 使うと解放されるよ！
      • GKE オンプレも今後は使えるのでは?
    • マネージド k8s の選定基準
      • マネージドの範囲
      • 自動化機能
      • K8s バージョンの追従

CA と GKE

  • K8s 環境は GKE が多い
    • オンプレ=>44%, GKE=>44%, AWS=>6%, EKS=>6%
  • GKE の自動化機能をフル活用してる
    • 一部プロダクトはこれらの機能提供前に存在したので使ってないが
  • アドテクのレイテンシ要件を GKE で満たせてる
  • 新規開発のほとんで GKE を使用
  • ステートフルな部分は GCP の他のサービスをフル活用

宣伝

「『みんなの Docker/Kubernetes』という本が出ます！」

(感想)

「GKE でアドテクのレイテンシ要件満たせている」というのが大変興味深かったです。
アドテクだと集計的なある程度時間がかかる job や、機械学習のような GPU 等のデバイスをアタッチするケースがあるはず。
そういった場合の GKE/k8s 活用について機会があったら伺いたい。

コンテナ開発プラットフォームに GKE を選択すべき 7 つの理由

前のセッションで運用面詳しく触れられたので 7→5 つに絞って紹介

理由 1 Security

  • K8s を採用する理由
    • 当初はアジリティでは?
    • エンタープライズで使う場合セキュリティ大事
  • GCP のセキュリティは高く評価されている
  • 今のセキュリティ
    • 昔は「クラウドのセキュリティは心配」
    • 今はセキュリティがクラウドを選ぶ理由になっている
  • GCP のセキュリティ
    • 色々なレイヤーで徹底的な防御がデフォルトで ON
    • ストレージレイヤでのデフォルト暗号化
    • ハードウェアでもセキュリティを重視
      • YouTube で Cloud On Air みてください
  • コンテナのセキュリティ?
    • Infra Security
      • インフラはコンテナを開発するのに安全か?
      • K8s の機能を使って ID,シークレット,ネットワークをどう守るか
      • IAM,Audit Logs,Networking などの機能の活用
    • Software Supply Chain
      • どうコンテナイメージに脆弱性がないことを保証するか
      • ビルドされたイメージが deploy されるまでに改ざんされないことをどう担保するか
    • Runtime Security
      • コンテナが不審な挙動を示した時
      • メモ間に合わず
  • コンテナセキュリティの脅威とリスク
    • インフラ
      • 権限昇格
      • 機密漏えい
    • メモムリ
  • GKE: Use RBAC and IAM
    • プロジェクトレベルで IAM を使う
    • クラスタ/ネームスペースでは RBAC を使う
  • プライベートクラスタと承認済みネットワーク
    • K8s の master も承認済みネットワークのみからのアクセスに限定できる
  • Cloud Armor
    • スケーラブルな WAF
    • DDoS 防御
    • IP アドレス制御
    • LB で WAF を使える
    • BackendConfig(beta)で GKE でも使える
  • Software Supply Chain
    • どうコンテナイメージに脆弱性がないことを保証するか
    • ビルドされたイメージが deploy されるまでに改ざんされないことをどう担保するか
    • CI/CD パイプラインを作っただけでは信頼できない deploy を止めることはできない
    • イメージのメタデータ
      • 意図したところでビルドされたか
      • 意図したテストが実施済みか
    • イメージのメタデータをもとに判断
    • GKE ではどう作れるか?
      • コンテナレジストリの脆弱性スキャン
        • パッチ未適用による脆弱性が多い
      • バイナリオーサライゼーション
        • 検証済みイメージのみがビルドリリースプロセスに乗る
  • Runtime セキュリティ
    • Container Optimized OS
      • GKE のデフォルト
      • セキュアで軽量な OS
      • ChromiumOS ベース
    • Runtime security partners in Cloud SCC (beta)

理由 2 Network

  • ざまざまな GCP サービスとの統合
    • Google Cloud Load Balancing
      • エニーキャスト
        • ユーザーの近いところでリクエスト受けてくれる
    • Google のグローバルインフラを使える
    • Container Native Load Balancing (beta)
      • 通常は、一旦 VM にリクエスト振られるのでダブルホップ問題生じる
      • CN LB 使うとリクエストがダイレクトにコンテナに届く

理由 3 Hybrid Cloud

  • 適材適所
    • ゴール: コードをどこでも実行できる環境を整える
    • とはいえマネージド k8s サービスごとに得手不得手がある
    • K8s のリソースをどう実装するかがマネージド k8s サービスの差別化ポイントになる
    • あるいはオンプレで GPU を購入してるケースなど
  • GCP Solution: GKE On-Prem (beta)
    • オンプレのクラスタを GCP Console から一元的に管理できる
    • オンプレも StackDriver で可観測性を提供
      • Google Fluentd 入れればいけるとかそんな?
  • クラスタ集中管理のメリット
    • 同じツール使える

事例: メルカリさん

  • 元はオンプレのモノリス構成
  • マイクロサービス化
    • 徐々にマイクロサービス化
    • マイクロサービス化が完了したサービスから GKE に乗せていく
  • オンプレで動かした方が良いワークロードはオンプレに残せる
  • 今後
    • オンプレリソースも k8s に寄せて GKE で管理したい
    • Istio 導入したい

理由 4 Observability

  • 可観測性
  • Logging の鍵
    • GCP の内外の情報をどう集めるか
  • Monitoring
    • 単に見せるだけではなく適切なアラートを送る必要
  • 何が課題か
    • モノリスと比べて対象リソースが増える
    • 包括的に Logging/Monitoring する必要がある
    • DevOps/SRE,Dev,SecOps 等の役割ごとに見るメトリクスが違う
  • GCP Solution: Stackdriver
    • Logging/Monitoring を提供する統合基盤
    • Stackdriver k8s Monitoring(beta)
      • K8s のワークロード監視に最適化された Stackdriver のツール
      • ノードの CPU/mem に加えて Pod,コンテナの CPU/mem もみれる、アラートも出せる
      • クリックすると Logging 画面に遷移、同じ画面で Monitoring/Logging 両方みれる
      • 既存の Stackdriver ユーザーも移行できる
      • 新規の場合はボタン 1 つクリックするだけ
  • Works With Open Source: Prometheus
    • Stackdriver とのシームレスなインテグレーション
    • Istio 使った場合は?=>この後のセッションで

理由 5: Contribution

  • Open Source is free like puppy
    • 子犬のようなもの
    • 世話をし続ける必要がある
    • 「k8s の機能を 1 つリリースした」では不十分
  • コンテナと k8s の歴史
    • Google の貢献の歴史
  • GKE はどこにいくのか?
    • GKE is going to …
      • To be Reliable
      • To be Scalable
      • To be Open
  • To be Reliable
    • Regional Cluster GA since Q3’18
    • Regional Persistent Disks(beta)
      • ゾーン障害があっても大丈夫
  • To be Scalable
    • Scalability of GKE
      • Pod/Node 両方の水平/垂直スケーリング
    • Node Auto-Provisioning (beta)
      • 適切なサイズのインスタンスを持つ新しいノードプールを作成
      • 自動?
  • To be Open

(感想)

GCP/GKE の beta を含めたいろいろな機能のご紹介が大変興味深かったです。
今度会社で SA の方を通じて詳しく教えていただこうと思いました。

GKE を用いたレガシーシステムからのリプレース事例

自己紹介

  • FUJIFILM Prints & Gifts のバックエンド作ってる
    • プリントや写真雑貨を注文できるサービス
    • ましかくプリント
      • 手のひらに収まるサイズの正方形の写真
      • フチのパターンをカスタマイズできる
    • WALL DECOR
      • 壁掛け写真
    • 写真雑貨

プロジェクト概要

  • ネットプリントサービスの運用が 10 年越えた
    • 機能改善スピード低下してた
    • ユーザーの消費動向が変わった
    • リプレイスしよう！
    • フロントエンドの動線が複雑
    • 一部商品の合わせ買いができない
    • バックエンドはサブシステム単位で分割されていた
  • リプレイス後
    • フロントエンドの動線をシンプルにした
    • カートが統一された
    • OMS(バックエンド)はマイクロサービス化
      • 中央に GKE、周りにマネージドサービス
      • イベント駆動

GKE 利用までの経緯

  • 富士フィルムの文化
    • See と Think を重要視
    • S->T->PDCA
  • 現状分析
    • 保守コスト増大の原因は?
      • 品質担保難しい
      • 保守要員の学習コスト高い
      • 影響範囲の見極めが難しい
      • モノリシックなアプリケーションだから?
    • 運用コスト増大の原因は?
      • システム構成変更コストが大きい
      • 季節イベントごとの負荷状況に応じたシステム増設コストが大きい
        • 年賀状
    • 別にモノリシックを志向したわけではない
      • 先人も工夫してきたようだが。。
  • 負荷量変動への対応を最優先にする！
    • スケーラビリティ確保しやすい仕組みを最優先にする
    • コンテナを使う
    • 他の問題も解消できそう
    • 機が熟した
    • コンテナを利用した実績がなかった
      • 新技術導入に不安の声もあった
      • チャレンジさせてほしいと説得
  • オーケストレーションツールは使いたい
    • 何が標準か?
      • 流行度
      • ベンダーの覇権争い
      • 仕様策定状況
        • JS フレームワークで辛かった思い出がある
    • 運用できるか?
      • 運用に耐えうるか
      • 自分たちが理解できるか
      • デモではない

(コンテナやオーケストレーションツールの)調査

  • Docker と k8s に絞って調査
    • Docker 社の OSS リリース
    • Google が「すでにコンテナ使ってるよ」リリース
    • Docker, Docker Swarm, k8s など
    • OCI 発足=>標準化進んだ
    • K8s v1.0 が出て CNCF 設立
      • ベンダーロックインなくなった
    • OCI 1.0
    • Docker が k8s サポートを発表
      • => k8s が事実上標準になった
    • AKS, EKS の発表
    • CRI(通信インタフェース)も標準化された
    • デファクトスタンダードが定まった
    • マネージドサービスが整った
  • クラウドベンダーの選定(GKE 選定理由)
    • 日本国内で提供されてる k8s サービスは当時 GKE だけ
    • Google は k8s 開発元で安心
    • マネージド k8s の 4 年以上の安定運用実績

取り組む上での課題(組織面)

  • 周りの理解
    • なんで使うの?
    • 技術的優位性は?
    • 細かくいろいろな質問が出てくる
    • 新技術でスケジュール遵守できる?
  • 近道はなかった
    • 資料作って説明->指摘受けて修正
    • 熱意が必要だった
  • 現場では味方が多かった
    • 10 年ものの構成をみんな良いとは思ってなかった
    • 何れにしてもリプレイスするしかない
    • 相談できた
    • 技術学習の協力が得られた
  • リスクの背負い方
    • 明確な解はなかった
    • バックアッププランの準備と提案
    • 技術習得していることの説明
    • Google のサポート

取り組む上での課題(開発面)

  • 最初の課題は技術習得
    • GKE/GCP/コンテナ/オーケストレーション使用経験なし
      • Azure は使ったことあった
    • 独学+ハンズオンで基礎固め
    • Google エンジニアのサポート
    • トライアンドエラーで学習
      • (GKE は)トライアンドエラーしやすい環境だった
  • 事前調査
    • レガシーシステム自体のルール把握
      • 調査はしたが完全には無理だった
      • 実施してから発覚したこともある
    • 効率的なシステム間連携は知識が必要
      • Pub/sub 連携のイベント発火条件などは当初は無駄が多かった
      • 徐々にリファクタリングしていった
        • よりマネージドサービス活用する構成にしていった
        • 最初からはできなかった
    • 運用
      • ログやアラートは最終的にはなんとかなった
      • メトリクスの書き方はドキュメントだけでは満たせず Google SA に聞いた
    • 設計/設定
      • K8s 設定記述方法
        • Yaml の書き方に慣れるのに時間かかった
  • 基本設計
    • できるだけ細かく分割しようとした
      • 動くものはできた
      • しかし制御不能、指摘も多かった
      • 異常系大変だった
    • ある程度の粒度で分割
      • マイクロサービスの思想は取り入れた
      • 何が何でも分割すればいいというものではない
  • 商用利用に向けての課題
    • マネージドサービスでできる範囲の見極め
    • 監視面は社内の他のシステムと合わせたかった
      • すでにリッチな監視系があった
      • GCP デフォルトでは足りなかった
      • 最終的には Prometheus 使った
  • レガシーシステムとの連携
    • レガシーシステム側を変えることは無理
    • IP アドレス制限や古いプロトコルへの対応が必要だった
    • 当初は不要にできる見込みだったが捨てきれなかった

効果

  • スケーラビリティは確保できた
    • スケールすべきものとしなくてもいいものを分離できた
    • 負荷が高い機能も切り出しやすくなった
    • リージョンまたぎや今後の横展開も行いやすい構成にできた
  • 保守運用コスト削減もできた
    • 影響範囲を限定できた
    • 学習コストも分離できた
    • ランニングコストが 3/5 になった
    • サーバー構築不要になった
    • ログ/アラートが一元管理可能になった
      • 調査しやすい
      • 蓄積できる
    • 導入 8 ヶ月でサービスダウンなし
  • 機能改善スピードも向上した
    • 影響範囲が見極めやすくなった
    • イベント開催にも対応できるようになった

取り組んでみて

  • GKE の学習コストは高かったが得られる効果が大きかったのでコストパフォーマンスは良かった
  • すぐに動かせるのは良かった
  • GCP ドキュメント充実してた
    • 使いこなしはこれから
  • アプリ開発に集中でき、インフラ懸念を大きく払拭できた
    • サービスが死なない(セルフヒーリング)
    • 調査はするが障害復旧に時間取られない
  • 組織の壁は厚い
    • 乗り越えるには熱意
    • 仲間大事
  • Google の人の協力偉大

(感想)

レガシーサービス運用のつらみは大変共感できました。
根回しや各種調整含めて熱意を持って挑まれていて素晴らしかった。

コンテナによる開発と運用の進化

「今日はマイクロサービスの話をします」とのこと。
会場で実際にマイクロサービス作ってる人はまだ少なめだった。
実際にマイクロサービスでサービス提供するには?

製品ライフサイクル

  • ライフサイクル
    • コンセプト
    • ビジネス
    • 開発
    • 運用
    • 一般公開
  • いかにライフサイクルを早く回すか
    • 早く価値を届ける
  • 3 つのポイント
    • 人(ビジネス/技術)
      • CxO, Manager, Business, Tech
      • DevOps, SRE
    • プロセス
      • Scrum(アジャイル), Waterfall
    • テクノロジー
      • クラウド, マイクロサービスアーキテクチャ, CI/CD
  • マイクロサービスアーキテクチャの活用は技術だけではない
  • Change Management
    • 変化をうまく管理していこう
    • 興味があれば Google, Google パートナーがサポートプログラムを提供してるのでお声がけください
    • Cloud Next でも扱ってるよ
  • 今日はテクノロジに絞った話

マイクロサービスとは

  • 2014 年に提唱
    • 機能ごとに独立したアプリケーションに分割
    • 各サービスは単一の目的を持つ
    • 個々のアプリケーションを独立してリリースできる
    • 分散システム
    • サービス間は疎結合
    • 軽量な WebAPI などでやり取り
  • ASIs to ToBe (Monolith to MIcroservice)
    • 新規サービスから
    • 既存サービスを部分的に
      • 実際は大体こちらですよね
      • Domain を抜き出しマイクロサービス化する
        • レコメンドだけ抜き出す
        • ユーザー管理だけ抜き出す
      • もう少し大きく部署相当機能でマイクロサービス化する
        • EC サービス関連だけマイクロサービス化する
      • ビジネス側の関係者が多いとイテレーションが遅くなる
        • 理想は開発チームとビジネスチームが 1:1
  • The Problem
    • 分散アーキテクチャへの移行
      • これまでのモノリシックなアーキテクチャ向けの方法では監視/管理/保護が困難
  • 4 challenges of Microservices
    • プロセス内コミュニケーション → プロセス外コミュニケーション
      • RPC+API Gateway
    • 管理
      • サービスメッシュ
    • マイクロサービス境界とデータサイロ
      • データレイク
    • アプリケーション外のコーディングを減らす
      • CI/CD
      • このセッションのスコープ外
        • F/O さんのセッションで触れられる
  • プロセス外コミュニケーション
    • 呼び出し先マイクロサービスのトラッキングが困難
    • ビルド時に API の不整合を検知できない
    • ルールや技術で工夫してイテレーション速度を担保
    • 宣言的に API を管理
      • REST API (HTTP 1.1)
        • Open API でメッセージフォーマットを定義
        • 互換性管理の竹のガイドライン作成(推奨)
      • gRPC (HTTP 2.0)
        • Protocol Buffers でメッセージフォーマットを定義
        • Language Guide に従うと下位互換性の担保が容易
      • スタブの自動生成
      • バリデーション
    • API のバージョン管理
      • Goo.gl/mgbJv8
      • Google での API バージョン管理ベストプラクティスを公開
      • Cloud Endpoint で実現をサポート
      • セマンティックバージョニングで管理
        • マイナーバージョンアップデートは後方互換性担保
        • メジャーバージョンアップデートは後方互換性なし
    • API 設計ガイド
      • cloud.google.com/apis/design/
    • Cloud Endpoints によるマイクロサービスの実現
      • API Keys -> Cloud Endpoints -> Stackdriver logging -> Visualize
      • Stackdriver logging: API コールのログと API Key を紐づけて管理
      • Visualize: BigQuery + Data ポータル
      • 内部で使ってる gRPC の API を外部向けに REST で提供したりできる
    • 可観測性 w/ GCP(事例)
      • Stackdriver Products
      • Prometheus
      • 通信制御は Istio 使っていきたい

サービスメッシュ

  • サービスメッシュとは?
    • マイクロサービスにするとシステムが複雑化する
    • システム管理を簡略化する
      • サービスディスカバリ
    • サイドカーと呼ばれるネットワークプロクシ
  • Istio
    • Google と IBM が中心に開発
    • OSS
    • プロクシとして Envoy を使う
    • GKE ではボタン押せば使える
  • Istio の価値
    • トラフィックコントロール
      • バージョンを上げた時にローリングアップデートしたい
      • 今までだと LB で制御してた
      • Istio 使うと Istio にお任せできる
      • 旧バージョンに 90%流すとか
    • セキュリティ
      • これまではマイクロサービス間は素通し
      • Istio を使うとマイクロサービス間の通信制御ができる
        • 暗号化もできる
      • Role Based Access Control
        • ユーザーへの認可もできる
    • 可観測性
      • Istio の監視
        • MIxer でテレメトリの収集
          • マイクロサービス間でのトラフィック
      • GUI のインタフェースもある
    • Istio on GCP の機能、ロードマップ
      • Istio on GKE
      • 〜
  • データレイク
    • 各マイクロサービスごとにデータを持つ
    • データがサイロになってしまう
    • 各マイクロサービスから pub/sub に分析に必要なデータを送り込む
    • Pub/sub からデータレイクにデータを集めて分析できる

(Istio / CSM Demo)

(感想)

ようやく Istio が何なのかイメージ湧いた気がします。
Managed Istio と WebUI が大変興味深くて期待。

FreakOut の広告プロダクトでの GKE 活用事例と GKE 新機能の導入について

Google Cloud INSIDe Digital の内容が含まれるとのこと。

自己紹介/会社紹介

  • F/O の CTO やってます
  • 2010 年創業
  • 国内初 DSP
  • 今は DSP 以外も色々やってる
  • グループ全体 632 名, エンジニア 60 名

F/O の広告プロダクト紹介

  • DSP
    • Red(FreakOut DSP)
    • 国内初かつ国内最大級
    • 350,000 Req/sec
    • 20 Billion Req/day
    • 600 Billion Req/month
    • オンプレ 700 台で構成
  • ASE
    • 位置情報マーケティングプラットフォーム
    • 位置情報ターゲティング広告
    • インフラは AWS
  • Red for Publishers
    • アドネットワークを作れるプロダクト
    • アドネットワークの基盤
    • 海外拠点立ち上げ時にアドネットワークをすぐ作れる
    • GCP でホスト
    • 日本では Poets という名前
    • Go+Perl
    • GCP で事例紹介されてる
  • LayApp
    • アプリエンゲージメントプラットフォーム
    • アプリデベロッパーの収益機会最大化支援
    • ユーザーセグメンテーション
    • 機械学習でエンゲージメント配信
    • GCP ＋ ML Engine 使ってる

プロダクション環境での GKE 運用

  • 100%GCP で構成
  • アプリは全部 GKE で動いてる
    • ワークロードごとにクラスタ分けれてる
  • GKE 1.10.11 を使ってる
  • 広告配信、UI、バッチ
  • CronJob (>= k8s 1.8)使ってる
  • カナリアリリース環境を用意
    • 特定の Git ブランチを少量の Pod に deploy して本番トラフィック流せる
  • Stackdriver を活用してる
    • Monitoring
      • Prometheus と併用
      • UI は Grafana 使ってる
        • 見やすい、使い勝手良い
      • k8s Monitoering 導入検討中
    • Logging
      • コンテナのエラーログを集約
      • アラート: pub/sub -> cloud functions -> Slack
    • Profiler
      • 常に最新のコードのプロファイルを可視化、比較
  • BigQuery
    • 全てのアクセスログ、アプリログを集約してる
      • 数十億レコード/day
    • fluend 経由
      • サイドカー
      • ストリームインサート!
      • A/b テストの結果をすぐに集約できる
    • 可視化は re:dash
    • MySQL のマスタデータもインポートしてる
  • Vulnerability scanning(beta)
    • Alpine メインなので対象
    • 脆弱性はリリースタイミングとは別のタイムラインで出現する
    • Pub/sub で通知されるので cloud functions で subscribe して Slack 通知
  • Customize
    • K8s の yaml のカスタマイズができる
    • Kubectl のサブツールとしてマージされた
    • Production/stg/canary など環境ごとの設定を上書きしてる
      • Replicas
      • 環境変数
      • Configmap
  • Other tools
    • Stern
      • 複数コンテナのログを端末で素早く確認できる
      • Tails -F のようなイメージ
    • Kubectx
      • クラスタ切り替え
        • Prod/stg/dev 等
      • 同梱の kubens でネームスペースも切り替え

GKE での CI/CD

  • Tools
    • GitHub
    • CircleCI
    • Cloud Build
    • Cloud Container Registry
    • Cloud pub/sub
    • Cloud … メモれなかった
  • CI のフロー
    • GitHub に push
    • テスト&ビルド
      • CircleCI
      • Cloud Build
        • Master: 本番用
        • Develop: カナリアリリース
    • カナリアリリース
      • エンジニアが手動で 1pod - 数 pods に deploy
      • Spineker とかで自動化できそうだが今の所手動で足りてる
  • CD のフロー
    • GitHUb で PR マージ
    • Build & deploy ( cloud build)
      • Docker build
      • Docker push
      • Kubectl set image
        • kustomize 使いたい
    • Notification
      • Pub/sub への publish
      • メモ追いつかなかった

GKE の新機能を活用した k8s 環境構築

  • VPC native cluster (alias IP)
    • Scale enhancements
    • Hybrid connectivity
    • Better VPC integration
    • Security checks
    • IP address management
  • Cloud Memorystore for Redis
  • Cloud NAT
    • マネージド NAT
    • アウトバウンドの Gateway
    • 要 Private Cluster
    • 外部アクセスの接続元 IP アドレスを限定する
      • IP アドレスの事前登録が必要なケースとか
    • Region, network, subnetwork に Cloud NAT のものを指定
  • Network Endpoint Groups
    • コンテナネイティブな負荷分散が可能
    • Instance Group は iptables を介して pod にルーティングされる
    • NEGs は Pod を直接ターゲットにできる
    • 設定簡単
  • BackendConfig custom resource
    • GKE の ingress コントローラにカスタムリソースを定義できる
      • Balancer Settings
        • タイムアウト設定
        • 接続ドレインタイムアウトの設定
        • Session affinity をクッキーベースにする
      • Cloud Armor
        • DDoS 攻撃からアプリを守る
        • IP アドレスのホワイトリスト/ブラックリスト
          • 社内ツールへのアクセス元 IP アドレス制御
      • Cloud IAP
        • LB に認証機能を追加できる
          • 任意の URL に Google 認証をかけられる
          • E.g. Grafana に認証をかけるなど
      • Cloud CDN
        • キャッシュポリシーの設定を k8s の config で行える
      • Google managed SSL certificates(beta)
        • マネージド SSL(無料)
        • 中身は Let’s Encrypt
        • 自動更新される
        • Ingress アノテーションで紐づける
    • Service と BackendConfig を紐づけて使う

まとめ

  • GCP を活用して複数の広告プロダクトを開発/運用してる
  • アプリは GKE/k8s 上で動いてる
  • 運用に Stackdriver 便利
  • CI/CD の構築も容易(Cloud Build)
  • GKE では GCP の最新機能使える

(感想)

複数の広告プロダクトの開発/運用のお話が大変実践的で勉強になりました。
オンプレ/AWS/GCP と併用されている中で、GCP の認証は Google 認証に寄せられるにしても他のシステムとの認証の連携は大変そうだと感じた。
機会があればこの辺りのお話を伺いたい。

運営周りの感想

運営(いわゆるロジ)周りも素晴らしくて参考になったのでメモしてました。
勉強会やイベントの運営に携わらせていただく機会が多いので参考になる。

  • タイムキープすばらしかった
    • 一番前に居たのでタイムキーパーの方の動きが見えた
    • 登壇者の方みなさん時間ぴったりだった、たぶん
  • 撮影
    • 動画/静止画複数行われていた模様
  • アナウンスが素晴らしかった
    • メインスクリーンに 10 秒おきくらいに必要な情報でる
    • 開始まで繰り返しアナウンス
    • 紙のパンフレットにも案内あり
  • 設備素晴らし

About

Hidenori MATSUKI

🍣 🍶

another website: mazgi.com

TableOfContents

Categories

Tags

google kubernetes