インフラ設計

Amazon GameLift でマルチプレイヤーゲームサーバーをホスティング - マッチメイキングとフリート管理

GameLift によるゲームサーバーのデプロイ、FlexMatch マッチメイキング、スポットインスタンスの活用を解説します。

約 3 分で読めます

GameLift の概要

GameLift はマルチプレイヤーゲームの専用サーバーをマネージドにホスティングし、世界 15 以上のリージョンで低レイテンシ接続を提供するサービスです。FPS、バトルロイヤル、MOBA などのリアルタイムマルチプレイヤーゲームで、プレイヤーに低レイテンシの接続を提供します。FlexMatch マッチメイキングエンジンでスキルベースのマッチングを実現し、Auto Scaling でプレイヤー数に応じたフリートサイズの自動調整を行います。GameLift Server SDK をゲームサーバーバイナリに統合することで、セッション管理、ヘルスレポート、プレイヤー接続管理を GameLift が代行し、ゲーム開発者はゲームロジックの実装に専念できます。

FlexMatch とフリート管理

FlexMatch はルールベースのマッチメイキングエンジンで、プレイヤーのスキルレーティング、レイテンシ、チームサイズ、カスタム属性に基づいてマッチを構成します。マッチングルールは JSON で定義し、「スキル差が 100 以内のプレイヤーを 5 対 5 でマッチング」といった条件を設定します。ルールには拡張 (expansion) を定義でき、待機時間が長くなるにつれてスキル差の許容範囲を段階的に広げることで、マッチ成立率と品質のバランスを取れます。フリートはゲームサーバーのインスタンスグループで、オンデマンドとスポットの混在構成が可能です。スポットインスタンスの中断時は GameLift がプレイヤーセッションを別のサーバーに自動移行します。ゲームセッションキューを使うと複数フリートにまたがってゲームセッションの配置を管理でき、フェイルオーバーやコスト最適化の柔軟性が高まります。

マルチリージョンとレイテンシ最適化

GameLift のマルチロケーションフリートは、 1 つのフリート定義で複数リージョンにゲームサーバーをデプロイします。 FlexMatch のマッチメイキング設定でプレイヤーのレイテンシデータを評価し、最もレイテンシの低いリージョンにゲームセッションを配置します。プレイヤーは GameLift SDK でレイテンシを測定し、マッチメイキングリクエストに含めます。 Anywhere フリートを使うと、オンプレミスやエッジのサーバーを GameLift のフリート管理に統合でき、特定地域でのレイテンシ要件に対応できます。リアルタイムサーバー機能では、 Node.js スクリプトでゲームロジックを記述し、カスタムバイナリのビルドなしで軽量なゲームサーバーを構築できます。 GameLift について体系的に学びたい方は、関連書籍 (Amazon)も参考になります。

設計のベストプラクティスと落とし穴

GameLift を本番運用する際の設計上の重要ポイントをまとめます。Server SDK の統合では、ProcessReady コールバックで onStartGameSession、onProcessTerminate、onHealthCheck の 3 つを正しく実装する必要があり、onHealthCheck が false を返すとプロセスが異常と判定されて終了されます。ゲームセッションの最大同時プレイヤー数は CreateGameSession 時に指定し、途中変更はできないため、余裕を持った設定が必要です。スポットインスタンス利用時は、onProcessTerminate が呼ばれてからプロセス終了まで通常 2 分間の猶予があり、この間にゲームステートの保存やプレイヤーへの通知を完了させます。ゲームセッションキューでは、優先度設定でスポットフリートを先に配置し、フォールバックとしてオンデマンドフリートを後に置く構成が推奨されます。また、GameLift のビルドアップロードはリージョンごとに行う必要があり、CI/CD パイプラインで全ターゲットリージョンへのデプロイを自動化すべきです。

他のホスティング方式との比較

マルチプレイヤーゲームサーバーのホスティング方式として、GameLift 以外に EC2 での自前運用、ECS/EKS でのコンテナ化、サードパーティの Multiplay や i3D.net があります。EC2 自前運用はフルコントロールが得られますが、マッチメイキング、スケーリング、セッション管理のすべてを独自に構築する必要があり、運用負荷が極めて高くなります。ECS/EKS はコンテナ化による可搬性が利点ですが、ゲーム特化のマッチメイキングやレイテンシベースの配置ロジックは自前で実装する必要があります。GameLift は FlexMatch、FleetIQ、マルチロケーションフリートなどゲーム専用機能がすべて統合されており、ゲーム開発チームのインフラ運用工数を大幅に削減します。一方で GameLift は AWS 固有のサービスであり、マルチクラウド戦略やオンプレミス中心の運用を志向する場合は Anywhere フリートか他方式が適しています。Realtime Servers は低負荷のカジュアルゲームに適しますが、物理演算を多用する FPS タイトルではカスタムバイナリ方式が必須です。

GameLift のコスト最適化

