Azure Batch を使用する同期マルチプレイヤー

  • [アーティクル]

ゲーム サーバー プールは、仮想マシンと開かれたポートを作成する Azure Batch によって管理されます。 各リージョンに、専用のゲーム サーバーのプールがあります。

アーキテクチャの図

SAzure Batch を使用する同期マルチプレイヤー

関連するサービス

  • Azure Traffic Manager - 待機時間に基づいて、最も適したリージョンのゾーンにプレイヤーを接続するので、選択されています。
  • Azure Batch - VM を作成し、ポートを開くために使用されます。 ユーザーが定義するパラメーターに基づいてプールを自動的にスケーリングできるため、選択されています。

Azure Traffic Manager 用に 1 つのリソース グループを使用し、各リージョンの仮想マシン クラスター用に 1 つのリソース グループを使用します。

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

仮想マシンで実行されているオペレーティング システムと、プラットフォーム イメージまたはカスタム イメージのどちらが使用されているかにより、いくつかの違いがあります。

オペレーティング システム

  • Windows

    • Windows Server 仮想マシンを稼働させてスケジュールを準備するには、Linux 仮想マシンの約 2 倍の時間を必要とします。
    • 現時点では、Windows Server 2016 より Windows Server 2012 の方がパフォーマンスが優れています。
    • Windows の有効なオンプレミス ライセンスを既に所有している場合は、SKU のコストを全額支払う必要がない場合があることに注意してください。

  • Linux

    • 稼働させてスケジュールを準備するのに要する時間は、Windows の約半分で済みます。

プラットフォーム イメージ

  • プラットフォーム/Marketplace イメージ

    • セキュリティ修正プログラムで更新されます。 これらのイメージではサポートを利用できます。
    • 使用期間の長いプールでプラットフォーム イメージを使用することの欠点は、イメージが非推奨となり、リポジトリから削除され、プールをスケールアップできなくなる可能性があることです。

  • カスタム イメージ

    • カスタム イメージのブート時間は、ソースが既に存在するカスタム ソフトウェアやデータによって大聞く変化します。
    • 利点は、OSDisk にすべてがプレインストールされたソフトウェア/データでイメージを準備できることです。
    • 3 種類のカスタム イメージ ソース ディスクのいずれかを使用できます: 1. Snapshot、2. Manageddisk、3. VHD。
      • 現時点では、Snapshot をソースにすることをお勧めします。 ストレージにはスケールの制限があり、一度に 2500 VM を超えて Azure Batch をスケーリングすることはできません。

コンテナー

Linux コンテナーでゲームをコンテナー化している場合は、コンテナーを実行するために事前に作成されたイメージがあります。 コンテナー タスクの実行をサポートするコンピューティング ノードのプールを作成し、コンテナー タスクをプールで実行する方法については、「Azure Batch で コンテナー アプリケーションを実行する」を参照してください。

利用可能な Linux イメージについては、このリンクに記載されている microsoft-azure-batch パブリッシャーを参照してください。

デプロイ テンプレート

プロジェクトを Azure サブスクリプションにデプロイするには、次のボタンをクリックします。

この操作を実行すると、Azure サブスクリプションに対する BatchWithPoolDeploy.json ARM テンプレート ファイルのテンプレート デプロイがトリガーされ、必要な Azure リソースが作成されます。 より正確な手順:

  • Azure ストレージ アカウントを作成します。
  • Azure ストレージ アカウントに関連付けられた Azure Batch アカウントを作成します。
  • D2s_v3 Windows Server 2016 上に (既定では) 5 ノードのプールを作成します。
  • プールには、ゲーム サーバーの起動に使用できる空の開始タスクがあります。

これにより、Azure アカウントの料金が発生する場合があります。

Azure サービスの名前付け規則と制限事項をまとめた記事が含まれる一般的なガイドライン ドキュメントを参照してください。

注意

ARM テンプレートの動作に興味がある場合は、このリファレンス アーキテクチャで利用されている各サービスの Azure Resource Manager テンプレートのドキュメントを参照してください。

ステップ バイ ステップの手順

  1. プレイヤーのクライアント デバイスは、Azure Traffic Manager に接続し、プレイヤーがゲーム サーバーを検索する要求をルーティングします。
  2. Azure Traffic Manager は、待機時間が最も短いリージョンのゾーンに接続し、マッチメイキングをポイントして、使用可能なゲーム サーバーを取得します。
  3. マッチメイキングには、ゲーム サーバーの選択に必要なすべての情報が保持されています。さらに容量が必要な場合は、事前に Azure Batch サービスに対して ping を実行し、スケールアウトを開始します。
  4. Azure Batch サービスは要求を受け取り、スケールアウトを開始します。自動スケーリングが設定されている場合は、設定されているルールに応じて、プロセスが事前に開始されている可能性があります。
  5. ゲーム セッションが終了し、ゲーム サーバーが使用可能になると、ゲーム サーバーは、状態の更新と最新の IP アドレスおよびポートを、マッチメイキングに定期的に送信します。
  6. 各プレイヤー デバイスは、マッチメイキングによって提供された接続情報を使用して、ゲーム サーバーに直接接続します。
  7. ゲーム セッションが終了すると、関連情報が保存されます。

スケーリング

Azure Batch の自動スケーリングを使用するサービスでは、タスクの要求が増加するとプールにノードが動的に追加され、減少するとコンピューティング ノードが削除されます。

コンピューティング ノードのプールに対して自動スケーリングを有効にするには、ユーザーが定義した自動スケーリング式にプールを関連付けます。 Azure Batch サービスでは、自動スケーリング式を使用して、ワークロードの実行に必要なコンピューティング ノードの数が決定されます。

自動スケーリングは、プールの作成時に、または既存のプールで、有効にすることができます。 自動スケーリングが構成されているプールの既存の式を変更することもできます。 Azure Batch では、プールに割り当てる前に式を評価し、自動スケーリングの実行の状態を監視することができます。

または、この例のように、マッチメイキングを使用して、Azure Batch にスケールアウトのタイミングを事前に把握させることもできます。

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

仮想ネットワークに仮想マシンの Azure Batch サービス プールを含める場合は、いくつかの要件があります。

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

Azure Batch Explorer: Azure Batch サービスと対話して、Azure Batch アカウント内のエンティティを表示、管理、監視、デバッグできるようにするツールです。 実行中のすべての仮想マシンとその現在の状態を確認するために、ヒート マップが用意されています。これを読み取る方法は次のとおりです。

  • 白いブロックは、仮想マシンがアイドル状態で、作業を割り当てる準備ができていることを意味します。
  • 黄色のブロックは、仮想マシンが起動中またはシャットダウン中で、使用できないことを意味します。
  • 緑のブロックは、仮想マシンが現在ワークロードを実行していることを意味します。
  • 赤いブロックは、仮想マシンが問題のある状態であることを意味します。

価格設定

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

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

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