専用ゲームサーバーの移行ガイド

この記事では、コンピュータのゲームサーバーを Google Cloud Platform(GCP)に移行する際の考慮事項について説明します。今日、ほとんどのオンライン ゲームは、マシン(仮想マシンまたは物理マシン)で実行される専用ゲームサーバー プロセスを利用しています。このガイドは、専用ゲームサーバー プロセス(オンプレミスまたはクラウド)の実行に関する知識があるゲーム デベロッパーやオペレーション チームを対象としています。ゲームサーバーを GCP に移行する際には多くの考慮事項がありますが、柔軟性が向上するため、有用な課金モデルや業界トップのグローバル インフラストラクチャ、最新のクラウド技術など、大きなメリットを見込めます。このガイドは、移行への取り組みをサポートすることを目的としています。ゲーム業界では標準的な用語が確立されていないため、この記事では次のように定義します。

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

GCP でゲームサーバーを実行する理由

専用ゲームサーバーをクラウドに移行するゲームスタジオが増え続けています。これは、リリース時のプレーヤー ベースを予測することが基本的に困難であり、それに合わせてハードウェアを購入することを避けるためです。GCP では、アクティビティの急増にシームレスに対処できるだけでなく、利用分だけを支払うことができるため、リリース時のリスクを大幅に取り除くことができます。主なメリットは次のとおりです。

  • Google Compute Engine VM は 1 時間単位ではなく、分単位で課金されます。VM を継続して実行すると、継続利用割引が自動的に適用されます。容量を予約する必要はなく、関連費用のリスクを負うこともありません。
  • カスタム VM では、専用ゲームサーバーで実際に使用した CPU とメモリに応じて支払うことが可能です。
  • Compute Engine VM は短時間で起動します(Linux の場合は数秒、Windows の場合は数分)。
  • 広範なリージョンで提供されるため、ゲームサーバーをユーザーの近くに配置できます。デフォルトのグローバル ネットワーク空間では、サーバーがお客様の既存のサービスと簡単に通信することが可能で、追加作業も不要です。
  • デプロイや QA テスト、イベント用に、1 回限りの環境を数分でプロビジョニングでき、不要になるとすぐに削除できます。他の環境に影響を及ぼすこともなく、コミットメントも不要です。
  • Google Cloud Storage でホストされるビルドを CDN 送信元として設定することや、バケットから直接ビルドを配信することが簡単に行えます。
  • 別のディスク上のビルド アーティファクトのスナップショットを使用すると、OS を簡単にアップグレードできるだけでなく、シンボリック リンクを使用してビルドを本番環境に昇格させることも可能です。

分離された環境でプロジェクトを使用する

開発、テスト、ステージング、パブリック環境が異なるプロジェクトに分割されることがよくあります。プロジェクトは軽量で、作成と破棄も簡単です。また、他の方法として、テスト環境のプロジェクトを作成し、ビルドをデプロイし、QA でスモークテストを実行し、ビルドの昇格または却下の準備が整った後でプロジェクトを破棄することもできます。この方法では、リソースと割り当てが確実に分離されます。たとえば、テストで質の悪いビルドがあったとしても、リソースの余計な消費によって、本番環境サービスが影響を受けることがあってはなりません。また、プロジェクトを破棄すると、必ずそのプロジェクト内のすべてのリソースが削除されるため、テストまたは開発環境で発生する請求について忘れることもないでしょう。

クラウドへのビルド

ビルドを Cloud Storage にアップロードすると、GB 単位のストレージ費用のみが発生します。アップロード後は、CDN 送信元としてこのアップロードを使用することや、他のスタジオまたは請負業者にビルドを配信することが容易になります。また、オブジェクトのライフサイクル管理を使用して、アップロードされたオブジェクトの有効期間を設定すると、管理オーバーヘッドを制御できるようになり、費用も抑えることができます。

配信

