クラウド上のゲーム インフラストラクチャの概要

ここでは、クラウド プラットフォーム上にゲームインフラをホスティングする場合に使用する共通のコンポーネントとデザイン パターンについて説明します。

ビデオゲームの世界は大幅に進化し、盛況なエンターテイメント ビジネスに成長しています。インターネットの普及に伴い、オンライン ゲームは業界の成長に不可欠な要素となっています。

オンライン ゲームの形態は 1 つではありません。セッション型で複数のプレーヤーが対戦するものや、大量のプレーヤーが参加する仮想世界、1 人で楽しむものまで、さまざまです。

以前は、クライアント / サーバー型のゲームを実現するために、専用のサーバーを購入してオンプレミスまたは共同で配置し、メンテナンスを行う必要があり、大規模なスタジオかパブリッシャーでなければ、このようなインフラを持つことはできませんでした。また、ハードウェアの固定費を予算内に抑えながら顧客のニーズに応えるため、綿密な予測や容量計画を行う必要がありました。現在では、クラウドベースのコンピューティング リソースを活用することで、規模の大小にかかわらず、どのゲーム デベロッパーやパブリッシャーでも、高額な初期投資を行わずに、必要なリソースを適宜利用できるようになりました。

コンポーネントの概要

次の図は、ゲーム アーキテクチャのオンライン部分を表しています。

フロントエンドとバックエンドのコンポーネントからなる、GCP 上のゲーム インフラストラクチャの図。

ゲーム アーキテクチャのフロントエンド コンポーネントは次のとおりです。

  • 高度なゲーム機能を提供するゲーム プラットフォーム サービス。
  • ゲームをホスティングする専用ゲームサーバー。

ゲーム アーキテクチャのバックエンド コンポーネントは次のとおりです。

  • システムに記録されるゲームデータ。通常、ゲーム データベースに保存されます。
  • 分析データとゲームプレイ イベントを保存し、照会する分析スタック。

これらのコンポーネントは、オンプレミス、プライベート クラウド、パブリック クラウドにホスティングされます。また、フルマネージド ソリューションの場合もあります。コンポーネントとエンドユーザー間の通信のレイテンシ要件を満たしていれば、どのシステムでも問題ありません。

フロントエンド

フロントエンドは、クライアントが直接またはロードバランサ層を介してやり取りするためのインターフェースを提供します。

たとえば、セッション型のファースト パーソン シューティング ゲームの場合、フロントエンドにマッチメイキング サービスが含まれます。このサービスは、専用ゲームサーバー インスタンスの接続情報をゲーム クライアントに配信します。

  1. クライアントがマッチメイキング サービスにリクエストを送信します。
  2. マッチメイキング サービスがクライアントに接続情報を送信します。
  3. 接続情報を受け取ったクライアントは、User Datagram Protocol(UDP)を使用して専用ゲームサーバー インスタンスに直接接続できます。

外部のクライアントだけがフロントエンド サービスを使用するわけではありません。通常、フロントエンド サービスは相互に通信を行うか、バックエンドに接続します。

フロントエンド サービスはインターネット経由で利用できるため、攻撃を受ける可能性が高くなります。サービス拒否攻撃や不正なパケットから保護するため、フロントエンド サービスを強化し、セキュリティと信頼性の問題を解決する必要があります。フロントエンド サービスと比較すると、バックエンド サービスは通常、信頼できるコードにのみアクセス可能であるため、攻撃を受けにくくなります。

ゲーム プラットフォーム サービス

このコンポーネントの一般的な名前は、「プラットフォーム サービス」または「オンライン サービス」です。プラットフォーム サービスでは、重要なメタゲーム機能とのインターフェースを提供します。たとえば、インターフェースを利用してプレーヤーが専用ゲームサーバーのインスタンスに参加したり、ゲームのソーシャル グラフを維持できます。通常、ゲームを実行する Steam、Xbox Live、Google Play Games などのプラットフォームは、次のサービスを提供しています。

  • スコアボードと対戦履歴
  • マッチメイキング
  • オンライン ロビー
  • チャット
  • インベントリの管理
  • 承認
  • パーティ / グループ
  • プロフィール
  • ギルド
  • クロスプラットフォームの認証
  • フィード
  • ソーシャル アイデンティティのマッピング
  • 分析
  • プレゼンス

