AWS Well-Architected ゲーム業界レンズを読んでサマライズしてみた

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

AWS でシステムを効率的、友好的、費用対効果を高く使いこなすためには「AWS Well-Architected」を理解することが重要です。
ベストプラクティスには答えが書いているわけではありませんが、その内容を理解＆実践することでシステムの価値を大きく向上させる可能性を秘めています。

AWS Well-Architected とは

AWS 上でワークロード (IT システム) を設計および実行するための主要な概念や設計原則、ベストプラクティスを解説した資料です。
AWS が長年積み重ねてきたノウハウが凝縮した読み応えのある素晴らしい資料です。
中心となる6つの柱と、特定の業界・テクノロジーに特化したレンズ、環境をアセスメントする Tool、特定のユースケースに焦点を当てたガイダンスなどで構成されています。

今回はゲーム業界レンズを取り上げ、私なりの解釈を加えサマライズしてみたいと思います。

AWS Well-Architected 6つの柱を知りたい

その前に基本的な6つの柱を知りたいという方は以下のリンクを参照ください。

AWS Well-Architected
[初心者向け]AWS Well-Architected ドキュメントの歩き方

一般的な設計原則

6つの柱と同じくゲーム業界レンズでも一般的な設計原則を記述されています。
原本のドキュメントを基に私の解釈で説明します。

プレイヤーの行動と使用パターンを理解することで、ゲームを進化させ、プレイヤーを保護する

ゲーム内でのプレーヤーの行動履歴や行動パターンを保管・分析し、不正なアクティビティを検出したりプレーヤー体験向上に役立てます。
このことによりゲーム内イベント開催後の課金率分析をする、または、SNS キャンペーンでの非アクティブユーザーの帰還率を測定するといったことが考えられます。

プレーヤー同士のチャットや音声コミュニケーションを AI/ML で分析し、好ましくない発言をするユーザーに対して警告を送り改善してもらうこともプレーヤー体験を向上させる1つの案だと考えます。

ゲームの操作を簡素化し、開発速度を高めるテクノロジーを使用する

プレーヤーを自ゲームに惹きつけ多くの競合ゲームへ鞍替えさせないために、流行やニーズに対して迅速な対応が求められます。
新機能やバグフィックの実装スピードを向上させ、かつ、運用の手間を削減するテクノロジーを導入します。
高度に自動化されたパイプライン (コードレビュー、テスト、ビルド、デプロイ) を構築します。

アーキテクチャを最適化し、実際のプレイヤーエクスペリエンスを反映するようにメトリクスを改善する

プレーヤー体験を反映したメトリクスを取得します。
レスポンスタイムかもしれません。操作エラー率かもしれません。自ゲームの特性とプレーヤー行動パターンを反映するメトリクスは何かを考えます。

ゲームプレイが長時間または広範囲に中断されることはプレーヤーにとって大きなストレスです。
障害に強いシステム、障害が発生してしまっても影響範囲を狭くする仕組みが必要です。
サブシステムやモジュール間が相互に強く依存しないシステム設計を行います。

ピーク時のプレイヤーの同時実行数に対応し、必要に応じて動的にスケールするようにインフラストラクチャを設計する

プレーヤーの需要増減に合わせてシステムを自動的に伸縮可能にするアーキテクチャを採用します。
セッション数や同時処理数のメトリクスを使用して、プレーヤーがストレスを感じる前に先手を打ってスケールアップ/スケールアウトします。

ピークを凌いだ後は自動的にスケールダウン/スケールインします。このことでムダなコストを払うリスクを回避します。

ランブックを実装してゲームの操作を改善する

ランブック (運用手順書) は繰り返し実行されるゲーム運用タスクの改善に役立ちます。
障害やユーザー報告に関する調査や対応、新コンテンツリリースなどの大規模イベント前のインフラスケール、日常的な運用タスクなどの作業を行うためにランブックは必要です。

ランブックはし易い状態であることが理想です。Markdown のような軽量なフォーマットで書かれ、スクリーンショットを見て行う人間操作ではなく変数とコマンドラインを駆使した手順が望ましいと考えます。
自動化可能であれば自動化し、極力人間が関与しない仕組みを構築できればなお良しです。

シナリオ

ゲーム業界レンズではゲームアーキテクチャの一般的なシナリオが紹介されています。
ここはサマライズする内容でもないと思います。公式ドキュメントを参照ください。

