Tweet
Tweet

Slide 1

Slide 1 text

Online Multiplay Game leveraging AWS Fumihiko Hata | Solutions Architect | 2019.11.20

Slide 2

Slide 2 text

自己紹介 畑史彦 ソリューションアーキテクト アマゾンウェブサービスジャパン ゲームやエンターテインメント業界の会社を 担当させていただいています 週末は１歳と４歳の子供が遊んでくれます

Slide 3

Slide 3 text

マルチプレイゲーム？ このセッションでは オンライン のマルチプレイゲームを指して 「マルチプレイゲーム」と呼びます。 マルチプレイゲームの種類とそこに求められる要件を整理し、 それぞれ AWS に構築する際にどういう選択肢があるかを考え、あて はめてみます。 個々のサービスの詳細な説明は割愛されますことをご了承ください

Slide 4

Slide 4 text

Agenda Multiplay Game • Popular? or Not? • Problems and Requirements Architecture • P2P or Server/Client Implementation • Pub/Sub or Streams (Amazon ElastiCahce Redis) • Serverless or Server-based • Managed Service or Amazon EC2 • “Custom Game Server“ or “ Realtime Server“ (Amazon GameLift)

Slide 5

Slide 5 text

Popular? or Not?

Slide 6

Slide 6 text

オンラインマルチプレイヤーゲーム

Slide 7

Slide 7 text

オンラインマルチプレイヤーゲーム Fortnite Apex Legends PLAYERUNKNOWN'S BATTLEGROUNDS 荒野行動 PUBG MOBILE and more…

Slide 8

Slide 8 text

オンラインマルチプレイヤーゲーム • PUBG を始めとした多数の、 いわゆる バトルロワイヤルゲーム の人気の上昇 • 1 対 多、100 ± の多人数対戦 • それにより高まる緊張感と勝利の興奮 • ゼロベースでの武器調達、隠れる・逃げる・建築などの多様な戦略と楽しみ方 • その流れはいまやモバイルにも • もちろん、バトロワ以外にも多数のマルチプレイのジャンルとゲームタイトル • MMO、MO、MOBA、FPS、TPS、CCG、RTS、格ゲー、レース、パズル、etc. • eスポーツの盛り上がり

Slide 9

Slide 9 text

マルチプレイの状況 株式会社 Gz ブレイン 2019年1月31日発行 『ファミ通モバイル白書２０１９』 182ページ マルチプレイの状況 より

Slide 10

Slide 10 text

マルチプレイの状況 株式会社 Gz ブレイン 2019年1月31日発行 『ファミ通モバイル白書２０１９』 182ページ マルチプレイの状況 より 実はオンラインのマル チプレイを遊んでいる のは全体の１割未満 ※モバイル

Slide 11

Slide 11 text

マルチプレイの状況 あれ？マルチプレイゲームってそんなに 流行ってない？

Slide 12

Slide 12 text

マルチプレイの状況 あれ？マルチプレイゲームってそんなに 流行ってない？ ・・・というよりは既に流行っているが、 それに加えてなお これからさらに新たにマ ルチプレイを遊びはじめるユーザのポテン シャルがある、という状況と捉えられる 今後、マルチプレイは、タイトル本数だけ でなく多様化や進化も激しくなっていきそう

Slide 13

Slide 13 text

マルチプレイの状況 あれ？マルチプレイゲームってそんなに 流行ってない？ ・・・あるいは既に流行っているが、 それに加えてなお これからさらに新たにマ ルチプレイを遊びはじめるユーザのポテン シャルがある、とも言える！ 今後、マルチプレイのゲーム性や タイトルはどんどん多様化 ＆ 増加 していく可能性 開発サイドに求められること・・・ より迅速なマルチプレイゲームの 実装、改善、試行錯誤、そして運用

Slide 14

Slide 14 text

Problems and Requirements

Slide 15

Slide 15 text

マルチプレイ実装における技術的課題

Slide 16

Slide 16 text

マルチプレイ実装における技術的課題１ 通信レイテンシ（遅延） 物理的に遠く離れたところにいるプレイヤー 同士を、仮想的に近付ける（ゲームの中では 近くにいるように感じさせる） • 光が遅く思えるほどには地球はでかい • 不安定なインターネットという通信環境 • 多数のプレイヤーへのリアルタイムな通信 を処理するための莫大なマシンリソース ※ もちろんそれ以外にもマルチプレイ特有の 様々な課題や要件がある： マッチメイキング、 チート、セキュリティ、etc.

Slide 17

Slide 17 text

マルチプレイ実装における技術的課題１ 通信レイテンシ（遅延） 物理的に遠く離れたところにいるプレイヤー 同士を、仮想的に近付ける（ゲームの中では 近くにいるように感じさせる） • 光が遅く思えるほどには地球はでかい • 不安定なインターネットという通信環境 • 多数のプレイヤーへのリアルタイムな通信 を処理するための莫大なマシンリソース ※ もちろんそれ以外にもマルチプレイ特有の 様々な課題や要件がある： マッチメイキング、 チート、セキュリティ、etc. FPS TPS 格ゲー / レーシング MO / MMO CCG / ターンベース ※上記はあくまで目安。 ゲーム性によっても全然変わる。 より低遅延が 要求される