ゲーム プラットフォーム サービスは、ウェブサービスと同じように進化しました。

  • 2000 年代の初め、プラットフォーム サービスの多くはモノリシック サービスとして実行され、多くの場合はシングルトンとして実装されていました。統合を行ったとしても、このパターンはクラウドには適していません。

  • 現在のサービス指向アーキテクチャ(SOA)のパターンが広まったのは 2000 年代中頃で、さまざまなサービスが個別にスケーラブルな形態で提供されるようになりました。また、このサービスはゲーム クライアントやサーバーだけでなく、ウェブサービスやスマートフォンのアプリからのアクセスも可能になっています。

  • この 5 年ほどで、多くのウェブ企業が支持するマイクロサービス アプローチを採り入れるデベロッパーが増えています。プラットフォーム サービスとウェブ アプリケーションが抱える基本的な課題は同じです。どちらも、開発サイクルを短縮し、世界中にサービスを分散させ、実行することが求められています。マイクロサービスを利用すると、このような問題を解決できます。特に、クラウド プラットフォームでアプリケーションを設計する場合には最適な選択肢となります。

  • さらに、プラットフォーム サービスまたはフルマネージド プラットフォーム サービスを構築する方法として、ホスティング サービスまたはマネージド サービスが利用されるケースが増えています。

バックエンド プラットフォーム サービス

大半のプラットフォーム サービスは外部のクライアントからアクセスされますが、非公開のプレーヤー ランキング サービスを提供する場合などはオンライン インフラの他の部分からのアクセスのみを許可します。このようなバックエンド プラットフォームには通常、外部ネットワークのルーティングや IP アドレスが設定されず、フロントエンド プラットフォーム サービスと同じ方法で設計されます。

Google Cloud Platform のプラットフォーム サービス ソリューション

以下のソリューションでは、Cloud Platform でバックエンド サービスを構築する方法について詳しい情報を提供しています。

専用ゲームサーバー

専用ゲームサーバーはゲームロジックを提供します。ユーザーにとってのレイテンシを最小限に抑えるため、クライアントのゲームアプリは専用ゲームサーバーと直接通信を行います。この機能は、フロントエンド サービス アーキテクチャの一部となります。

業界でも標準的な用語はまだ確立していませんが、この記事では次のように定義します。

  • 「マシン」は、ゲームサーバーのプロセスが実行される物理マシンまたは仮想マシンを意味します。
  • 「ゲームサーバー」は、ゲームサーバー プロセスを意味します。1 台のマシン上で複数のゲームサーバー プロセスが同時に実行されることもあります。
  • 「インスタンス」は、単独のゲームサーバー プロセスを意味します。

専用ゲームサーバーの種類

専用という言葉は、バックエンドのゲームサーバーを意味するわけではありません。もともとは、1:1 の比率で専用のハードウェア上で実行されるゲームサーバーのことを表す用語です。現在では、多くのゲーム パブリッシャーが 1 台のマシン上で同時に実行される複数のゲームサーバー プロセスを管理しています。これらのプロセスがマシン全体を占有することはまずありませんが、専用ゲームサーバーという言葉はいまでもゲーム業界でよく使われています。

専用ゲームサーバーは、実行されるゲームの種類によって異なります。以下では、ゲームサーバーのカテゴリについて簡単に説明します。

リアルタイム シミュレーション

最近まで、専用ゲームサーバーは主に、市販のリアルタイム シミュレーション ゲームのフロントエンドとして使用されていました。リアルタイム シミュレーションのゲームサーバーは垂直方向のスケーリングに課題があります。最も需要の高いゲームでは、マシンごとの複数サーバー プロセスの実行やゲーム世界の地理的分散など、手動での水平方向スケーリングが行われています。このため、カスタムフローを制御し、信頼性が高く、輻輳を回避できる UDP が通信手段として主に利用されています。

大半のリアルタイム シミュレーションのゲームサーバーは、エンドレス ループとして実装されていますが、一定の時間予算内にループを終了することを目標としています。標準的な時間予算は 16 または 33 ミリ秒で、それぞれ 1 秒あたり 60 回または 30 回の状態更新を行います。この更新レートは、フレームレートまたはチックレートともいいます。サーバーは高頻度でシミュレーションを更新しますが、複数の更新を行った後で状態の更新をクライアントを送信することも珍しくありません。この方法では、必要なネットワーク帯域幅を適切な範囲に抑えることができます。更新頻度が下がることによる影響は、ラグ補償内挿外挿などの方式を使用することで軽減できます。