• リアルタイム同期ゲームのためのゲームホスティング
  • ゲームサーバープロセス
  • サーバーレスバックエンドによるセッションベースのゲームサーバーホスティング
  • 低レイテンシーゲーム向けのマルチリージョンおよびハイブリッドアーキテクチャ
• ゲームバックエンド
  • コンテナベース
  • サーバーレスベース
• クラウド内でのゲーム制作 (GPIC)
  • CI/CD
  • ワークステーション
• ゲーム分析パイプライン

Well-Architected の柱

Well-Architected の5本の柱という観点で、ゲーム業界レンズを説明しています。
ここから実用的になっていくのでサマライズし甲斐があります。

運用上の優秀性

クラウドベースのゲームをあらゆる規模でデプロイおよび運用するためのベストプラクティスに注目しています。

運用上の優秀性の柱 に加えてゲーム業界レンズの設計原則があります。

ゲームオペレーションチームのために測定可能かつ達成可能な目標を定義し、必要に応じて適応させる

ゲームシステムは事前の需要予測がとても難しいという特性があります。
スケールアップ/アウト、スケールダウン/インが容易なアーキテクチャを採用します。サーバーレス、マイクロサービス、マネージドサービス、AutoScaling など人手をかけずスケールする AWS サービスを選定します。
事前のテストを十分に実施し、SLI/SLO を定義します。

オペレーションランブックを使用してゲームのリリースや特別なイベントを事前に計画およびスケールする

イベントのピーク時のプレイヤー同時実行数の推定をモデル化し、インフラストラクチャの容量を事前にスケールするための先を見越した計画を策定します。
過去のイベント開催時やパフォーマンステスト時テレメトリーを保管しておき、ピークに備えます。
ランブックによる自動化を仕組み化し、弾力性のあるアーキテクチャを設計します。

プレイヤーのサポートリクエストを受け取り、調査し、対応するための運用モデルを確立する

ゲームに関する問題やユーザーからの苦情をモニタリングする仕組みを実装します。
コミュニティフォーラム、ソーシャルメディア、E メール、チケットシステム、コールセンター、自動化されたチャットボットソリューションなどが考えられます。
SNS をエゴサする Lambda 関数を作るというのも面白いと思います。

ベストプラクティス

Well-Architected のフォーマットとも言える質問と回答方式のベストプラクティスです。

GAMEOPS01: ゲームのライブオペレーション (LiveOps) 戦略をどのようにして定義しますか？

GAMEOPS_BP01: ゲームの目標とビジネスのパフォーマンスメトリクスを使用して、ライブオペレーション戦略を策定する

ビジネスという意味でのパフォーマンスメトリクスを定義します。プレイヤーの同時実行数、アクティブユーザーのターゲット数などが考えられます。
例えば、「少なくとも毎月 1 回は新しいコンテンツ更新をリリースし、リリース中にダウンタイムは発生させない」という目標があるとします。この目標を満たすデプロイ戦略を策定するといった形です。

GAMEOPS_BP02: 既存のゲームソフトウェアをゲームで再利用する前に検証およびテストする

開発時間とコストを節約するために既存の (以前のゲームの) コンポーネントやソースコードを再利用するケースがあります。
これ自体は生産性の向上に役立つますが、以前のパフォーマンスの問題や安定性の問題が新しいプロジェクトに引き継がれるリスクもあります。
ですので、再利用するケースでも必ずテストを行いリスクを解消しておきます。

GAMEOPS02: ゲーム環境をホストするためのアカウントはどのように構成しますか？

GAMEOPS_BP03: マルチアカウント戦略を採用し、ゲームやアプリケーションごとに独自のアカウントに分離する

複数の実行環境を使いゲームを開発・サービス提供します。
例えば、以下のような実行環境を想定します。

• ゲーム開発環境
• テストまたは QA 環境
• ステージング環境
• 本番稼働環境
• 共通プラットフォーム環境
• セキュリティ環境

実行環境ごと、または、ある程度のグルーピングで AWS アカウントを分離します。
AWS アカウント分離基準を示します。

• 厳密なセキュリティ
  • 本番環境の AWS アカウント運用維持管理は限られた運用メンバーのみに限定する
• 厳密なコスト管理
  • 実行環境ごとの AWS 利用料金を把握したい
  • コスト配分タグでは完全に分離できない
  • 一方でエンドポイントなどは作れば作るほど利用料金が発生する、適度なグルーピングは行う (テストとステージングは同じアカウントにする、など)
