専用サーバーを展開するためのフリートを作成する

Last updated on October 21, 2026

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

AGS Public Cloud

Public Cloudのお客様の場合、AccelByte Multiplayer Servers（AMS）は制限付きの無料トライアルとしてご利用いただけます。詳細については、AMSのPublic Cloud無料トライアル特典を参照してください。

注記

AGS CLI は AGS 向けの統一コマンドラインツールであり、Extend と AMS のツールも含まれるようになりました。このページの手順は現在も有効です。統合ツールの詳細は AGS CLI のドキュメント を参照してください。

概要​

フリートは、リージョンごとのスケーリング設定に基づいて、ホストインスタンスをスケーリングし、そのホストインスタンス内で実行される専用サーバー（DS）を管理します。

この記事では、Admin Portal または AGS CLI を使用して、ニーズに合わせて AMS でフリートを作成およびカスタマイズする方法を説明します。

フリートの作成を自動化する方法については、フリート作成の自動化方法（Extendを使用）を参照してください。

前提条件​

このガイドを開始する前に、以下を完了している必要があります。

リージョンの有効化​

フリート内で専用サーバーを実行するために必須ではありませんが、AGSマッチメイキングを使用している場合は、プレイヤーが専用サーバーを利用できるようにしたいリージョンに対してQoSを有効にする必要があります。

利用可能なリージョンでQoSを有効にするには、以下の手順に従います。

  1. AccelByte Admin Portalでゲームのネームスペースに移動します。
  2. サイドバーでMultiplayer > Multiplayer Server > QoS Regionsを選択します。
  3. QoS Regionsリストで、プレイヤーに利用可能にしたいリージョンのトグルボタンをオンにします。

フリートの種類​

AMSは2種類のフリートをサポートしています。

Production（本番用）​

Productionフリートは実運用中のゲーム向けに最適化されており、常に消費可能な専用サーバーのバッファを保持することで、プレイヤーに専用サーバーを迅速かつ効率的に割り当てるように設計されています。これは、新しいフリートを作成する際のデフォルトのフリートタイプです。また、Productionフリートは専用サーバーイメージやコマンドライン引数などの不変属性を使用し、専用サーバーのデプロイを壊してライブゲームのプレイヤーに悪影響を及ぼしかねない意図しない変更を防止します。

注記

開発中にProductionフリートを使用することは全く問題のない選択肢であり、場合によっては最善のアプローチとなることもあります。

Development（開発用）​

Developmentフリートは、同じVM群で複数の専用サーバーバージョンやコマンドラインの組み合わせを実行できるようにすることで、開発時の柔軟性とコスト効率を高めます。これにより、複数の専用サーバーバージョン、ゲームモード、マップなどをテストするために必要なホストインスタンスの数を最小限に抑え、開発中のコストを削減できます。Developmentフリートは、専用サーバーイメージとコマンドライン引数をフリートから分離することでこれを実現しており、専用サーバーのクレームフローで専用サーバーイメージとコマンドライン引数を後からバインドできるようにします。Developmentフリートは、リクエストされるまでどの設定を実行するかを認識していないため、準備済みの専用サーバーの完全なバッファを維持することはできません。しかし、Developmentフリートは、特定の専用サーバー設定がリクエストされた時点で速やかに専用サーバーを起動できるだけのVM容量を維持します。

さらなるコスト効率のため、Developmentフリートは、一致するクレームリクエストやDSの実行がない状態が設定された期間続くと「ハイバネート（休止）」するように設定できます。Developmentフリートがハイバネートすると、実質的なバッファはゼロに設定され、ウォッチドッグが解放されVMが解放されます。マッチするクレームリクエストが到着すると、以前に設定されたサイズが復元されます。

Developmentフリートは、AGSの公式ドキュメントやAdmin Portalで簡潔に「Build Configuration（ビルド構成）」と呼ばれる、Development Server Build Configurationsと連携して動作します。Build Configurationは専用サーバーイメージとコマンドライン引数から構成され、これらは関連付けられたDevelopmentフリートで指定されたコマンドライン引数に追加されます。Build Configurationを作成し、Developmentフリートに関連付ける方法については、開発用フリートでビルド構成を使用するを参照してください。