リアルタイム シミュレーションのゲームサーバーでは、レイテンシが重要な問題となり、多くのコンピューティング リソースと帯域幅を必要とするワークロードが実行されます。このため、ゲームサーバーの設計とそれを実行するコンピューティング プラットフォームは慎重に検討する必要があります。

セッション型または対戦型のゲーム

現在では、サーバーで個別のセッションを実行するゲームが一般的です。たとえば、Call of Duty™、Overwatch™、Titanfall™ などのファースト パーソン シューティング(FPS)ゲームや、Dota 2™ や Vainglory™ などのマルチプレーヤー オンライン バトルアリーナ(MOBA)ゲームのマルチプレーヤー セッションなどがその一例です。これらのゲームのサーバーは、ゲームプレイの展開を迅速に行い、ゲーム状態の詳細な計算を行う必要があるため、スレッドが AI または物理シミュレーションで占有されることが多くなります。

大量のプレーヤーが参加する持続型ゲーム

大規模マルチプレーヤー オンライン ゲーム(MMOG)の先駆けとなったのが約 20 年前に登場した Ultima Online™ です。World of Warcraft™ や Guild Wars™ など、現在人気の MMOG は、機能が常に進化し、複雑なサーバー デザインになっています。

MMOG サーバーではこの複雑さが常に問題となります。たとえば、サーバー インスタンス間でゲーム エンティティを受け渡し、ゲーム世界を複数の環境に分散させ、隣接するゲーム領域のシミュレーションを行う必要があります。数百や数千のプレーヤーが参加するゲーム世界の状態を更新するには、多くのコンピューティングとメモリが必要になりますが、Eve Online™ などでは、時間の遅れを利用してこの課題を解決しています。

リクエスト / レスポンス型のサーバー

技術的にみると、どの専用ゲームサーバーも一連のリクエストとレスポンスをベースにしています。ただし、モバイルゲームのサーバーの場合には、リアルタイムで通信を行う必要性が低いため、ウェブ ホスティングと同様に HTTP リクエスト / レスポンスで通信を行います。

リクエスト / レスポンス型のゲームサーバーは、ウェブサービスと同じ課題を抱えています。

  • ゲームサーバーのレスポンス時間をできるだけ短縮する。
  • レイテンシを減少し、冗長性を追加するため、世界各地にゲームサーバーを分散させる。
  • サーバー上でゲーム クライアントのアクションを検証し、攻撃や詐欺を未然に防ぐ。
  • ゲームサーバーを強化して、サービス拒否攻撃などの攻撃を防ぐ。
  • クライアント側の通信に指数的減衰を実装する。
  • スティッキー セッションを構築するか、プロセスの状態を外部化する。

リクエスト / レスポンス型のゲームサーバーには、通信手段がコンパクトになり、アプリケーションやネットワークの障害後に簡単に再試行できる利点がありますが、このようなメリットはターン制のモバイルゲームにも有効です。

ゲーム状態の外部化

プレーヤーはゲームが中断しないことを期待し、その期待はますます強くなっています。このニーズに応えるには、個々のサーバー インスタンスに影響を及ぼす問題からユーザーの体験を保護しなければなりません。この課題は、プレーヤーの状態データを単一のゲームサーバー プロセス以外で管理することで解決できます。これにより、サーバー プロセスのクラッシュによる影響を最小限に抑え、効果的な負荷分散を行うこともできます。

しかし、ウェブサービスでよく利用されている状態パターンの外部化をそのまま利用することはできません。さまざまな点で問題があります。たとえば、次の点が問題になります。

  • 外部の状態ファイルに更新を書き込む速度。特に、1 秒間に十数回更新を行うエンティティが数多く存在する場合は問題になります。Memcached や Redis など、メモリキャッシュの Key-Value ストアを使用している場合も同様です。
  • 外部状態キャッシュに対するクエリの最長レイテンシは、大きな問題です。1% または 0.1% のクエリでさえも、更新期限を大幅に過えるレイテンシが発生すれば、状態更新の期限を守ることは難しくなります。
  • 外部状態キャッシュに対するアクセス権(読み取り専用または読み取り / 書き込み)の設定。サーバーモデルが複雑になります。

しかし、これらの問題を解決することによるメリットが複数あります。状態を外部化し、適切なアクセス管理を実施して多くのプロセスにアクセスを許可すると、ゲームの状態更新の計算を並行して実行できます。また、インスタンス間のエンティティの移動も簡単になります。