• リソース上限の限界
  • アカウントあたりのリソース使用数に限りがある
  • 申請すれば増やせるがそれでも限界はある
  • 申請できないリソースもある (初期値が上限値)

AWS Organizations を使うとマルチアカウントを効率的に管理可能です。

• ランディングゾーンによる統制ベストプラクティスの実装
• OU のよる論理的なアカウントグループ化、階層化
• OU 単位でのコントロールポリシー適用
• AWS SSO の利用

GAMEOPS_BP04：リソースのタグ付けを使用してインフラストラクチャリソースを整理する

AWS リソースには適切なタグを付け、識別性の向上をはかります。
チーム内でタグ命名規則を予め決めておきましょう。

• 名称 (Nameタグ)
• 所有者のチーム名、個人名
• ゲーム名、アプリケーション名、プロジェクト名
• 実行環境 (Prod / Dev / Staging など)
• 役割 (DB / Web / Game など)
• コスト配分タグ

GAMEOPS03: ゲームのデプロイはどのようにして管理しますか？

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

ゲームサーバーやゲームバックエンドへのアプリケーションデプロイ (リリース) は、ダウンタイムを最小限に抑える仕組むを取り入れます。

• IaC の活用
• モノリスからマイクロサービスへ
• 1機能を複数台で構成する
• 入れ替え可能にする (セッションをサーバー内に持たないなど)

GAMEOPS_BP06：ピーク要件をサポートするために必要な事前スケールインフラストラクチャ

プレーヤー需要の急増に備えて事前に準備をしておきます。

事前スケール要件を適切に洗い出すために、本番環境と同一のステージング環境で負荷テストやパフォーマンステストを実施します。ステージング環境は本番環境とは別アカウントが望ましいでしょう。
様々な条件をシュミレートしてシステムが全ての条件に耐えられることを検証します。
可能であれば SPOF を発見し削除します。

AWS のサービスクォータを引き上げることも大切です。
通常、上限緩和には時間を要します。上限に達してから緩和申請を出しても間に合わない可能性があります。

GAMEOPS_BP07：プレーヤーの動作をシミュレートすることにより、起動前にパフォーマンスエンジニアリングと負荷テストを実施する

アプリケーションのパフォーマンスを詳細に分析するために APM を導入します。AWS X-Ray や SaaS を使い効果的に分析します。

負荷テスト中に意図的に障害を注入して、障害に対するシステムの挙動を確認します。AWS サービスでは Fault Injection Simulator が該当します。

GAMEOPS04: ゲームの状態をどのように監視しますか？

GAMEOPS_BP08：プレーヤーに影響を与える問題を検出および監視するために、ゲームをインストルメント化する

プレーヤーからの問題報告に対応するため、原因を調査するために監視ソリューションを導入します。

• 外形監視
  • バックエンドまで一気通貫で正常確認
  • レスポンスタイム
• APM
• 分散トレース
• ログ
• メトリクス

ソーシャルネットワークをエゴサーチし、フィードバックや苦情をキャッチします。

GAMEOPS05: 時間の経過とともにゲームをどのように最適化しますか？

GAMEOPS_BP09：プレーヤーの傾向とパターンを特定するのに役立つ主要なゲームメトリックを監視する。この情報を使用して、ゲームのバランスを取り直し、ゲームデザインを最適化し、インフラストラクチャを改善する

プレーヤーのアクティビティを表すテレメトリデータを取得します。

テレメトリデータは分析用バックエンドの送信し、分析・保存します。
AWS では ゲーム分析パイプライン の実装ガイトを公開しています。

セキュリティ

セキュリティの柱 に加えてゲーム業界レンズの設計原則があります。

プレーヤーの使用行動の監視とモデレート

善良なプレーヤーの体験を低下させる可能性のある、不快で不適切な行動を検出し対応します。

ベストプラクティス

GAMESEC01:プレーヤーのIDとアクセス管理をどのように管理しますか？

ゲームプレーヤー ID 管理アプローチを1つ以上組み合わせて使用します。

• 認証されていない、または匿名のアクセス
  • プレーヤー ID 作成が必要ないパターン
  • 初回アクセス時に一意の識別子を生成してデバイスに保管する
• ユーザー名とパスワードによる認証
  • ゲームのバックエンドに ID 管理を実装している