警告

Developmentフリートは、いかなる本番シナリオにも使用しないでください。

フリートの作成​

AMSは需要が発生した際に専用ゲームサーバーを起動できます。しかし、AMSがそれを効率的に行うには、専用ゲームサーバーを最適に実行する方法、およびどこで、いつ実行するかについての必要なデータをすべて把握している必要があります。フリート作成プロセスでは、AMSがフリートを管理するために必要な情報がすべて提供されていることを確認します。

フリートを作成するには、以下の手順に従います。

  1. AccelByte Admin Portalでゲームのネームスペースに移動します。

  2. サイドバーでAMSメニューを開き、Fleet Managerを選択します。Fleet Managerページが表示されます。

  3. Create Fleetボタンにマウスを合わせ、Create Newを選択します。Create Fleetフォームが表示されます。

  4. Fleet & Imageセクションで、フリートの名前を入力します。この名前はネームスペース内で一意である必要があります。次に、フリートの種類に応じて、以下のいずれかを行います。

    • Productionフリートの場合、アカウントにアップロード済みの専用サーバーイメージを1つ選択します。フリートはこのイメージに基づいて専用サーバーを起動します。イメージIDまたはイメージ名でイメージを検索できます。
    • Developmentフリートの場合、Development Fleetの横にあるスライダーをクリックします。次に、Hibernate featureスライダーを使用してハイバネーションを有効にするかどうかを決定します。ハイバネーションを有効にした場合、Set hibernate time入力を使用してハイバネーションが発生するまでの時間を選択します。

  5. NextをクリックしてDeployment Profileセクションに進みます。

  6. Deployment Profileセクションで、必要に応じてタイムアウト値、ポート設定、コマンドラインを調整します。

    タイムアウト

    • Creation Timeout（作成タイムアウト）：作成タイムアウトは、ローカルウォッチドッグが専用サーバーを起動し、その状態を「Creating」とマークした時点からカウントを開始します。このタイムアウトは、専用サーバーが初期化するための設定可能な時間制限を与えます。専用サーバーが初期化に失敗した場合、AMSはそのサーバーを削除し、新しいサーバーに置き換えます。

      • 作成タイムアウトは、専用サーバーが「Creating」状態にある場合にのみ適用されます。専用サーバーがゲームセッションをホストする準備ができたことをウォッチドッグに通知すると、「Ready」状態に移行します。

    • Claim Timeout（クレームタイムアウト）：クレームタイムアウトは、専用サーバーが「Ready」状態に入った時点からカウントを開始します。これは、専用サーバーがゲームセッションにクレームされるまでアイドル状態を維持できる時間制限を与え、ウォッチドッグが時間の経過とともに劣化する可能性のあるアイドルサーバーを削除し、新しいサーバーに置き換えられるようにします。

    • Session Timeout（セッションタイムアウト）：セッションタイムアウトは、専用サーバーがゲームセッションにクレームされ、「In Session」状態に入った時点からカウントを開始します。これは、専用サーバーがゲームセッションを処理する時間制限を与え、ゲームセッションが終了した後に正常に終了しない古いサーバーをウォッチドッグが削除できるようにします。

    • Drain Timeout（ドレインタイムアウト）：ドレインタイムアウトは、アクティブなゲームセッションを処理していない専用サーバーがローカルウォッチドッグからドレイン信号を受信した時点からカウントを開始します。ドレイン信号は、実行中のVMが削除される予定であることを専用サーバーに伝え、ウォッチドッグが強制終了する前に必要な作業を完了して終了するための設定可能な時間を与えます。アクティブなセッションを処理しているDSはドレインタイムアウトの対象にならないことに注意してください。

    • Unresponsive Timeout（無応答タイムアウト）：無応答タイムアウトは、サーバーがAMSウォッチドッグにタイムリーにハートビートを送信しないために無応答状態になった時点からカウントを開始します。設定されたタイムアウト中に、専用サーバーが復旧し、再度ウォッチドッグにハートビートを送信することが期待されます。ハートビートを受信する前にタイムアウトを超えた場合、AMSはそのサーバーを削除し、新しいサーバーに置き換えます。

    ポート設定

    専用サーバーがリスンするポートを追加します。作成したポートの実際のポート値は、ランタイム時に生成されます。フリートにはデフォルトポートが自動的に作成され、これは編集または削除できません。

    コマンドライン

    コマンドラインボックスに、専用サーバーのコマンドライン引数を追加し、専用サーバーが希望する設定で実行するために必要な追加パラメータを必ず指定してください。コマンドの構築方法については、専用サーバーのコマンドラインを構築するを参照してください。

  7. NextをクリックしてDS Host & Regionセクションに進みます。

  8. DS Host & Regionセクションで、専用サーバーを実行するインスタンスタイプと、そのインスタンスで実行する専用サーバーの数を選択します。フリートに最適なインスタンスタイプを選択する際の考慮事項については、AMSフリート向けインスタンスタイプの選択ガイドラインページを参照してください。 次に、フリートのスケーリング戦略を設定します。フリートが専用サーバーを実行したい各リージョンについて、以下のようにmin、max、bufferサイズ（インスタンス数ではなく専用サーバー数）を設定します。

    • Min Servers（最小サーバー数）：このリージョンで常に実行される最小限のDS数です。バッファ値を設定している場合（推奨）、通常は最小サイズ0で十分です。最小値の設定は、設定されたバッファでは対応しきれないような初期の大量のプレイヤー流入が予想されるイベント（ローンチを含む）の前に役立ちます。
    • Max Servers（最大サーバー数）：リージョンで実行するDSの最大数です。これは、ゲームサーバーのコストが予算を超えないようにするための安全策です。Productionフリートの場合、ピーク時に想定されるプレイヤー数に対応する必要があります。つまり、max = <ピークCCU> / <DSあたりのプレイヤー数>となります。
    • Buffer Servers（バッファサーバー数）：需要の増加に動的に対応するための追加インスタンスです。フリートは、この数のDSを「Ready」状態で維持し、ゲームセッションによってクレームされる準備をします。これにより、需要が増加する期間（例えばプレイヤー数の増加による）中に、フリートが負荷を処理するための追加DSを作成することが保証されます。Productionフリートの場合、適切なバッファサイズの選択方法については以下にリンクされているガイドを確認してください。
