Cloud Spanner を使ったグローバル マルチプレーヤー ゲームの開発方法

※この投稿は米国時間 2021 年 11 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

最新のビデオゲームのほとんどは、開発期間と資本の両面で制作に何年もの投資を必要としています。開発期間は、規模、開発プラットフォーム、スコープ、ゲームの種類など、さまざまな要因に影響されます。ゲーマーはプレイを開始したその日からグローバルなマルチプレーヤー体験を期待することが多いため、ゲームの成功は、リリースしてから最初の数週間で、数百万人のプレーヤーが参加するコミュニティにどれだけ効果的にスケールできるかにかかっていると言えます。このようなスケールの要求に対応するには、ゲームの設計に高可用性と安定性を組み込む必要があります。ゲームのリリース当初に起きる問題は致命傷になりかねません。悪い経験を味わったプレーヤーのアクセスは鈍化し、盛り上がっていた期待もすぐに消えてしまいます。言い換えれば、勢いがすべてです。

Cloud Spanner がアーキテクチャの複雑さに対応する仕組み

あらゆる種類のオンライン ゲームでは、プレーヤーの実績や統計情報、リーダーボード、ゲームデータなど、膨大な量のデータを大規模に保存する必要があります。ゲームに参加するプレーヤーが増えると、データ量が直線的または指数関数的に増加します。そのため、ゲームのデータベースに求められる最も重要な条件は、高可用性を維持しながらスケールできることです。

ゲームのワークロードでは一般的に、ゲームデータの厳密な一貫性を選択的に維持しながらスケーラビリティを実現するために、NoSQL データベースとリレーショナル データベースが必要です。Google Cloud では、モバイル ファーストやクロス プラットフォーム対応などゲーム特有の要件に応じて、NoSQL として Firestore や Bigtable を選択できます。リレーショナル データベースに関しては、皆様ご存じの SQL というインターフェースを介してスケーラビリティとグローバルな一貫性の両方を提供するという点で、Spanner に匹敵するものはありません。

Spanner は、分散型でグローバルにスケーラブルな Google の SQL データベース サービスで、コンピューティングとストレージを切り離して、処理リソースをストレージとは別にスケールできます。つまり、読み取りと書き込みの両方における 1 秒あたりのオペレーション数などの側面で高いパフォーマンスを達成するために、ダウンタイムなしで水平方向のアップスケールが可能です。分散型スケーリングが可能な Spanner のアーキテクチャは、オンライン ゲームのような予測不可能なワークロードに最適なソリューションです。

ゲームの予定外のダウンタイムは、ゲームタイトルの寿命を縮める最も危険な脅威です。そのため、ゲーム会社は、予定外の障害が発生した場合にゲームサービスの中断を最小限に抑えることができる高可用性のバックエンド データベースを求めています。Spanner はマルチリージョン インスタンスに対して業界最高水準の 99.999% の可用性を実現し、リージョンとマルチリージョンの両方の構成で透過的な同期レプリケーション機能を提供します。グローバルに分散されたレプリカ シャードは、ローカルコピーからサービスを提供することで、レイテンシの短縮という付加的なメリットをもたらします。

Spanner は、ANSI SQL やスキーマのようなリレーショナル セマンティクスをサポートしており、非正規化の必要がないため、ゲームサービスのデータベースをオンラインで簡単に更新できます。ANSI SQL は、デベロッパーやデータベース管理者（DBA）が習得に要する時間を短縮できます。さらに、オブジェクト リレーショナル マッピング（ORM）に対応しているため、開発時間の短縮にもつながります。

Spanner は、ゲーム会社が PCI、SoC コンプライアンス、FedRAMP などのコンプライアンス要件を満たしやすくなるコンプライアンス認証を取得しています。さらに、Spanner は VPC-SC でサポートされており、その監査ロギングには管理ジョブだけでなくユーザー アクティビティ（DML、DDL、クエリ）も含まれます。

推奨される Spanner 導入プロセス

Spanner の導入には明確なプロセスが用意されており、上記の主要なマイルストーンに沿って進めることで簡単に実施できます。Spanner はリレーショナル セマンティクスをサポートする分散型データベースなので、従来のリレーショナル データベースとの違いを理解することが重要です。試行錯誤や将来の最適化を最小限に抑えるために、開発チームと DBA はゲーム開発ライフサイクルの初期段階で Spanner の評価を始めることをおすすめします。

Spanner に慣れてきたら、Spanner の ANSI SQL とスキーマのサポートにより、既存のリレーショナル データベースのスキーマと関連クエリをわずかな変更で簡単に変換できます。中には、2～3 週間という短い期間でこの変換を完了したゲーム会社のお客様もいらっしゃいます。評価と移行用のオープンソース ツールである Harbourbridge をはじめとしたさまざまなツールにより、Spanner への異種移行を確実かつ容易に行うことができます。

他のデータベースと同様に、Spanner ではスループットやレイテンシなどの目標パフォーマンス要件を満たすために、負荷テストによるパフォーマンスの最適化が必要です。そのため、Spanner には、最適化のための分析情報を提供するイントロスペクション ツールが用意されています。さらに、可視化された直感的なクエリ実行プランにより、データベースに関する深い知識がないデベロッパーでも、長時間実行されるクエリを最適化できます。ゲームのリリース日の前にデータベースの準備をしておくことで、Spanner を適切に分散させ、十分なスループットに対応できるようにします。

Niantic Labs は、数百万人のユーザーに対応する、グローバルにスケーラブルなゲームを Google Cloud 上に構築しました。以下の動画では、Google Kubernetes Engine（GKE）と Spanner を使ったスケーリングの経験のほか、同社のデータ サイエンス チームがどのように BigQuery、Dataflow、Pub/Sub を使ってデータ分析を行っているかを伺いました。

Vimeo は、成長を続ける動画 SaaS 市場の主要企業であり、190 か国以上で 2 億人以上のユーザーにサービスを提供しています。以下の動画では、Cloud Spanner によって Vimeo のプラットフォームを稼働させる方法と、Vimeo が Google Cloud を使用することにした理由を伺いました。

Google Cloud 上のグローバルにスケーラブルなゲーム バックエンド、Spanner の利点、従来のリレーショナル データベースとの違いについて詳しくは、Cloud Spanner を使ったグローバル マルチプレーヤー ゲームの開発方法のホワイトペーパーをご覧ください。