フリートサイズの最適化

Last updated on February 4, 2026

注釈：本資料はAI技術を用いて翻訳されています。

はじめに

AccelByte Multiplayer Servers（AMS）では、フリート内の専用サーバーの数が自動的にスケールアップおよびスケールダウンし、1日の異なる時間帯におけるプレイヤー数の変動に応じてサーバーの需要の変動に追従します。スケーリングはリージョンごとに独立して行われます。そのため、専用サーバーを実行したい各リージョンに対してスケーリング戦略を設定できます。

このガイドでは、AMSでフリートに適切なスケーリング戦略を設定する方法について説明します。これらの値を適切に設定し、常に十分な専用サーバーを準備することで、スムーズなプレイヤー体験を保証しながら、リソース使用量とコストも最適化できます。

フリートサイズの最適化

フリートを作成または設定する際、DS Host & Regionセクションでそのサイズを設定します。フリートの作成ガイドのステップ9を参照してください。

すべてのフリートスケーリング設定は、専用サーバーの数で定義されます（ホストインスタンスではありません）。AMSは適切な数のホストインスタンスの実行を自動的に処理します。

不適切なスケーリング戦略により、プレイヤーが専用サーバーをクレームできなくなる可能性があります。このようなクレーム失敗の一般的な原因は、最大値またはバッファサイズが不十分であることです。フリートが必要なだけのDSを生成していないことに気づいた場合は、まず最大値が十分であることを確認してから、バッファサイズを確認してください。

フリートのスケールは次のように設定することをお勧めします。

インスタンスあたりの専用サーバー数

Dedicated Serversフィールドで、ホストインスタンスあたりの専用サーバー数を指定します。大きなマシンは、インスタンスあたりより多くの専用サーバーを収容できます。

フリートは、最小および最大サーバー数（以下で説明）をインスタンスあたりのサーバー数の最も近い倍数に丸めることで、ホストインスタンスの利用を最適化することに注意してください。これにより、効率的なリソース割り当てが保証され、アカウントに請求されるホストインスタンス内の未使用容量が防止されます。

たとえば、インスタンスあたり5台のサーバー、最小3台のサーバー、最大28台のサーバーの場合、フリートはこれらの値をそれぞれ5と30に調整します。

さらに、バッファ値で追加の仮想マシンリクエストが必要な場合、この新しいインスタンス内のすべての5台の専用サーバーがバッファとして指定されます。

最大サーバー数

Max Servers値は、特定のリージョン内で実行できるサーバーの最大数を定義します。この値はコスト保護として機能し、ゲームサーバーの費用が予算を超えないようにします。この値は、「Creating」、「Ready」、または「Claimed」のすべての状態のサーバーをカウントします。

important

Max Serversはハード制限です。フリートはこの数を超えてスケールしません。その結果、不十分な値は、プレイヤーがマッチ用の専用サーバーを取得できないクレーム失敗につながる可能性があります。

Max Serversの妥当な見積もりは、ピーク使用期間中に予想される最大同時接続プレイヤー数（ピークCCU）を収容するために必要なサーバー数（少なくとも）です。

• 式：Max Servers >= Peak CCU / Players per Server

Max Serversを予想されるピークCCUを超えて、予算が許す限り高く設定することをお勧めします。このアプローチにより、ピークCCUが初期見積もりを超えた場合でもプレイヤーが専用サーバーを取得できることを保証しながら、ピークCCUが見積もりを超えない場合は追加コストが発生しません。

最小サーバー数

Min Servers値は、リージョン内で常に実行されている必要があるサーバーの最小数を指定します。この設定により、アクティビティが少ない期間でも、受信するプレイヤーリクエストを処理するために一定数のサーバーが利用可能であることが保証されます。

ほとんどのシナリオでは、Min Serversを0に設定し、代わりにバッファを設定することをお勧めします。この設定により、動的スケーリングが可能になり、フリートが変動するプレイヤー需要に効率的に適応できます。ただし、プレイヤーの突然の流入が予想されるローンチやイベント中は、より高いMin Servers値が有用です。このアプローチにより、初期のプレイヤー流入を処理するのに十分な準備済みサーバーが確保されると同時に、プレイヤーの増加が初期ラッシュ後に安定すると予想されるため、必要ない可能性のある過度に大きなバッファサイズを回避できます。

