狠狠撸

狠狠撸Share a Scribd company logo

[CEDEC 2018] グローバル スケール コネクテッドゲームを GCP で作ろう！

?
?
S
Samir Hammoudi

本セッションでは、どのように GCP を活用すれば、グローバルかつスケーラブルなコネクテッドゲームを作れるかをご紹介いたします。今回は ２ つのリファレンスアーキテクチャ（ソーシャルゲームとマルチプレイヤーゲーム）を参考にし、エンジニアの永遠のチャレンジである「可用性」や「スケーラビリティ」を満たしながら、ゲームを楽に開発できる環境をご紹介します。

1 of 41
Download to read offline
グローバル スケール コネクテッドゲームを GCP で作ろう！ Samir Hammoudi (Twitter: @ksimir) ゲーム テクニカル スペシャリスト グーグル?クラウド?ジャパン合同会社
Confidential & Proprietary Samir Hammoudi (サミール ハムディ) ゲーム テクニカル スペシャリスト Twitter: @ksimir LinkedIn: https://www.linkedin.com/in/hammoudi/ → スイスで７年間コンスタントとしてプライベートクラウド系のプロジェクトを担当 → 4年前に日本に移住、外資系大手IT ベンダーに入社 → 2016年11月にゲーム会社担当のセールスエンジニアとしてGoogle に入社 → 今は JAPAC でゲームに特化したエンジニアとして、ゲーム会社を支援 → GCP では GKE と Cloud Spanner が大好き！ 自己紹介
Confidential & Proprietary 大规模ゲームタイトルを作る时のチャレンジ リファレンス アーキテクチャ #1: ソーシャルゲーム リファレンス アーキテクチャ #2: マルチプレイヤーゲーム おさらい アジェンダ
大规模ゲームタイトルを作る时のチャレンジ
Confidential & Proprietary グローバルタイトルの３つのチャレンジ スケーラビリティ ゲームがヒットするかを想定する のが非常に難しい 負荷にあわせてスケールする必 要がある サーバエンジニアの一番の 恐怖はバックエンドが負荷に 耐えられないサイズに 設計すること 接続性 ゲームジャンルによって レイテンシにセンシティブな タイト ルがある 例：FPSやMMOなど ?? 世界中のプレイヤー を一緒にプ レイさせることは チャレンジング LiveOps ユーザーリテンションを 向上するには、プレイヤーの 挙動にあわせて、ゲームを常に 進化?改善させる ? よりリアルタイムに プレイヤーの行動を把握するには どうすればいいのか？
Confidential & Proprietary スケーラビリティ - コンピュート DAU Time MAX DAU +10 サーバ -8 サーバ サーバ 2台のみの支払い オンプレだと、Max DAUを耐えるための サーバ 10台の継続的な支払いが必要
Confidential & Proprietary スケーラビリティ - データベース ID User Lvl 1 Sam 99 2 Leo 30 3 Dan 10 4 Pat 40 ID User Lvl 1 Sam 99 2 Leo 30 3 Dan 10 4 Pat 40 ID User Lvl 1 Sam 99 2 Leo 30 3 Dan 10 4 Pat 40 シングル RDB シャードされた RDB NoSQL DB
Confidential & Proprietary スケーラビリティ - 現状の制約 シングル RDB シャードされた RDB NoSQL DB Pros: シンプル Cons: スケールアッ プのみ Pros: スケールアウト Cons: オペレーションの複 雑さ Pros: ネイティブにス ケールアウト Cons: RDB の機能が 不足 (strong consistency, SQL)
Confidential & Proprietary 接続性 - コネクテッドゲーム リアルタイムなマルチプレイヤーゲームは特に、ゲームサーバとプレイヤー間のレイテンシを 最小限にすることがもっとも重要 ポテンシャルの追 加レイテンシはこ こ！
Confidential & Proprietary 接続性 - リアルタイムゲーム リアルタイムのマルチプレイヤーゲームの 1つの要件としては、ゲームサーバとプレイヤー間の 距離を最短にする必要がある
Confidential & Proprietary LiveOps 目的は、プレイヤーの利用動向から、ログを分析し、その結果に基いてゲームの改善や 新規コンテンツの開発につなげること プレイヤー サーバ DWH チャレンジ：どのように利用動向を DWH に持っていくのか？ 求め られる速さは？ リアルタイムか、それとも 定期インポートでいいのか？
リファレンス アーキテクチャ #1 ソーシャルゲーム (スケーラビリティ & LiveOps)
Confidential & Proprietary API Server Cache KVS (Sessions, DB Caching) Database (User data, Master data, Transaction data) Game Score Queue Cache KVS (Leaderboard) Object Storage (Static assets, binary data) Game Score Process ① ② ③ ソーシャルゲームのバックエンド
Confidential & Proprietary 1. プレイヤーは新しいパズルを開始し、 API サーバと通信する 2. データベースの負荷を抑えるために、 API サーバはまずキャッシュ用の KVS を参照して、データが存在 しなければ、データベースにアクセスする 3. パズルが終了したら、データベースに格納されたプレイヤーデータの更新が行われ、平行に API サーバ は新しいスコアを Game Score 用の Queue に入れます What’s happening here?
Confidential & Proprietary GCP でコンピュートのスケーラビリティを解決するのは容易 ● ロードバランサ (HTTP/TCP/UDP) ● オートスケールするインスタンス ● オートスケールするコンテナ スケールするデータベースも GCP では充実している ● Cloud Datastore [NoSQL]：自動スケール Document DB ● Cloud Bigtable [NoSQL]：KVS ● Cloud Spanner [NewSQL]：スケールする RDB スケーラビリティ - GCP のソリューション Compute Engine App Engine Kubernetes Engine Cloud Datastore Cloud Bigtable Cloud Spanner
Confidential & Proprietary 仮想サーバ OS Dependencies Application Code Hardware ベアメタルサーバ OS Dependencies Application Code Hardware コンテナ OS Dependencies Application Code Hardware ゲームインフラの進化
Confidential & Proprietary バージョニング 共有しやすい 再利用 Introspection デプロイ時間の加速 ポータブル Immutable infrastructure Isolation なぜゲームでコンテナを？
Confidential & Proprietary ● “コンテナオーケストレーション ” ○ コンテナ中心のインフラ ● Google の内部システムとコンテナの運用経験にイン スパイアされている ● Runs Anywhere ● 2014年にオープンソース化 ● Kubernetes やクラウドネイティブエコシステムを管理 する CNCF に寄贈 Kubernetes (k8s) とは？
Confidential & Proprietary Kubernetes (k8s) とは？ Google Trends
Confidential & Proprietary 新しいゲームプロジェクトも k8s を選択 Agones Kubernetes 上で構築されたマルチ プレイヤーゲーム向けの OSS ゲーム サーバホスティングとスケーリングサービス Google が Ubisoft と協力して開発 Open Match (coming soon…) Kubernetes 上で構築された OSS の マッチメーカーフレームワーク Google が Unity と協力して開発
Confidential & Proprietary GKE は GCP のマネージド Kubernetes サービス - Pod autoscale (Horizontal Pod Autoscaling) - メトリック (CPU/Memory/Custom) に 基づいて Pod を自動スケールする - Node autoscale (Cluster Autoscaler) - リソースが不足した場合、自動的に ノードを追加する - リソースが余っている場合にも、自動的に ノードを削除する ゲームでのメリット：自動的に API サーバを スケールし、必要な分のみを払う Google Kubernetes Engine & スケーラビリティ Horizontal Pod Autoscaling Cluster Autoscaler
Confidential & Proprietary Cloud Storage Cloud Memorystore (beta) BigQuery RelationalNon-relational Object Warehouse Object storage, data lake Managed Redis Cloud Datastore/ Cloud Firestore (beta) 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 フルマネージド データサービスの Portfolio
Confidential & Proprietary Cloud Spanner = RDB + NoSQL
Confidential & Proprietary What is Cloud Spanner? Google のマネージド?スケーラブル?リレーショナルデータベース?サービス 完全マネージドのグローバルスケールで DB サービス1 2 3 4 ゾーン間?リージョン間の自動 synchronous レプリケーション スキーマ、ACID トランザクション、SQL Google 内部では、既に５年以上の運用経験 (Google 広告, Google Play…)
Confidential & Proprietary ゲームでの Cloud Spanner のメリット Google のマネージド?スケーラブル?リレーショナルデータベース?サービス DB のスケールアウトが１クリック、１秒で可能（イベント対応などに）1 2 3 4 ノードを追加することだけで、パフォーマンスがニアリニアに上がる プレイヤーが少なくなったら、１クリックでスケールイン 高可用性をネイティブで提供： 99.99% SLA (99.999% マルチリージョン)
Confidential & Proprietary Clients API Server Cloud Memorystore for Redis (Sessions, DB Caching) Cloud Spanner (User data, Master data, Transaction data) Game Score Queue Cloud Memorystore for Redis (Leaderboard) Cloud Storage (Static assets, binary data) Game Score Process LB Clients
Confidential & Proprietary API Server Object Storage (Logs)) ① PubSub Worker DWH Worker ② ① ストリーミングモデル ② バッチモデル ソーシャルゲームでのログの処理
Confidential & Proprietary データを DWH に入れるには、GCP に選択肢が複数あります LiveOps - プレイヤーから DWH まで Batch model 1. Cloud Storage → Cloud Functions → BigQuery 2. Cloud Storage → Batch script → BigQuery Streaming model 1. Firebase Analytics → BigQuery 2. Cloud Pub/Sub → Cloud Dataflow → BigQuery 3. Stackdriver Logging → BigQuery 4. Stackdriver Logging → Cloud Pub/Sub → Cloud Dataflow → BigQuery
Confidential & Proprietary DHW Batch Streaming Clients API Server Cloud Storage Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Functions Stackdriver Logging Firebase Analytics LB
Confidential & Proprietary LiveOps - ストリーミングソリューション Firebase Analytics ● Client side logging ● 実装が容易 ● Firebase SDK が必要 ● BQ に入れる直前の ETL は不可能 Stackdriver Logging ● Server side logging ● 実装が容易 (ログをJSON 形式でアプリが出力する ) ● Cloud Pub/Sub に転送す れば ETL は可能 Cloud Pub/Sub + Cloud Dataflow ● Server side logging ● リアルタイムの ETL ● パイプラインを Java か Python でコーディングする 必要がある 実装の複雑さ 柔軟性
リファレンスアーキテクチャ #2 マルチプレイヤーゲーム (接続性)
Confidential & Proprietary Matchmaker Server Manager API Server Cache KVS (Matchmaking) Database (User data, Master data) Dedicated Game Servers Game Score Queue Cache KVS (Leaderboard) Object Storage (Static asserts) Game Score Process Cache KVS (DGS list) ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑧
Confidential & Proprietary 1. クライアントが対戦をリクエスト 2. リクエストは KVS にキャッシュされて、 Matchmaker は他のプレイヤーとマッチする 3. Server Manager から Matchmaker は DGS を依頼し、Server Manager は KVS にアクセスしDGS の情報を取得 4. 空いてる DGS がなければ、Server Manager は新しい DGS をプロビジョンする 5. Matchmaker は Server Manager から取得した DGS の IP/Port をクライアントに返す 6. クライアントは DGS の IP/Port と通信する（TCP か UDP） 7. マッチが完了すると、 DGS は API Server に結果を返す 8. プレイヤーデータは Database と Game Score Queue に同時に更新される 9. Game Score Process はマッチの結果を Leaderboard 用の KVS に Insert する 10. クライアントが Leaderboard をアクセスする際には API Server 経由で KVS からランキングを取得す る What’s happening here?
オンプレや 他のクラウド Google Cloud ネットワーク
17 リージョン 125 POP 低レイテンシ ~120 ms ~100 ms
Confidential & Proprietary Clients Matchmaker Server Manager Cloud Memorystore for Redis Cloud Spanner (User data, Master data) Dedicated Game Servers Game Score Queue Cloud Memorystore for Redis (Leaderboard) Cloud Storage (Static asserts) Game Score Process Cloud Memorystore for Redis (DGS list) TCP/UDP LB LB Leaderboard API Server
- API Server - Matchmaker - Server Manager - Leaderboard - Database ゲームサーバ
おさらい
Confidential & Proprietary グローバルタイトルの３つのチャレンジ スケーラビリティ Google Kubernetes Engine な どのスケールするコンピュートを 利用して、 Cloud Spanner のような スケールする RDB と連携する と、フルスケールする バックエンドを作ることが可能 接続性 API ベースのサービスは一箇所 にまとめて (Matchmaker, Server Manager, API Server) 低レイテンシである Google ネッ トワークをフル活用する GCP の 17 リージョンを 利用して、ゲームサーバは よりプレイヤーに近い場所に配 置する LiveOps ゲームの要件により、 ストリーミングかバッチの モデルを選択する GCP が提供する様々な データの取り込み方法 を 活用し、ログを分析し、 最高のゲームへ進化させる
Google Cloud INSIDE Games & Apps @ Next '18 日 時 : 2018 年 9 月 19 日（水）14:00 - 20:00 場 所 : ビアレストラン ガーデンアイランド　東京プリンスホテル 前庭 参加者募集中! https://goo.gl/hXRwU Q
Confidential & Proprietary Thank you

