AMSローンチ準備チェックリスト

Last updated on February 4, 2026

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

この記事は、AccelByte Multiplayer Servers (AMS) を使用してゲームを開発から本番環境に移行するのに役立ちます。開発フェーズから数千人のプレイヤーがいるライブゲームへの移行には、すべてのプレイヤーに対してゲームの高可用性を確保するための慎重な計画が必要です。

できるだけ早く計画を開始してください。Accelbyteのサーバープロバイダーには制限があります。大量の容量が必要な場合は、Accelbyteアカウントマネージャーと協力してください。大量のマシンとは、リージョンあたり10台を超えるBare Metalサーバー、およびリージョンあたり1,000 vCPUを超えるものを指します。Bare MetalプロバイダーとCloudプロバイダーは、容量リクエストの増加に対応するのに最低4週間かかります。

AMSローンチ準備アンケート（ダウンロード）に記入し、公開ゲームのローンチまたはイベントのさまざまな側面を確実に検討するためのチェックリストとして使用してください。この記事で説明されているすべてのトピックが含まれていますが、特定の質問に答えるためのより多くのコンテキストが必要な場合に備えて、ローンチ準備アンケートの質問について詳しく説明するためにこの記事を提供しています。参考のために、以下にアンケートの内容のコピーを含めています。

アンケートの内容（上記からダウンロード）

ローンチまたはイベントの準備のために、このアンケートに記入してください。質問が状況に当てはまらない場合はスキップできます。たとえば、ロードテストを実行しないことを選択した場合、ロードテストに関する質問は関連しない可能性があります。このアンケートをチェックリストとして使用して、公開ゲームローンチのさまざまな側面を確実に検討してください。

一般

• 一般公開がゲームをプレイできる日時:
• イベントのタイプ（例：アーリーアクセス、プラットフォームローンチ、地域ローンチ（例：特定の国でのソフトローンチ）、マーケティングビート（テレビ広告プッシュ、Epic Game Storeでの無料提供、またはGamePassでのライブ））:
• ピーク同時接続ユーザー数（PCCU）:
  • ベアケース（OK）:
  • ブルケース（良好）:
  • ホームランケース（大成功）:

デプロイメント

各ローンチイベントにどのデプロイメントを使用しますか？

• AGS環境URL:
• AGS名前空間:
• AMSイメージ:
• AMSフリート:
• 使用するゲームモードとインスタンスタイプ（VMまたはBare metal）を記入してください:

ゲームモード	AMSインスタンスタイプ	VM あたりのサーバー数	マッチ構成（例：1v1、2v2）	プレイヤーの割合	通常のセッション長	最大セッション長

容量計画

ゲームで有効にするAMSリージョンを記入してください:

リージョン	ターゲットピークCCUの割合による地域CCU	ゲート開放時の予想CCU	ユーザーランプアップ/ログインキュー率	フリート最大サイズ [DS]	フリートバッファサイズ [DS]
North America East (us-east-2)
North America West (us-west-2)
Asia Northeast (ap-northeast-2)
Europe Central (eu-central-1)
Asia Southeast (ap-southeast-1)
South America East (sa-east-1)
Australia East (ap-southeast-2)

容量制限

• アカウントの容量制限（リージョンごとおよびインスタンスタイプごと）はターゲットCCUに十分ですか？
• Bare metalを使用していますか？
  • どのフォールバックフリートを有効にしますか？

専用サーバーのパフォーマンスと動作

• DSは次の条件下で終了しますか:
  • 最後のプレイヤーが退出し、ゲームが終了したとき？
  • 最後のプレイヤーが退出し、ゲームが実行不可能になったとき（例：プレイヤーがゲームに再接続しない）？
  • DSがクレームされたがプレイヤーが接続しないとき？
• DSにドレインシグナルが送信されたとき、どのようなアクションを実行しますか:
  • セッション中？
  • セッション外？
• フリートでタイムアウトが設定されていますか:
  • セッションタイムアウトは最大セッション期間より長いですか？
• ゲームサーバーはセッションタイムアウトを動的に延長しますか（例：永続的なゲームワールドの場合）？
• DSは追加のプロセスを生成しますか？その場合、子プロセスを生成するトリガーは何ですか、子プロセスは何を担当していますか、子プロセスを終了するトリガーは何ですか？
• VMあたりのサーバー構成のインスタンスタイプをストレステストしましたか？GrafanaでDSパフォーマンスメトリクスを確認しましたか？
• 異なるインスタンスタイプで実行されているDSをテストしましたか？