バッファサイズ

バッファサイズは、ゲームセッションがすぐにクレームできるように、フリートが「Ready」状態に保つ必要があるサーバーの数をフリートに指示します。新しいサーバーの起動には1〜10分かかる場合があり、これはプレイヤーにとって容認できない待ち時間です。DS作成時間には、AMSが新しいホストインスタンスを初期化し、専用サーバーイメージをダウンロードし、起動してAMS Watchdogに接続することが含まれます（ベアメタルサーバーは初期化する必要はありませんが、イメージのダウンロードと起動には時間が必要です）。

バッファサイズをどの程度高く設定するかを決定する際には、DS作成時間を10分と想定することをお勧めします。需要の増加に対してバッファサイズが小さすぎると、ゲームはサーバーを待たなければなりません。

注記

開発フリートの場合、バッファ設定は通常、1からVMあたりの専用サーバー数の間で最もうまく機能します。

• 1に設定すると、既存のすべてのVMがいっぱいになるまで新しいVMは起動しません。
• VMあたりの専用サーバー数と同じ数に設定すると、既存のVMのいずれかのサーバーがクレームされるとすぐに新しいVMが起動します。

一般的に、バッファ設定のDS数に対して既存のVMに十分なスペースがない場合、新しいVMが起動します。

バッファサイズの見積もり

必要なバッファサイズは、需要がどの程度速く変化するか、および新しいサーバーの起動にかかる時間によって異なります。次の式に従います。buffer = <単位時間あたりの需要の変化> x <DSの起動にかかる最大時間>

式の意味は次のとおりです。

• <単位時間あたりの需要の変化>は、2つの時点でのクレームされたサーバー数の差です。
  • これを決定するために使用される式は(<t2時点の需要> - <t1時点の需要>)/(t2-t1)です。 <t1時点の需要>と<t2時点の需要>は、期間の開始時と終了時のクレームされたサーバーの予想数です。
  • t1とt2は、それぞれ需要の増加が計算される期間の開始時刻と終了時刻です。
• <DSの起動にかかる最大時間>は、新しいサーバーの起動にかかる推定最大時間です（最大10分）。

ライブゲームプロダクションでは、バッファ要件は長期的な（日周期）変動よりも短期的な（最大10分）クレームされたサーバー数の変動によって主に決定されることがわかります。言い換えれば、リージョンの昼夜サイクルによって引き起こされる需要の傾向は、1〜10分以内に発生する需要の変化と比較すると無関係になります。この短期的な変動は、プレイヤーがマッチに出入りするなど、いくつかの要因によって引き起こされます。1つのマッチを終了した「In-Session」サーバーが新しい「Ready」サーバーに置き換えられるまでに短い遅延があるという事実を考慮すると、見かけ上安定した需要がある場合でもバッファが必要です。このため、以下のGrafanaメトリクスを使用したバッファサイズの見積もりで説明する需要の短期的な変動に基づいてバッファサイズを設定することをお勧めします。 :::

図解として、次の画像は、需要がどれだけ速く変化するかを示し、長期的な傾向と短期的な変動の違いを示しています。クレームされたサーバー数の突然のジャンプが見られます。バッファは、この増加を処理するための「Ready」サーバーを提供します。

Grafanaメトリクスを使用したフリートサイズの最適化

AMSは、フリートのパフォーマンスに関する貴重な洞察を提供するGrafanaダッシュボードを提供します。これらのダッシュボードは、フリートサイズの最適化とスケーリングリソースの際にデータ駆動型の意思決定を行うのに役立ちます。これらのダッシュボードの包括的なガイドについては、AMS Dashboardsドキュメントを参照してください。

AMS Fleet Overviewダッシュボードは、各リージョンの詳細情報を提供します。

ダッシュボード情報を次のように使用します。