More Related Content

[CEDEC 2018] グローバル スケール コネクテッドゲームを GCP で作ろう！

  • 1. グローバル スケール コネクテッドゲームを GCP で作ろう！ Samir Hammoudi (Twitter: @ksimir) ゲーム テクニカル スペシャリスト グーグル?クラウド?ジャパン合同会社
  • 2. Confidential & Proprietary Samir Hammoudi (サミール ハムディ) ゲーム テクニカル スペシャリスト Twitter: @ksimir LinkedIn: https://www.linkedin.com/in/hammoudi/ → スイスで７年間コンスタントとしてプライベートクラウド系のプロジェクトを担当 → 4年前に日本に移住、外資系大手IT ベンダーに入社 → 2016年11月にゲーム会社担当のセールスエンジニアとしてGoogle に入社 → 今は JAPAC でゲームに特化したエンジニアとして、ゲーム会社を支援 → GCP では GKE と Cloud Spanner が大好き！ 自己紹介
  • 3. Confidential & Proprietary 大规模ゲームタイトルを作る时のチャレンジ リファレンス アーキテクチャ #1: ソーシャルゲーム リファレンス アーキテクチャ #2: マルチプレイヤーゲーム おさらい アジェンダ
  • 5. Confidential & Proprietary グローバルタイトルの３つのチャレンジ スケーラビリティ ゲームがヒットするかを想定する のが非常に難しい 負荷にあわせてスケールする必 要がある サーバエンジニアの一番の 恐怖はバックエンドが負荷に 耐えられないサイズに 設計すること 接続性 ゲームジャンルによって レイテンシにセンシティブな タイト ルがある 例：FPSやMMOなど ?? 世界中のプレイヤー を一緒にプ レイさせることは チャレンジング LiveOps ユーザーリテンションを 向上するには、プレイヤーの 挙動にあわせて、ゲームを常に 進化?改善させる ? よりリアルタイムに プレイヤーの行動を把握するには どうすればいいのか？
  • 6. Confidential & Proprietary スケーラビリティ - コンピュート DAU Time MAX DAU +10 サーバ -8 サーバ サーバ 2台のみの支払い オンプレだと、Max DAUを耐えるための サーバ 10台の継続的な支払いが必要
  • 7. Confidential & Proprietary スケーラビリティ - データベース ID User Lvl 1 Sam 99 2 Leo 30 3 Dan 10 4 Pat 40 ID User Lvl 1 Sam 99 2 Leo 30 3 Dan 10 4 Pat 40 ID User Lvl 1 Sam 99 2 Leo 30 3 Dan 10 4 Pat 40 シングル RDB シャードされた RDB NoSQL DB
  • 8. Confidential & Proprietary スケーラビリティ - 現状の制約 シングル RDB シャードされた RDB NoSQL DB Pros: シンプル Cons: スケールアッ プのみ Pros: スケールアウト Cons: オペレーションの複 雑さ Pros: ネイティブにス ケールアウト Cons: RDB の機能が 不足 (strong consistency, SQL)
  • 9. Confidential & Proprietary 接続性 - コネクテッドゲーム リアルタイムなマルチプレイヤーゲームは特に、ゲームサーバとプレイヤー間のレイテンシを 最小限にすることがもっとも重要 ポテンシャルの追 加レイテンシはこ こ！
  • 10. Confidential & Proprietary 接続性 - リアルタイムゲーム リアルタイムのマルチプレイヤーゲームの 1つの要件としては、ゲームサーバとプレイヤー間の 距離を最短にする必要がある
  • 11. Confidential & Proprietary LiveOps 目的は、プレイヤーの利用動向から、ログを分析し、その結果に基いてゲームの改善や 新規コンテンツの開発につなげること プレイヤー サーバ DWH チャレンジ：どのように利用動向を DWH に持っていくのか？ 求め られる速さは？ リアルタイムか、それとも 定期インポートでいいのか？
  • 13. Confidential & Proprietary API Server Cache KVS (Sessions, DB Caching) Database (User data, Master data, Transaction data) Game Score Queue Cache KVS (Leaderboard) Object Storage (Static assets, binary data) Game Score Process ① ② ③ ソーシャルゲームのバックエンド
  • 14. Confidential & Proprietary 1. プレイヤーは新しいパズルを開始し、 API サーバと通信する 2. データベースの負荷を抑えるために、 API サーバはまずキャッシュ用の KVS を参照して、データが存在 しなければ、データベースにアクセスする 3. パズルが終了したら、データベースに格納されたプレイヤーデータの更新が行われ、平行に API サーバ は新しいスコアを Game Score 用の Queue に入れます What’s happening here?
  • 15. Confidential & Proprietary GCP でコンピュートのスケーラビリティを解決するのは容易 ● ロードバランサ (HTTP/TCP/UDP) ● オートスケールするインスタンス ● オートスケールするコンテナ スケールするデータベースも GCP では充実している ● Cloud Datastore [NoSQL]：自動スケール Document DB ● Cloud Bigtable [NoSQL]：KVS ● Cloud Spanner [NewSQL]：スケールする RDB スケーラビリティ - GCP のソリューション Compute Engine App Engine Kubernetes Engine Cloud Datastore Cloud Bigtable Cloud Spanner
  • 16. Confidential & Proprietary 仮想サーバ OS Dependencies Application Code Hardware ベアメタルサーバ OS Dependencies Application Code Hardware コンテナ OS Dependencies Application Code Hardware ゲームインフラの進化
  • 17. Confidential & Proprietary バージョニング 共有しやすい 再利用 Introspection デプロイ時間の加速 ポータブル Immutable infrastructure Isolation なぜゲームでコンテナを？
  • 18. Confidential & Proprietary ● “コンテナオーケストレーション ” ○ コンテナ中心のインフラ ● Google の内部システムとコンテナの運用経験にイン スパイアされている ● Runs Anywhere ● 2014年にオープンソース化 ● Kubernetes やクラウドネイティブエコシステムを管理 する CNCF に寄贈 Kubernetes (k8s) とは？
  • 19. Confidential & Proprietary Kubernetes (k8s) とは？ Google Trends
  • 20. Confidential & Proprietary 新しいゲームプロジェクトも k8s を選択 Agones Kubernetes 上で構築されたマルチ プレイヤーゲーム向けの OSS ゲーム サーバホスティングとスケーリングサービス Google が Ubisoft と協力して開発 Open Match (coming soon…) Kubernetes 上で構築された OSS の マッチメーカーフレームワーク Google が Unity と協力して開発
  • 21. Confidential & Proprietary GKE は GCP のマネージド Kubernetes サービス - Pod autoscale (Horizontal Pod Autoscaling) - メトリック (CPU/Memory/Custom) に 基づいて Pod を自動スケールする - Node autoscale (Cluster Autoscaler) - リソースが不足した場合、自動的に ノードを追加する - リソースが余っている場合にも、自動的に ノードを削除する ゲームでのメリット：自動的に API サーバを スケールし、必要な分のみを払う Google Kubernetes Engine & スケーラビリティ Horizontal Pod Autoscaling Cluster Autoscaler
  • 22. Confidential & Proprietary Cloud Storage Cloud Memorystore (beta) BigQuery RelationalNon-relational Object Warehouse Object storage, data lake Managed Redis Cloud Datastore/ Cloud Firestore (beta) 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 フルマネージド データサービスの Portfolio
  • 23. Confidential & Proprietary Cloud Spanner = RDB + NoSQL
  • 24. Confidential & Proprietary What is Cloud Spanner? Google のマネージド?スケーラブル?リレーショナルデータベース?サービス 完全マネージドのグローバルスケールで DB サービス1 2 3 4 ゾーン間?リージョン間の自動 synchronous レプリケーション スキーマ、ACID トランザクション、SQL Google 内部では、既に５年以上の運用経験 (Google 広告, Google Play…)
  • 25. Confidential & Proprietary ゲームでの Cloud Spanner のメリット Google のマネージド?スケーラブル?リレーショナルデータベース?サービス DB のスケールアウトが１クリック、１秒で可能（イベント対応などに）1 2 3 4 ノードを追加することだけで、パフォーマンスがニアリニアに上がる プレイヤーが少なくなったら、１クリックでスケールイン 高可用性をネイティブで提供： 99.99% SLA (99.999% マルチリージョン)
  • 26. Confidential & Proprietary Clients API Server Cloud Memorystore for Redis (Sessions, DB Caching) Cloud Spanner (User data, Master data, Transaction data) Game Score Queue Cloud Memorystore for Redis (Leaderboard) Cloud Storage (Static assets, binary data) Game Score Process LB Clients
  • 27. Confidential & Proprietary API Server Object Storage (Logs)) ① PubSub Worker DWH Worker ② ① ストリーミングモデル ② バッチモデル ソーシャルゲームでのログの処理
  • 28. Confidential & Proprietary データを DWH に入れるには、GCP に選択肢が複数あります LiveOps - プレイヤーから DWH まで Batch model 1. Cloud Storage → Cloud Functions → BigQuery 2. Cloud Storage → Batch script → BigQuery Streaming model 1. Firebase Analytics → BigQuery 2. Cloud Pub/Sub → Cloud Dataflow → BigQuery 3. Stackdriver Logging → BigQuery 4. Stackdriver Logging → Cloud Pub/Sub → Cloud Dataflow → BigQuery
  • 29. Confidential & Proprietary DHW Batch Streaming Clients API Server Cloud Storage Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Functions Stackdriver Logging Firebase Analytics LB
  • 30. Confidential & Proprietary LiveOps - ストリーミングソリューション Firebase Analytics ● Client side logging ● 実装が容易 ● Firebase SDK が必要 ● BQ に入れる直前の ETL は不可能 Stackdriver Logging ● Server side logging ● 実装が容易 (ログをJSON 形式でアプリが出力する ) ● Cloud Pub/Sub に転送す れば ETL は可能 Cloud Pub/Sub + Cloud Dataflow ● Server side logging ● リアルタイムの ETL ● パイプラインを Java か Python でコーディングする 必要がある 実装の複雑さ 柔軟性
  • 32. Confidential & Proprietary Matchmaker Server Manager API Server Cache KVS (Matchmaking) Database (User data, Master data) Dedicated Game Servers Game Score Queue Cache KVS (Leaderboard) Object Storage (Static asserts) Game Score Process Cache KVS (DGS list) ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑧
  • 33. Confidential & Proprietary 1. クライアントが対戦をリクエスト 2. リクエストは KVS にキャッシュされて、 Matchmaker は他のプレイヤーとマッチする 3. Server Manager から Matchmaker は DGS を依頼し、Server Manager は KVS にアクセスしDGS の情報を取得 4. 空いてる DGS がなければ、Server Manager は新しい DGS をプロビジョンする 5. Matchmaker は Server Manager から取得した DGS の IP/Port をクライアントに返す 6. クライアントは DGS の IP/Port と通信する（TCP か UDP） 7. マッチが完了すると、 DGS は API Server に結果を返す 8. プレイヤーデータは Database と Game Score Queue に同時に更新される 9. Game Score Process はマッチの結果を Leaderboard 用の KVS に Insert する 10. クライアントが Leaderboard をアクセスする際には API Server 経由で KVS からランキングを取得す る What’s happening here?
  • 36. Confidential & Proprietary Clients Matchmaker Server Manager Cloud Memorystore for Redis Cloud Spanner (User data, Master data) Dedicated Game Servers Game Score Queue Cloud Memorystore for Redis (Leaderboard) Cloud Storage (Static asserts) Game Score Process Cloud Memorystore for Redis (DGS list) TCP/UDP LB LB Leaderboard API Server
  • 37. - API Server - Matchmaker - Server Manager - Leaderboard - Database ゲームサーバ
  • 39. Confidential & Proprietary グローバルタイトルの３つのチャレンジ スケーラビリティ Google Kubernetes Engine な どのスケールするコンピュートを 利用して、 Cloud Spanner のような スケールする RDB と連携する と、フルスケールする バックエンドを作ることが可能 接続性 API ベースのサービスは一箇所 にまとめて (Matchmaker, Server Manager, API Server) 低レイテンシである Google ネッ トワークをフル活用する GCP の 17 リージョンを 利用して、ゲームサーバは よりプレイヤーに近い場所に配 置する LiveOps ゲームの要件により、 ストリーミングかバッチの モデルを選択する GCP が提供する様々な データの取り込み方法 を 活用し、ログを分析し、 最高のゲームへ進化させる
  • 40. Google Cloud INSIDE Games & Apps @ Next '18 日 時 : 2018 年 9 月 19 日（水）14:00 - 20:00 場 所 : ビアレストラン ガーデンアイランド　東京プリンスホテル 前庭 参加者募集中! https://goo.gl/hXRwU Q