デプロイメント戦略とアップデート

• デプロイメント戦略（blue-greenまたはcanary）をテストしましたか？
• ゲームクライアントを更新するとき、同じクレームキー（したがって同じ専用サーバーバージョンを使用）を使用しますか、それとも新しいクレームキー（したがって新しいフリートをアクティブにする必要がある）を使用しますか？

モニタリングとデバッグ

• 実行中のDSのログを表示できますか？終了したDS（クラッシュまたは成功）のログをダウンロードできますか？
• DSログを収集し、それに応じてログサンプリングルールを設定しましたか（例：クラッシュの場合は100％、成功したサーバーの場合は1〜5％）？
• ログとコアダンプ以外のアーティファクトを収集しますか？どれですか？
• AMSメトリクスを監視するためにGrafana Cloudにアクセスできますか？
  • 特定のリージョンでのクレーム失敗を確認する方法を知っていますか？
  • Ready DS（バッファ）の数を監視する方法を知っていますか？
• フリートのバッファサイズを要件に基づいて（定期的に）監視および調整する予定ですか？

ロードテスト

• フリートがターゲットPCCUにスケールできることをテストしましたか？
• 外部依存関係（Extendまたはその他）は何ですか？ある場合、それらは負荷下でテストされていますか？

アクセス権

• AMS Admin Portalまたはその他のツールにアクセスする必要があるすべてのチームメンバーがアクセスできますか？

備考

ゲームスタジオとして、成功したローンチを確実にする責任があります。AMSはツールとインフラストラクチャを提供しますが、ゲームの健全性を積極的に監視および管理する必要があります。次のガイドは、成功したローンチのためにゲームを準備するのに役立ちます。

備考

主要なローンチの場合は、完成したアンケートをアカウントマネージャーに事前に提出して、ソリューションアーキテクトチームによってレビューされるようにしてください（Standard、Professional、およびEnterpriseサポートプランで利用可能）。

ローンチまたはプレイテストの前にテストする重要なシナリオ

AMSでのローンチまたはプレイテストの前にテストする重要なシナリオは次のとおりです。

• バッファ設定がスケールアウトに十分であり、イベントの予想されるゲームセッション作成率を使用して複数のVM分のDSをクレームすることでクレーム率を処理できることを確認します。

• セッション終了後にDSが適切に終了することを確認します。

• クレームが停止し、セッションが完了した後、フリートがスケールバックインすることを確認します。

フリートサイジング/容量計画

容量計画には、リージョンごとのピークCCU（PCCU）の見積もりが必要です。上記で提供されているテンプレートを使用して、リージョンごとのフリートサイズを見積もります。

Bare metal

フリートがBare metalインスタンスタイプを使用している場合は、フォールバックフリートの設定を行って、静的容量よりも大きなDS数へのバーストを可能にします。

容量制限

AMSアカウントの容量制限（ソフトリミット）がターゲットよりも高いことを確認してください。これらの制限はリージョンごとおよびインスタンスタイプごとであるため、使用するすべてのリージョンとインスタンスタイプを確認してください。詳細については、容量制限を参照してください。複数のクラウドプロバイダーに分散した複数のフリートを持つことで、容量制限のリスクを軽減することを検討してください。

デプロイメント戦略（ゲームアップデート）

専用サーバーバージョンのスムーズなアップデートとロールバックを確実にするために、デプロイメント戦略を実装およびテストします。多くの場合、ゲームは初日にアップデートが必要です。アップデートをロールアウトすることが重要な場合、ライブプレイヤーに悪影響を与えたくありません。したがって、ライブフリートでアップデートをロールアウトおよび実行するためにこれらの戦略を使用する方法を理解していることを確認してください。

• Blue-Greenデプロイメント: 2つの同一のフリートを維持し、トラフィックを徐々にシフトすることで、ダウンタイムなしで専用サーバーを更新します。詳細はこちら。
• Canaryデプロイメント: 完全なロールアウトの前に、少量のライブトラフィックで新しいバージョンを安全にテストします。詳細はこちら。

専用サーバーの互換性

デプロイメント戦略の一部として、新しいゲームクライアントが古い専用サーバーと互換性があるかどうかを検討してください。専用サーバーイメージを更新せずにゲームクライアントを更新できますか？（逆も同様です。）そうでない場合は、ゲームクライアントによって生成されたクレームリクエストに互換性のあるサーバーのクレームキーのみが含まれていることを確認してください。上記のデプロイメント戦略と同様に、サーバーの複数バージョンのサポートについて学びます。

