翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

GAMEOPS03-BP04 プレイヤーへの影響を最小限に抑えるデプロイ戦略を採用する

ゲームソフトウェアとインフラストラクチャのデプロイ戦略を組み込み、プレイヤーをゲームから遠ざけるダウンタイムを最小限に抑えます。特定のタイプの更新では、ゲームクライアントに新しい更新をインストールする必要がある場合がありますが、デプロイ中のダウンタイムを最小限に抑えるか、回避するようにゲームを設計します。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

ゲームデプロイ戦略を開発する際に考慮すべき最も重要なステップの 1 つは、ゲームインフラストラクチャの管理方法を決定することです。AWS CloudFormation や Hashicorp の Terraform などの Infrastructure as Code (IaC) ツールを使用してゲームインフラストラクチャを管理し、環境の準備中のヒューマンエラーを減らします。インフラストラクチャテンプレートは自動パイプラインにデプロイしてテストできるため、さまざまなゲーム環境の設定に一貫性が生まれます。

ゲームに使用できるデプロイ戦略がいくつかあります。

ローリング置換

デプロイのローリング置換の主な目的は、ゲームをシャットダウンしたり、プレイヤーに影響を与えたりせずにリリースを実行することです。実行するアップグレードまたは変更は下位互換性があり、システムの以前のバージョンの近くで動作することが重要です。