• サードパーティのソーシャルネットワークおよびゲームプラットフォームとの認証およびアカウントリンク
  • ID フェデレーションを使用してプレーヤーを認証する
  • ソーシャルネットワークや自前の統合 ID を使う

GAMESEC_BP01：ゲームバックエンドサービスへのリクエストは認証が必要

ゲームクライアントからバックエンドへリクエストが行われるケースでは JWT などの短期間トークンを使用します。

ゲームが匿名アクセスを使用しているケースでは、ゲームクライアントに AWS SDK を組み込んでおき Cognito identity pools から短期間クレデンシャルを取得します。

GAMESEC_BP02：マルチプレイヤーゲームへの参加を求めるプレイヤーのリクエストは、ゲームバックエンドサービスによって検証される

セッションベースのマルチプレーヤーゲームでは、ゲームバックエンドのマッチメイキングサービスを使用してリクエストを検証します。
マネージドな Amazon GameLift を活用し運用負荷を軽減します。

GAMESEC_BP03：パスワードを必要とするプレーヤーユーザーアカウントは、強力なセキュリティポリシーを適用する

言うまでもなく強力なパスワードポリシーを適用します。

GAMESEC_BP04：プレーヤーが自分のアカウントで多要素認証（MFA）を設定するためのオプションを提供する

こちらも言うまでもないと思います。
メール、電話(SMS込)、2要素認証アプリ等の実装を検討します。

GAMESEC02：ゲームコンテンツへの不正アクセスをどのように防止しますか？

GAMESEC_BP05：ダウンロード可能なコンテンツへのアクセスを許可されたクライアントとユーザーに制限する

ダウンロード可能なコンテンツの保存には費用効果が高い S3 を使用します。
プレーヤーにグローバルでパフォーマンスの高いコンテンツ配信を行うために CloudFront を前面に使用します。

S3 へのコンテンツアップロードは IAM ポリシーを適切に設定した承認されたユーザー or AWS サービスのみに限定します。

CloudFront では署名付き URL と署名付き Cookie の何れかを使用し、ログインしたプレーヤーのみがコンテンツをダウンロード可能な仕組みを導入します。
署名付き URL と署名付き Cookie の選択

GAMESEC_BP06：オリジンアクセスを許可されたコンテンツ配信ネットワーク（CDN）に制限する

コンテンツ配信に CloudFront のような CDN で行うケースでは、オリジン (S3 や EC2) へのアクセスを CDN のみに限定します。
CDN を迂回してオリジンに直接アクセスされないようセキュリティを強化するとともに、不要なオリジンデータ転送コストを抑制します。

GAMESEC_BP07：不正アクセスを防ぐために地理的制限を実装する

グローバルゲームの場合、国ごとに異なるリリース戦略を採用することがあると思います。
また、国内ゲームでは基本的に国内からのアクセスに限定して問題が無いこともあります。
CloudFront や AWS WAF を使用して地理的制限を実装します。

GAMESEC_BP08：デジタル著作権管理（DRM）ソリューションを使用してコンテンツへのアクセスを制限する

プライベートコンテンツを暗号化し、認証されたプレーヤーに復号化キーを配布することにより、暗号化ベースのアプローチを採用することもできます。
プレーヤーが早期にゲームをダウンロードできるようにしておきつつ、コンテンツには決められた時間までアクセスできないようにします。

GAMESEC03：ゲーム内のプレーヤーの使用行動をどのように監視および分析しますか？

GAMESEC_BP09：プレーヤーの使用ログを収集、保存、分析して、不適切な動作を検出する

ゲーム分析パイプライン を実装しログを分析します。
商用のロギングソリューションを使用することも選択肢です。

ゲーム内チャットの分析を行うには、S3 に音声データを保管 → Amazon Transcribe でテキストに変換 → テキストを分析といった方法が考えられます。
もちろんリアルタイム分析も可能です。

プレーヤーがコンテンツを生成しアップロードするケースでは Amazon Rekognition を使用して分析します。

Amazon Fraud Detector を活用すると、詐欺的なサインアップなどの不正アクティビティを検出可能です。

Amazon Lookout for Metrics は ML を使用してビジネスデータの異常を自動検出するサービスです。
収益、ログイン、トランザクションなどのデータが突然落ち込むなどの外れ値を簡単に検知することが可能です。

Fraud Detector と Lookout for Metrics はビルドインのマネージドサービスですが、Amazon SageMaker を使用してカスタムな ML モデルを構築・学習・ホストすることも可能です。