Cloud Storage のようなオブジェクト ストアや、永続ディスクなどのブロック ストレージを使用して、クラウドでアセットやバイナリをホストすることがよくあります。Amazon Web Service の S3 を使用する既存のプロセスでは、API の互換性があるため、Cloud Storage への変更や拡張が簡単です。Cloud Storage にアセットを保存することは、ビルドをお客様、CDN、リモート オフィスに配信するためには有効な方法ですが、Cloud Storage からゲームサーバー VM へのコピーを行う際に余分な読み込み時間が発生するため、推奨される方法ではありません。多数の専用ゲームサーバーを使用されているお客様は、新しい専用ゲームサーバー VM を起動するために必要なすべてのライブラリ、アセット、バイナリを備えたディスク イメージを焼き付けるパターンについて理解されていることでしょう。この戦略は、オンプレミスまたは他のクラウドと同様に、GCP でも有効な方法です。ただし、Google では読み取り専用ディスクとスナップショットのペアリングを行うことをおすすめします。次のセクションでは、その大きなメリットについて詳しく説明します。

スナップショットと読み取り専用ディスクによる戦略

ほとんどのゲームでは、OS とゲームサーバー ビルドは個別に変更できます。ゲームビルドは OS ディスクに置かず、別の永続ディスクに置くことをおすすめします。その永続ディスクには、ソフトリンク(シンボリック リンク)で対象のディレクトリを参照する必要なビルド アーティファクトを保存するようにします。このセットアップにより、複数のビルドを VM に配信するためのクリーンなワークフローが作成されます。手順としては、各ビルドを個別のディスクに置き、すべてのディスクを VM に接続し、ゲームサーバー バージョンを変更する準備ができたら、シンボリック リンクをアップデートするだけです。別のディスク上の以前のビルドは、新しいバージョンが安定し、迅速なロールバックが可能であると判断できるまで、接続したままにすることができます。永続ディスクは複数の VM に接続できるため、費用の削減になり、アセットをすべての VM に配信する必要もなくなります。

この方法をゲーム開発パイプラインの一部として行う場合、ビルドシステムを設定して、必要なステップを踏んでディスクを作成し、適切なディレクトリ構造内にすべてのアーティファクト ファイルを格納することをおすすめします。たとえば、gcloud コマンドを実行する簡単なスクリプトを使用することや、選択するビルドシステムに GCP 固有のプラグインを使用することができます。また、ディスクのコピーを複数作成し、作成したコピーに VM を分散させる形で接続することをおすすめします。これにより、スループットに対処できるほか、失敗のリスクも管理できます。また、1 つのスナップショットから複数の永続ディスクを同時に作成できることに注意してください。これは、同じゲームサーバー ビルドの複数のディスクコピーを迅速に作成するための効果的な手段です。

ネットワーク

GCP は、Google のカスタムビルトによるプライベート ファイバー ネットワークで実行され、主要都市の拠点(PoP)と GCP データセンターとの間で非常に低いレイテンシを実現します。GCP のネットワーク モデルを使用すると、サーバーをホストするリージョンと、できるだけお客様の ISP の近くの Google PoP との間の Google ネットワーク上に、重要なゲームプレイ関連のトラフィックを確保することができます。これとは対照的に、他のベンダーが提供するより一般的な「ホットポテト」ルーティング戦略では、トラフィックが VM を離れるとすぐに公衆インターネットへのルーティングを試みます。Google のネットワークは、より高い信頼性と予測可能なレイテンシをゲームのプレーヤーに提供できます。

また、GCP はデフォルトでグローバル ネットワーク空間に接続します。VPN や他のネットワーク ソフトウェアを使って、異なるリージョンやゾーンに「接続」する必要はありません。ある VM を us-central1-b ゾーンで、別の VM を eu-central1-a で開始してから、同じネットワークを使用するよう設定すると、それ以外の設定なしで互いに到達できるようになります。ゾーン間のすべてのトラフィックは Google のプライベート ネットワーク上にとどまるため、公衆インターネットの BGP による余分なホップに起因するレイテンシも発生しません。

プロジェクト間のネットワーク

作成した各 GCP プロジェクトはデフォルトで、分離されたグローバル ネットワークとなります。VM が公衆インターネットを経由せずに別のプロジェクトにある場合、VM は相互に通信できなくなります。プロジェクト間のネットワークを確立する方法は多くありますが、単独のプロジェクトを使用して、プライベート ネットワーク空間で相互に通信させるよう、サーバーとサービスを実行することをおすすめします。

ゲームサーバー向けの GCP ネットワーキング

