サーバー保留
Understand the server hold feature and how it preserves resources for your game servers.
読み終わるまでの所要時間 2 分最終更新 25日前
サーバー保留とは、サーバーが割り当てを受け入れられる状態を保つ (つまり指定された期間の予約が実行される) 管理パターンです。
ほとんどのケースで、サーバー保留を開始する機能は、予約ベースのフリートのみに適用されます。ただし、割り当てを処理するフリートでも使用できます。
問題のコンテキスト
予約ベースのフリートでは、Multiplay Hosting は、これから発生するマッチに対して最適なサーバーを選択できません。割り当てベースのフリートのように効率よくスケールできないため、予約済みサーバーが断片化して多くのマシンに残ってしまうことがあります。予約済みサーバーがないマシンについては、事前設定済み TTL に基づいて停止と削除が検討されます。 予約済みサーバーが断片化している可能性があるために、Multiplay Hosting が予約ベースのフリートのコストを効率よく最適化することが難しくなります。TTL を短縮すると、未使用のマシンをさらに迅速にプロビジョニング解除 (それによってコストを削減) できますが、サーバーライフサイクルを注意深く管理しないと、TTL が短いマシンが停止中に多くの予約リクエストを受け取り、ゲームセッションの中断を引き起こす可能性が高くなります。例えば、プレイヤーがサーバーに参加しても、そのサーバーがまもなく停止する場合があります。これは、マシン待機中終了 TTL を長くすればサーバー保留ソリューションなしで解決できますが、これにはコストがかかります。解決策
サーバーを保留すると、サーバーが実行されているマシンを、事前設定済み TTL が経過しても存続させておくことができます。保留タイムアウトはサーバーごとに設定できます。ただし、Multiplay Hosting の観点では、マシンをプロビジョニング解除するかどうか決定する際に、最も先のタイムアウトが考慮されます。サーバーを保留することで、使用可能なサーバー数に悪影響を及ぼすことはありません。サーバー保留が影響するのはプロビジョニング解除のみであり、新しいマシンのプロビジョニングには影響しません。 Multiplay Hosting では以下の動作が推奨されます。- サーバーを保留する期間が、以下の 1 つまたは組み合わせに基づくようにします。
- 平均マッチ時間: マッチを終了したプレイヤーは別のサーバーに参加できます。
- 現在または少し先のサーバー需要: トラフィックの急上昇はゲーム開発者によって予測されます。
- 新しいプレイヤーを受け入れるまでの平均時間: サーバーがこの時間内にプレイヤーを受け入れなかった場合は、容量が必要とされていない可能性があります。
- サーバー保留期間は、サーバーによって定期的に確認され、必要に応じて更新されます。
- 容量が必要なくなると、サーバー保留は削除されます。
- さらに効率的なスケーリング: マシンの停止と削除をさらに迅速かつ安全に行うことができます。
- ゲームセッションの保証: 予約済みとなったサーバーは、事前に保留されていた場合に限り存続することが保証されます。
- サーバーライフサイクルの改善: サーバーのライフサイクルは、Multiplay Hosting ではなくゲームスタジオによって細かく制御されます。
サーバー保留の実行
サーバー保留の作成、表示、削除は、ローカルプロキシ上で関連するエンドポイントを実行して行うことができます。API ドキュメントは こちら にあります。 サーバー保留を作成することで、問題のサーバーがHELDALLOCATEDRESERVEDサーバー保留の失効
上記のドキュメントに指定されているDELETE- 最新の保留リクエストに指定されたタイムアウトを超過している (サーバーが 状態に遷移する)
ONLINE - サーバーが割り当てられている (サーバーが 状態に遷移する)
ALLOCATED - サーバーが予約済みになっている (サーバーが 状態に遷移する)
RESERVED - サーバーが手動で停止されている (サーバーが 状態に遷移する)
AVAILABLE - サーバーが手動で再起動されている (サーバーが 状態に遷移する)
ONLINE - アクティブなビルド設定が変更されている (サーバーが 状態に遷移する)
ONLINE
- サーバー自体がいずれかの戻りコードで終了したとき
HELD