専用サーバーを展開するためのフリートを作成する
注釈:本資料はAI技術を用いて翻訳されています。
Shared Cloudのお客様の場合、AccelByte Multiplayer Servers (AMS)は制限付きの無料トライアルとして利用できます。詳細については、AMSのShared Cloud無料トライアル特典を参照してください。
はじめに
フリートは、リージョンごとのスケーリング設定に基づいて、ホストインスタンスをスケーリングし、それらのホストインスタンス内で実行されている専用サーバー(DS)を管理します。
この記事では、Admin Portalを使用して、ニーズに合わせてAMSでフリートを作成およびカスタマイズする方法について説明します。
フリート作成を自動化する方法については、フリート作成を自動化する方法(Extendを使用)を参照してください。
前提条件
このガイドを始める前に、以下が必要です:
- AMSアカウントをセットアップしていること。
- 専用サーバーをAccelByte Gaming Services (AGS) Game SDKと統合していること。
- 専用サーバービルドをAMSにアップロードしていること。
リージョンの有効化
フリートで専用サーバーを実行するために必須ではありませんが、AGSマッチメイキングを使用している場合は、プレイヤーが専用サーバーを使用できるようにしたいリージョンのQoSを有効にする必要があります。
利用可能なリージョンのQoSを有効にするには:
- AccelByte Admin Portalでゲームネームスペースに移動します。
- サイドバーでAMS > QoS Regionsを選択します。
- QoS Regionsリストで、プレイヤーが利用できるようにしたいリージョンのトグルボタンをオンにします。
フリートタイプ
AMSは2種類のフリートをサポートしています:
プロダクション
プロダクションフリートはライブゲーム用に最適化されており、常に消費可能な専用サーバーのバッファを維持することで、プレイヤーに専用サーバーを迅速かつ効率的に割り当てるように設計されています。これは、新しいフリートを作成する際のデフォルトのフリートタイプです。プロダクションフリートは、専用サーバーイメージやコマンドライン引数などの不変属性も使用して、専用サーバーの展開を破壊し、ライブゲームのプレイヤーに悪影響を与える可能性のある偶発的な変更を防ぎます。
開発中にプロダクションフリートを使用することは完全に問題なく、場合によっては最良のアプローチかもしれません。
開発
開発フリートは、同じVM セット上で複数の専用サーバーバージョンとコマンドラインの組み合わせを実行できるようにすることで、開発中により柔軟性とコスト効率を提供します。これにより、複数の専用サーバーバージョン、ゲームモード、マップなどをテストするために必要なホストインスタンスの数を最小限に抑えることで、開発中のコストを削減できます。開発フリートは、専用サーバーイメージとコマンドライン引数をフリートから切り離し、専用サーバーのクレームフローで専用サーバーイメージとコマンドライン引数を遅延バインドできるようにすることで、これを実現します。開発フリートは、要求されるまでどの設定を実行するかわからないため、準備完了状態の専用サーバーの完全なバッファを維持できません。ただし、開発フリートは、特定の専用サーバー設定が要求されるとすぐに専用サーバーを起動するために必要なバッファを供給するのに十分なVM容量を維持します。
追加のコスト効率のために、開発フリートは、一致するクレームリクエストまたは実行中のDSがない設定された期間が経過した後、「休止」するように設定できます。開発フリートが休止状態になると、その有効バッファはゼロに設定され、ウォッチドッグがドレインされ、VMが解放されます。一致するクレームリクエストが入ってくると、以前に設定されたサイズが復元されます。
開発フリートは、AGS公式ドキュメントおよびAdmin Portalでは簡潔に「Build Configurations」と呼ばれる、Development Server Build Configurationsと連携して動作します。Build Configurationsは、専用サーバーイメージとコマンドライン引数で構成され、関連する開発フリートで指定されたコマンドライン引数に追加されます。Build Configurationを作成して開発フリートに関連付ける方法については、開発フリートでビルド設定を使用するを参照してください。
プロダクションシナリオでは開発フリートを使用しないでください。
フリートの作成
AMSは、需要があるときはいつでも専用ゲームサーバーを起動できます。ただし、AMSが効率的にそれを行う前に、専用ゲームサーバーを最適に実行する方法、およびいつどこで実行するかに関するすべての必要なデータが必要です。フリート作成プロセスにより、AMSがフリートを管理するために必要なすべての情報を提供したことが保証されます。
フリートを作成するには、次の手順に従います:
-
AccelByte Admin Portalでゲームネームスペースに移動します。
-
サイドバーで、AMSメニューを開き、Fleet Managerを選択します。Fleet Managerページが表示されます。
-
Create Fleetボタンにカーソルを合わせて、Create Newを選択します。Create Fleetフォームが表示されます。
-
Fleet & Imageセクションで、ネームスペース内で一意である必要があるフリートの名前を入力します。次に、フリートのタイプに応じて、次のいずれかを実行します:
- プロダクションフリートの場合、アカウントにアップロードされた1つの専用サーバーイメージを選択します。フリートは、このイメージに基づいて専用サーバーを起動します。イメージIDまたはイメージ名を使用してイメージを検索できます。
- 開発フリートの場合、Development Fleetの横にあるスライダーをクリックします。次に、Hibernate featureスライダーを使用して休止を有効にするかどうかを決定します。休止が有効になっている場合、Set hibernate time入力を使用して休止が行われる期間を選択します。
-
Nextをクリックして、Deployment Profileセクションに移動します。
-
Deployment Profileセクションで、必要に応じてタイムアウト値、ポート設定、コマンドラインを調整します。
タイムアウト
-
Creation Timeout: 作成タイムアウトは、ローカルウォッチドッグが専用サーバーを起動し、その状態を「Creating」としてマークしたときにカウントを開始します。このタイムアウトは、専用サーバーが初期化するための設定可能な時間制限を提供し、専用サーバーが初期化に失敗した場合、AMSはサーバーを削除して新しいものと交換します。
- 作成タイムアウトは、専用サーバーが「Creating」状態にある場合にのみ適用されます。専用サーバーがゲームセッションをホストする準備ができたことをウォッチドッグに通知すると、「Ready」状態に入ります。
-
Claim Timeout: クレームタイムアウトは、専用サーバーが「Ready」状態に入ったときにカウントを開始します。これは、ゲームセッション用にクレームされる前に専用サーバーがアイドル状態のままでいる時間制限を提供し、ウォッチドッグが時間の経過とともに劣化する可能性のあるアイドルサーバーを削除して新しいものと交換できるようにします。
-
Session Timeout: セッションタイムアウトは、専用サーバーがゲームセッションによってクレームされ、「In Session」状態に入ったときにカウントを開始します。これは、専用サーバーがゲームセッションを提供するための時間制限を提供し、ゲームセッションが終了した後に正常に終了しない古いサーバーをウォッチドッグが削除できるようにします。
-
Drain Timeout: drainタイムアウトは、アクティブなゲームセッションを提供していない専用サーバーがローカルウォッチドッグからdrainシグナルを受信したときにカウントを開始します。drainシグナルは、専用サーバーが実行されているVMが削除される予定であることを通知し、ウォッチドッグが強制的に終了する前に、必要不可欠な作業を完了して終了するための設定可能な期間を提供します。セッションを提供しているDSは、drainタイムアウトの対象にはならないことに注意してください。
-
Unresponsive Timeout: 無応答タイムアウトは、サーバーがAMSウォッチドッグにタイムリーなハートビートを送信しないために無応答状態になったときにカウントを開始します。設定されたタイムアウト中、専用サーバーは回復を試み、ウォッチドッグに再びハートビートを送信することが期待されます。ハートビートを受信する前にタイムアウトを超えた場合、AMSはサーバーを削除して新しいものと交換します。
ポート設定
専用サーバーがリスニングするポートを追加します。作成するポートの実際のポート値は、実行時に生成されます。デフォルトポートはフリート用に自動的に作成され、編集または削除できません。
コマンドライン
コマンドラインボックスに、専用サーバーのコマンドライン引数を追加し、専用サーバーが目的の設定で実行するために必要な追加パラメータを指定していることを確認します。コマンドの構築方法については、専用サーバーコマンドラインの構築を参照してください。
-
-
Nextをクリックして、DS Host & Regionセクションに移動します。
-
DS Host & Regionセクションで、専用サーバーを実行するインスタンスタイプと、インスタンスで実行する専用サーバーの数を選択します。フリートに最適なインスタンスタイプを選択する際の考慮事項については、AMSフリートのインスタンスタイプの選択ガイドラインページを参照してください。 次に、フリートのスケーリング戦略を設定します。フリートで専用サーバーを実行する各リージョンについて、min、max、bufferサイズ(インスタンス数ではなく、専用サーバー数)を次のように設定します:
- Min Servers: このリージョンで常に実行される最小DS数。バッファ値を設定すると仮定すると(推奨)、最小サイズは通常0で十分です。最小値の設定は、設定されたバッファを圧倒するような初期の大量のプレイヤー流入が予想される場合(ローンチを含む)のイベント前に役立ちます。
- Max Servers: リージョンで実行する最大DS数。これは、ゲームサーバーのコストが予算を超えないようにするための安全策です。プロダクションフリートの場合、ピーク時に予想されるプレイヤー数に対応する必要があります。つまり:
max = <ピークCCU> / <DS あたりのプレイヤー数>。 - Buffer Servers: 需要の増加に動的に対応するための追加インスタンス。フリートは、ゲームセッションによってクレームされる準備ができている「Ready」状態のこの数のDSを維持します。これにより、需要が増加する期間(プレイヤー数の増加など)に、フリートが負荷を処理するための追加DSを作成します。プロダクションフリートの場合、適切なバッファサイズの選択方法については、以下にリンクされているガイドを確認してください。
- スケーリング戦略が正しく設定されていないと、プレイヤーがマッチ用のDSをクレームできなくなります。最大サイズまたはバッファサイズが不十分であることは、クレーム失敗の一般的な原因です。特定のゲーム要件に合わせてフリートサイズを調整する方法の詳細については、フリートサイズの最適化ページを参照してください。
- フリートは、最小サーバーと最大サーバーをインスタンスあたりのサーバー数の最も近い倍数に丸めることで、AMSインスタンスの使用率を最大化します。これにより、アカウントに請求されるAMSインスタンスに無駄なリソースがないことが保証されます。たとえば、インスタンスあたり5サーバー、最小3、最大28の場合、フリートはそれぞれ5と30に調整されます。さらに、バッファ値によって追加の仮想マシンが要求される場合、新しいインスタンス内のすべての5つの専用サーバーがバッファになります。
- 開発フリートの場合、ほとんどの場合、VMあたりのDS数として設定した数と1の間のバッファ設定が適切です。1に設定すると、既存のVMがすべて満杯になるまで新しいVMは起動しません。DS/VM設定と等しい設定では、既存のすべてのVMにクレームされたDSが存在するとすぐに新しいVMが起動します。一般的に、既存のVMにバッファ設定で設定されたDS数を収容するスペースがない場合、新しいVMが起動します。
-
Nextをクリックして、Logs & Artifacts Samplingセクションに移動します。
-
Logs & Artifacts Samplingセクションで、専用サーバーのログとアーティファクトを収集するためのサンプリングルールを設定します。サンプリングルールについては、サンプリングルールセクションを参照してください。
-
Nextをクリックして、Summaryセクションに移動します。
-
フリート設定を確認してから、Createボタンをクリックします。Create Fleetポップアップが表示されます。
-
(オプション)ポップアップで、作成後すぐにフリートをアクティブ化するオプションがあります。この手順をスキップして、後でフリートをアクティブ化または非アクティブ化できます。
-
Createをクリックしてフリートを作成します。フリートはすぐにFleetsリストに追加されます。
専用サーバーコマンドラインの構築
いくつかの必須フラグを除いて、独自の専用サーバーコマンドラインを自由に構築できます。
開発フリートは、プロダクションフリートとは少し異なる動作をします。開発フリートの専用サーバーコマンドラインは、フリートのコマンドラインに関連するBuild Configurationのコマンドラインが追加されたものの組み合わせです。必須フラグが開発フリートのコマンドラインまたはBuild Configurationのコマンドラインのいずれにも指定されていない場合、フリート内のビルド設定で専用サーバーは正常に起動しません。
必須フラグは次のとおりです:
- Unreal
- Unity
-dsid=${dsid} -port=${default_port} -watchdog_url=${watchdog_url}
-ABDsId, -dsid: 専用サーバーID
dsidは、フラグ-ABDsId ${dsid}または-dsid ${dsid}によって専用サーバーに渡される必要があります。フラグの使用法はSDKでカバーされています。
-ABPort, -port: ポート
ポートは、任意の形式のフラグで専用サーバーに渡すことができます。ポートの置換変数は、次の形式に従います: ${<<your_port_name_in_lowercase>>_port}。
-ABWatchdogUrl, -watchdog_url: ローカルウォッチドッグへのURL
ウォッチドッグは、ホスティングマシン内の専用サーバーの監視エージェントです。SDKは、URLを使用してウォッチドッグに自動的に接続します。
プレフィックスとして-ABを使用すると、AGS Unreal SDK設定を注入する機能が追加されます。したがって、次を呼び出すことで、値を取得して必要に応じて使用できます:
auto ServerApiClient = AccelByteOnlineSubsystemPtr->GetServerApiClient();
ServerApiClient->ServerSettings->AMSServerWatchdogUrl;
ServerApiClient->ServerSettings->DSId;
ServerApiClient->ServerSettings->StatsDServerPort;
スニペットで使用されているAccelByteOnlineSubsystemPtrを取得するには、この[ガイド]に従ってください。
-dsid ${dsid} -port ${default_port} -watchdogUrl ${watchdog_url}
-ABDsId, -dsid: 専用サーバーID
dsidは、フラグ-ABDsId ${dsid}または-dsid ${dsid}によって専用サーバーに渡される必要があります。フラグの使用法はSDKでカバーされています。
-ABPort, -port: ポート
ポートは、任意の形式のフラグで専用サーバーに渡すことができます。ポートの置換変数は、次の形式に従います: ${<<your_port_name_in_lowercase>>_port}。
-ABWatchdogUrl, -watchdogUrl: ローカルウォッチドッグへのURL
ウォッチドッグは、ホスティングマシン内の専用サーバーの監視エージェントです。SDKは、URLを使用してウォッチドッグに自動的に接続します。
プレフィックスとして-ABを使用すると、AGS Unity SDK設定を注入する機能が追加されます。したがって、次を呼び出すことで、値を取得して必要に応じて使用できます:
var dsid = AccelByteSDK.GetServerRegistry().Config.DsId;
var port = AccelByteSDK.GetServerRegistry().Config.Port;
var watchdogUrl = AccelByteSDK.GetServerRegistry().Config.WatchdogUrl;
置換用の追加変数
さらに、AMSは専用サーバーコマンドラインで次の変数の変数置換をサポートしています:
| 変数名 | 説明 |
|---|---|
${creation_timeout} | フリートで定義されている作成タイムアウトの値に展開されます。 |
${session_timeout} | フリートで定義されているセッションタイムアウトの値に展開されます。 |
${drain_timeout} | フリートで定義されているdrain idle timeoutの値に展開されます。 |
${unresponsive_timeout} | フリートで定義されている無応答タイムアウトの値に展開されます。 |
${artifact_path} | 再帰的に収集されるアーティファクトディレクトリの絶対パスの値に展開されます。 |
サンプリングルール
サンプリングルールは、このフリートによって管理される専用サーバーのログ、カスタムアーティファクト、コアダンプをいつ収集するかをAMSに指示します。サンプリングルールは、アーティファクトタイプと専用サーバーの終了ステータスによって定義されます。
設定可能なルールは3つあります:
- ステータス0(成功)で終了する専用サーバーの_ログ_と_カスタムアーティファクト_を収集する割合
- ステータス > 0(失敗)で終了する専用サーバーの_ログ_と_カスタムアーティファクト_を収集する割合
- ステータス > 0(失敗)で終了する専用サーバーの_コアダンプ_を収集する割合
UIのEnable Log Samplingセクションは、ログとカスタムアーティファクトの両方に適用されます。UIのEnable Artifacts Samplingセクションは、コアダンプにのみ適用されるため、異常終了サンプリングレートのみが適用されます。これが混乱を招くことは認識しており、今後のリリースでUIを修正します。

各ルールの値は、アーティファクトが収集される専用サーバーの割合を定義します。たとえば、サンプリング値100は、フリートに属するすべての専用サーバーのアーティファクトを収集するようにAMSに指示しますが、50は、AMSが専用サーバーの_おおよそ_半分からアーティファクトを収集することを意味します。
サンプリング割合をゼロに設定すると、一致するすべてのアーティファクトを報告するようにAMSに指示しますが、実際には収集して保存しません。
サンプリングルールを非アクティブ化することもでき、サンプリングルールを効果的に無効にします。つまり、AMSはルールに一致するアーティファクトを報告しません。
Admin Portalを使用して専用サーバーから収集されたアーティファクトを表示および管理するには、専用サーバーのログとアーティファクトの表示と管理の記事を参照してください。
次のステップ
開発フリートを作成した場合は、開発フリートでビルド設定を使用する方法を学ぶ必要があります。専用サーバーを展開するためのプロダクションフリートを作成した場合は、新しいフリートから専用サーバーをクレームするためのPlay Sessionを設定する準備ができています。
また、さまざまな専用サーバークレームシナリオを探索することもできます。