Cloud Platform 専用ゲームサーバー ソリューション

Cloud Platform で専用ゲームサーバーを実行する方法については、次の記事をご覧ください。

バックエンド

バックエンド サービスは、他のフロントエンドまたはバックエンド サービスに対してのみインターフェースを提示します。外部クライアントはバックエンド サービスと直接通信できません。バックエンド サービスはデータの保存とアクセスの手段を提供します。たとえば、データベースへのゲーム状態データの保存、データ ウェアハウスへのロギング イベントや分析イベントの保存を行います。

ゲーム データベース

プレーヤーがゲームをあきらめ、二度と戻らなくなるシナリオとして、サーバー障害とプレーヤーの進捗データの消失が挙げられます。いずれの状況も、データベース レイヤの設計に問題がある場合に発生します。

ゲームの状態とプレーヤーの進行状況データを保存するデータベースは、ゲームインフラの最も重要な部分となります。

データベースの能力を評価する場合には、予想されるワークロードだけでなく、ゲームが広く普及した場合に必要になるワークロードも検討する必要があります。予想されるプレーヤー数に基づいてバックエンドを設計し、テストを行っても、負荷が急増した場合、信頼性のあるサービスの提供はできなくなります。予期しない負荷急増への対応も計画していないと、データベース問題によりゲームが利用不能になり、ユーザーが離れる結果となります。

これはゲームの弱点です。成功したプロダクトを提供している企業の大半は段階的な成長を想定しています。しかし、ゲームの場合、最初に大きな関心を集めるものの、その勢いは急速に衰え、ユーザー数が激減していきます。ゲームの人気が急騰すると、データベースが過負荷状態になり、進行状況データを保存する前に遅延が発生することや保存できなくなることがあります。ゲームのどの機能に対し、リアルタイム更新のサポートを止めるか決めざるを得ない状況は、ゲーム開発者として陥りたくない状況ですので、データベースリソースを慎重に計画してください。

ゲーム データベースを設計する場合には、次の点に注意が必要です。

  • 十分な情報に基づいて判断する。テスト作業が楽という理由で、あるデータベースを開発用に使い、すべてのオプションを評価せずに、そのデータベースをそのまま本番データベースにしないでください。予測されるプレーヤー数がデータベースにアクセスする方法と頻度を把握し、その 10 倍を前提とします。これにより、想定するシナリオに最適なバックエンドを選択できます。データベースに対するアクセスが急増したときに対処方法を探すような状況は避けなければなりません。
  • 適切な解決策は 1 つとは限らない。1 種類のデータベースしか利用してはいけない、という規則はありません。成功しているゲームの多くは、リレーショナル データベースにアカウント情報を保存してゲーム内購入を処理し、NoSQL データベースを使用してゲームの状態情報を保存しています。リレーショナル データベースではトランザクションが保証されますが、大容量で低レイテンシのワークロードの処理には NoSQL データベースのほうが適しています。
  • データをバックアップする。データベースの障害から復旧できるように、バックアップを定期的に行い、地理的に離れた場所に保存する必要があります。

リレーショナル データベース

多くの開発チームは、1 つのリレーショナル データベースで開発を始めています。データとトラフィックが増加し、データベースのパフォーマンスが許容範囲に近づくと、データベースのスケーリングを検討します。スケーリングが可能でない場合、カスタムのデータベース サービスレイヤを実装します。このレイヤでクエリの優先度を設定し、結果をキャッシュに保存することで、データベースに対するアクセスを制限できます。スケーリングとデータベース サービスレイヤを追加することで、大量のプレーヤーに対応可能なゲーム バックエンドを構築できますが、これらの方法にも問題があります。

  • スケーリング - 従来のリレーショナル データベースはスケールアップ(垂直方向のスケーリング)を前提としています。クラウド ネイティブのゲーム バックエンドを計画する場合には、スケールアウト(水平方向のスケーリング)を使用してください。1 つの VM のコア数には制限があります。クラウド プロジェクトに VM を追加するほうが簡単です。リレーショナル データベースでも、シャーディングクラスタリング階層のレプリカなどの手法で水平方向にスケーリングできますが、実行中のデータベースを停止せずにこれらを追加するのは簡単なことではありません。トラフィックやデータの量が 1 つのデータベースの能力を超える可能性が少しでもある場合は、小さいクラスタから始めます。危機的な状況になってからスケーリングを検討するようなことは避けるべきです。実行中のクラスタにノードを追加することは簡単ではありませんが、不可能ではありません。
  • スキーマの変更 - ヒットするゲームで、データベース スキーマが開始当時からライフサイクルを通して変わらないゲームはほとんどありません。プレーヤーは常に新しい機能とコンテンツを求めています。このような追加を行うには、新しい種類のデータをデータベースに保存しなければなりません。開発プロセスの初期の段階で、スキーマの更新方法を決めておくべきです。所定のプロセスがない状態でゲームのリリース後にスキーマを更新すると、予期しない停止時間やプレーヤー データの消失が発生する可能性があります。
  • 管理 - 稼働中のリレーショナル データベースのスケーリングやスキーマの更新は複雑な操作になります。Cloud Platform では自動的に管理されるリレーショナル データベースは一般的なサービスですが、今のところ、ゲーム バックエンドでのこうした自動管理のデータベースの普及率は高くありません。これは、ゲーム バックエンドでのワークロードは書き込みが多いためです。

