元RX-7乗りの適当な日々

デブサミ2018「Kubernetesを用いた最強のマイクロサービス環境をGKEで実現しよう」講演メモ #devsumi

IT

Googleのパワーを強く感じられるセッション。さすがでございました。そのセッションのメモでございます。

• 福田 潔 氏
  • Google Cloud Japan
  • Customer Engineer
• GKE = Google kubernetes Engine

他のクラウドと比べてGoogleが勝っている点3つ

• ビッグデータ関連での利用
• ML/AIでの利用
• コンテナの利用

kubecon 2017 keynote => 「kubectl is the new ssh...」

• kubernetesの世界では、低レイヤを気にしなくてよくなる
• kubectlは、これからのエンジニア全員が覚えるべきコマンドである

なぜkubernetesが注目されるのか

• VM => コンテナ => コンテナオーケストレータ
  • アプリケーションのコンテナ化が進んでいる
• モダンアプリケーションのインフラとして

コンテナオーケストレータ

• Dockerだけではできないこと
  • 複数のノードに対するコンテナのデプロイは？
  • ノード障害が発生した場合は？
  • コンテナ障害は？
  • アップデートは？

モダンアプリケーション

• デジタル空間でのビジネスが当たり前になっているので、ネットを通じて顧客接点となるアプリは非常に重要
• 使いにくいアプリは顧客獲得機会の損失を意味する
• 要件
  • ユーザビリティ、24/7、アジリティ、性能、マルチデバイス
• それを支える技術要素
  • 自己修復能力、モジュール化、スケール、リリースパイプライン、Blue/Green、カナリアデプロイ、ロールバック、モニタリング
• これらをkubernetesは機能としてほぼ持っている

kubernetesとは

• クーバネティス
• ギリシャ語で「操舵手」「統治者」といった語が語源
• コンテナをどこで実行するのかを管理
• Googleの社内システムからインスピレーション
• 100%オープンソース
  • 様々な企業が開発に携わっている
• Write Once Run Anywhere
• 複数のコンテナランタイムをサポート

デファクトスタンダードへ

• MSとAWSがkubernetesに対応した
• 3大クラウドベンダ全てがkubernetesにコミットしている
• CNCFによって32個の認証プラットフォームを認定

Google kubernetes Engine (GKE)

• GCP上で動作するマネージドkubernetes
• 2014年に登場
• アルファクラスタ機能
• Zero-Opsクラスタを目指す
  • GKEのランタイムはGCEで出来ている
  • GCEにSSHする必要はない = VMは気にしなくて良い
• 特徴
  • 簡単 (Simple)
  • 信頼性が高い (Reliable)
  • 効率性 (Efficient)
  • GCP各サービスとの統合 (Integrate)
• クラスタはgcloudコマンドかGUIコンソールから、4〜5分で作成可能
• クラスタへの接続はGUIコンソールから案内される
  • 5分後にはkubectlが実行できる

クラスタのアップグレード

• kubernetesはおよそ3ヶ月に1度マイナーバージョンアップ
• マスタとノード、両方のバージョンを気にする必要がある
• マスタは自動でアップグレードされる
• アップグレードスケジュールは、Release Noteに公開

ノードの自動アップグレード

• 管理オーバーヘッドが少なくなる
• セキュリティの強化
• 新しい機能へのアクセス
• 設定は、コマンドかGUIでフラグをつけるだけ

メンテナンスウィンドウ

• 自動アップグレードのタイミングを制御できるように、マスタ・ノードともに特定の曜日、4時間単位で設定が可能

マスターのearly upgrade

• 自動アップグレードを待たず、いち早くアップグレードさせることも可能
• 手動でコマンドを実行する感じ

ノードのヘルスチェック・自動修復

• マスターはノードのヘルスチェックを10秒間隔で行なっている
• 継続的にヘルスチェックを行い、長時間（10分前後）ヘルスチェックに失敗すると修復プロセスを開始する(COSを洗濯した場合)
• マニュアルでヘルスチェック・修復させることもできる

マルチゾーンクラスタ

• デフォルトでは指定したゾーンに対してクラスタマスターとノードが作成される
• 追加のゾーンを指定することもできる
  • 新規作成時や既存クラスタに設定可能

リージョナルクラスタ

• ノードだけではなく、マスタも複数ゾーンに分散できる
  • マスタも冗長化できる
  • ただしまだベータ扱い
• GKEでは、現状マスタには課金されないので、使えるなら美味しそう

COS = Container-Optimized OS

• OSイメージの選択肢はCOSまたはUbuntu
• COS：Docker利用に最適かされた軽量OS

GKEにおけるスケール戦略

• ポッドレベル (kubernetes)
  • SO(スケールアウト)はPod数を制御(HPA)、SU(スケールアップ)はPodに対するリソース割り当てを制御(VPA)
• クラスタレベル (GKE)
  • SOはNode数を制御(クラスタオートスケーラ)、SUはNodeのリソース割り当て（インスタンスタイプ）を変更

• クラスタサイズの変更はコマンドで簡単にできる
• クラスタオートスケーラでは、同じ種類のノードがスケールしていく（ノードプールに設定されたノードテンプレートが使用される）

VMインスタンスタイプの変更

• 既存インスタンスを無停止で変更することはできない
• 新しいノードプールを作成し、そのプールに既存のワークロードを移行する
• ダウンタイムなしでワークロードを移行することも可能

プリエンプティブルVM

• 中断される可能性がある
• 非常に安価に利用可能
• 任意のマシンタイプ

• ワークロードによっては、VMのコストを大幅に下げることもできる
• 作り方はフラグをつけるだけ

GKEにおけるGCPの役割

• GKEクラスタの実行基盤
  • ノード => GCE、永続ディスク
  • ノードプール => Instance Group
  • Service/Ingress => TCP/UDP/HTTP(s) LB
  • VPC
• アドンコンポーネントをマネージメントサービスとして提供
  • データストア => cloud spanner, Cloud Datastore, Cloud SQL
  • DWH => BigQuery
  • メッセージング => Cloud PubSub
  • 運用管理
  • CI/CD

メルカリ導入事例

「ロードバランサとGKEが導入の決め手」

GCPのロードバランサ

• アプリケーションフロントエンドは強力なLBが必要
• グローバル負荷分散：クロスリージョン フェイルオーバー
  • リージョンがダウンしても別リージョンにルーティングしてくれる
• Googleのグローバルインフラ
  • LBはエッジで動いていて負荷分散している
  • 世界各地にエッジポイントが存在する
  • エッジ + バックボーン = 低レイテンシ = 優れたUX

Permalink | コメント(0) | トラックバック(0)