クラウド上のゲームインフラの概要

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

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

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

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

コンポーネントの概要

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

画像

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

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

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

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

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

フロントエンド

フロンドエンドは、インターネット クライアントが直接またはロードバランサ経由で通信を行うためのインターフェースを提供します。

たとえば、セッション型のファーストパーソン シューティング ゲームの場合、フロントエンド サービスでマッチメイキング サービスを実行します。このサービスは、専用ゲームサーバー インスタンスの接続情報をゲーム クライアントに配信します。ゲーム クライアントは、インターネット経由でマッチメイキング サービスにリクエストを送信します。接続情報を含むマッチメイキング サービスからレスポンスを受信すると、クライアントは、UDP(User Datagram Protocol)を介して専用ゲームサーバー インスタンスに直接接続できるようになります。

外部のクライアントだけがフロントエンド サービスを使用するわけではありません。通常、フロントエンド サービスは相互に通信を行うか、バックエンドに接続します。フロントエンド サービスはインターネット経由で利用できるため、攻撃を受ける可能性が高くなります。サービス拒否攻撃や不正なパケットから保護するため、フロントエンド サービスを強化し、セキュリティと信頼性の問題を解決する必要があります。通常、バックエンド サービスにアクセスするには、デベロッパーまたは信頼できるサードパーティ パートナーが作成したコードを使用する必要があるため、攻撃を受ける可能性はフロントエンドよりも低くなります。

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

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

プラットフォーム サービスの例:

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

ゲーム プラットフォーム サービスのソフトウェア デザインは、ウェブサービスの機能や API と類似したパターンで進化しています。

  • 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 など、メモリキャッシュのキー値ストアを使用している場合も同様です。
  • 外部の状態キャッシュに対するクエリのレイテンシ。1% または 0.1% のクエリでレイテンシが発生すれば更新期限を過ぎてしまうため、状態更新の期限を守ることは難しくなります。
  • 外部状態キャッシュに対するアクセス権(読み取り専用または読み取り / 書き込み)の設定。サーバーモデルが複雑になります。このアクセス管理を利用すると、サーバー インスタンス間で状態を簡単に転送できます。

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

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

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

バックエンド

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

ゲーム データベース

プレーヤーがゲームを中断し、そのまま抜けてしまうと、サーバー障害やプレーヤーの進捗データの消失が発生する可能性があります。このような状況が発生するのは、データベース レイヤの設計に問題がある場合です。

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

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

これはゲームの弱点です。成功したサービスを提供している企業の大半は段階的な成長を想定しています。しかし、ゲームの場合、最初に大きな関心を集めるものの、その勢いは急速に衰え、ユーザー数が激減していきます。ゲームの人気が急騰すると、データベースが過負荷状態になり、進行状況データを保存する前に遅延が発生したり、保存できなくなったりします。リアルタイムでの更新を打ち切る機能を決める必要があっても、ゲーム デベロッパーが反対することもあります。データベース リソースの計画は慎重に行う必要があります。

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

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

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

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

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

NoSQL データベース

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

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

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

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

  • 管理 - 大半のクラウド プロバイダは、ホスティングまたはマネージドの NoSQL データ ストレージ エンジンを 1 つ以上提供しています。Cloud Platform でも複数のエンジンを提供しています。

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

分析

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

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

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

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

次のステップ

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

  • Google Cloud Platform のその他の機能を試すには、チュートリアルをご覧ください。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...