注記
  • スケーリング戦略の設定が誤っていると、プレイヤーがマッチのためにDSをクレームできなくなります。最大値やバッファサイズの不足は、クレーム失敗の一般的な原因です。特定のゲーム要件に合わせてフリートサイズを調整する方法については、フリートサイズの最適化ページを参照してください。
  • フリートは、最小および最大サーバー数をインスタンスあたりのサーバー数の最も近い倍数に丸めることで、AMSインスタンスの使用を最大化します。これにより、アカウントに課金されるAMSインスタンスに無駄なリソースが生じないようにします。例えば、インスタンスあたり5台のサーバーがある場合、最小値3、最大値28であれば、フリートはそれぞれ5と30に調整します。さらに、バッファ値によって追加の仮想マシンがリクエストされる場合、新しいインスタンス内の5台の専用サーバーすべてがバッファになります。
  • Developmentフリートの場合、多くのケースでは、バッファ設定は1からVMあたりのDS数として設定した数値までの間が適切です。設定が1の場合、既存のVMがすべて満杯になるまで新しいVMは起動しません。設定がDS/VM設定と同じ値の場合、既存のすべてのVMにクレームされたDSが存在するとすぐに新しいVMが起動します。一般的に、既存のVMがバッファ設定で指定された数のDSを収容する余地がない場合、新しいVMが起動します。

  1. NextをクリックしてLogs & Artifacts Samplingセクションに進みます。

  2. Logs & Artifacts Samplingセクションで、専用サーバーのログとアーティファクトを収集するためのサンプリングルールを設定します。サンプリングルールについては、サンプリングルールセクションを参照してください。

  3. NextをクリックしてSummaryセクションに進みます。

  4. フリートの設定を確認し、Createボタンをクリックします。Create Fleetポップアップが表示されます。

  5. （任意）ポップアップでは、フリートを作成した直後にすぐに有効化するオプションがあります。この手順をスキップして、後でフリートを有効化または無効化することもできます。

  6. Createをクリックしてフリートを作成します。作成したフリートは、すぐにFleetsリストに追加されます。

