- ゲーム セッションが終了したとき (たとえば、試合が終了したときや、最後に接続していたプレイヤーが退出したとき) に、ゲーム サーバー プロセスが終了するようにしてください。ゲームでプレイヤーの再接続を許可している場合は、まず短い猶予期間を待ちます。MPS がゲーム セッションを終了することはありません。サーバーは、そのプロセスが終了するまで Active のままです。ビルドがスケールダウンしても MPS は Active サーバーを削除しないため、終了しないサーバーは料金が発生する容量を使用し続けます。プロセスが終了すると、MPS はそれを新しいサーバーに置き換えます。詳細については、マルチプレイヤー サーバーのライフサイクルを参照してください。
-
サーバーが Active になったとき (たとえば、Game Server SDK (GSDK) の
ReadyForPlayersメソッドがtrueを返したとき) にタイマーを開始します。数分以内にプレイヤーが接続しない場合は、プロセスを終了します。これにより、理由を問わず誰も参加しないサーバーが無期限に Active のままになることを防げます。タイムアウトは、プレイヤーが通常接続にかかる時間に基づいて設定してください。 - サーバーに必要なクリーンアップを行ってからプロセスを終了する GSDK シャットダウン コールバックを登録します。GSDK がプロセスを終了することはありません。ShutdownMultiplayerServer API を呼び出すと、MPS はコールバックを呼び出します。この API は、スタックしたゲーム サーバーを終了する場合など、緊急時にのみ呼び出してください。通常の状況でゲーム セッションを終了するためには使用しないでください。このセクションで前述したように、ゲーム サーバーは自ら終了する必要があります。シャットダウン要求から 15 分経過してもプロセスが実行中の場合、MPS はプロセスを強制終了します。詳細については、ゲーム サーバーの正常なシャットダウンを参照してください。
開発
- ローカル ワークステーション上での反復的なテストには、LocalMultiplayerAgent (LMA) を使用してください。すべての成果物がローカルで実行されるため、時間とコストを節約でき、デバッグも簡素化されます。このツールはオープンソース化されており、貢献や機能拡張は常に歓迎されます。詳細については、ゲーム サーバーのローカル デバッグと PlayFab との統合を参照してください。
- スケジュール を使用して、standingBy サーバーのコストを節約するための具体的なスケジュールを設定します。たとえば、すべてのテストと検証が営業時間中に実行される場合、営業時間中のみ standingby サーバーを持つようにスケジュールを設定できます。スケジュールの設定に追加コストはかかりません。
- VM メトリック または独自の プロファイラー を使用して、選択したサイズの 1 台の VM で実行するゲーム サーバーの数を決定します。VM 上のすべてのサーバーが Active でプレイヤーで満員の状態で負荷テストを行ってください。同じ VM 上のサーバーはほぼ同時に割り当てられ、ゲーム セッションを開始する場合があるため、そのケースもテストに含めてください。CPU には余裕を残してください。CPU が飽和状態の VM では、割り当てが遅くなったり失敗したりする可能性があります。
- より詳細な分析には、サーバー ログ と クラッシュ ダンプ を使用します。
ローンチ準備
- 割り当てリクエストを ビルド エイリアス に向けるようにカスタマイズします。これにより、サーバー更新の一環としてゲーム クライアントを新しいゲーム サーバーにシームレスに移行することができ、クォータの問題 (後述) の管理にも役立ちます。
- QoS Beacons を使用してゲーム クライアントに最も近いリージョンを追跡し、それを割り当てに使用します。これらは PlayFab Matchmaking と組み合わせて、類似のレイテンシを持つクライアントをグループ化し、最も近いサーバーを割り当てることもできます。
- PlayFab MPS の広範な地理的カバレッジをフルに活用して、ゲーム サーバーがプレイヤーの近くに常に配置されるようにします。リージョン障害に備えて可用性を高めるために、同一地理エリア内の複数リージョンの使用を検討してください。たとえば、NorthEurope と WestEurope にサーバーを配置し、割り当てリクエストで両方のリージョンを (優先順位順に) 指定すると、1 つのリージョンで失敗した割り当てが、リスト内の次のリージョンで成功する可能性があります。
-
ビルド エイリアスに対して割り当てる場合は、プレイヤーに許容できるエクスペリエンスを提供するすべてのリージョンを、優先順に
PreferredRegionsに列挙します。MPS はその順序でリージョンを試行し、ビルドの重みはリージョン内でどのビルドがリクエストを処理するかを決定するだけです。重みが 0 のビルドは、フォールバックとしても使用されることはありません。詳細については、他のビルドやリージョンへのフォールバックを参照してください。 -
RequestMultiplayerServer が
MultiplayerServerTooManyRequestsエラーで失敗した場合、要求されたどのリージョンでも、どのビルドにも StandingBy サーバーがなかったことを意味します。名前に反して、このエラーはリクエストがスロットリングされていることを意味するものではありません。このエラーを回避するには:PreferredRegionsに近くの複数のリージョンを列挙します。- 予想されるピークに合わせてスタンバイ サーバーを設定します。
- 各ビルド リージョンのサーバーの最大数を、予想されるピークを上回る余裕を持たせて設定します。スタンバイが不足した場合でも、MPS はその最大数を超えてサーバーを作成しません。
- ビルドで使用するすべての VM ファミリとリージョンについて、ローンチのかなり前に クォータ をリクエストしてください。新しいビルドをロールアウトする場合、古いビルドのサーバーがドレインされるまで、古いビルドと新しいビルドが同時にコアを使用するため、両方に十分なクォータをリクエストしてください。容量を分散させるために、異なる VM ファミリを使用するビルドを同じエイリアスの背後に配置することを検討してください。これにより、割り当てが同じリージョン内の別の VM ファミリにフォールバックできます。
- ゲーム サーバー用の仮想マシン SKU が、ゲームのローンチ予定のすべてのリージョンで利用可能でない場合があります。そのような場合は、エイリアスを使用してビルドを SKU とリージョンで分割するか、単一ビルド内でリージョン オーバーライドを使用して、それらのリージョンに対してのみ異なる仮想マシン SKU を選択します。
- 需要に応じてゲーム サーバーをスケールアップするために 動的スタンバイ を使用します。これをデフォルトの静的な standingBy 構成と組み合わせることで、ローンチ時の高需要に対応するコスト効率の良い方法を提供できます。
- ローンチ前にゲーム サーバーの監視を設定します。VM メトリックを有効にすると、Game Manager で VM の CPU、メモリ、ディスク、ネットワークのメトリックを確認できます。より高度な監視を行うには、VmStartupScript を使用して独自の監視ツールを VM にインストールします。VmStartupScriptGallery リポジトリには、VM メトリックとゲーム サーバー ログを Azure Monitor、Application Insights、Azure Data Explorer などのサービスに送信するサンプルがあります。
ローンチ日
- PlayFab Game Manager のダッシュボードとイベント ストリームで、ゲームの成功したローンチを追跡します。祝う時間を取ってください、あなたはそれに値します!
ローンチ後
- ゲームは需要リズムを持つ傾向があり、それをまた スケジュール に構成できます。コスト効率の良いローンチ後のゲームのスケーリングには、スケジュールを 動的スタンバイ と併用してください。
- ゲーム サーバーの更新や、新しいゲーム体験へトラフィックを徐々に移行するために、ビルド エイリアス を使用します。
-
エイリアスを新しいビルドに移行する場合は、MPS がアイドル状態の VM を解放できるように、古いビルドのスタンバイ サーバーを 0 に設定します。古いビルドは、その Active サーバーがドレインされた後にのみ削除してください。また、クライアントが要求するリージョンを、エイリアスのビルドが展開されているリージョンと同期させてください。エイリアスのどのビルドも要求されたどのリージョンにも展開されていない場合、リクエストは
MultiplayerServerNotFoundで失敗します。