GuardDuty を使用すると AWS 内部の不正なアクティビティを検知可能です。

GAMESEC04: プレーヤーの不正行為や虐待行為に対応するためのポリシーをどのように定義および実施していますか？

GAMESEC_BP10 : 悪意のある人物や虐待的な行動を処理するためのインシデント対応計画を実装する

セキュリティインシデントが起こる前に対応を整備し、定期的に訓練を実施します。

• 教育
  • 開発スキル:「シフトレフト」のアプローチを取り入れます。プロジェクトの早い段階からセキュリティを意識します
  • AWSサービス: AWS のセキュリティ系サービスを習熟します
  • アプリケーションの認識: 組織のインフラストラクチャとアプリケーションを深く理解することは、それらを保護する上で利点となります
• 準備
  • 主要な担当者と外部リソースを特定する: 利害関係者、法律専門家、AWS サポートなど外部リソースとの連絡手段を確立します。依存関係を減らし応答時間を短縮します
  • インシデント管理計画: インシデントへの対応、インシデント中のコミュニケーション、およびインシデントからの回復計画を作成します
  • 適切なアクセス権: セキュリティインシデントに対応するチーム用の IAM ユーザーまたはロールを準備します。それらにはセキュリティインシデントを調査するために十分なアクセス権を設定します
  • ツールデプロイ: セキュリティチームが調査に使用するツールをデプロイします
  • フォレンジック機能: 原因調査をより本格的に行うためのフォレンジック機能を準備します
• シミュレート
  • GameDay: 現実的なシナリオでインシデント管理の計画と手順を実践するための内部イベントを実施します
  • 証拠の収集: システムからのアラート、チケットシステムなど様々手段で証跡を収集します
  • インシデントを封じ込める: 侵害されたクレデンシャルを無効にする、コンピューティングリソースを分離するなどのアクションを実行します
  • インシデントを根絶する: 影響を受けやすいアプリケーションまたはインフラストラクチャ構成の脆弱性の軽減に向けて取り組みます
  • インシデントからの回復: バックアップから正常な状態を復元します。また、脆弱性は取り除きます。
  • インシデント後の報告: インシデントの処理を詳細に確認し、学んだ教訓を文書化し、学んだことに基づいてRunbookを更新し、新しいリスク評価が必要かどうかを判断する必要があります。
• 繰り返し
  • 封じ込めと復旧機能の自動化: インシデントの封じ込めと復旧を自動化して、応答時間と組織への影響を削減します。

GAMESEC_BP11 : 悪意のある人物に関連付けられたアカウントを停止する

悪意のある人物の言動は他の善良なプレーヤーの体験に悪影響を及ぼします。
利用規約に違反していることが確認された悪意のある人物に対して、アカウント停止を課すプロセスを導入します。

信頼性

信頼性の柱 に加えてゲーム業界レンズの設計原則があります。

ビジネス予測を満たすために必要なピークプレーヤーの同時実行性とシステムスケーラビリティの目標について合意する

ピーク時に予想される同時プレーヤーの数の見積もり、それを満たすためのシステムスケーラビリティ目標を設定します。
この目標はゲーム信頼性のベースラインになります。需要の変化に自動的に対応するスケーリングポリシーを定義します。

信頼性とプレーヤーエクスペリエンスへの影響を測定する

ゲームでの KPI を定義し、測定します。

ベストプラクティス

GAMEREL01: ゲームインフラストラクチャは、プレーヤーの需要の変化にどのように対応しますか？

パフォーマンス効率の柱 に加えてゲーム業界レンズの設計原則があります。

ベストプラクティス

GAMEREL01 : ゲームインフラストラクチャはプレーヤーの需要の変化にどのように対応しますか？

GAMEREL_BP01: アクティブなプレーヤーのゲームセッションの状態を組み込んだスケーリング戦略を実装する

プレーヤーセッションをステートレスな実装とし、ゲームプレイを中断することなくインフラストラクチャを自動スケールするソリューションを実装します。

GameLift を使用して自動スケールを管理することも可能です。

GAMEREL_BP02: ゲームでの複数のEC2インスタンスタイプの使用をサポートする

EC2インスタンスを使用してゲームをホストする場合、複数のインスタンスタイプを使用します。
スケーリング時、EC2 リソース不足に陥るリスクを回避します。

複数のインスタンスタイプをサポートすることはスポットインスタンス使用時にも役立ちます。