デプロイメントのテスト

これらの戦略のいずれかを使用すると仮定して、ローンチ前にテストすることをお勧めします。たとえば、異なるクレームキーを持つ2つ（またはそれ以上）のフリートを同時に実行し、2つの（互換性のない）ゲームクライアントを実行して、互換性のあるフリートからのみ専用サーバーをクレームすることをテストします。

モニタリング

適切なモニタリングは本番環境の成功に不可欠です。ローンチ前に、ローンチ中にメトリクスとDSクラッシュおよびログを積極的に監視する方法を学びます。

メトリクス

AMSサービスダッシュボードを参照してください。開発中にこれらのメトリクスを試して、たとえばクレーム失敗をシミュレートしてメトリクスへの影響を観察することで、より良い理解を得ることをお勧めします。次の監視方法を認識することをお勧めします。

• クレーム失敗: クレーム失敗を監視します。
• フリートサイジング: サーバー使用率を追跡し、特に各リージョンで十分なREADYサーバーがあることを確認します。
• パフォーマンスメトリクス: 専用サーバーのCPU、メモリ、ネットワーク使用量を監視します。
• クレーム率: サーバークレームの率を監視します。突然の低下は問題を示している可能性があります。

クラッシュとログ（専用サーバー）

専用サーバーはクラッシュする可能性があります（または操作中にあまり明白でない問題が発生する可能性があります）。Admin Portalのフリート詳細ページを通じて、失敗状態の専用サーバー（例：CRASHED、またはCREATINGでスタックしているもの）を監視します。

• ローンチ前にログサンプリングルールを設定して、終了した専用サーバーのログを確実に収集します。
  • 最初は、デバッグを容易にするためにcrashログ収集率を100％に設定し、ストレージコストを管理するためにsuccessfulサーバーログ収集率を低く（1〜5％）保ちます。
• 実行中のサーバーでログストリーミング機能を使用してリアルタイムログを表示する方法を学びます。

専用サーバービルドの検証

ローンチが近づいたら、専用サーバーがすでにAMSと統合されており、クレームできることを前提としています。追加の対策として、次のシナリオをテストすることをお勧めします。これらは開発中に必ずしもテストされるわけではありませんが、より多くのオーディエンスにスケールアップする際に重要です。

ローンチ前に、専用サーバービルドが次のことを確認してください。

• ゲームセッションが終了したときに終了します。エラーなしで正常に終了する必要があります。
  • 最後のプレイヤーが退出し、ゲームが終了したとき（つまり、マッチが終了したとき）に終了します。
  • 最後のプレイヤーが退出し、ゲームが実行不可能になったとき（例：プレイヤーが再接続しない）に終了します。
  • DSがクレームされたがプレイヤーが接続しなかったときに終了します。
• 致命的なエラーが発生したときにゼロ以外の終了コードで終了します。（これにより、DSはAMSでCRASHEDステータスを表示します。）
• ドレインシグナルを正しくリスニングします：セッション中は無視し、それ以外の場合は正常に終了します。詳細については、ドレインシグナルのリスニングを参照してください。
• 指定されたVMインスタンスタイプでVMあたりのDSパッキング構成でパフォーマンステストされています。専用サーバーが異なるゲームモード、マップ、チーム構成をサポートしている場合は、これらのいずれも予想される制限を超えないことをテストします。
  • インスタンス内のすべてのDSをクレームし、それらでゲームプレイを実行して、完全な使用率での動作を検証することでこれをテストします。
• ローンチで使用するのと同じ本番フリート構成を使用して、ライブAMSフリートでエンドツーエンドで検証されています。

タイムアウト

ローンチ前に、フリートが正しいタイムアウトを設定していることも確認してください。Admin Portalで適切なデフォルトを提供しようとしていますが、すべてのDSの動作が異なるため、ゲームのニーズに応じて設定する必要があります。タイムアウトを設定することは、上記のシナリオの適切なテストに代わるものではありませんが、DSが無期限に存続してスケーリングの問題を引き起こすのを防ぐためのフォールバックとして機能します。タイムアウトの設定の詳細については、フリートの作成を参照してください。

パッキングとインスタンスの選択