NoSQL データベース

非リレーショナル データベースは大規模な運用が可能で、特に、書き込みが多いワークロードの処理に適しています。ただし、NoSQL データモデル、アクセス パターン、トランザクションの保証について、よく理解しておく必要があります。

NoSQL データベースには多くの種類があり、ゲーム状態の保存に適しています。このデータベースの特徴は次のとおりです。

  • スケーリング - 水平方向のスケーリングを前提に設計されています。デフォルトで使用されていることも少なくありません。通常、データベースを停止せずにクラスタのサイズを変更できますが、追加ノードが完全に統合されるまでは、パフォーマンスが低下する場合もあります。

  • スキーマの変更 - スキーマは動的で、アプリケーション レイヤによって適用されます。これは大きなメリットで、新しいゲーム機能のフィールドを簡単に追加できます。

  • 管理 - ほとんどのクラウド プロバイダでは少なくとも 1 つのホスト型またはマネージド NoSQL データ ストレージ エンジンを使用できます。Google Cloud Platform ではこうした NoSQL データ ストレージ エンジンを複数使用できるようになっています。

Google Cloud Platform のゲーム データベース ソリューション

分析

現在のゲームでは、分析は重要なコンポーネントになっています。オンライン サービスとゲーム クライアントの両方が分析結果とテレメトリー イベントを共通の収集ポイントに送信します。イベントはデータベースに保存されます。この情報は、ゲームプレイのプログラマー、デザイナーだけでなく、ビジネス インテリジェンスのアナリストやカスタマー サポートの担当者も利用できます。収集する分析結果が複雑になっても、クエリを簡単に実行できるように、イベントに同じフォーマットを使用する必要があります。

この 10 年間で、Google で公開されたオープンソース フレームワークである Apache™ Hadoop® の利用者が大幅に増加しました。Hadoop エコシステムの拡大により、複雑な ETL(抽出、変換、読み込み)を実行して分析イベントをデータ ウェアハウスに挿入する一括処理が増えています。MapReduce の使用により、有益な結果が配信される速度が向上した結果、より多くのリソースを必要とする新たな分析が可能になりました。

一方、クラウドで利用可能な技術も進化を続けています。その多くはマネージド サービスとして提供され、専任の人員を確保しなくても、簡単に利用できます。Google の最新のストリーミング ETL のパラダイムでは、一括処理とストリーミング処理の両方に統合アプローチを採用しています。このパラダイムは、マネージド クラウド サービスとオープンソース プロジェクトの Apache Beam の両方で利用できます。クラウドデータ ストレージの料金体系も継続的に改善されています。データの書き込みと読み取りを最適な方法を行う大規模なクラウド データベースに大量のログと分析イベントを保存できるようになりました。これらのデータベースの最新のクエリエンジンは TB 単位のデータを数秒で集計します。たとえば、500 億の Wikipedia ページビューを 5 秒で分析します

Google Cloud Platform のゲーム分析ソリューション

次のステップ

オンライン ゲームのソリューションには共通のパターンがあります。クライアントがサービスのフロントエンドとゲームサーバーに接続し、これらのコンポーネントがバックエンドに接続して分析や状態の保存を行います。これらのコンポーネントは、オンプレミス、クラウド、あるいはその両方で実行できます。パターンの詳細については、ゲーム ソリューションをご覧ください。