Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Cloud OnAir] Google Kubernetes Engine と Cloud Spanner の紹介 2020 年 1 月 30 日放送

384 views

Published on

今話題の Google Kubernetes Engine と Cloud Spanner の基本を解説していきます。噂は聞いていたけどまだ触ったことのない方、これから勉強しようと思っていた方、ぜひこの放送をご覧ください。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[Cloud OnAir] Google Kubernetes Engine と Cloud Spanner の紹介 2020 年 1 月 30 日放送

  1. 1. Cloud Onr Cloud OnAir Cloud OnAir Google Kubernetes Engine と Cloud Spanner の紹介 2020 年 1 月 30 日 放送
  2. 2. Cloud OnAir Cloud OnAir Google Kubernetes Engine 入門
  3. 3. Cloud OnAir 1 2 Agenda Cloud OnAir コンテナと Kubernetes Google Kubernetes Engine (GKE) vs Kubernetes
  4. 4. Cloud OnAir Cloud OnAir コンテナと Kubernetes
  5. 5. Google では 10 年間に渡り、すべてのサービスを コンテナで動かしてきた 毎週 40 億以上のコンテナを立ち上げている Images by Connie Zhou
  6. 6. Cloud OnAir Google はワークロードを 運用チームの 10 倍早く 成長させた Core ops team Number of running containers コンテナは運用を楽にする
  7. 7. Cloud OnAir コンテナはアプリケーションコードと その依存性を 1 つのユニットとしてまとめる これにより、アプリケーションとインフラを 疎結合にすることができる - コンテナはアプリケーションとその依存性が まとまっているため、例えば、開発環境、 テスト環境、本番環境をまたいだデプロイが 容易になる - オンプレミス、プライベートクラウド、 パブリッククラウド等、異なる実行環境間の 移動が容易になる コンテナ イメージ 依存性 アプリケーション コード コンテナとは
  8. 8. Cloud OnAir 軽量 仮想マシンに比べて 軽量でシンプル 数十ミリ秒で起動 ポータブル 様々な実行環境に対応し、 デプロイメントが容易 効率性 リソース使用量が少なく、コ ンピュートリソースを 細分化して効率的に 利用可能 なぜコンテナ?
  9. 9. Cloud OnAir Node Node Cluster Node ??? ● 複数の Node にどうやってコンテナをデプロイする? ● Node がダウンしたらどうする? ● コンテナに障害が発生したらどうする? ● アプリケーションの更新はどうする? ● コンテナ間の通信はどうする? コンテナ コンテナ コンテナ コンテナコンテナ コンテナ コンテナ管理の課題
  10. 10. Cloud OnAir Kubernetes κυβερνήτης: Greek for “pilot” or “helmsman of a ship” the open source cluster manager from Google Kubernetes
  11. 11. Cloud OnAir Kubernetes (k8s) とは オープンソース のコンテナ オーケストレーションシステム Google 内部で使われている Borg を参考に開発 Kubernetes とはギリシャ語で操舵手の意味 略称は “k8s” Go 言語で書かれている https://kubernetes.io/ Source: CNCF, https://gke.page.link/KubernetesCompanyContributions
  12. 12. Cloud OnAir ● コンテナをホストする (コンテナを動かす) ● コンテナのスケジューリング (どこに配置するか決める) ● (負荷が増えたら) オートスケーリング ● (壊れたら) オートヒーリング ● (新しいアプリに置き換えたい) ローリング アップデート Kubernetes は拡張性が高いのも特徴の 1 つ Custom Resource Definition (CRD) を使うことで比較的容易に 独自機能を追加することが出来る Kubernetes が主に出来ること
  13. 13. Cloud OnAir Kubernetes のアーキテクチャ Scheduler Controller Manager API Server etcd kubelet Container Engine Pod (Containers) K8s の設定 kubectl / API Kubernetes Master Kubernetes Nodes kube-proxy
  14. 14. Cloud OnAir Cloud OnAir Google Kubernetes Engine (GKE) vs Kubernetes
  15. 15. Cloud OnAir Google Kubernetes Engine (A.K.A. GKE) Google が提供する Kubernetes のマネージド サービス ● 素早く k8s のクラスタを作成、利用開始可能 ● Master の管理は全て Google が行い、 お客様は Node の費用のみ負担頂く GCP の各種サービスとのインテグレーション ● Network services (HTTP(S) LB, NW LB, VPC) ● CI / CD (Cloud Build) ● Logging / Monitoring (Stackdriver)
  16. 16. Cloud OnAir GKE のアーキテクチャ Master SLA 付きのフルマネージド Google 管理のプロジェクトで動作 課金対象外 Auto-Everything 任意で選択可能 $gcloud $kubectl Node pool Nodes Node pool Nodes Node pool Nodes
  17. 17. Cloud OnAir Node の OS は Container-Optimized OS (COS) もしくは Ubuntu が選択可能 Node Pool は 1 つのクラスタ内で同じ 構成を持ったノードのサブセット よくある構成 ● ステートフルなアプリ向けの Node pool ● バッチジョブはプリエンプティブルVM の Node pool で Node と Node Pool Master 1 CPU 3.75 GB RAM 1 Nvidia V100 GPU 16 CPU 64 GB RAM Preemptible VM Node pool Nodes Node pool Nodes
  18. 18. Cloud OnAir Auto-Everything k8s をスケーラブルに使うために必要なものが全て自動化されている ● Auto-repair ○ パフォーマンスに問題があったり故障した Nodes を自動的にリプレイス ● Auto-upgrade ○ Nodes の Kubernetes / GKE バージョンを常に最新版に自動的に更新 (無効化も可能) ● Auto-scale (Cluster Autoscaler) ○ 需要に応じて Node pool 内の Nodes 数を自動的に増減 ● Auto-provision (beta) ○ Cluster Autoscaler の一部として動作し、リソースに最適な Node pool を作成・削除
  19. 19. Cloud OnAir ● Kubernetes のマスターを 同一 リージョン内の 3 つのゾーンで持つ ● Kubernetes API に対する 99.95% の SLA ● デフォルトで 3 つのゾーンで Node を配置、1 から 4 まで 選択可能 ● マスター側のメンテナンスが あってもサービス断なし Regional Clusters Zone BZone A Zone C Regional Control Plane Nodes Nodes Nodes
  20. 20. Cloud OnAir Public IP を持たない Nodes を 利用可能。 Master は Public IP を持つ必要が あるが、Firewall で許可された ネットワークからのみアクセス 可能。 Private Cluster Master Nodes
  21. 21. Cloud OnAir HTTP(S) ロードバランサーから 直接 Pod の IP を参照 “double-hop” 問題を解決 Latency とルーティング性能を改善 VPC-native clusters かつ kubernetes version 1.10+ で 利用可能 Container Native Load balancing Master CC Nodes C Nodes
  22. 22. Cloud OnAir GCP の各種サービスとのインテグレーション ● Cloud IAM / Workload Identity → クラスタのアクセス制御、クラスタ内は RBAC で ● Stackdriver Monitoring & Logging → One click で Monitoring と Logging を設定 ● Network Route , FW & Load Balancers (ingress) → HTTP LB, TCP / UDP LB, Route & FW ルールを自動的に作成 ● Persistent Disk (PDHDD & PDSSD) → Stateful アプリケーションも PDHDD & PDSSD でサポート → ReplicaSet でも自動 PD のプロビジョニング ● GCP コンソールに Dashboard インテグレーション
  23. 23. Cloud OnAir Cloud OnAir Cloud Spanner の技術概要
  24. 24. Agenda Cloud OnAir 1 3 2 概要 Cloud Spanner のキーコンセプト Cloud Spanner のトランザクション
  25. 25. Cloud OnAir NewSQL とは? リレーショナルデー タベース構造 水平方向の スケーラビリティ +
  26. 26. Cloud OnAir データベース ポートフォリオ Cloud Storage Cloud Memorystore BigQuery RelationalNon-relational Object Warehouse Object storage, data lake Managed Redis Cloud Datastore / Cloud Firestore Serverless scalable document store Cloud Bigtable Low latency, scalable wide column store Cloud SQL Managed MySQL & PostgreSQL Cloud Spanner Scalable mission-critical RDBMS Enterprise data warehouse In-memory
  27. 27. Cloud OnAir Cloud Spanner: the best of RDBMS + NoSQL
  28. 28. Cloud OnAir Cloud Spanner とは? Google のマネージド・スケーラブル・リレーショナルデータベース・サービス 完全マネージドのグローバルスケールで DB サービス1 2 3 4 ゾーン間・リージョン間の自動 synchronous レプリケーション スキーマ、ACID トランザクション、SQL Google 内部では、既に 7 年以上の運用経験 (AdWords, Google Play…)
  29. 29. Cloud OnAir Cloud OnAir Cloud Spanner のキーコンセプト
  30. 30. Cloud OnAir リージョナル & マルチリージョン構成 Asia Pacific Americas Europe, Middle East, & Africa Tokyo Taiwan Mumbai Singapore Current regions Netherlands Finland Belgium Los Angeles Iowa N. Virginia S. Carolina MontrealOregon
  31. 31. Cloud OnAir シングルリージョン Cloud Spanner instance Zone A Zone B Zone C DB 1 DB 2 DB 1 DB 2 DB 1 DB 2 ● 1 ノードごとに 3 つのレプリカ
  32. 32. Cloud OnAir マルチリージョン Zone A RW - Replica US region 1 (Default Leader) Zone B RW - Replica Zone A RW - Replica US region 2 Zone B RW - Replica Zone A Witness US region 3 (Witness) Write Quorum (US) Asia Region Europe Region Zone A RO - Replica Europe region 1 Zone B RO - Replica Zone A RO - Replica Asia region 1 Zone B RO - Replica ● 例えばこの 3 大陸の構成では 9 つのレプリカ ※ us-central2 はプライベート GCP リージョンです
  33. 33. Cloud OnAir SLA シングルリージョン (SR) 99.99 % マルチリージョン (MR) 99.999 %
  34. 34. Cloud OnAir Cloud Spanner の時刻同期(TrueTime API) US Datacenter EU Datacenter Time MastersTime Masters 時刻同期 時刻同期 原子時計 原子時計 GPS受信機 GPS受信機 Spanner Node Spanner Node Spanner Node Spanner Node Spanner Node Spanner Node Time Masters Armageddon Masters GPS Masters
  35. 35. Cloud OnAir 同期レプリケーションと強整合性 Data is synchronously replicated using Paxos consensus. Update Cloud Spanner instance Zone A Zone B Zone C DB 1 DB 2 DB 1 DB 2 DB 1 DB 2
  36. 36. Cloud OnAir Split はデータが格納される単位 ゾーン 1 Node1 Node2 Node3 Split Split Split Split Split Split ゾーン 2 Node1 Node2 Node3 Split Split Split Split Split Split ゾーン 3 Node1 Node2 Node3 Split Split Split Split Split Split
  37. 37. Cloud OnAir Split とは? ● テーブルは主キーでソートされる ● テーブルは主キー範囲で分割される ● Split は負荷とサイズに応じて分割される
  38. 38. Cloud OnAir Split のレプリケーション ゾーン 1 Node1 Node2 Split ( a ~ f ) Split ( g ~ k) Split ( l ~ s) Split ( t ~ z ) ゾーン 2 Node1 Node2 ゾーン 3 Node1 Node2 Split ( a ~ f ) Split ( g ~ k) Split ( a ~ f ) Split ( g ~ k) Split ( l ~ s) Split ( t ~ z ) Split ( l ~ s) Split ( t ~ z ) Paxos グループ
  39. 39. Cloud OnAir Cloud Spanner のスキーマ & データモデル プライマリキー(PK) ○ 各テーブルに PK が必須 ○ PK は 1 つか複数のカラムでもOK ○ ルートテーブル以外の子テーブルはその親を 含む祖先テーブルのPK を必ず持つ ○ 子テーブルの PK は、親テーブルの PK と同じ順を持つ CREATE TABLE Users ( UserId STRING(36) NOT NULL, LastAccess TIMESTAMP, Point INT64, StartDate DATE, UserName STRING(100), ) PRIMARY KEY (UserId) TIPS:Auto-increment は HOTSPOT になるので、PK には UUIDv4 にしよう!
  40. 40. Cloud OnAir Hotspot とは?
  41. 41. Cloud OnAir Cloud Spanner のスキーマ & データモデル インターリーブ (親子関係) ● データベースには複数のテーブルを定義できる ● データを物理的にコロケーションしたい場合 ● 最大で 7 階層まで CREATE TABLE UserItems ( UserId STRING(36) NOT NULL, ItemId STRING(36) NOT NULL, Num INT64 NOT NULL, ) PRIMARY KEY (UserId, ItemId), INTERLEAVE IN PARENT Users ON DELETE CASCADE
  42. 42. Cloud OnAir インターリーブした場合のデータのロケーション インターリーブした場合インターリーブしない場合
  43. 43. Cloud OnAir セカンダリインデックス ○ インデックスに保持される値 ■ 定義した値 ■ 元テーブルの主キー ■ STORING に定義した値 ○ インターリーブが可能 ○ STORING 句を使うことで、 定義したデータをインデックスに 含めることが可能。 CREATE INDEX SongsBySingerAlbumSongNameDesc ON Songs(SingerId, AlbumId,), INTERLEAVE IN Albums Cloud Spanner のスキーマ & データモデル TIPS: Cloud Spanner でインデックスもテーブルなので、 HOTSPOT が発生する可能性があるので注意!
  44. 44. Cloud OnAir Cloud OnAir Cloud Spanner のトランザクション
  45. 45. Cloud OnAir Cloud Spanner のトランザクションと処理の方法 ● 読み書きトランザクション(セルのロック) 1 つ以上の読み取り結果に応じて 書き込みを行う必要がある場合、 読み書きトランザクションの中で 読み書きを実行する必要があります。 ● 読み取り専用トランザクション(ロックなし) データの一貫したビューを取得するために、 複数の読み取り呼び出しを行う場合、 読み取り専用トランザクションの中で 読み取りを実行する必要があります。 Read A Write A commit Read A Read B
  46. 46. Cloud OnAir Cloud Spanner におけるデータの書き込みとロック ● 事前にデータの読み取りせずに、書き込みを行う場合(Blind write) ○ ライター共有ロックと呼ばれる共有ロックを用いる ○ コミット タイム スタンプの順に順序が決定される ● 読み書きトランザクション ○ 読み書きトランザクションを利用する場合、データを読み取る タイミングでは共有ロックが行われる。実際に書き込みを行う際に、 排他ロックを取得し書き込みを行う
  47. 47. Cloud OnAir トランザクションを必要としない読み取り ● Strong Read ○ 現在のタイム スタンプでの読み取りであり、この読み取り処理の 開始時までに commit されたすべてのデータを確実に確認できます。 Cloud Spanner のデフォルトでは、Strong Read を使用して 読み取りリクエストが処理されます。 ● Stale Read ○ 過去のタイムスタンプによる読み取りです。レイテンシの影響を 受けやすいものの古いデータは許容できるアプリケーションの場合、 Stale Read を使用するとパフォーマンスが向上することがあります。
  48. 48. Cloud OnAir データの書き込みの方法 ● DML トランザクション内で処理を実行します。 ● Mutation API トランザクションを利用した書き込み、Blind write の両方が利用可能。 Insert_or_update などの Mutation にしかない存在しないAPI があります。 ● 注意事項 同一のトランザクション内でDML と Mutation API を同時に指定しない。 処理が実行されるタイミングが異なっており、DML が先に実行されます。
  49. 49. Cloud OnAir データ更新後のデータの読み取りについて Mutation を利用する場合 トランザクションの開始 1.データ A の検索 2.データ A を B に変更 3.データ B の検索 トランザクションの完了 ● 「3.データ B の検索」を実行した タイミングでは、更新後のデータを 検索することができない。 ● トランザクションの完了後 ( Commit が完了した後 ) で再度検索を 行う必要がある。 ● Cloud Spanner クライアントが変更の 状態を内部に保存し、Commit の タイミングで Mutation をサーバに 送信する。
  50. 50. Cloud OnAir DML を利用する場合 トランザクションの開始 データ A の検索 データ A を B に変更 データ B の検索 トランザクションの完了 ● 「3.データ B の検索」を実行した タイミングでは、更新後のデータを 検索することが可能。 ● DML の場合には、サーバサイドで 変更状態をバッファリングするため、 コミットする前のデータを 同一トランザクション内で 参照することが可能。 データ更新後のデータの読み取りについて
  51. 51. Cloud OnAir トランザクション処理と利用ケース ● トランザクションを必要としない読み取り ○ 単一のデータ読み取り ○ 複数回データを読み取る際に、一貫性を必要としない場合 ● トランザクションを必要としない書き込み ○ 単一行の書き込み ● パーティション化DML ○ データの一括更新、削除など、トランザクションの制限を超えて 処理を実行したい場合 ● 読み書きトランザクション ○ データの読み込みの結果に応じて書き込みを実行する場合 ● 読み取り専用トランザクション ○ 複数のデータの読み取りで一貫したビューが必要となる場合
  52. 52. Cloud OnAir Cloud Spanner の利用方法 ● Google Cloud Console ● gcloud CLI ● gRPC API ○ Cloud Spanner Client Library for Go ○ Cloud Spanner Client Library for Java ○ Cloud Spanner Client Library for Node.js ○ Cloud Spanner Client Library for Python ○ Cloud Spanner Client Library for PHP ○ Cloud Spanner Client Library for Ruby ○ Cloud Spanner Client Library for C# ○ Cloud Spanner Client Library for C++ (Beta) ● REST API ● JDBC driver (Google + 3rd party)
  53. 53. Cloud OnAir Cloud OnAir お客様事例 Colopl, Inc. 様 / SQUARE ENIX 様
  54. 54. Cloud OnAir DRAGON QUEST WALK 2019 年 9 月 12 日リリース 2 ヶ月で 1000 万 DL を突破 © 2019 ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved.
  55. 55. Cloud OnAir 株式会社コロプラ 様 ● 2017 年に GCP 移行を開始し、全てのタイトルを GCP 上で運用 ● 2018 年夏以降のタイトルに GKE + Spanner 構成を採用 ○ 以降のタイトルでも、同様の構成 ● 2019 年リリースのドラゴンクエストウォークでも GKE + Spanner 構成 ○ ユーザー系 Database は全て Cloud Spanner で運用 ○ 10,000+ Pods on GKE

×