[レポート] AWSで実現するマルチプレイ #AmazonGameTech #AmznGameTechJP

Amazon Game Tech

#AWS

#ソリューション

#初心者向け

#イベント

#勉強会

yoshihitoh

2019.11.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSで実現するマルチプレイ

2019年11月20日（水）にアマゾン目黒オフィスでアマゾンウェブサービス社の自社イベント「Amazon Game Developers Conference」が開催されました。

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によるメッセージング処理を提供
  - ステートレスでもステートフルでもいける
  - ターンベースの戦略ゲームなど軽量なモバイルゲームなどに向いてる