Slide 18

Slide 18 text

マルチプレイ実装における技術的課題２ 大量の同時接続 レイテンシ（遅延）にシビアな接続を、同時かつ多 数維持し、それらの間で相互にデータを同期や処理 させ続けれなければいけない • １ゲームセッションあたりのプレイヤー数が多い ほど、単位マシンあたりの処理は重くなる • P2P の場合、クライアント端末の性能限界 （後述） • ゲームセッションの寿命もポイント MOBA や CCG は数分〜 だが、 MMO は半永続的

Slide 19

Slide 19 text

マルチプレイ実装における技術的課題２ 大量の同時接続 レイテンシ（遅延）にシビアな接続を、同時かつ多 数維持し、それらの間で相互にデータを同期や処理 させ続けれなければいけない • １ゲームセッションあたりのプレイヤー数が多い ほど、単位マシンあたりの処理は重くなる • P2P の場合、クライアント端末の性能限界 （後述） • ゲームセッションの寿命もポイント MOBA や CCG は数分〜 だが、 MMO は半永続的 MMO バトルロワイヤル MO レース / MOBA CCG ※上記はあくまで目安。 ゲーム性によっても全然変わる。 １ゲームセッション あたりのプレイヤー数

Slide 20

Slide 20 text

P2P or Server/Client

Slide 21

Slide 21 text

Offline or Online 友達の家に集まって

Slide 22

Slide 22 text

Offline or Online 友達の家に集まって Internet

Slide 23

Slide 23 text

Peer to Peer (P2P) or Client/Server Internet ゲームサーバ (リレー / TURN)

Slide 24

Slide 24 text

Peer to Peer (P2P) or Client/Server Internet ゲームサーバ (リレー / TURN) Internet

Slide 25

Slide 25 text

Peer to Peer (P2P) or Client/Server Peer to Peer (P2P) サーバリソースが不要 → コスト◎ 通常はフルメッシュの NW 構造。 n(n-1)/2 の接続数。 100人対戦を P2P で単純に繋いだら、 1端末 99 接続、トータル 4,950 接続 (!) → 人数が少ない場合に有効 通信がサーバを経由せずダイレクトなの でレイテンシが優位なことも NAT 越えという実装と安定稼働の難しさ 一部端末の通信環境の悪さや不具合が、 マルチプレイ全体への影響となることも。 → 総じて安定稼働の実装難易度の高さ Client/Server プレイヤー数に応じてサーバリソースが 増加 NW 構成はシンプル。 プレイヤー数分のコネクション サーバを経由する通信オーバーヘッド サーバでロジックをチェックすることで チートを防ぎやすい ✨ ゲームロジックの大半をサーバに持たせ ることができるので、更新やデプロイが 容易かつ迅速 ✨ 同様に不具合の調査も相対的に楽

Slide 26

Slide 26 text

Peer to Peer (P2P) or Client/Server Peer to Peer (P2P) サーバリソースが不要 → コスト◎ 通常はフルメッシュの NW 構造。 n(n-1)/2 の接続数。 100人対戦を P2P で単純に繋いだら、 1端末 99 接続、トータル 4,950 接続 (!) → 人数が少ない場合に有効 通信がサーバを経由せずダイレクトなの でレイテンシが優位なことも NAT 越えという実装と安定稼働の難しさ 一部端末の通信環境の悪さや不具合が、 マルチプレイ全体への影響となることも。 → 総じて安定稼働の実装難易度の高さ Client/Server プレイヤー数に応じてサーバリソースが 増加 NW 構成はシンプル。 プレイヤー数分のコネクション サーバを経由する通信オーバーヘッド サーバでロジックをチェックすることで チートを防ぎやすい ✨ ゲームロジックの大半をサーバに持たせ ることができるので、更新やデプロイが 容易かつ迅速 ✨ 同様に不具合の調査も相対的に楽 もちろん P2P と Client/Server 構成を併用することも可能。 実際は P2P 構成だけを使うということはまれ。 Hole Punching 出来ない場合にはリレーサーバが 通信を仲介する構成にフェイルオーバーする。

Slide 27

Slide 27 text

Hole Punching • いわゆる NAT 越えの方法の１つ • 昨今のエンドユーザ端末は、だいたいなん らかの NAT 配下にいることが多い • 各端末が自分のアドレスとポートを自己申 告 (xxx.xxx.xxx.xxx) してもそれが NAT で書 き換えられているのであれば、他の端末か らそこ宛 (xxx.xxx.xxx.xxx) に通信しても届 かない • そのため、一度サーバ (STUN サーバ) と通 信させることでそのサーバから見える （NATされた後の）アドレスとポートを収 集し、それを各端末に教える • 各端末は、そのアドレスとポートを使って お互いにダイレクトに通信しあう ※ NAT の状況によっては、STUN だけでは解決できないことも（→ TURN を使うなど） ※ NAT 越え (NAT traversal) の手法は、STUN 以外にも B2BUA など他にも複数ある

Slide 28

Slide 28 text