GAMEREL02: アクティブなプレーヤーに対するインフラストラクチャ障害の影響を最小限に抑えるにはどうすればよいですか？

GAMEREL_BP03: ゲーム機能の緩い結合を実装して、プレーヤーのエクスペリエンスへの影響を最小限に抑えて障害を処理する

サーバーコンポーネントを可能な限り独立して動作できるように設計します。
緩い結合とすると、1つのコンポーネントの障害が他のコンポーネントに伝搬しにくいという利点があります。
さらに回復力を高めるには、コンポーネント間の処理を非同期にします。SQS などのキューイングサービスをコンポーネント間に入れることを検討します。

GAMEREL_BP04: インフラストラクチャの障害を長期的に監視して、プレーヤーの動作への影響を測定する

テレメトリを取得、保存し障害原因の解析に使います。
障害発生前の潜在的な問題を発見することに役立てます。

GAMEREL_BP05: 各ゲームサーバーインスタンスでホストされるゲームセッションの数を調整して、爆風の半径を減らす

ゲームサーバーインスタンスごとにホストできるゲームセッションの最大数を決定します。インスタンス障害が発生した際の影響範囲が決まります。 インスタンスあたりのセッション数を少なくすると障害発生時の影響範囲を限定できますが、必要なインスタンスが増えるためコストも増加します。

GAMEREL_BP06：ゲームインフラストラクチャを複数のアベイラビリティーゾーンとリージョンに分散して、復元力を向上する

数ある AWS ベストプラクティスの中で鉄板ではないでしょうか。
AWS インフラストラクチャの強みを最大限発揮して可用性を向上させるためにコンポーネントを複数アベイラビリティーゾーンに均等配置します。
ゾーン間の冗長構成を容易にするためマネージドサービスを活用します。

パフォーマンス効率

パフォーマンス効率の柱 に加えてゲーム業界レンズの設計原則があります。

ゲームクライアント、インターネット、ゲームインフラストラクチャなど、エンドツーエンドでゲームのパフォーマンスを測定する

現代の監視論としてプレーヤー視点でのパフォーマンス監視が重要です。

ベストプラクティス

GAMEPERF01: ゲームインフラストラクチャをホストする地理的地域をどのように決定しますか？

GAMEPERF_BP01: プレーヤーとビジネスの利害関係者からのフィードバックを確認する

ゲームの先行予約、マーケティングイベントやキャンペーンなどの情報を利害関係者と話し、これらの備える戦略を整備します。

GAMEPERF_BP02: パフォーマンスを向上させるために、ゲームインフラストラクチャをレイテンシーに敏感なプレーヤーの近くに配置するアプローチをとる

グローバル展開しているゲームの場合、プレーヤーがいる地域に近い AWS リージョンへ展開します。
複数リージョンへほぼ同一のインフラストラクチャを展開するこになるので、Infrastructure as Code を活用します。

AWS には Outposts や ECS Anywhere などハイブリッド構成を導入できるサービスがあります。必要に応じてそれらも検討します。

GAMEPERF_BP03: ネットワークアクセラレーションテクノロジーを使用して、インターネット全体のパフォーマンスを向上させる

CloudFront、Global Accelerator、S3 Multi-Region Access Point など使うと、プレーヤー物理位置に近いアクセスポイントへリクエストがルーティングされ、ネットパフォーマンスが最適化されます。

GAMEPERF02: ゲームセッションがリソースを過剰に使用し、同じゲームサーバーインスタンスで実行されている他のプレーヤーに影響を与えるのをどのように防ぎますか？

GAMEPERF_BP04: ゲームサーバーのプロセスを監視して問題を検出する

ゲームサーバーインスタンスで利用できるリソースを監視します。しきい値を超過したときにアラームを生成します。
ログはサーバーインスタンスとは別の永続ストレージで集中管理します。
サーバー上のプロセスダンプも集中管理をすると解析に役立ちます。

GAMEPERF_BP05: シミュレートされた実際のゲームプレイシナリオを使用して、ゲームサーバーのパフォーマンスをテストする

様々なケースを想定したテストシナリオを用意します。
プレーヤーの一般的な操作をシュミレートするテストシナリオを作成します。
機能ごとにストレステストを実施します。

これらのテストを通じて、各リソースが想定通り適切に処理できることを確認します。

GAMEPERF03: ゲームに適したコンピューティングソリューションをどのように選択しますか？

GAMEPERF_BP06: 複数のコンピューティングタイプにわたるゲームパフォーマンスのベンチマーク

