Azure Kubernetes Service (AKS) を使用した同期マルチプレイヤー

マネージド Azure Kubernetes Service (AKS) を使用して、Azure 上の Kubernetes オーケストレーターでコンテナー化された専用ゲーム サーバーを管理できます。

この記事では、GitHub のこのサンプルで使用されているアーキテクチャについて説明します。 このリファレンス アーキテクチャのコードはガイダンスの例にすぎず、運用環境で使用するにはコードの最適化が必要な場合があることに注意してください。

アーキテクチャの図

SAzure Kubernetes Service を使用した同期マルチ プレイヤー

関連するサービス

  • Azure Traffic Manager - 待機時間に基づいて、最も適したリージョンのゾーンにプレイヤーを接続します。
  • Azure Kubernetes Service - Kubernetes のデプロイと操作が簡素化されます。
  • Azure Container Registry - すべての種類のコンテナー デプロイに対するイメージを格納できます。

アーキテクチャの考慮事項

カスタム リソース定義 (CRDs)

このリファレンス アーキテクチャでは、カスタム リソース定義 (CRD) オブジェクトを使用して Kubernetes を拡張します。 これらのオブジェクトを使用して、専用のゲーム サーバー エンティティを表します。

具体的には、2 つのコア エンティティがあり、それぞれに 2 つの CRD で表されます。

  • DedicatedGameServer: マルチプレイヤー ゲーム サーバー自体を表します。 各 DedicatedGameServer には、1 つの対応する子ポッドがあり、これによりゲーム サーバーの実行可能ファイルでコンテナー イメージが実行されます。

  • DedicatedGameServerCollection: 同じポッド テンプレートを実行する関連する DedicatedGameServers のコレクション/セットを表し、コレクション内でスケールイン/アウトできます (つまり、インスタンスを追加または削除します)。

    同じ DedicatedGameServerCollection のメンバーである DedicatedGameServer は、実行環境に多くの類似性があります。たとえば、そのすべてが同じマルチプレイヤー マップまたは同じ種類のゲームを起動できます。 したがって、1 つのコレクションをゲームの "旗取り" モードに使用し、別のコレクションを "征服" モードに使用できます。 または、1 つのコレクションをマップ "X" でプレイしているプレイヤーに使用し、別のコレクションをマップ "Y" でプレイしているプレイヤーに使用できます。

コンポーネント

このリファレンス アーキテクチャには 2 つの主要なコンポーネントが含まれ、どちらも単一インスタンスの Kubernetes デプロイとして作成されます。

  1. API サーバー コンポーネント

    これは、プロジェクトの API サーバーです (Kubernetes API サーバーとは関係ありません)。 次の 2 つのサブコンポーネントが含まれます。

    1. API サーバー サブコンポーネント

      ゲーム サーバーまたは外部のスケジューリング システム (ロビー サービスやマッチメイキングなど) から呼び出すことができる REST API を提供します。

    2. Webhook サブコンポーネント

      Kubernetes の受付 Webhook であり、Kubernetes API サーバーに対する CRD に関する要求を検証して変更します。

  2. コントローラー

    Kubernetes コントローラーは、アクティブな調整プロセスであるオブジェクトです。 簡単に言うと、これは、コントローラーがオブジェクト (またはオブジェクトのセット) の望ましい状態と実際の状態を監視することを意味します。 コントローラーは、オブジェクトをアクティブに比較し、実際の状態が望ましい状態になるように、すべての作業を行います。

    このプロジェクトにはコントローラーのセットが含まれており、それぞれによって特定のオブジェクトのセットを調整するためのタスクが実行されます。 すべてのコントローラーは、公式の Kubernetes サンプル コントローラーが基になっており、ドキュメントはこちらにあります。 このプロジェクトのコントローラーは、カスタム リソース定義 (CRD) オブジェクト (DedicatedGameServerCollection と DedicatedGameServer) を調整するために作成されました。

    1. DedicatedGameServerCollectionController

      これには、DedicatedGameServerCollection の DedicatedGameServer オブジェクトを処理する義務があります。

    2. DedicatedGameServerController

      これには、DedicatedGameServer オブジェクトのポッドを処理する義務があります。

    3. DGSActivePlayersAutoScalerController

      必要に応じて (コントローラーのコマンド ライン引数を使用して) 開始され、ポッドの自動スケーリング メカニズムに加わっているすべての DedicatedGameServerCollection でポッドの自動スケーリングを行います。

これらのコンポーネントは、DedicatedGameServer の名前空間と異なる、専用の名前空間 (サンプルでの名前は dgs-system) の一部です。 大規模なクラスターのシナリオでは、DedicatedGameServerCollection のリストごとに名前空間を用意できます。

パブリック IP アドレス

ゲーム クライアントは専用ゲーム サーバーに直接接続できる必要があるため、すべてのノードにはパブリック IP アドレスが必要です。 Azure Kubernetes Service では、既定ではパブリック IP アドレスは提供されませんが、この GitHub プロジェクトを使用して有効にすることができます。

デプロイ テンプレート

Azure Kubernetes クラスターを作成するには、こちらの手順に従います。

セキュリティに関する考慮事項

すべての API メソッドは、アクセス コードによって保護されています。アクセス コードは文字列として表され、apiaccesscode という Kubernetes シークレットに保持されます。 これは、プロジェクトのインストール中に作成され、すべてのメソッド呼び出しコードの GET パラメーターで渡す必要があります。 既定で認証を必要としない唯一のメソッドは、/running メソッドです。 ただし、これは API サーバー プロセスのコマンド ライン引数で変更できます。

最適化に関する考慮事項

小規模なクラスターの場合は、すべてのノードに対して単一のポッド (API サーバー サブコンポーネント、Webhook サブコンポーネント、コントローラーを含むもの) を使用することで簡略化できます。 Kubernetes クラスターでは、設計により、すべてのノードのポッドが相互に対話できます。

Sポッドの 1 つの管理セットによる AKS を使用したサーバー ホスティング

その他のリソースとサンプル

Kubernetes の公式ドキュメント

価格設定

Azure サブスクリプションをお持ちでない場合は、無料アカウント を作成して 12 か月間の無料サービスの利用を開始できます。 それらのサービスの制限を超えない限り、Azure 無料アカウントで無償で提供されているサービスに対して料金が発生することはありません。 Azure Portal または使用状況ファイルを通じて使用状況を確認する方法について説明します。

これらのリファレンス アーキテクチャの実行中に使用される Azure サービスのコストはユーザーが負担します。 その合計は使用状況によって異なります。 リファレンス アーキテクチャで使用されていた各サービスの価格は、Web ページで確認ください。

また、Azure の料金計算ツールを使用して、使用する予定の Azure サービスのコストを構成および見積もることもできます。