Hole Punching • いわゆる NAT 越えの方法の１つ • 昨今のエンドユーザ端末は、だいたいなん らかの NAT 配下にいることが多い • 各端末が自分のアドレスとポートを自己申 告 (xxx.xxx.xxx.xxx) してもそれが NAT で書 き換えられているのであれば、他の端末か らそこ宛 (xxx.xxx.xxx.xxx) に通信しても届 かない • そのため、一度サーバ (STUN サーバ) と通 信させることでそのサーバから見える （NATされた後の）アドレスとポートを収 集し、それを各端末に教える • 各端末は、そのアドレスとポートを使って お互いにダイレクトに通信しあう N A T Player A Player B src: xxx.xxx.xxx.xxx src: yyy.yyy.yyy.yyy dst: xxx.xxx.xxx.xxx ※ NAT の状況によっては、STUN だけでは解決できないことも（→ TURN を使うなど） ※ NAT 越え (NAT traversal) の手法は、STUN 以外にも B2BUA など他にも複数ある

Slide 29

Slide 29 text

Hole Punching • いわゆる NAT 越えの方法の１つ • 昨今のエンドユーザ端末は、だいたいなん らかの NAT 配下にいることが多い • 各端末が自分のアドレスとポートを自己申 告 (xxx.xxx.xxx.xxx) してもそれが NAT で書 き換えられているのであれば、他の端末か らそこ宛 (xxx.xxx.xxx.xxx) に通信しても届 かない • そのため、一度サーバ (STUN サーバ) と通 信させることでそのサーバから見える （NATされた後の）アドレスとポートを収 集し、それを各端末に教える • 各端末は、そのアドレスとポートを使って お互いにダイレクトに通信しあう N A T STUN Player A Player B src: xxx.xxx.xxx.xxx src: yyy.yyy.yyy.yyy あなたは外から見ると: yyy.yyy.yyy.yyy ですよ。 dst: yyy.yyy.yyy.yyy ここではかなり単純化して図示している。 • 実際は、シグナリングサーバ経由で STUN が取得したアドレスを 各 Peer に配るステップなどもあるが省略 • また、Player B も NAT 配下の可能性があるがそれも省略 • その他、 NAT が多重である可能性、 FW の考慮、etc. • 最終的にダイレクトに通信することができなければ TURN サーバ を使うなどしなければならない ※ NAT の状況によっては、STUN だけでは解決できないことも（→ TURN を使うなど） ※ NAT 越え (NAT traversal) の手法は、STUN 以外にも B2BUA など他にも複数ある

Slide 30

Slide 30 text

Hole Punching • いわゆる NAT 越えの方法の１つ • 昨今のエンドユーザ端末は、だいたいなん らかの NAT 配下にいることが多い • 各端末が自分のアドレスとポートを自己申 告 (xxx.xxx.xxx.xxx) してもそれが NAT で書 き換えられているのであれば、他の端末か らそこ宛 (xxx.xxx.xxx.xxx) に通信しても届 かない • そのため、一度サーバ (STUN サーバ) と通 信させることでそのサーバから見える （NATされた後の）アドレスとポートを収 集し、それを各端末に教える • 各端末は、そのアドレスとポートを使って お互いにダイレクトに通信しあう N A T STUN Player A Player B src: xxx.xxx.xxx.xxx src: yyy.yyy.yyy.yyy あなたは外から見ると: yyy.yyy.yyy.yyy ですよ。 dst: yyy.yyy.yyy.yyy ※ NAT の状況によっては、STUN だけでは解決できないことも（→ TURN を使うなど） ※ NAT 越え (NAT traversal) の手法は、STUN 以外にも B2BUA など他にも複数ある STUN や TURN、ICE などの Hole Punching の技術は IETF によって RFC 化されている部分も多いので、 正確かつ詳細な説明は RFC をご覧ください。 ここではかなり単純化して図示している。 • 実際は、シグナリングサーバ経由で STUN が取得したアドレスを 各 Peer に配るステップなどもあるが省略 • また、Player B も NAT 配下の可能性があるがそれも省略 • その他、 NAT が多重である可能性、 FW の考慮、etc. • 最終的にダイレクトに通信することができなければ TURN サーバ を使うなどしなければならない

Slide 31

Slide 31 text

Peer to Peer (P2P) or Client/Server Peer to Peer (P2P) サーバリソースが不要 → コスト◎ 通常はフルメッシュの NW 構造。 n(n-1)/2 の接続数。 100人対戦を P2P で単純に繋いだら、 1端末 99 接続、トータル 4,950 接続 (!) → 人数が少ない場合に有効 通信がサーバを経由せずダイレクトなの でレイテンシが優位なことも NAT 越えという実装と安定稼働の難しさ 一部端末の通信環境の悪さや不具合が、 マルチプレイ全体への影響となることも。 → 総じて安定稼働の実装難易度の高さ Client/Server プレイヤー数に応じてサーバリソースが 増加 NW 構成はシンプル。 プレイヤー数分のコネクション サーバを経由する通信オーバーヘッド サーバでロジックをチェックすることで チートを防ぎやすい ✨ ゲームロジックの大半をサーバに持たせ ることができるので、更新やデプロイが 容易かつ迅速 ✨ 同様に不具合の調査も相対的に楽 NAT 越え自体も面倒だがそれ以外にも P2P は実装及び運用上難しい側面がある もちろん P2P が C/S より劣っている ということはなく一⾧一短ではあるが、、