ゲームサーバーを EC2 でホストする場合、特定に合わせてインスタンスファミリーを選択します。
最適なインスタンスファミリーは1つでないケースもあります。EC2 AutoScaling を使い複数のインスタンスファミリーを組み合わせて構成することを検討します。
また、Intelベースのインスタンス、AMDベースのインスタンス、ARMベースのGravitonインスタンスなど、さまざまなタイプのプロセッサでゲームがどのように動作するかを評価する必要があります。

• 汎用: M で始まるインスタンス (M6g,M6i,M5a など)
• コンピューティング最適化: C で始まるインスタンス (C7g,C6gn,Hpc6a など)
• メモリ最適化: R/X/z で始まるインスタンス (R6g,X2gd,z1d など)
• 高速コンピューティング: P/DL/Trn/Inf/G/F/VT で始まるインスタンス (P4,DL1,Trn1,Inf1,G5,F1,VT1 など)
• ストレージ最適化: Im/Is/I/D/H で始まるインスタンス (Im4gn,Is4Gen,I4i,D3,H1 など)

GAMEPERF_BP07: ゲーム開発仮想ワークステーションにグラフィックインスタンスを使用する

EC2 を仮想ワークステーションとして使用する際には GPU 搭載のインスタンスを選択します。「G」で始まるインスタンスファミリーが該当します。

Amazon Nimble Studio はクラウドベースの仮想ワークステーション、ファイルストレージ、およびクラウドベースのスタジオの運用に必要なツールへのアクセスを提供します。
インフラストラクチャ構築の手間を軽減しながらクリエイターに必要な環境を準備します。

独自の仮想ワークステーションを用意したい場合には、NICE DCVサーバーがプリインストールされたマシンイメージを MarketPlace から無料で入手します。

GAMEPERF_BP08: レイテンシに依存しないコンピューティングタスクを非同期ワークフローにプッシュする

全ての機能を見直し同期通信が必要かどうか、非同期で実装可能を検討します。
同期通信は各リソースを大量に消費することがある処理です。
プレーヤーからバックエンドへのリクエストはキュー (SQS など) に入れることで体験的な応答速度が改善する可能性があります。

GAMEPERF04: パフォーマンスを最適化するためにマッチメイキングサービスをどのように設計しますか？

GAMEPERF_BP09: ゲームのネットワーク遅延しきい値を定義する

遅延に敏感な多くのゲームでは、ネットワーク遅延、ジッター、パケットロスなどのパフォーマンスデータを収集するために、ゲームのエンドポイントに ping を送信するようにゲームクライアントをインストルメント化し、このデータをメトリクス収集バックエンドに報告して、分析できるようにすることが一般的です。プレイヤーをゲームセッションにマッチングさせる際、マッチメイキングサービスでプレイヤーのゲームを選択する際に使用する入力の1つとして、ゲームクライアントが認識したゲームサーバーのインフラへのネットワーク遅延を組み込むようにゲームを構成します。

GAMEPERF_BP10: ゲームプレイモードとゲームホスティングリージョンごとに個別のマッチメイキングサービスを実行する

プレーヤーがが選択できる複数のゲームモードを提供している場合、ゲームモードごとに個別のマッチメイキングサービスを用意します。このことでリソースの競合を減らします。

ゲームを複数のリージョンで提供している場合は、マッチメイキングサービスとゲームサーバーを同じリージョンにデプロイします。

GAMEPERF_BP11-マッチメイキングのパフォーマンスを定期的に監視する

ゲームセッションに入る前の待機時間を減らすことが重要です。この待ち時間が長いとプレーヤーは興味を失い離脱してしまう可能性があります。

マッチメイキングサービスがプレーヤーに適したゲームセッションを見つけるのにかかる時間を追跡するためのメトリックを設定します。このメトリックを定期的に分析しプレーヤーの行動や感情と関連付けます。

コスト最適化

コスト最適化の柱 に加えてゲーム業界レンズの設計原則があります。

プレーヤー、プラットフォーム、およびゲーム機能ごとのインフラストラクチャコストを測定する

コスト最適化を行えるようにコストの追跡を行います。コストが AWS リソースのどこにかかっているかを理解する必要があります。利用している AWS サービスごとに料金ページを確認し課金基準を理解します。

コスト最適化とプレーヤーエクスペリエンスのトレードオフを評価する