このデプロイでは、サーバーインスタンスは、更新されたバージョンを実行しているインスタンスによって段階的に置き換えられます (置換またはロールアウト）。このローリング置換は、いくつかの異なる方法で実行できます。たとえば、専用ゲームサーバーのフリートにローリング更新を実装するには、一般的なアプローチとして、デプロイされた新しいゲームサーバービルドバージョンを含む EC2 インスタンスの新しい Auto Scaling グループを作成し、この新しいサーバーフリートでホストされているゲームセッションにプレイヤーを徐々にルーティングします。新しいゲームサーバービルドを使用するための前提条件として必要な関連するゲームクライアント更新がある場合は、検証チェックを含めて、この新しいゲームクライアント更新がインストールされているプレイヤーのみがこれらのゲームセッションにルーティングされていることを確認する必要があります。

古いゲームサーバービルドバージョンを含むサーバーフリート (EC2 Auto Scaling グループなど) は、通常、ゲームオペレーションチームがこのプロセスを自動化できるようにする個別サーバーメトリクスを設定することで、アクティブなプレイヤーセッションを正常にドレインした後にのみサービスから削除されます。または、インフラストラクチャの量とローリングデプロイの実行時間を短縮するために、既存の本番稼働用インスタンスがサービスから削除され、新しいゲームサーバービルドで更新され、本番稼働用フリートに戻される代替アプローチを実行できます。このアプローチにより、必要なインフラストラクチャの量が減りますが、サーバーの交換に伴ってプレイヤーが利用できるライブゲームサーバーの数が減るため、リスクも高くなります。

このモデルは、ゲームプレイをホストしないデータベース、キャッシュ、アプリケーションサーバーなどのバックエンドサービスへのローリングデプロイを実行するためにも使用できます。これらのサービスが複数のクラスター化されたインスタンスで高可用性の方法でデプロイされている限り、これらのサービスへのデプロイの複雑さは、専用のゲームサーバーへのデプロイよりも小さくする必要があります。

ブルー/グリーンデプロイ

ゲームでのブルー/グリーンデプロイの主な目的は、ダウンタイムを最小限に抑え、問題が特定された場合に以前のデプロイへの安全なロールバックを可能にすることです。ゲームバックエンドの 2 つのバージョンに互換性があり、プレイヤーに同時にサービスを提供できるデプロイに適しています。

ブルー/グリーンデプロイ戦略では、2 つの同一の環境 (ブルーとグリーン) が設定されます。既存のゲームバージョンには青のラベルが付けられ、デプロイターゲットである新しいゲームバージョンには緑のラベルが付けられます。グリーン環境を移行する準備ができたら、フェイルバックが必要な場合に備えて古い環境 (ブルー) を使用できるようにしながら、トラフィックをグリーン環境に移行するようにルーティングレイヤーを設定できます。このシナリオでは、ルーティング更新でマッチメーキングサービスを更新して新しいフリートへのゲームセッションの送信を開始するように設定する必要がある場合があります。ゲームバックエンドサービスの場合、サービスの Amazon Route 53 の DNS レコードを更新したり、アプリケーションロードバランサーの重みをシフトして新しいターゲットグループにトラフィックを送信したりする場合があります。

Blue/Green デプロイ戦略の欠点の 1 つは、デプロイの実行に必要な追加のインフラストラクチャによるスタンバイ環境の固有のコストです。この追加のインフラストラクチャコストを削減するオプションは、新しいゲームソフトウェアが本番環境に既にデプロイされているのと同じサーバーにデプロイされる Blue/Green デプロイのバリアントを採用することを検討することです。このシナリオでは、新しいグリーンサーバープロセスを既存のブルーサーバープロセスとともに新しいソフトウェアで開始できます。カットオーバーは、個別の物理インフラストラクチャ間ではなくサーバープロセス間で行われます。このアプローチでは、新しいサーバーがクラウドで起動されるのを待つ必要がなくなるため、大量のインフラストラクチャにまたがるゲームのデプロイを高速化することもできます。このデプロイアプローチのベストプラクティスについては、「 でのブルー/グリーンデプロイ」を参照してください AWS。

Canary デプロイ

Canary デプロイは、ゲームの早期アルファビルドまたはベータビルドをリリースしたり、新しいゲームモード、マップ、チャレンジなどのゲーム機能を実稼働中の制限付きまたは小さなプレイヤーのセットにリリースしたりするために戦略を適用できるため、ゲーム開発者にとって便利です。このようなデプロイは Canary と呼ばれます。リリースには追加の追跡とレポートが含まれている可能性があるため、実際のプレイヤーがそのゲームや機能をプレイすると、ゲームプレイテレメトリが収集され、異常や問題が分析されます。

新機能の場合、プレイヤーはこれについて一貫して通知されないため、ゲームテレメトリはプレイヤーに問題が発生しているかどうかを判断するために使用される主要なソースであり、リリースをロールバックする必要があります。同時に、重大な問題が特定されない場合、この機能をさらに多くのプレイヤーにロールアウトして追加データを取得できます。プレイヤーに通知された場合は、そのエクスペリエンスに関する定期的なフィードバックを提供するように求められます。このようなテストアクティビティは、ライブ運用チームが調整するのが理想的です。

戦略として、Canary デプロイを標準リリースに使用して、プレイヤーが徐々に新機能を利用できるようにすることもできます。標準の Blue/Green 環境よりも潜在的な利点は、フルスケールの 2 番目の環境を必要としないことです。新しいスケールダウン環境の容量によって、新機能にオンボードするプレイヤーの数が決まります。プレイヤーを追加する前に、容量を適切にスケーリングする必要があります。このカスタマイズされたブルー/グリーン手法は、標準のブルー/グリーンよりもコストが比較的低いと予想される場合でも、Canary デプロイのローリング置換手法よりも高いコストが発生すると推定されます。

本番環境で 1 つの Canary のみを実行し、データとフィードバックに集中します。複数の Canary がデプロイされている場合、本番環境の問題のトラブルシューティングと分離が複雑になり、収集されるデータセットとフィードバックの品質が低下します。

Canary のバリエーションは、1 つ以上の実験 (通常は UI テスト) がターゲットを絞ったデプロイで実行され、ゲームバックエンドサーバーの 1 つのセットが機能の 1 つのバージョンを提供し、別の同じサイズのセットが同じ機能の別のバージョンを提供する場合です。これに対して追加のインフラストラクチャや特別なインフラストラクチャは作成されず、バックエンドサーバーの選択したポケットのみがこれらの更新を受け取ります。実験の結果は、プレイヤーが同じ機能の各バージョンにどのように反応するかを観察し、全体的な好き嫌いのコンセンサスがあるかどうかを判断し、そのユーザビリティや機能で特定された問題があるかどうかを観察することです。このような戦略的実験は A/B テストとも呼ばれ、全体的なプロセスは A/B テストと呼ばれます。これらの実験が完了すると、テストに使用されるサーバーのゲームバックエンドシステムの最新バージョンに戻す前に、必要なテストデータが収集されます。

従来のデプロイ

従来のデプロイスタイルでは、スケジュールされたメンテナンスウィンドウ中にゲームがシャットダウンされ、ゲームバックエンド内のサーバーインスタンスが最新のコードビルドで更新される前に、接続されたプレイヤーがドロップまたはドレインされます。このデプロイは、実行されるたびにプレイヤーに影響し、スケジュールの前にプレイヤーに通知する必要があります。その結果、このモデルはプレイヤーに最も大きな影響を与えるため、可能な限り避ける必要があります。

ゲームの更新がデプロイされると、ゲームを再開するのを待っているプレイヤーにゲームを開く前に、ゲームの煙をテストできます。これにより、プレイヤーが短時間でログインしてプレイしようとすると、トラフィックが急増する可能性があります。したがって、このようなトラフィックの急増を処理するようにゲームが設計されていない場合は、プレイヤーをバッチでゲームに戻すことを徐々に許可できます。

または、トラフィックのオープンスパイクを維持するためにインフラストラクチャを過剰にプロビジョニングすることを選択できます。ゲームトラフィックが解決したら、リソースをスケールダウンできます。必要に応じて、プレイヤー数が最低のオフピーク時間にこのタイプのデプロイを実行します。頻繁にスケジュールされたメンテナンスと拡張メンテナンスには、本質的にプレイヤーの減少や収益の損失のリスクがあります。また、プレイヤーは新しいリリース後に変更されることを想定しており、ダウンタイムが続くとゲームへの信頼が失われる可能性があります。

実装手順