Slide 32

Slide 32 text

「Amazon GameLift （後述）を使用して、メッシュ化された ピアツーピアネットワークから専用サーバーへとインフ ラストラクチャを移行しました。これによって、安定性 や接続に関するさまざまな問題を解決し、『フォーオ ナー』のコアプレイヤーの環境をすべてのプラット フォームにおいて改善することに成功しました」 Exploring Trends of Multiplayer Game Infrastructure with Amazon Gamelift GDC2018 https://www.gdcvault.com/play/1024829/ 事例： UBISOFT様 For Honor

Slide 33

Slide 33 text

AWSグローバルインフラストラクチャ 22 リージョン リージョンとは、世界各地に 建設された物理的なロケーション、 複数のアベイラビリティゾーンから構成される 69 アベイラビリティゾーン リージョンの中にある複数の独立したロケーションで、 複数のデータセンター群から構成される 200 のPOP CDN や DNS などの拠点でユーザエクスペリエンス向 上のためネットワーク的にユーザにより近い位置で サービスを提供 ケープタウン、ミラノ、ジャカルタ、スペインにリージョンを新設予定 ユーザに近い位置でゲームサーバを稼働させることによりレイテンシを低減可能

Slide 34

Slide 34 text

AWSのグローバルネットワーク 100GbEのプライベート専用線で全てのリージョンを接続(中国除く) AWS バックボーンによる高速で安定した通信

Slide 35

Slide 35 text

EC2インスタンスファミリー 汎用 コンピューティング 最適化 ストレージ 最適化 高速 コンピューティング (GPU・FPGA) メモリ 最適化 メモリ・I/O・CPUクロック重視、GPU・FPGA搭載などの特徴を持つ 大きく5つのカテゴリに分類されるインスタンスファミリーを提供。 処理するワークロードに合わせて選択 F1 P3 G3 M5 M5a H1 D2 C5 C5n X1 R5 Z1d A1 I3 X1e R5a High Memory I3en T3 T3a M5n R5n 豊富なインスタンスラインナップと 高い処理能力

Slide 36

Slide 36 text

EC2インスタンスファミリー 汎用 コンピューティング 最適化 ストレージ 最適化 高速 コンピューティング (GPU・FPGA) メモリ 最適化 メモリ・I/O・CPUクロック重視、GPU・FPGA搭載などの特徴を持つ 大きく5つのカテゴリに分類されるインスタンスファミリーを提供。 処理するワークロードに合わせて選択 F1 P3 G3 M5 M5a H1 D2 C5 C5n X1 R5 Z1d A1 I3 X1e R5a High Memory I3en T3 T3a M5n R5n

Slide 37

Slide 37 text

C5n: 最も広帯域なN/Wを実現 最大サイズでは100 Gbps 、小さいサイズでも25 Gbps のピーク帯域 C5に比べ33% メモリ増量 Intel Xeon Scalable プロセッサ搭載 分析やビッグデータ処理に ネットワーク帯域性能 あたりのコストパフォーマンス AWSのスケーラビリティは そのまま C5n 同様の広帯域インスタンスとして R5n, M5n なども提供 ゲームサーバの大量の通信を支える広帯域のインスタンス

Slide 38

Slide 38 text

Implementation

Slide 39

Slide 39 text

AWS におけるゲームバックエンドの典型的構成の例

Slide 40

Slide 40 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile (1) ゲームクライアント（プレイヤーの端末）

Slide 41

Slide 41 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile Amazon CloudFront Asset Distribution S3 Bucket (2) 静的ファイル（DLCなど含む）の配信

Slide 42

Slide 42 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server DB Cache Database Job Worker Queue API (Out-Game) Amazon CloudFront Asset Distribution S3 Bucket (3) Request を受けて DB を参照/更新する API サーバ。 API サーバ自体はステートレスであることが多い。 キューとワーカーによる非同期のバルク処理と併用さ れることも。

Slide 43

Slide 43 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest DB Cache Database Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Amazon CloudFront Asset Distribution S3 Bucket (4) ロビーやバトルルームのセッションなど をステートフルに管理するゲームサーバ。 インゲームを構成する。

Slide 44

Slide 44 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest DB Cache Database Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Batch Server Amazon CloudFront Asset Distribution S3 Bucket Batch Processing (5) ランキング集計など様々 なバッチ処理。 日次バッチ/月次バッチなど

Slide 45

Slide 45 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest ETL / Aggregation DB Cache Database Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Analytics Datamart Redshift Cluster (Data Warehouse) S3 Bucket Batch Server Amazon CloudFront Asset Distribution S3 Bucket Batch Processing (6) KPI 算出などのためのデータ集計や 分析データの ETL 。 ETL や集計自体は通常定期バッチ処理。 ※ ストリーミング処理と併用される、いわゆる ラムダ・アーキテクチャのパターンも多い。

Slide 46