専用サーバーのコマンドラインを構築する​

いくつかの必須フラグを除けば、専用サーバーのコマンドラインは自由に構築できます。

Developmentフリートは、Productionフリートとは少し異なる動作をします。Developmentフリートの専用サーバーコマンドラインは、フリートのコマンドラインに関連付けられたBuild Configurationのコマンドラインが追加されたものです。必須フラグがDevelopmentフリートのコマンドラインまたはBuild Configurationのコマンドラインのいずれにも指定されていない場合、そのフリート内でそのビルド構成を使用した専用サーバーは正常に起動しません。

必須フラグは以下の通りです。

-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を取得するには、この[ガイド]に従ってください。

置換用の追加変数​

さらに、AMSは専用サーバーのコマンドラインにおいて、以下の変数の置換をサポートしています。

変数名説明
${creation_timeout}フリートで定義された作成タイムアウトの値に展開されます。
${session_timeout}フリートで定義されたセッションタイムアウトの値に展開されます。
${drain_timeout}フリートで定義されたドレインアイドルタイムアウトの値に展開されます。
${unresponsive_timeout}フリートで定義された無応答タイムアウトの値に展開されます。
${artifact_path}再帰的に収集されるアーティファクトディレクトリの絶対パスの値に展開されます。

サンプリングルール​

サンプリングルールは、このフリートで管理されている専用サーバーのログ、カスタムアーティファクト、コアダンプをいつ収集するかをAMSに指示します。サンプリングルールは、アーティファクトの種類と専用サーバーの終了ステータスによって定義されます。

設定可能なルールは3つあります。

  • ステータス0（成功）で終了した専用サーバーに対して収集する_ログ_と_カスタムアーティファクト_の割合
  • ステータス > 0（失敗）で終了した専用サーバーに対して収集する_ログ_と_カスタムアーティファクト_の割合
  • ステータス > 0（失敗）で終了した専用サーバーに対して収集する_コアダンプ_の割合
注記

UIのEnable Log Samplingセクションは、LogsとCustom Artifactsの両方に適用されます。UIのEnable Artifacts Samplingセクションはコアダンプにのみ適用されるため、異常終了時のサンプリング率のみが適用されます。これが分かりにくいことは認識しており、今後のリリースでUIを修正する予定です。

アーティファクトサンプリングルール

各ルールの値は、アーティファクトが収集される専用サーバーの割合を定義します。例えば、サンプリング値100は、フリートに属するすべての専用サーバーに対してアーティファクトを収集することをAMSに指示します。一方、50は、AMSが専用サーバーの_おおよそ_半分からアーティファクトを収集することを意味します。

サンプリング率をゼロに設定すると、AMSはすべての一致するアーティファクトを報告しますが、実際には収集・保存して取得できるようにはしません。

サンプリングルールを無効化することもでき、これによりサンプリングルールが実質的に無効になり、AMSはルールに一致するアーティファクトさえも報告しなくなります。

Admin Portalを使用して専用サーバーから収集されたアーティファクトを表示・管理する方法については、専用サーバーのログとアーティファクトの表示・管理の記事を参照してください。

次のステップ​

Developmentフリートを作成した場合は、開発用フリートでビルド構成を使用する方法を学ぶ必要があります。専用サーバーをデプロイするためのProductionフリートを作成した場合は、新しいフリートから専用サーバーをクレームするためにPlay Sessionを設定する準備ができています。

また、さまざまな専用サーバーのクレームフローのシナリオを確認することもできます。

に最終更新
On this page