『ドラゴンボール レジェンズ』の舞台裏を支える Google Cloud
Google Cloud Japan Team
Posted by Google Cloud ゲーム テクニカル スペシャリスト サミール ハムディ
バンダイナムコエンターテインメント（BNE）の『ドラゴンボール レジェンズ』は、人気の高い『 ドラゴンボール』シリーズをモチーフとした、全世界のゲーマーに向けて配信を開始した新しいモバイル ゲームです。このゲームを支えるクラウド インフラストラクチャの計画は、特殊な課題を抱えていた BNE が、その解決のために Google Cloud と話し合いを持った 2017 年 2 月にスタートしました。
BNE は、自ら予測する需要に基づいて、次の 3 つの意欲的な要件を設けていました。
- 極端なまでのスケーラビリティ : このゲームは全世界に配信されるため、数百万のプレーヤーが参加してもびくともしないスケーラビリティの高いバックエンドが必要でした。
- グローバル ネットワーク : このゲームはプレーヤー同士のリアルタイム対戦をサポートするため、地域の枠を超えて信頼性が高くレイテンシが低いネットワークが必要でした。
- リアルタイム データ アナリティクス : このゲームはプレーヤーの行動に基づきリアルタイムで発展するように作られているため、データ ウェアハウスにデータをストリーミングするデータ アナリティクス パイプラインが必須でした。プレーヤーがどのようにプレーしているかを計測して評価し、臨機応変にゲームを調整できるようにするのです。
この 3 つの要件は、いずれも私たち Google が多くの経験を有する分野です。Google は、10 億人以上のユーザーを対象とするグローバル サービスを複数運用し、サービスが生成するデータを活用して継続的にサービスを改善しています。Google Cloud Platform（GCP）は、これらの Google サービスと同じインフラストラクチャで実行されているため、GCP のお客様は Google と同じテクノロジーを活用できます。
以下では、BNE がドラゴンボール レジェンズのインフラストラクチャ構築に向けて Google Cloud と行った共同作業を紹介します。
課題 1 : 極端なまでのスケーラビリティ
日本のゲーム会社は MySQL を多用しています。日本のエンジニアたちは、スキーマ、SQL クエリ、強整合性を備えたリレーショナル データベースの扱いに慣れています。MySQL ならアプリケーション サイドの多くのことが単純化されます。結果整合性やスキーマレスといったデータベースの弱点を処理しなくて済むわけです。MySQL はゲーム以外でも広く使われており、ほとんどのバックエンド エンジニアが MySQL の経験を有しています。このように MySQL には多くの利点がありますが、一方でスケーラビリティが低いという大きな限界を抱えています。実際、スケールアップ データベースとして MySQL のパフォーマンスを上げたければ、CPU や RAM、もしくはディスクの増設が必要です。確かに、シングルインスタンスの MySQL で負荷を処理できなくなっても、シャーディングで負荷を分散することは可能です。ユーザーをグループ分けし、複数の独立した MySQL インスタンスに振り分けるのです。
ただし、シャーディングにはいくつも欠点があります。リシャーディングは労力がかかり、エラーを起こしがちなので、ほとんどのゲーム開発者は配信前に、必要とされるシャード数を計算します。そのとき、想定以上のプレーヤーが殺到しても対応できるように、データベースを過度にプロビジョニングしてしまう傾向があります。プレーヤーの規模が予想どおりになれば問題はありません。しかし、ゲームが途方もない成功を収めて需要が予測を超えたらどうなるでしょうか。アクティブなプレーヤーが少しずつ減るロング テールを起こしたり、まったくの失敗に終わったりしたらどうなるでしょうか。MySQL のシャーディングは動的にスケーラブルなものではなく、サイズの調整にはメンテナンスが必要でリスクもあります。
理想は、リレーショナル データベースのすべての利点を有しながら、ダウンタイムなしでスケールイン、スケールアウトできるデータベースです。BNE は、ドラゴンボール レジェンズで予測される大量のトラフィックを MySQL で処理したいという意向を持っていましたが、私たち Google は Cloud Spanner を使うことを提案しました。
なぜ Cloud Spanner なのか
Cloud Spanner は、MySQL のものとよく似たスキーマで強整合性を維持しつつ、水平スケーラビリティと高可用性を提供するフルマネージドのリレーショナル データベースです。マネージド サービスなのでメンテナンスは Google SRE に任せることができ、ダウンタイムのリスクもありません。私たちは、BNE がゲームをグローバルに展開するうえで、Cloud Spanner がきっと役に立つと考えたのです。
評価から実装へ
新技術を採用するときは、実際のシナリオで期待どおりのパフォーマンスが得られることを確認するため、必ずテストが必要になります。BNE は、MySQL を手放す前に、GCP に新しい Cloud Spanner のインスタンスを作り、MySQL で使っていたものとよく似たスキーマのテーブルも作りました。BNE のバックエンド開発者たちは Scala を使っていたので、Cloud Spanner の Java クライアント ライブラリを選択して Cloud Spanner のロードテスト コードを書きました。ピーク時に 3 万 QPS（1 秒あたりのクエリ数）に達するクエリについていけるかどうかをテストしたのです。Google の担当エンジニアと Cloud Spanner エンジニアリング チームも協力して、この目標は楽にクリアしました。さらに BNE は、INSERT、UPDATE、DELETE などの SQL コマンドを書くために独自のデータ操作言語（DML）まで作りました。
ゲーム リリース
概念実証を終えた BNE は実装を開始しました。予想されるデイリー アクティブ ユーザー（DAU）に基づき、BNE は必要とされる Cloud Spanner ノードの数を計算しました。予想される事前登録者に十分なサービスを提供できる数です。配信開始に備え、バックエンドの評価のために 2 度にわたるクローズド ベータ テストを実施しましたが、データベースでは何の問題も発生しませんでした。ドラゴンボール レジェンズの事前登録者は最終的に全世界で 300 万人を超えましたが、これだけのユーザーを抱えながらも、ゲームの正式リリースは問題なく成功しました。
要するに、BNE はデータベースの操作に時間を費やすことなく、ゲームの改良に集中することができたのです。
課題 2 : グローバル ネットワーク
BNE の第 2 の課題に移りましょう。プレーヤー同士がリアルタイムで対戦できるゲーム（PvP）の構築がそれです。ドラゴンボール レジェンズでの目標は、世界中どこにいても、すべてのプレーヤーが別のプレーヤーと対戦できるようにすることでした。ネットワーキングについて少しでも知識があれば、この場合、レイテンシが問題になることは容易に想像がつくでしょう。たとえば、東京とサンフランシスコ間のラウンド トリップ タイム（RTT）は平均で 100 ミリ秒程度です。そこで BNE は、ゲームのすべての時間を 250 ミリ秒に分割しました。ユーザーにはリアルタイムのように見えても、実際には高速に交替してプレーをしています（アーキテクチャの詳細はこちらをご覧ください）。250 ミリ秒もあればレイテンシへの対処には十分だと思われるかもしれませんが、インターネット経由で通信する場合にはレイテンシの予測はきわめて困難です。
Google 専用ネットワークのメリット
ゲーム クライアントがインターネット経由で GCP 上のサーバーにアクセスする様子を図示すると、次のようになります。ホップ数が毎回まちまちなので、PvP の体感速度もまちまちになります。
BNE がドラゴンボール レジェンズのバックエンドとして GCP を使用することにした主な理由の 1 つは、Google の専用ネットワークです。下図からもわかるように、全世界で数百万に上る GCP の POP（接続拠点）のいずれかにゲーム クライアントがアクセスすると、Google の専用ネットワークにつながります。これでホップ数は予測可能になり、レイテンシは最小限に抑えられます。
Google Cloud Networking の活用
ゲーム会社は通常、2 人のプレーヤーを直接つなぐか、専用ゲーム サーバーを間に挟んで PvP を実現します。プレーヤー間のレイテンシを抑えたい戦闘ゲームの場合は、一般に P2P 通信が使われます。2 人のプレーヤーが地理的に近い場所にいれば P2P はうまく機能しますが、距離が遠くなると信頼性が失われがちになります（P2P プロトコルをブロックするキャリアもあります）。
異なる大陸間で 2 人のプレーヤーが通信するときは、まずは P2P による通信を試みます。うまくいかなければ、coturn という STUN/TURN サーバーのオープンソース実装にフェイルオーバーして、Google の専用ネットワークを介して通信します。これが 2 人のプレーヤーのリレーとして機能します。大陸間バトルでは、レイテンシが低く信頼性が高い Google ネットワークをできる限り活用するのです。
課題 3 : リアルタイム データ アナリティクス
BNE の最後の課題はリアルタイムのデータ アナリティクスでした。BNE は最高のユーザー エクスペリエンスをファンに提供する方法の 1 つとして、オペレーターによるゲームの変更を定期的に行い、新鮮味を感じさせるライブ オペレーション（LiveOps）を実施しようとしていました。ただし、プレーヤーのニーズを知るためにはデータ、つまりユーザー アクションのログ データが必要です。リアルタイムでデータが得られれば、ユーザーの満足度を上げてプレー時間を延ばすためにどのような変更を加えるかを判断できます。このデータを収集するため、BNE は Cloud Pub/Sub と Cloud Dataflow を組み合わせてユーザー データをリアルタイムで変換し、BigQuery に転送することにしました。
- Cloud Pub/Sub はグローバルに信頼性の高いメッセージング システムです。Cloud Dataflow が処理できるようになるまで、ログをバッファリングします。
- Cloud Dataflow はフルマネージドの並列処理サービスです。リアルタイムで並列に ETL を実行できます。
- BigQuery はフルマネージドのデータ ウェアハウスです。ゲームのすべてのログを格納します。BigQuery はペタバイト規模のストレージを提供するため、スケーリングが問題になることはありません。ログのクエリ処理の並列度が高いため、BNE はわずか数秒で数テラバイトのデータをスキャンし、クエリの応答を得られるようになりました。
このシステムにより、ゲーム プロデューサーは、ほぼリアルタイムでプレーヤーの行動を可視化し、ファンを満足させるためにどのような新機能をゲームに投入するか、ゲーム内をどのように変更するかを判断できるようになりました。
まとめ
Cloud Spanner を導入したおかげで、BNE はデータベースのキャパシティ プランニングやスケーリングに時間を費やすことがなくなり、素晴らしいゲームの開発に集中できるようになりました。フルマネージドのスケーラブルなデータベースを使用することで、ヒューマン エラーによるリスクと運用のオーバーヘッドも大幅に削減できました。
また、BNE は Google の専用ネットワークも活用しています。Cloud Networking により、大陸間のバトルの場合でも最高のユーザー エクスペリエンスをファンに提供できるようになりました。
Google のアナリティクス スタック（Cloud Pub/Sub、Cloud Dataflow、BigQuery）は、ユーザーの行動をリアルタイムで分析し、ファンを喜ばせるためのゲームの調整方法を判断することに大いに貢献しています。
BNE がゲーム用データベースとして Cloud Spanner をどのように評価し、採用したかを詳しく知りたい方は、今年 7 月にサンフランシスコで開催される Google Cloud Next '18の BNE セッションにぜひお越しください。
* この投稿は米国時間 6 月 14 日、Google Cloud の Gaming Technical Specialist である Samir Hammoudi によって投稿されたもの（投稿はこちら）の抄訳です。