Slide 46 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest ETL / Aggregation DB Cache Database Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Analytics Datamart Redshift Cluster (Data Warehouse) S3 Bucket Batch Server Machine Learning Training Server Inference Endpoint S3 Bucket Amazon CloudFront Asset Distribution S3 Bucket Batch Processing (7) 機械学習がゲーム開発や運営に活用 される事例は増えている。 学習用のサーバ、推論を提供するWeb API サーバが主要コンポーネント

Slide 47

Slide 47 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest ETL / Aggregation DB Cache Database Build Server Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Analytics Datamart Redshift Cluster (Data Warehouse) S3 Bucket Batch Server Machine Learning Training Server Inference Endpoint S3 Bucket Amazon CloudFront Asset Distribution S3 Bucket Batch Processing (8) コードのコンパイルやア セットのパッケージング、レ ンダリングなど様々なビルド 処理

Slide 48

Slide 48 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest ETL / Aggregation DB Cache Database Build Server Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Analytics Datamart Redshift Cluster (Data Warehouse) S3 Bucket Batch Server Machine Learning Training Server Inference Endpoint S3 Bucket Amazon CloudFront Asset Distribution S3 Bucket Batch Processing (9) 開発環境やテスト環境 通常、本番環境の構成のサブセット やスモールセットとして同時に複数 が運用される Dev/Test Env

Slide 49

Slide 49 text

AWS におけるゲームバックエンドの典型的構成の例 PC Mobile ELB API Server Battle / Quest ETL / Aggregation DB Cache Database Build Server Job Worker Queue Match Making Lobby Game Server (In-Game) API (Out-Game) Analytics Datamart Redshift Cluster (Data Warehouse) S3 Bucket Batch Server Machine Learning Training Server Inference Endpoint S3 Bucket Amazon CloudFront Asset Distribution S3 Bucket Batch Processing Dev/Test Env

Slide 50

Slide 50 text

Redis Pub/Sub? or Redis Streams? Amazon ElastiCache Redis

Slide 51

Slide 51 text

Redis Pub/Sub • SUBSCRIBE したチャネルにメッセージ が PUBLISH されると Subscriver 全員に メッセージが配信される • 複数人の双方向通信を容易に実現 • Web 系サービスやゲームでは馴染みのあ る Redis で実現できるという手軽さ • Redis のマネージド・サービスである Amazon ElastiCache も利用可能 • メッセージは保管や queuing されない • コンピューティングの EC2 と pubsub 機 能の Redis が物理的に別れるのでレイテ ンシのシビアな用途には向かない • EC2 Instance のローカルに Redis サーバ を配置する構成も可能。だが、その場合 は Service Discovery など別の考慮事項が。 Application Load Balancer Instances ElastiCache for Redis publish subscribe WebSocket など

Slide 52

Slide 52 text

株式会社 Cygames 様 SHADOWVERSE AWS Summit Tokyo 2017 http://tech.cygames.co.jp/archives/3027/

Slide 53

Slide 53 text

Redis Streams • Redis 5.0 で新たに追加された新しい機能 であり、新しいデータ型 • Pub/Sub に近いが機能が大幅に強化 • 時系列追記型のデータ構造 • 任意のフィールドを複数保持可能 • 過去データを保持 → Consume されても データが残る（※） • 各 Consumer はそれぞれのペースで、範囲 指定して複数のデータを読み出せる • クライアントをグループ化した協調動作 → 異なる Consumer 間でのメッセージ処 理のスケールを設計可能 • クライアントが一時的な接続断から復旧し た後にその間のメッセージを後からまとめ て取得する、などの柔軟な処理が可能 ※ 永続化されるという意味ではありません。 Application Load Balancer Instances ElastiCache for Redis XADD #hoge * msg "hey!" XREAD STREAMS #hoge 0 WebSocket など https://aws.amazon.com/jp/redis/Redis_Streams/

Slide 54

Slide 54 text

Amazon CloudFront • Amazon CloudFront • CDN のサービスだが、 WebSocket もサポートし、 ALB をオリジンにすることが可能 • この場合は、キャッシングとは異なる用途 • WebSocket の通信品質の向上を 期待、ジッタ（ゆらぎ）の改善 （ただし利用の際は実際の環境で検証） Application Load Balancer Instances ElastiCache for Redis XADD #hoge * msg "hey!" XREAD STREAMS #hoge 0 WebSocket など Amazon CloudFront

Slide 55

Slide 55 text

Amazon Global Accelerator • Amazon CloudFront • CDN のサービスだが、 WebSocket もサポートし、 ALB をオリジンにすることが可能 • この場合は、キャッシングとは異なる用途 • WebSocket の通信品質の向上を 期待、ジッタ（ゆらぎ）の改善 （ただし利用の際は実際の環境で検証） • AWS Global Accelerator • CloudFront を利用するのに似て、ユーザに 近いエッジロケーションから通信先の AWS リージョンまで AWS バックボーンを利用 • インテリジェントなトラフィック分散 • 固定のエニキャスト IP • リージョン間フェイルオーバー Application Load Balancer Instances ElastiCache for Redis XADD #hoge * msg "hey!" XREAD STREAMS #hoge 0 WebSocket など AWS Global Accelerator

