ゲームに関する API +データベース サーバーの構築パターン
Embedded Files
多くのクライアント / サーバー型のゲーム アーキテクチャは、高度なゲーム機能を提供するサーバーのインターフェースとなる API サーバーと、プレイヤーのゲームデータを記録するデータベース サーバーによって構成されます。
ゲームにおける API + データベース サーバーを構成する際の考慮事項として、予想されるワークロードだけでなく、予期しないトラフィックの急増に対するスケーラビリティについても検討すべき点があげられます。
具体的には以下のようなシナリオです。
新規ゲームのローンチ時における大量ユーザーの流入
毎日のピークタイムにおけるアクティブ ユーザーの一時的な増加
ゲーム内イベントにおけるユーザー アクセスのスパイク
ゲームが広く普及することによるユーザー アクセスの増加
予想されるプレーヤー数に基づいてシステムを設計しテストを行ったとしても、予期しない負荷急増への対応ができていない場合には、信頼性のあるサービスの提供はできなくなります。場合によっては、API + データベース サーバーの高負荷が原因でゲームが利用不能になり、ユーザーが離れる結果を招いてしまいます。
強固な API + データベース サーバーを構成するうえでは、サービス拒否攻撃や不正なパケットからの保護についても考慮が必要です。API サーバーは、クライアントが直接、または負荷分散層を介してやり取りするインターフェースとなるため、セキュリティと信頼性の問題を解決する必要があります。また、データベース サーバーは通常、API サーバーなど信頼できるコードからのみアクセス可能となるようにアクセス制御をするべきです。
Google Kubernetes Engine + Cloud Spanner パターン
Google Kubernetes Engine + Cloud Spanner パターン
解決する課題・使い所
一口にゲーム向けの API サーバーのホスティングといっても、ゲームにおいては様々な要件が発生することがあります。例として、
アプリケーション ランタイム（開発言語）の制約
サービス拡大に向けた様々な新機能の追加、マイクロ サービスの管理
課金基盤などの外部システムとの連携
メンテナンス実施タイミングの調整
カスタマイズ性の高いデプロイメント
強力なスケーラビリティ
などが挙げられます。API サーバーをホスティングする際の Google Cloud の製品の主な選択肢としては、Google App Engine、Cloud Run、Compute Engine、そして Google Kubernetes Engine（GKE）が考えられますが、それらの選択肢のなかでも、特に大規模なタイトルの運用や上記のような要件を見据えた柔軟なゲーム インフラを構築したい場合には、GKE が適しています。GKE はコンテナベースのオーケストレーション システムである Kubernetes のクラスタを構成し管理するマネージド サービスです。
次に、複雑なデータアクセスが想定されるゲームのデータベースとしてリレーショナル データベースが検討される際には、前述のような、ゲーム運営において起こりうる急激なユーザやトラフィックの増減に対応することのできるデータベースが求められてきます。水平方向にスケール可能なフルマネージドのリレーショナル データベースである Cloud Spanner は、このようなゲームのユースケースにおいて最も適したデータベース ソリューションです。
利点
スケーラビリティ / システムの可用性
24 時間 365 日提供されるゲームのサービスにおいて、システムのダウンタイム、メンテナンス時間を極小化することは、非常に重要なテーマです。
GKE は、マネージドの Kubernetes クラスタのため、自動修復をはじめとした Kubernetes 自体の持つ機能をサポートしているだけでなく、Kubernetes マスタの自動管理も行なっています。可用性を向上させるためには、GKE クラスタはリージョン クラスタモードで作成して、Kubernetes マスタを冗長化し、Kubernetes のノードはリージョン内の複数ゾーンに分散して配置することが推奨されます。
Cloud Spanner はマネージド サービスで運用されており、通常のデータベースの運用で想定されるバージョンアップやパッチ当て作業といったダウンタイムを伴うメンテナンスは発生しません。Cloud Spanner インスタンスはリージョン構成、またはより可用性の高いマルチリージョン構成から選択することが可能です。
GKE と Cloud Spanner の SLA は以下をご参照ください。
スケーラビリティ
GKE のノードは Cluster Autoscaler を用いることでオートスケールすることが可能です。大規模に Kubernetes の Pod や GKE Node を構成する場合の、クラスタ毎における割り当てと上限は以下をご参照ください。
また、単一の GKE クラスタには収まりきらないような、大規模・グローバルに展開するサービスにおいては、Ingress for Anthos を用いて、Cloud Load Balancing 配下に複数の GKE クラスタを構成し、ユーザーから最も近い GKE クラスタにロード バランシングをする構成も選択肢として考えられます。
Cloud Spanner は、水平方向にスケールする分散データベースのため、従来のリレーショナル データベースで行なう水平・垂直分割によるシャーディングという作業自体が発生しません。従って、ユーザやトラフィックの増加に対して、アプリケーション側のコードやコンフィグレーションの変更を伴わずにデータベースの性能をスケールさせることができます。Cloud Spanner をスケールする際に必要な作業はノード数の増減のみです。
アーキテクチャの柔軟性
GKE は、Cloud Load Balancing をはじめとする、様々な Google Cloud リソースとネイティブに連携できる製品です。API サーバーを GKE で構成する場合の大多数のユースケースでは、Kubernetes の Ingress リソースを定義して Cloud Load Balancing を使用し、Network Endpoint Group を利用して Kubernetes の Pod へトラフィックを分散する構成がとられます。クライアントとの通信は HTTP 1.1 または HTTP/2 プロトコルをサポートしており、Websocket や gRPC も利用可能です。
その他、GKE は以下のようなユースケースにおいて、良い選択肢となる可能性があります。
Google App Engine 等のサーバーレス製品でサポートされていないアプリケーション ランタイムを使いたい
Istio や Anthos Service Mesh を組み合わせて、サービス メッシュを構成したい
注意事項
GKE クラスタのアップグレード戦略を適切に計画しましょう。
Cloud Spanner のスキーマ設計には考慮が必要です。ゲームのユースケースに適した Cloud Spanner のベスト プラクティスについては以下をご参照ください。
このパターンで作成された事例
参照文献
Page updated
Report abuse