• Namespace claim failure rate：クレーム失敗が表示されている場合、プレイヤーが専用サーバーを取得できなかったことを意味します。そのリージョンに十分な「Ready」専用サーバーがあるかどうかを確認してください。また、そのリージョンでクレームが予想されていたかどうかも検討してください。場合によっては、誤ったセッションテンプレートを示している可能性があります。上記の例では、クレーム失敗率は0であり、これは良好です。

• Running DS：任意の時点でクレーム状態にある専用サーバーの数をメモし、現在のバッファサイズが十分かどうかを評価します。さらに、準備済みサーバーの数が常に多いなど、無駄なリソースの兆候を探します。その場合は、バッファサイズを減らすことを検討してください。

• Buffer size recommendation：過去数日間にフリートに実際に必要なバッファの量をより良く把握できます。次のセクション「ライブゲームデータからGrafanaを使用したバッファサイズの設定」で説明されているように、AMS Buffer Sizingダッシュボードを使用します。

ライブゲームデータからGrafanaを使用したバッファサイズの設定

AMS Buffer Sizingダッシュボードは、ゲームの履歴データに基づいてバッファサイズを推奨します。このダッシュボードを表示する際、fleet_idを提供することで特定のフリートのデータを表示するオプションがあります。このダッシュボードの詳細については、AMS Dashboardsドキュメントを参照してください。

ダッシュボードは、各リージョンに必要な（「推奨」とラベル付けされた）バッファサイズを示しています。これは、専用サーバーの傾向とクレームされたサーバーの短期的な変動に基づいて必要だったであろうバッファのサイズです。

注記

• 最初は、このダッシュボードを効果的に使用するのに十分な履歴データがない場合があります。最初の1〜2日間は、わずかに大きめのバッファで開始することをお勧めします。その後、ダッシュボードデータでバッファサイズを調整します。ローンチ中に最小設定を使用することもできます。
• バッファ要件はゲームによって異なります。クレームされたDSのピーク数（<ピークCCU> / <サーバーあたりのプレイヤー数>）の10％から20％のバッファをよく見かけます。一部の（まれな）シナリオでは、50％にもなることがあります。これを出発点として使用しますが、データに基づいて調整してください。

適切なバッファサイズを見つけるには、グラフ上のRecommended buffer size setting (max over 24h)と呼ばれる黄色の線を使用します。この線は、過去24時間の短期的な増加の1〜10分以内のクレームされた専用サーバーの最大増加を示しています。過去数日間のその値をメモして、バッファ要件の目安を得てください。

最適なバッファサイズを得るには、過去数日間のこの線の最大値を選択することをお勧めします（上記の例では13台の専用サーバー）。ただし、最近のイベントが現在のデータを将来の需要のより有効な予測因子でなくなる方法でデータに影響を与えたかどうかも考慮する必要があります。サーバーの可用性を確保することと、リソースの無駄を避けることのバランスを見つけてください。これは、アイドル状態のサーバーを多く持ちすぎることなく、プレイヤーが簡単にプレイできるようにすることを意味します。

プレイヤー人口のコスト最適化のためのフリート分割

リージョン間でプレイヤー人口が大きく異なる場合は、コストを削減するためにフリートを分割することを検討してください。高人口リージョンと低人口リージョンの両方にサービスを提供する単一のフリートの代わりに、低人口リージョン用に小さいインスタンスタイプを持つ別のフリートをデプロイします。

1. 小さいインスタンスタイプを使用して、低人口リージョンに新しいフリートを作成します。
2. 元のフリートから同じクレームキーを新しいフリートに割り当てます。
3. 新しいフリートをアクティブ化します。
4. 元のフリートの低人口リージョンを無効にします。

ベストプラクティス

• 使用状況の監視：フリートの使用状況を定期的に監視し、可用性とコストを最適化するために必要に応じて最大サイズとバッファサイズを調整します。
• クレーム失敗の監視：GrafanaのAMSダッシュボードでクレーム失敗を定期的に確認します。
• ピークの計画：履歴データと予想されるプレイヤーアクティビティを考慮して、適切な最大サイズとバッファサイズを設定します。

次のステップ

フリートの管理やその他の設定の構成の詳細については、専用サーバーをデプロイするフリートの作成ページを参照してください。