Slide 56

Slide 56 text

Serverless or Server-based?

Slide 57

Slide 57 text

抽象度 時代の流れ

Slide 58

Slide 58 text

抽象度 時代の流れ

Slide 59

Slide 59 text

抽象度 時代の流れ

Slide 60

Slide 60 text

抽象度 時代の流れ

Slide 61

Slide 61 text

抽象度 時代の流れ

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

Serverless WebSocket 通信 • Amazon API Gateway と AWS Lambda による WebSocket のサポート • WebSocket の接続のハンドリングを API Gateway に任せることができる。 AWS Lambda のコードもシンプルに。 • (1) 新規接続、 (2) メッセージ送信、 (3) 切断、 3つのポイントで実行される処理を3つの Lambda Function にそれぞれ実装するだけ • API Gateway の WebSocket の接続 ID の保存に Amazon DynamoDB などを使う。 • サーバの運用保守がなくなり、スケーリングの 管理の負担が大幅に低下 • DynamoDB は通常1桁ミリ秒のレイテンシで 応答する WebSocket Amazon API Gateway メッセージ Amazon DynamoDB 接続 切断

Slide 64

Slide 64 text

Serverless WebSocket 通信 (1) 新規接続 1. API Gateway に WebSocket プロトコルで新規 の接続要求が着信する 2. API Gateway は、新規の接続 (TCP Session) に 対して Connection ID を払い出し、Lambda Function を呼び出す 3. Lambda Function は Connection ID を 受け取り、DynamoDB に保存する WebSocket Amazon API Gateway メッセージ Amazon DynamoDB 接続 切断 Put connection id Invoke with connection id 接続要求

Slide 65

Slide 65 text

Serverless WebSocket 通信 (2) メッセージ送信 1. API Gateway は、メッセージの内容を Lambda Function に伝える 2. Lambda Function は DynamoDB に保存された Connection ID の一覧を取得する 3. Lambda 関数は、Connection ID ごとに、API Gateway の WebSocket 管理用 API を呼び出す。 呼び出す際には Connection ID とメッセージを データとして API Gateway に渡す。 4. API Gateway は指定された Connection ID (クライアント) に対しメッセージを送信する WebSocket Amazon API Gateway メッセージ Amazon DynamoDB 接続 切断 Scan connection id Message with each connection id Message Message

Slide 66

Slide 66 text

Serverless WebSocket 通信 (3) 切断 1. API Gateway に WebSocket プロトコルで切断 要求が着信する 2. API Gateway は、切断要求のあった Connection ID を Lambda Function に伝えて呼 び出す 3. Lambda Function は Connection ID を受け取り、 DynamoDB からレコードを削除する WebSocket Amazon API Gateway メッセージ Amazon DynamoDB 接続 切断 DeleteItem connection id Invoke with connection id 切断要求

Slide 67

Slide 67 text

Serverless WebSocket 通信 • WebSocket の接続のハンドリングを API Gateway に任せることができる。 AWS Lambda のコードもシンプルに。 • サーバの運用保守がなくなり、スケーリングの 管理の負担が大幅に低下 • DynamoDB は通常1桁ミリ秒のレイテンシで 応答する WebSocket Amazon API Gateway メッセージ Amazon DynamoDB 接続 切断

Slide 68

Slide 68 text

Managed Service or Amazon EC2

Slide 69

Slide 69 text

Amazon GameLift 数百万のプレイヤーに対応できるよう 専用ゲームサーバーをスケーリング・ホスティング AWS グローバルインフラストラクチャ上で稼働 DDoS 攻撃から保護するように設計 待機時間とレイテンシを 最小に抑えたゲーム体験を実現 柔軟にカスタマイズできる マッチメイキング機能を提供 クラウド内でセッションベースのマルチプレイヤー専用のゲームサーバーを デプロイ、操作、スケーリングするマネージドサービス

Slide 70

Slide 70 text

Managed Service or Amazon EC2 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 オンプレミス ゲームサーバ on EC2 Amazon GameLift お客様がご担当 AWS が提供する機能 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装

Slide 71

Slide 71 text

GameLift の担当範囲 Session Session Session Session Session Session Session Session Session マッチメイキング チャット 認証 ゲームサーバー群 GameLiftのカバー範囲 プレイヤーのマッチメイキング機能と マッチメイキング後に振り分けられる ゲームセッションが稼働する専用 ゲームサーバの管理機能の２つを提供

Slide 72

Slide 72 text

２種類のゲームサーバーのホスティング Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 カスタムゲームサーバー リアルタイムサーバー

Slide 73

Slide 73 text

２種類のゲームサーバーのホスティング Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 カスタムゲームサーバー リアルタイムサーバー

Slide 74

Slide 74 text

カスタムゲームサーバーの主要コンポーネント 主要コンポーネント 役割 ゲームサーバー クラウドで実行されるゲームのサーバーソフトウェア ゲームセッション プレイヤーの接続先となるゲームサーバーのインスタンス Amazon GameLift サービス ゲームサーバーをホストするための リソースを管理するコアサービス ゲームクライアント デバイスで実行されているゲームのソフトウェア クライアントサービス （ゲームサービス） GameLift サービスとゲームクライアント間の 通信を仲介するサービス 認証認可などゲーム固有のロジックも処理