GCP での専用ゲームサーバー向けの最も一般的なネットワーキング パターンは、Google Cloud Platform Console を使用して「ゲーム」ネットワークを作成する方法です。このネットワークは、適切なゲームポートをインターネット トラフィックに対して開放するように設定します。また、ヘルスチェック、モニタリング、プラットフォーム サービス通信のために必要な内部ポートも設定します。その後、専用ゲームサーバーをホストする VM を作成する際に、このネットワークを指定します。

ベスト プラクティス

ゲームサーバーを GCP に移行した後、GCP インフラストラクチャを使用するためにサーバービルドをさらに最適化してメリットを得ることができます。

vCPU の最適化

クロック速度は vCPU ごとに比較的一定ですが、Google には以前の Intel CPU アーキテクチャが複数含まれているクラウド リージョンがあります。一部のゲームのお客様によると、アーキテクチャ固有のフラグを使用してコンパイルし、該当ファミリーの CPU を提供するリージョン内でサーバーを実行すると、Linux で最大 20% の速度が改善することが確認されています。この vCPU 速度の持続性は、CPU 負荷の高いタスクに対し、スケールアップに代わるスケールアウトのアプローチで効果を発揮します。可能であれば、ワーカー スレッドを使用してコードを並列化し、少数の CPU からさらにサイクルを必要とする代わりに、複数の CPU を使用できるようにしてください。

ネットワークの最適化

トラフィックの下りは課金されますが、上りは無料です。サーバーからのパケットよりも、クライアントからのパケットに対しより高い更新レートを使用する非対称の通信パターンを使用することを検討してみましょう。多くの場合、サーバーの更新レートが低いことによる影響は、補間または外挿により軽減される場合があります。このトピックで推奨されるガイドは、Gaffer on Games(Glenn Fieldler のサイト)のゲーム ネットワーキング シリーズです。また、クライアントとサーバーのマーシャリング / シリアル化コードを効果的に行える場合は、パケット圧縮を使用してパケットサイズを小さくすることを検討してください。

アナリティクス イベントとロギングの最適化

大容量のアナリティクス イベントとロギングパスを Google BigQuery または Cloud Storage に設定し、個々のゲームサーバー プロセスで、これをオンまたはオフにする機能を持たせるようにします。この方法により、報告を受けた悪用について迅速に調査したり、ゲームプレイの分散について分析したり、ML トレーニング データを生成したりできます。いずれのサービスでもデータの保存は非常に安価です(現在、ストレージ 5 TB の利用料は $102.40/月で、これまでより大幅に値下げされました)。また、指定した日時に自動的に期限切れになるよう設定できるため、費用やデータ ボリュームの管理が容易です。

ゲーム状態の外部化

ゲーム状態の外部化の潜在的なメリットについては、クラウドゲーム インフラストラクチャの概要で詳しく説明します。ゲーム状態のどの部分を外部化できるかについては、検討する価値があります。現在、ある程度の外部化された状態を実現できるようになっており、日々発展しているクラウド技術により、この機能の改善が期待されています。外部化された状態では、次のような多くの便利な機能を利用できるようになります。

  • プレイ中でも VM 間でのゲームサーバー プロセスの移行が可能で、中断による影響も最小限に抑えることができます。これは、次のようなさまざまな状況で利用できます。

    • 同じ場所にあるゲームサーバーまたはサービスで、ユーザーのトラフィック パターンを予測する必要もなく、大量のサーバー間通信を同じリージョン(または同じ VM)で確立する場合。
    • リソース使用量の高いプロセスを分離する場合。
    • 更新のためにシャットダウンする必要のある VM や、ピーク時を経過した後の使用量を削減するために除外する必要のある VM から、プロセスのライブ マイグレーショをシームレスに行う場合。
  • シミュレーションの異なる部分で複数のプロセスを動作させ、メモリを共有するように(ただし、大規模に)、互いに更新情報を共有できるようにする場合。

  • 状態のシリアル化のディスクへの保存や、他のゲームサーバーとの共有が可能になるため、eSports に対して次のような新しい可能性を開くことができます。

    • サーバーにキャプチャされた権威あるリプレイと分析記録。
    • 専用ゲームサーバーの「ミラーリング」により、ゲーム クライアントの膨大な観戦者にライブで対応。

次のステップ

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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