GameLift のコストはインスタンス時間で課金されます。スポットインスタンスをフリートに指定すると、オンデマンド比で最大 70% のコスト削減が可能です。FleetIQ がスポットの中断率が低いインスタンスタイプを自動選択し、ゲームセッションの中断を最小化します。Auto Scaling ポリシーでアクティブなゲームセッション数やプレイヤー数に基づいてフリートサイズを調整し、ピーク時間外のインスタンスを削減します。オンデマンドとスポットの混合フリートで、ベースラインをオンデマンドで確保し、ピーク時の追加キャパシティをスポットで賄う構成が推奨されます。

まとめ

GameLift はマルチプレイヤーゲームサーバーのホスティングと FlexMatch マッチメイキングを提供するサービスです。マルチロケーションフリートでプレイヤーに最もレイテンシの低いリージョンを自動選択し、スポットインスタンスで最大 70% のコスト削減を実現します。Anywhere フリートでオンプレミスやエッジのサーバーも統合管理でき、リアルタイムサーバーで軽量なゲームロジックを構築します。

関連するサービス

Amazon GameLiftマルチプレイヤーゲーム用の専用サーバーホスティングサービスAmazon EC2クラウド上で仮想サーバーを提供するコンピュートサービスAmazon CloudWatchAWS リソースとアプリケーションの監視・ログ管理・アラームを提供するサービス

関連する記事

AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。Elastic Beanstalk で始めるアプリケーションデプロイ自動化 - 環境構築からローリングデプロイまで環境構築からローリングデプロイまでを自動化する。デプロイポリシーの選定基準と .ebextensions によるカスタマイズ手法を紹介します。AWS Systems Manager によるフリート管理 - パッチ適用・インベントリ・ Run Command の自動化Patch Manager でパッチ適用を自動化し、Run Command でリモート操作を効率化する。Session Manager による SSH 不要のシェルアクセスも紹介します。

同じテーマの記事

Auto Scaling はなぜスケールアウトは速く、スケールインは慎重なのか - 非対称な判断ロジックの設計意図EC2 Auto Scaling がスケールアウトを即座に実行する一方でスケールインに冷却期間を設ける非対称な設計の理由、フラッピング防止の仕組み、ターゲット追跡スケーリングの内部ロジックを解説します。AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。AWS の障害ドメイン設計 - AZ・リージョン・パーティションの 3 層構造が守る可用性の仕組みAWS のインフラが AZ (障害隔離)、リージョン (地理的分離)、パーティション (政治的分離) の 3 層で設計されている理由と、各層の障害がどこまで波及するかを具体的な事例とともに解説します。AWS 障害から学ぶ分散システムの原則 - 過去の大規模障害が変えたアーキテクチャS3 障害 (2017)、Kinesis 障害 (2020)、us-east-1 の特殊性など、AWS が公開した障害レポートを題材に、Shuffle Sharding、Static Stability、Cell-based Architecture といった設計原則を解説します。AWS はなぜそこにリージョンを建てるのか - データセンター立地選定の知られざる判断基準AWS がリージョンの立地を決定する際に考慮する電力供給、地政学リスク、データ主権法制、ネットワーク接続性、自然災害リスクなどの判断基準を、具体的なリージョンの事例とともに解説します。AWS の Availability Zone ID はなぜアカウントごとに異なるのか - AZ マッピングの設計意図us-east-1a がアカウントごとに異なる物理 AZ を指す仕組み、AZ ID (use1-az1) が導入された背景、キャパシティの均等分散という設計意図、クロスアカウントでの AZ 指定の注意点を解説します。バッチコンピューティング基盤 - AWS Batch で実現する大規模並列処理AWS Batch を活用した大規模バッチ処理の構築方法を解説します。ジョブキュー、コンピューティング環境の自動スケーリング、Spot インスタンスによるコスト最適化など、科学計算や大規模データ処理に最適なバッチ基盤の設計を紹介します。放送品質ライブ配信 - AWS Elemental MediaLive と MediaPackage で大規模配信基盤を構築するAWS Elemental MediaLive と MediaPackage を使った放送品質のライブ配信基盤を解説。リアルタイムトランスコード、DRM、広告挿入、マルチ CDN 配信を紹介します。

内容が近い記事・サービス

AWS Deadline Cloud でマネージドレンダーファームを構築 - VFX レンダリングのクラウド移行Deadline Cloud によるレンダーファームの構築、ジョブスケジューリング、スポットインスタンスによるコスト最適化を解説します。AWS Local ZonesAWS のコンピュート、ストレージ、データベースを大都市圏の近くに配置し、エンドユーザーに一桁ミリ秒のレイテンシを提供するインフラ拡張Elastic Load Balancing受信トラフィックを複数のターゲットに自動分散するロードバランサーサービスで、ALB、NLB、GLB、CLB の 4 種類を提供するAWS スポットインスタンスのエコシステム - 最大 90% 割引を支える成熟した中断管理AWS のスポットインスタンスは最大 90% の割引と成熟した中断管理ツールで、本番ワークロードにも採用されています。Azure Spot VM や GCP Spot VM との成熟度の差を、中断率・Fleet 管理・エコシステムの観点から分析します。