Amazon GameLift ホスティングでゲームをローンチするための準備

[重要] ホスティングソリューションの開発ロードマップのステップがすべて完了し、統合ゲームサーバー、ゲームクライアント向けのバックエンドサービス、ホスティングフリート、ゲームセッションプレイスメント方法 (キューなど) など、必要なコンポーネントがすべて整っていることを確認します。

[重要] 実行中にゲームサーバーが他の AWS リソースにアクセスできるようにする AWS Identity and Access Management (IAM) ロールを作成します。

[重要] 必要に応じて、他のホスティングリソースへのフェイルオーバーを設計して実装します。

ゲームのキューとフリートの構造を考慮して、ターゲットロケーションへのフリートのロールアウトを計画します。

AWS CloudFormation と AWS Cloud Development Kit (AWS CDK) を備えたコードとしての Infrastructure as Code (IaC) を使用してデプロイを自動化します。

Amazon CloudWatch と Amazon Simple Storage Service (Amazon S3) を使用して、ログと分析情報を収集します。

[重要] Amazon GameLift サービスクォータやその他の AWS のサービス クォータのリクエストを増やして、本番環境のニーズに合わせてライブ環境をスケールアップできるようにします。

[重要] ライブフリートで開いているポートが、サーバーが使用できるポートの範囲と一致していることを確認してください。

[重要] RDP ポート 3389 と SSH ポート 22 を閉じます。

ゲームの DevOps 管理計画を作成します。Amazon CloudWatch Logs または Amazon CloudWatch カスタムメトリクスを使用している場合は、サーバーフリートの重大または重要な問題に対するアラームを定義します。障害をシミュレートし、ランブックをテストします。

使用しているコンピューティングリソースが、各コンピューティングで同時に実行するサーバープロセスの数をサポートできることを確認します。

最初は、より保守的な値にスケーリングポリシーを調整し、必要と思われるよりも少し多めのアイドルキャパシティを提供します。後でコストを最適化できます。20% のアイドルキャパシティを持つターゲットベースのスケーリングポリシーの使用を検討します。

FlexMatch では、レイテンシールールを使用して、地理的に近いプレイヤー同士をマッチングします。負荷テストクライアントからの合成レイテンシー データを使用して、これがロード時にどのように動作するかをテストします。

プレイヤー認証とゲームセッションインフラストラクチャに負荷テストを実施して、需要に合わせて効果的にスケーリングできるかどうかを確認します。

サーバーが数日間稼働したままの場合でも、接続を受け入れることができることを検証します。

AWS Support プランレベルを「ビジネス」または「エンタープライズ」に引き上げて、AWS が問題や障害発生時に対応できるようにします。

[重要] スケールダウンでアクティブなゲームセッションを停止しないように、すべてのライブフリートで、フリート保護ポリシーをフルプロテクションに設定します。

[重要] 少なくともピーク時に予想される需要に対応するために、フリートの最大サイズを十分高い値に設定します。予期せぬ需要に備えて、最大サイズを 2 倍にすることをお勧めします。

開発チーム全員にローンチイベントに参加してもらい、ローンチルームでゲームのローンチをモニタリングするように奨励しましょう。

プレイヤーのレイテンシーとプレイヤーエクスペリエンスをモニタリングします。

プレイヤーの使用状況に基づいてアイドル容量を最小限に抑えるため、スケーリングポリシーを調整します。

プレイヤーのレイテンシーデータと改訂された要件を基に FlexMatch ルールを変更するか、ホスティング場所を追加します。

各コンピューティングリソースでできるだけ多くのゲームセッションを実行するためにランタイム設定を最適化します。この方法でパフォーマンス効率を最適化すると、同じコンピューティングリソースでより多くのサーバープロセスを実行できるため、フリートコストに直接影響する可能性があります。

分析データを使用して、継続的な開発を促進し、プレイヤーエクスペリエンスとゲームの寿命を向上させ、収益を最適化します。