Slide 75

Slide 75 text

カスタムゲームサーバーにおける ゲームへの統合と役割 ゲームサーバ クライアントサービス ゲームクライアント AWS SDK を使って Amazon GameLift のコントロール プレーンと通信、 その他、認証などの必要なサービス と適宜通信し (Optional) 、 ゲームサーバのアドレス/ポートな どの、接続のために必要な情報を クライアント（左）に返す Amazon GameLift Server SDK を使って、Amazon GameLift の コントロールプレーンと通信し、 プレイヤー及びゲームのセッション の状態を教えるともに指示を受け取 る クライアントサービス（中央） に対してマルチプレイをリクエ スト、 レスポンスの情報を使って ゲームサーバに直接接続。 AWS SDK Amazon GameLift Server SDK

Slide 76

Slide 76 text

カスタムゲームサーバーにおける ゲームのアーキテクチャ ① ③ ② ④ ⑤ ⑥

Slide 77

Slide 77 text

カスタムゲームサーバーの開発 主要なゲームエンジンをベースにして実装可能 Amazon GameLift Server SDK • C# (.NET) • C++ for Unreal Engine • C++ • Unity • Unreal Engine • Amazon Lumberyard • C++ または C# ライブラリを サポートするエンジン ゲームエンジン

Slide 78

Slide 78 text

フリートメトリクス • インスタンスの数 • ゲームセッション, プレイヤーセッション • サーバープロセス • インスタンスのパフォーマンス 時間経過にともなうメトリクスの変化をリアルタイムに追跡

Slide 79

Slide 79 text

フリート容量のスケーリング インスタンスをスケーリングしてコスト削減とプレイヤー体験をバランシング 手動で設定するかフリートメトリクスに基づく2種類の Auto Scaling を使用 • フリートメトリクスを用いた 評価式を作成して詳細に制御 • 特別な状況に対処するためターゲット 追跡の補助として有効 ターゲット追跡 ルールベースのスケーリング • フリートが維持する バッファのサイズを指定 • 多くのゲームでシンプルで効果的に機能

Slide 80

Slide 80 text

フリートでスポットインスタンスを活用 フリートタイプにスポットインスタンスを指定 最大で 90% の割引料金でゲームサーバーを稼動できる Amazon GameLift Spot Fleet スポットインスタンスを使うために • キューを使用してゲームセッションを配置 • ゲームサーバーで スポットの中断を処理できるようにする Amazon GameLift サービス ゲームサーバ onProcessTerminate

Slide 81

Slide 81 text

Amazon GameLift FlexMatch カスタマイズ可能なマッチメイキングサービス マッチングやリソースの手配を通じて最善のプレイヤー体験を実現 プレイヤーマッチングの評価方法を ゲームに合わせた柔軟な表現が可能 キューを使用して 最適なゲームセッションを効率的に配置 マッチメイキングのアクティビティに関する メトリクスを収集してリアルタイムに監視 最大 200 人の大規模なマッチングが可能 マッチングされたゲームの 空きプレイヤースロットを埋める マッチバックフィル機能を提供 （現在はカスタムゲームサーバーのみ）

Slide 82

Slide 82 text

FlexMatch ルールセット • プレイヤーのスキルレベルを マッチングに使いたい • 2つのチームを 4～8 人で構成したい • チームのスキルレベルの平均の差が 10 を超えないようにマッチングさせたい • 2つのチームが同じ人数になるように マッチングさせたい • もし一定時間マッチングしなかったら スキルレベルの差の条件を緩めたい マッチングを構築する一連の手順 チームのサイズと構造を定義しプレイヤーの評価方法を指定

Slide 83

Slide 83 text

North America Asia GameLift グローバルルーティング – 低レイテンシーの追求 Region (Virginia) Amazon Route 53 Region (Oregon) Region (Ireland) Region (London) Region (Tokyo) Region (Singapore) Alias Alias Alias Alias Alias Alias … … Amazon DynamoDB Amazon DynamoDB Queue Queue Queue Client Service Player Player … Europe Amazon GameLift FlexMatch

Slide 84

Slide 84 text

事例： Gearbox様 Borderlands 「Amazon GameLift のようなサービスは、考え得るあらゆる プラットフォームの世界中のユーザーに私たちがお届け できるプロフェッショナルなアベイラビリティーと信頼 性の点で、画期的なものです」 – Gearbox Borderlands developer Gearbox uses the cloud to change how it makes games | VentureBeat https://venturebeat.com/2018/02/05/borderlands-developer- gearbox-uses-the-cloud-to-change-how-it-makes-games/

Slide 85

Slide 85 text

“Custom Game Server“ or “Realtime Server“ Amazon GameLift

Slide 86

Slide 86 text

２種類のゲームサーバーのホスティング Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 カスタムゲームサーバー リアルタイムサーバー

Slide 87

Slide 87 text

マネージドサービス（GameLift）が やってくれること 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 オンプレミス ゲームサーバ on EC2 Amazon GameLift Custom Game Server お客様がご担当 AWS が提供する機能 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 Amazon GameLift Realtime Servers 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装