ゲームが安定してくるとプレーヤー人口の臨界点が明確になるはずです。その時点でスペックダウンやスケールインなどのコスト最適化を実施します。

ベストプラクティス

GAMECOST01: ゲームサーバーに適したコンピューティングソリューションをどのように選択していますか？

GAMECOST_BP01: ゲームサーバーを複数のコンピューティングタイプでベンチマークする

ゲームサーバーコードのベンチマークを実行して、ゲームセッションで使用する CPU、メモリ、ネットワーク帯域幅などのリソースを特定し、最小のコストでパフォーマンスの適切なバランスを提供するオプションを選択する必要があります。

複数の EC2 インスタンスタイプにわたるゲームサーバーのベンチマークの一環として、ゲームを実行するために必要なオペレーティングシステムとプロセッサの要件のタイプを決定する必要があります。
Windows Server を Linux に置き換えるとライセンスコストを削減できます。
Graviton 搭載のインスタンスを選択するとパフォーマンスあたりのコストが改善する可能性があります。

GAMECOST_BP02: 各ゲームサーバーインスタンスでホストされるゲームセッションの数を最適化して、コストを削減する

サーバーインスタンスごとにホストされるゲームセッションの数を最適化して、インスタンスの仕様効率を上げ、コストを削減します。
サーバーインスタンスごとのセッション数を多くすることで、必要なインスタンス数が減ります。

GAMECOST_BP03: コストを削減するには、適切なコンピューティング価格設定オプションを選択する

例えば EC2 ですと、オンデマンド、スポット、Reserved Instance、Savings Plans といった価格設定オプションがあります。
これを積極的に活用してコストを削減します。

常時必要なトラフィックを処理するために10台のインスタンスが必要、ある時間帯だけ20台のインスタンスが必要だと仮定します。 最初の10台はオンデマンドインスタンスを使用し、追加で増やした10台はスポットインスタンスを使うといった方式を検討します。

GAMECOST02: ゲームインフラストラクチャのデータ転送コストをどのように最適化していますか？

GAMECOST_BP04：インターネットを介したデータ転送のコストを最適化する

ゲームのバックエンドからプレーヤーにデータを転送するコストを削減するソリューションを実装します。
ゲームコンテンツが S3 または EC2 に保存されプレーヤーへ転送されるケースでは、CloudFront を使用します。CloudFront はプレーヤーを物理的に近い接続点へと誘導します。また、ゲームコンテンツがキャッシュ可能な場合はデータ転送コストを削減可能です。

GAMECOST_BP05：コストを最適化して、サービス、アベイラビリティーゾーン、およびリージョン間のデータ転送を削減する

トラフィックの方向によってデータ転送料金が異なります。この特性をよく理解してアーキテクチャを構成します。

EC2 であれば、インターネットから EC2 へのデータ転送は料金が発生しません。EC2 からインターネットはデータ転送料金が発生します。
リージョン内通信でも、Availability Zone をまたいだ通信は VPC ピアリングですとデータ転送料金が発生しますが、同じ VPC であれば発生しません。

GAMECOST03: ゲームインフラストラクチャのデータストレージコストをどのように最適化していますか？

GAMECOST_BP06: コストを削減するために、適切なタイプのストレージを選択する

EBS ボリュームは複数のボリュームタイプが用意されています。用途に合わせたボリュームタイプを選択します。

S3 も複数の選択肢があります。データ取り出しの頻度、冗長レベルによって適切なオプションを選択します。

GAMECOST04: ゲーム環境のコストをどのように測定しますか？

プレイヤー、ゲーム機能、環境ごとのコストのアトリビューションを実装する

ゲームバックエンドはマイクロサービス化するとコスト分析や最適化が容易になります。単一のモノリシックアプリーケーションを実装するとコンピュートリソースが共有されるため機能ごとのコスト算出が難しくなります。

ゲーム開発では様々な実行環境 (本番環境、ステージング環境、開発環境、テスト環境など) を用意します。環境ごとのコストを明確にするため AWS アカウントを分離します。

まとめ

AWS Well-Architected ゲーム業界レンズを読み込んでまとめてみました。
6つの柱が基本になるのですが、ゲームプレイは需要予測が難しいという前提での説明が多いと感じました。
原本はかなりのボリュームで読み応えがありとても参考になります。ぜひ原本を読んでみてください。

参考

AWS Well-Architected
Games Industry Lens AWS Well-Architected Framework

以上、吉井 亮 がお届けしました。