この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWSで実現するマルチプレイ
2019年11月20日（水）にアマゾン目黒オフィスでアマゾンウェブサービス社の自社イベント「Amazon Game Developers Conference」が開催されました。
本記事は、セッション「AWSで実現するマルチプレイ」をレポートします。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 畑 史彦さん
セッション概要
セッション紹介ページ からの引用です。
ゲームにマルチプレイの要素を追加する需要がますます増えています。マルチプレイやリアルタイム通信には様々な要求レベルがあり、また AWS でこれらを実現するのにも複数の選択肢があります。このセッションでは、ゲームにおけるマルチプレイやリアルタイム通信の用途や要件を整理するとともにそれらを実現するために AWS が何をサポートし AWS 上でどのように設計すればよいかを包括的にお話します。
レポート
マルチプレイゲーム？
- セッションではオンラインのマルチプレイゲームを指して「マルチプレイゲーム」と呼ぶ
- マルチプレイゲームの種類と要件を整理しAWSに構築する際の選択肢を考えてあてはめる
アジェンダ
- マルチプレイゲーム？
- アーキテクチャ
- 実装事例
オンラインマルチプレイヤーゲーム
- 流行ってるの？どうなの？
- 有名だよね、PUBGとかAPEXとか幅広い年代の人が遊んでる
- PUBGを始めとしたいわゆるバトルロワイヤルゲームの人気が上昇
- 1:N、100+の多人数対戦
- 高まる緊張感と興奮
- 一方でマルチプレイを遊んでいるのは全体の1割未満
- とはいえ既に流行っている
- これからさらに新しく始める人が増えそう、ポテンシャル高い
- 開発サイドに求められること
- より迅速な開発サイクルを
マルチプレイにおける技術的な課題
- 通信レイテンシ (遅延)
- 物理的に離れたところにいるプレイヤー同士を仮想的に近づける
- 多数なプレイヤーをリアルタイム処理するために必要となる膨大なマシンリソース
- それ以外にもマルチプレイ特有の問題もある
- マッチメイキング
- セキュリティ
- チート
- FPSやTPSはリアルタイム性が重要、ターン制のゲームだとそうでもない
- 大量の同時接続
- レイテンシにシビアな接続を同時かつ多数維持しそれらの間で相互似データの同期や処理を継続する
- セッション辺りのプレイヤー数が多いほど単位マシンあたりの処理が重くなる
- P2Pだとクライアント端末の性能限界
- ゲームセッションの寿命もポイント、MMOとかだと半永久的
アーキテクチャ
P2Pかクライアント・サーバか
- クライアント・サーバ
- プレイヤー数に応じてサーバーリソースが増加
- NW構成はシンプル
- サーバーを経由するオーバーヘッド
- サーバーで検証することでチートを防ぎやすい
- ゲームロジックの大半をサーバーに持たせるので更新やデプロイが用意かつ迅速
- P2Pだとフルメッシュ
- サーバーリソースが不要、コスト安い
- サーバー不要、レイテンシが優位になることもある
- NW構成が複雑、フルメッシュ
- NAT超えと安定稼働の難しさ
- 一部端末の通信環境が悪いとマルチプレイ全体に影響する
- 安定稼働の実装が難しい
- P2Pとクライアント・サーバー構成を併用することもできる
Hole Punching
- NAT超えの方法の1つ
- 昨今はだいたいなんらかのNAT配下にいることが多い
- 各端末が自分のアドレスとポートを自己申告してもNATで書き換えられているのであれば他の端末から底あてに通信しても届かない
- そのため一度サーバー(STUNサーバー)と通信させることでそのサーバーから見える(NATされた後の)アドレスとポートを吸収して各端末に伝える
- 各端末はそのアドレスとポートを使ってお互いに通信する
事例: UBISOFT様 For Honor
- Amazon GameLift を使用してメッシュ化されたP2Pから専用サーバーへとインフラを移行
- これによって安定性や接続に関する問題を解決
- すべてのプラットフォームにおいて改善できた
AWSグローバルインフラストラクチャ
- 22リージョン
- 69アベイラビリティゾーン
- 200のPOP (CDNやDNSなどの拠点でユーザ体験を向上させる)
- AWSバックボーンによる高速で安定した通信
EC2インスタンスファミリー
- メモリ・I/O・CPUクロック重視、GPU・FPGA搭載などの特徴を保つ
- 大きく5つのカテゴリに分類されるインスタンスファミリーを提供
- 処理するワークロードにあわせて選択できる
- C5nで最も広帯域なN/Wを実現
- 最大サイズでは100Gbps
実装事例
AWSにおけるゲームバックエンドの典型的構成の例
- CDNやS3からアセットを取得
- サーバー経由でAPIアクセス
- マッチメイキングとかでゲームサーバーを決める
- ゲームサーバーでゲームを開始
- その他にもサブシステムあり
- データ分析
- 機械学習
- 開発環境
Redisを使ったPub/Sub、Redis Streams
Redis Pub/Sub
- SUBSCRIBEしたチャネルにメッセージがPUBLISHされるとSubscriber全員にメッセージを配信する
- 複数人の双方向通信を容易に実現
- 馴染みのあるRedisで実現できるという手軽さ
Redis Streams
- Redis 5.0で新たに追加された新しい機能、新しいデータ型
- Pub/Subに近いが機能が大幅に強化された
- 時系列追記型のデータ構造
- 任意のフィールドを複数保持できる
- 過去データを保持 → Consumeされてもデータが残る
- 各Consumerはそれぞれのペースで範囲指定して複数のデータを読み出せる
Amazon CloudFront
- CDNのサービスだがWebSocketもサポートしALBをオリジンにすることができる
- この場合はキャッシングとは異なる用途
- 通信品質の向上を期待
Amazon Global Accelerator
- CloudFrontを利用するのと似ていてユーザに近いエッジロケーションから通信先のAWSリージョンまでAWSバックエンドで通信する
Serverless or Server-based
- Computingの進化
- 物理マシン → リードが長い
- 仮想マシン → 柔軟に使えるように
- コンテナ → プラットフォーム日依存・一環したランタイム環境など
- サーバーレス → イベントドリブン・連続的なスケール・使用量に応じた課金・インフラのメンテ不要
Serverless WebSocket通信
- Amazon API GatewayとAWS LambdaによるWebSocketのサポート
- WebSocketの接続のハンドリングをAIP Gatewayに任せることができる
- AWS Lambdaのコードもシンプルに
- 新規接続・メッセージ送信・切断のハンドラを書くだけ
Managed Service or Amazon EC2
Amazon GameLift
- クラウド内でセッションベースのマルチプレイヤー専用のゲームサーバーをデプロイ・操作・スケーリングするマネージド・サービス
- 数百万のプレイヤーに対応できるよう専用ゲームサーバーをスケーリング・ホスティング
- AWSグローバルインフラストラクチャ上で稼働
- GameLiftの担当範囲
- DDoS攻撃から保護
- スケーリング
- マッチメイキング
- レイテンシの考慮
- 2種類のゲームサーバーのホスティング
- カスタムゲームサーバー
- 主要コンポーネント
- ゲームサーバー
- ゲームセッション
- Amazon GameLiftサービス
- ゲームクライアント
- クライアントサービス
- 主要なゲームエンジンを使える
- Unity
- UnrealEngine
- Amazon Lumberyard
- フリートメトリクス
- メトリクスをリアルタイムに検知
- フリート容量のスケーリング
- フリートでスポットインスタンスを活用
- マッチング
- 最大200人のマッチング
- 柔軟なルールで設定できる
- 不公平にならないようにしたり
- 一定時間経過してもマッチしなければ緩和したり
- YAMLで定義
- 事例: Gearbox様 Borderlands
- 主要コンポーネント
- リアルタイムサーバー
- ゲームサーバー特有のロジックをGameLiftが担当してくれる
- Node.jsベースのフレームワークが組み込まれている
- カスタマイズしたいタイミングについて実装する
- TCP/UDPによるメッセージング処理を提供
- ステートレスでもステートフルでもいける
- ターンベースの戦略ゲームなど軽量なモバイルゲームなどに向いてる
- カスタムゲームサーバー
まとめ
要件やゲームの種類に応じて適切なサービスやプロトコル・実装方式を選択することの重要性が伝わってくる素晴らしいセッションでした。GameLiftの存在は知っていたものの実際の用途や事例についてイメージできていなかったので、本セッションで包括的な紹介を聞けてよかったです！
8
