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

この例では、ゲーム サーバー プールは、Azure Virtual Machine Scale Sets を作成して調整する Azure Service Fabric によって管理されています。 各リージョンに、専用のゲーム サーバーのプールがあります。

アーキテクチャの図

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

関連するサービス

  • Azure Traffic Manager - 待機時間に基づいて、最も適したリージョンのゾーンにプレイヤーを接続します。
  • Azure Service Fabric - コンテナー内のスケーラブルで信頼性の高いゲーム サーバーを簡単にパッケージ化、デプロイ、管理できるようにします。

デプロイ テンプレート

カスタマイズして独自のクラスターのセットアップに使用できる、サンプルの Service Fabric クラスター テンプレートについては、このリポジトリを参照してください。 目的は、入力と他の開発者が作成したクラスターの種類に基づいて、さまざまなテンプレートを提供することです。 テンプレートでは、Windows と Linux の両方のクラスターがカバーされています。

最初に使用する最も基本的なテンプレートは、このテンプレートです。 このテンプレートでデプロイできるセキュリティで保護された 5 ノードは、単一ノード タイプの Service Fabric クラスターで、Standard_D2_v2 サイズの仮想マシン スケール セット上のコンテナーで Windows Server 2016 Datacenter を実行しており、Azure Diagnostics がオンになっていて、ネットワーク セキュリティ グループが有効になっています。

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

この操作を実行すると、Azure サブスクリプションに対する azuredeploy.json ARM テンプレート ファイルのテンプレート デプロイがトリガーされ、必要な Azure リソースが作成されます。 これにより、Azure アカウントの料金が発生する場合があります。

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

ゲーム サーバーのバイナリは、Azure Storage または Azure Container Registry に格納できます。Service Fabric はどちらでも使用できます。

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

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

必要に応じて、ゲーム セッションが終了した後、関連する情報を Azure ストレージ アカウントに格納できます。

スケーリング

次の 2 つの主要な方法があります。

  1. マッチメイキングはスケーリングを制御しません。 代わりに、Azure Service Fabric 自動スケーリングを使用して、Azure Service Fabric がスケーリング要件を所有します。 この場合、サービスは、サーバーが報告する負荷に基づいて、またはリソースの使用状況に基づいて、ゲーム サーバーを動的にスケーリングします。 自動スケーリングを使用すると、優れた弾力性が得られ、必要に応じて、ゲーム サーバーの追加インスタンスまたはパーティションをプロビジョニングできます。 自動スケーリング プロセス全体は自動化されていて透過的であり、ポリシーを設定した後は、ゲーム サーバー レベルで手動スケーリング操作を行う必要はありません。 自動スケーリングは、作成時に、または更新を通じていつでも、有効にすることができます。

    自動スケーリングが役立つ一般的なシナリオは、マルチプレイヤー ゲームのように、時間の経過と共に負荷が変化する場合です。

  2. または、この例のように、マッチメイキングを使用して、Azure Service Fabric にスケールアウトのタイミングを事前に知らせることもできます。ベスト プラクティスは、プール管理パターンを使用することです。

    このパターンでは、アプリケーションが実行時に Service Fabric サービスのインスタンスを動的に作成する機能を必要とする状況に対してソリューションが提供されます (特に CreateServiceAsync を呼び出すことによって)。 これにより、管理する必要があるサービスを登録でき、構成されているサービスの使用可能インスタンス数をプールで確実に使用できます。

    デプロイおよび初期化されたゲームは、マネージャーを呼び出して、サービスのインスタンスを "要求" します。マネージャーは、一意の ID によって決定される、ゲームで以前に使用されていたインスタンス、またはまだ割り当てられていない使用可能なインスタンスを返すことにより、使用できるインスタンスへのポインターを返します。 一定期間アイドル状態のままになっているサービスのインスタンスがある場合、マネージャーはそれらを非アクティブ化してクラスター内の追加容量を解放します。

    このパターンを使用する主な利点は、新しいインスタンスを手動でインスタンス化するときに、ゲームの遅延時間が大幅に短縮されることです。

スケーラブルなゲームを構築する方法については、「Service Fabric での拡大縮小」を参照してください。

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

Azure Service Fabric のゲームとクラスターを正常に管理するには、信頼性を最適化するために実行することが推奨される操作があります。 セキュリティ、ネットワーク、コアとしてのインフラストラクチャ、監視などについて説明されているこのドキュメントを参照してください。

価格設定

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

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

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