ゲームに最適なインスタンスタイプとVMあたりのDS構成を選択します。通常、より大きなインスタンスサイズはよりコスト効率が高く、1台のマシンにより多くのDSをパックできるため、より高速なスケーリングが可能になります。VMあたりのDSが多すぎるとリソースの競合につながる可能性があるため、注意深く監視してください。AMS DS Metricsダッシュボードを使用して、VMあたりのCPU、メモリ、ネットワーク使用量を追跡します。これらのメトリクスは、インスタンスをオーバーパッキングしているか、DS密度を増やす余地があるかを特定するのに役立ちます。フリートのインスタンスタイプの選択を参照してください。

ロードテスト

AMSインフラストラクチャはロードテストされており、専用サーバーの安定したパフォーマンスを保証します。ただし、スムーズなローンチのために、次のことを検討することをお願いします。

容量テスト

すべての専用サーバーの起動時間が異なるため、スケーリング速度は異なります。ローンチ前に、最小サイズを最大サイズと等しく一時的に設定することで、最大サイズ（ターゲットPCCUを想定）でフリートを開始し、スケーリング動作に予期しない遅延がないかどうかを確認することが有用な演習になる場合があります。特に大規模なフリートを使用している場合は、フリートが目的のサイズにスケールアウトできることを検証するために、このようなテストを実行することをお勧めします。

容量制限の計画

クラウドサービスプロバイダーには制限があります。専用サーバーが複数のインスタンスタイプで実行できることを常に確認してください。AMSは3つのクラウドでいくつかの異なるインスタンスタイプでホスティングを提供しています。専用サーバープロセスが複数のインスタンスタイプと1つのクラウドで実行されることをテストおよび検証することをお勧めします。複数のクラウドを活用することで、単一のクラウドでインスタンスまたは容量が不足するリスクを軽減できます。クラウドプロバイダーは、特定のインスタンスの容量があることを絶対的に保証するものではなく、そのリージョンに容量が存在する場合にのみ容量を利用可能にします。AMSの異なるクラウド提供を利用してセカンダリフリートを設定することで、複数のクラウドで実行できるようにフリートを常に設定してください。

ローンチまたはイベントのために予約容量を確保したい場合は、Bare metalサーバーを検討してください。Bare metalサーバーは常にオンで、AMSアカウント専用です。Bare metalサーバーは、最低コストで最高のパフォーマンスを提供します。Bare metalへのコミットメントについて懸念がある場合は、アカウントチームに連絡して追加のオプションについて話し合ってください。

ゲートラッシュ

ゲートラッシュイベントへの対処は非常に一般的です。ゲートラッシュは、パッチ、ゲームのアンロックまたはローンチ、または予定された時間での計画されたプロモーションイベントなど、通常計画された急速で突然のプレイヤーの増加です。より高い最小サーバー数を使用するようにAMSフリート構成を調整して、これらのプレイヤーがシステムに到着したときに追加の容量がオンラインで準備されていることを確認します。AMSプラットフォームは常に容量を調整しており、クラウドインスタンスは起動してトラフィックを処理する準備ができるまでに最大10分かかる場合があります。ほとんどのクラウドプロバイダーの典型的な起動時間は約2分半であることが観察されています。最小サーバー構成を使用して、数千人のプレイヤーの突然の流入を吸収します。

外部依存関係とExtend

専用サーバーがAMSの一部ではない外部依存関係に依存している場合は、ローンチ前にこれらが適切にスケールされ、テストされていることを確認してください。これらはこのガイドの範囲外ですが、ロードテストに含めるようにしてください。カスタムマッチメイキングサービス、分析パイプライン、またはゲーム状態データベースを考えてください。

Extend（カスタムサーバー側ロジックのためのAGSのサービス）を使用している場合は、ローンチのためにExtendアプリを準備するためのガイダンスについて、Extendパフォーマンステストを参照してください。

その他

• AMS Admin Portal（およびその他のツール）にアクセスする必要があるすべてのチームメンバーのアクセス権を確認します。

通知

主要なローンチの場合は、完成したアンケートをアカウントマネージャーに事前に提出して、ソリューションアーキテクトチームによってレビューされるようにしてください（Standard、Professional、およびEnterpriseサポートプランで利用可能）。すべてのサーバープロバイダーの最小ターンアラウンドタイムは4週間です。ライブまたは計画されたイベントの少なくとも3か月前に容量計画の演習を開始することをお勧めします。