Slide 88

Slide 88 text

マネージドサービス（GameLift）が やってくれること 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 オンプレミス ゲームサーバ on EC2 Amazon GameLift Custom Game Server お客様がご担当 AWS が提供する機能 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 Amazon GameLift Realtime Servers 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 Unity, Unreal Engine, Amazon Lumberyard などの 主要なゲームエンジンをベースにして カスタムゲームサーバを実装 できるように専用の SDK を提供

Slide 89

Slide 89 text

マネージドサービス（GameLift）が やってくれること 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 オンプレミス ゲームサーバ on EC2 Amazon GameLift Custom Game Server お客様がご担当 AWS が提供する機能 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 Amazon GameLift Realtime Servers 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 Unity, Unreal Engine, Amazon Lumberyard などの 主要なゲームエンジンをベースにして カスタムゲームサーバを実装 できるように専用の SDK を提供 Node.js ベースの Javascript の フレームワーク・レイヤが 予め組み込まれている。 カスタマイズしたいタイミングについて 必要ならコールバック関数を JS で書くだけ 例） onMessage, onSartGameSession, etc.

Slide 90

Slide 90 text

Amazon GameLift リアルタイムサーバーとは 数行のスクリプトでゲームサーバーを作成できる軽量サーバーソリューション カスタムゲームサーバーと比較して複雑な処理を必要としないゲームに最適 Node.js ベースの JavaScript で実装 TCP, UDP によるメッセージング処理を提供 ステートレスとしてもステートフルとしても稼働 カスタムゲームサーバーと同様の GameLift の機能を利用可能（一部を除く） CCG、ターンベースの戦略ゲーム、 軽量のモバイルゲームなどに最適 Realtime Servers

Slide 91

Slide 91 text

Custom Game Server or Realtime Server Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 ゲームのジャンルや仕様、スキルセットに合わせて選択 カスタムゲームサーバー • ゲームエンジンを使用して サーバーのビルドバイナリを開発 • パッケージ化したビルドをアップロードし フリートをデプロイ • 詳細なゲームロジックを備え 完全にカスタマイズさせた 本格的なゲームサーバーとして最適 リアルタイムサーバー • Node.js ベースの JavaScript で サーバーのスクリプトを記述 • 記述したスクリプトをアップロードし フリートをデプロイ • 複雑さを必要とせず 簡単で迅速にゲームを起動させたい 軽量のゲームサーバーとして最適

Slide 92

Slide 92 text

ご利用料金について • 従量課金制 • 稼働しているインスタンス（ゲームサーバー）の使用時間 • Auto Scaling とスポットインスタンスでコストを削減 • インスタンスからインターネットへのデータ転送量 • ゲームクライアントとゲームサーバー間の アウトバウンドデータ転送に対して課金 • AWS 無料利用枠 • Amazon GameLift 向け c4.large オンデマンドインスタンスの使用 125 時間/月 EBS 汎用 (SSD) ストレージ 50 GB https://aws.amazon.com/jp/gamelift/pricing/

Slide 93

Slide 93 text

Wrap up

Slide 94

Slide 94 text

まとめ Peer to Peer (P2P) Redis Pub/Sub / Redis Streams Serverless WebSocket Game Servers on Amazon EC2 Amazon GameLift Custom Game Server Amazon GameLift Realtime Servers 通信レイテンシ ★★★ ～ ★★★★ ★ ★ − ～ ★★★ （※１） ★★★ （※１） ★★ ゲームセッション あたりのプレイヤー数 − ★★ ★★ − ～ ★★★ （※１） ★★★ ★★ 実装の柔軟性 ★★★★ ★★ ★ ★★★★ ★★★ ★ 実装の楽さ − ++ （Redis の慣れ にもよる） ★★ ★ ★★ ★★★★ 運用の楽さ − ★★ ★★★★ ★ ★★★ ★★★ コスト効果 ★★★★ ★ ★★ − ～★★ （※１） ★★ or ★★★ (FleetIQ) ★★ or ★★★ (FleetIQ) その他 NAT 越え出来なかった場 合など、P2P 以外の方法 との組み合わせを考慮。 Redis に慣れていれば 扱いやすい。 チャットなどにも使える。 Serverless 自体の初期 学習コストは多少あり。 チャットなどにも使える。 GameLift が使えるなら GameLift を推奨。 幅広い機能サポートと 柔軟性。ただし、ゲーム セッションの寿命が⾧い MMO などは不向き バックフィルなど一部未 サポート機能も。それら とレイテンシや処理能力 次第。 ※１ 設計と実装次第で大きく変動 ※２ また、上記全てあくまで目安です。ゲーム内容との相性や開発チームの状況、そして今後の AWS サービスのアップデートによって全く変わってきますことにご注意ください。

Slide 95

Slide 95 text

まとめ • オンラインマルチプレイ と言っても様々 • オンラインマルチプレイ の課題を解決する AWS における多様な解決手段と実装方法 • 開発チームの特性や、ゲーム内容に合った選択を！

Slide 96

Slide 96 text

Thank you!

Slide 97

Slide 97 text

No content