ゲームサーバーのライフサイクル
ノート: このページのコンテンツは、Unity Dashboard で使用可能な Multiplay Hosting に関連しています。Clanforge を使用している場合は、Clanforge のドキュメント を参照してください。
サーバーのライフサイクルは、保護されたリソースがあるマシンで実行されているプロセスとしての実行可能ビルドのライフサイクルです。3 つの異なるステージがあります。
サーバーのライフサイクルの開始と終了は、ゲームの要件によって異なります。割り当てのライフサイクル の前または直前に開始し、各 割り当て の後に終了するか、複数の割り当てにわたって継続できます。
作成
サーバーのライフサイクルの最初のステージでは、マシンに サーバースロット を作成します。サーバースロットは、実行する実行可能ビルドのリソースのプレースホルダーに似ています。Multiplay Hosting は、マシンをプロビジョニングして開始 するときに、サーバー密度 の計算に基づいていくつかのサーバースロットを作成します。サーバー密度の計算により、マシンの使用可能リソースとフリートの使用率の設定に基づいてマシンに収容できるサーバースロット数を調べます。
開始
サーバーのライフサイクルの 2 番目のステージでは、情報 (ビルドオプションや設定オプションなど) を使用して、実行可能ビルド (または Docker イメージ) を最初のステージ中に作成されたサーバースロット内のプロセスとして開始します。
サーバーがいつ開始するかは、ゲームの要件によって決まります。通常は、割り当てリクエストへのレスポンスで、または (フリートで start on provision (プロビジョニング時に開始) 設定を有効にしたかどうかに応じて) Multiplay Hosting がマシンをプロビジョニングしたときに開始します。
サーバーが開始するその他の状況は以下のとおりです。
- 割り当てを作成し、Multiplay Hosting が適切な実行可能 ビルド を実行していない サーバースロット を選択した。この場合、Multiplay Hosting は適切なビルドで実行可能ビルドを再起動します。
- 割り当てを作成し、Multiplay Hosting が不適切な ビルド設定 を使用しているサーバースロットを選択した。この場合、Multiplay Hosting は適切なビルド設定で実行可能ビルドを再起動します。
- API を使用するか Unity Dashboard を通じてサーバーを手動で開始した。
- 実行可能ビルドプロセスが クラッシュ した。この場合、Multiplay Hosting は クラッシュ を検出し、実行可能ビルドを自動的に再起動します。
- マシンが プロビジョニングプロセス を完了し、Start on provision (プロビジョニング時に開始) 設定が有効になっている場合。
- プロビジョニング時に開始設定を有効にしており、実行可能ビルドプロセスが意図的に終了された。この場合、Multiplay Hosting はサーバーを自動的に再起動します。
ノート: 割り当てペイロード を使用すると、サーバー開始動作も変更される可能性があります。
停止
サーバーのライフサイクルの 3 番目のステージでは、サーバーの実行可能ビルドプロセスを停止します。これはいくつかの道筋で発生する可能性があり、それぞれ Multiplay Hosting の異なる反応をトリガーします。内部シナリオと外部シナリオの両方がゲームサーバーの停止を引き起こす可能性があり、複数のシナリオが関係する場合があります (終了とクラッシュなど)。
内部的な停止
内部シナリオは、ゲームサーバー自体 (実行可能ビルドのプロセス) から発生するイベントです。これらのシナリオには以下のものがあります。
以下の図は、内部シナリオがサーバーの停止をトリガーするときのサーバーのライフサイクルを示しています。
意図的な終了
終了とは、0 の終了コードで実行可能ビルドプロセスが意図的に終了したことを意味します。Multiplay Hosting は、実行可能ビルドが意図的に終了したことを検出すると、サーバースロットを自動的に割り当て解除し、server.json ファイル 内の割り当て ID を消去して、サーバースロットを次の割り当て用に 準備 します。
ほとんどのゲームに推奨されるベストプラクティスは、各セッションの後に実行可能ビルドプロセスが終了するマッチメーカーフローを使用することです。このようにして終了すると、自動的な 割り当て解除 がトリガーされます。
クラッシュ数
クラッシュは、実行可能ビルドプロセスが 0 以外の終了コードで意図せず終了したことを意味します (意図的な終了 とは対照的)。Multiplay Hosting は、実行可能ビルドがクラッシュしたことを検出すると、同じ割り当て ID で再起動することでサーバーの回復を試行します。ただし、サーバーがクラッシュし続ける場合、Multiplay Hosting はその再起動を継続しません。クラッシュバックオフ を参照してください。
外部的な停止
外部シナリオは、設定、またはゲームサーバーの動作に対する反応により、API 呼び出しまたは自動化された Multiplay Hosting アクションから発生するイベントです。これらのシナリオには以下のものがあります。
- 再起動フラグが true に設定された割り当て API 呼び出し
- ゲームサーバーの動作不良
- ビルド設定の変更
以下の図は、外部シナリオがサーバーの停止をトリガーするときのサーバーのライフサイクルを示しています。
ゲームサーバーの動作不良
動作不良 とは、実行可能ビルドプロセスで何か予期しないこと (クラッシュ以外) が発生したことを意味します。通常、これは、実行可能ビルドプロセスがサーバースロットで可能な量よりも多くのリソースを使用しているか、長期にわたりクエリに応答していないことを意味します。
ノート: ビルドで クエリプロトコル を実装し、それをビルド設定で指定した場合、Multiplay Hosting はゲームサーバーがクエリに応答しているかどうかのみを確認します。
ノート: 現在割り当てられているサーバーを手動で停止しようとしても機能しません。代わりに、割り当て解除リクエストを送信する必要があります。
ビルド設定 ID の変更
割り当てを作成すると Multiplay Hosting は実行可能ビルドプロセスを再起動 (停止してから開始) し、Multiplay Hosting は間違った ビルド設定 (割り当てリクエストで指定されたもの以外のビルド設定) を使用しているサーバースロットを選択します。この場合、Multiplay Hosting は適切なビルド設定で実行可能ビルドを再起動します。サーバーによって現在使用中のビルド設定の値への変更が、すぐに反映されない場合があります。ダウンタイムなしのリリース モデルに従ってビルド設定を更新することをお勧めします。
サーバーのライフサイクルのバリエーション
共通点はありますが、すべてのゲームサーバーが同じライフサイクルをたどるわけではありません。厳密な動作は、ゲームセッションの管理方法によって異なります。最も一般的な 2 つの方法は以下のとおりです。
- マルチセッション割り当て: ゲームサーバーを継続的に割り当て、複数のゲームセッションに同じ割り当てを再利用します。
- シングルセッション割り当て: ゲームセッションが終了するたびにゲームサーバーを割り当て解除し、次のゲームセッションを新しい割り当てで開始します。
マルチセッション割り当て
マルチセッション割り当ては、複数のゲームセッションに同じ割り当てを再利用するゲームセッション管理パターンです。このパターンでは、ゲームセッション間でゲームサーバーを割り当てたままにします。ゲームセッション間でゲームサーバーの実行ファイルを終了するのではなく、ゲームサーバー状態のリセットやロビーの終了などの別の形式のクリーンアップを使用します。
ノート: マルチセッション割り当てに推奨されるベストプラクティスは、プロビジョニング時に開始設定を有効にすることです。これは、マシンプロビジョニング の完了時にゲームサーバーで割り当ての準備ができていることを意味します。
マルチセッション割り当てがあるゲームサーバーのライフサイクルでは、以下のプロセスを使用します。
- マシンのプロビジョニング: Multiplay Hosting がマシンをプロビジョニングします。
- サーバーの開始: start on provision (プロビジョニング時に開始) 設定が有効になっているため、ゲームサーバーは即時に開始します。
- サーバーの割り当て: ゲームサーバーを割り当てます。
- ゲームセッションの開始: ゲームセッション (またはマッチ) が開始します。
- ゲームセッションの終了: ゲームセッション (またはマッチ) が終了します。
- ゲームセッションのクリーンアップ: 実行可能ビルドが実行を継続し、場合によってはゲームサーバー状態のリセットやロビーの終了などのクリーンアップロジックを実行します。
- ゲームセッションの開始: ゲームセッション (またはマッチ) が開始します。
- ゲームセッションの終了: ゲームセッション (またはマッチ) が終了します。
- サーバーの割り当て解除: ゲームサーバーを割り当て解除します。
- サーバーがアイドルになる: ゲームサーバーは割り当てられていないため、アイドルになります。
- マシンの停止: Multiplay Hosting は、マシン上のすべてのゲームサーバーが生存時間より長くアイドルになると、マシンを停止します。
シングルセッション割り当て
シングルセッション割り当ては、ゲームセッションと割り当ての間に 1 対 1 の関係があるゲームセッション管理パターンです。このパターンでは、ゲームセッションが終了するたびに実行可能ビルドを終了し、ゲームサーバーを割り当て解除します。その後、次のゲームセッション用に新しい割り当てを作成します。
ノート: シングルセッション割り当てに推奨されるベストプラクティスは、プロビジョニング時に開始設定を無効にすることです。これは、ゲームサーバーはそれらを割り当てるまで開始しないことを意味します。
シングルセッション割り当てがあるゲームサーバーのライフサイクルでは、以下のプロセスを使用します。
- マシンのプロビジョニング: Multiplay Hosting が マシンをプロビジョニング します。
- サーバーがアイドル: ゲームサーバーは、割り当てられていないためアイドルです。
- サーバーの割り当て: ゲームサーバーを割り当てます。
- サーバーの開始: ゲームサーバーは割り当てられると開始します。
- ゲームセッションの開始: ゲームセッション (またはマッチ) が開始します。
- ゲームセッションの終了: ゲームセッション (またはマッチ) が終了します。
- 実行可能ビルドの終了: 実行可能ビルドは、ゲームセッションが完了し、すべてのプレイヤーが切断したことを検出すると、コード 0 で自動的に終了します。
- サーバーの割り当て解除: Multiplay Hosting は、実行可能ビルドがコード 0 で終了したことを検出すると、ゲームサーバーを自動的に割り当て解除します。
- サーバーがアイドルになる: ゲームサーバーは割り当てられていないため、アイドルになります。
- マシンの停止: Multiplay Hosting は、マシン上のすべてのゲームサーバーが生存時間より長くアイドルになると、マシンを停止します。
サーバー保留
サーバー保留は、サーバーが割り当てを受け取れるままになるか、指定された期間にわたり予約を実行できるサーバー管理パターンです。これについては、サーバー保留 セクションで説明します。