Online Multiplay Game leveraging AWS / AWSで実現するマルチプレイ [Amazon Game Developers Conference 2019]

https://aws.amazon.com/jp/about-aws/events/2019/doc1/

Transcript

1. Online Multiplay Game leveraging AWS Fumihiko Hata | Solutions Architect | 2019.11.20
2. 自己紹介 畑史彦 ソリューションアーキテクト アマゾンウェブサービスジャパン ゲームやエンターテインメント業界の会社を 担当させていただいています 週末は１歳と４歳の子供が遊んでくれます
3. マルチプレイゲーム？ このセッションでは オンライン のマルチプレイゲームを指して 「マルチプレイゲーム」と呼びます。 マルチプレイゲームの種類とそこに求められる要件を整理し、 それぞれ AWS に構築する際にどういう選択肢があるかを考え、あて はめてみます。 個々のサービスの詳細な説明は割愛されますことをご了承ください
4. 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)
5. Popular? or Not?
6. オンラインマルチプレイヤーゲーム
7. オンラインマルチプレイヤーゲーム Fortnite Apex Legends PLAYERUNKNOWN'S BATTLEGROUNDS 荒野行動 PUBG MOBILE and more…
8. オンラインマルチプレイヤーゲーム • PUBG を始めとした多数の、 いわゆる バトルロワイヤルゲーム の人気の上昇 • 1 対 多、100 ± の多人数対戦 • それにより高まる緊張感と勝利の興奮 • ゼロベースでの武器調達、隠れる・逃げる・建築などの多様な戦略と楽しみ方 • その流れはいまやモバイルにも • もちろん、バトロワ以外にも多数のマルチプレイのジャンルとゲームタイトル • MMO、MO、MOBA、FPS、TPS、CCG、RTS、格ゲー、レース、パズル、etc. • eスポーツの盛り上がり
9. マルチプレイの状況 株式会社 Gz ブレイン 2019年1月31日発行 『ファミ通モバイル白書２０１９』 182ページ マルチプレイの状況 より
10. マルチプレイの状況 株式会社 Gz ブレイン 2019年1月31日発行 『ファミ通モバイル白書２０１９』 182ページ マルチプレイの状況 より 実はオンラインのマル チプレイを遊んでいる のは全体の１割未満 ※モバイル
11. マルチプレイの状況 あれ？マルチプレイゲームってそんなに 流行ってない？
12. マルチプレイの状況 あれ？マルチプレイゲームってそんなに 流行ってない？ ・・・というよりは既に流行っているが、 それに加えてなお これからさらに新たにマ ルチプレイを遊びはじめるユーザのポテン シャルがある、という状況と捉えられる 今後、マルチプレイは、タイトル本数だけ でなく多様化や進化も激しくなっていきそう
13. マルチプレイの状況 あれ？マルチプレイゲームってそんなに 流行ってない？ ・・・あるいは既に流行っているが、 それに加えてなお これからさらに新たにマ ルチプレイを遊びはじめるユーザのポテン シャルがある、とも言える！ 今後、マルチプレイのゲーム性や タイトルはどんどん多様化 ＆ 増加 していく可能性 開発サイドに求められること・・・ より迅速なマルチプレイゲームの 実装、改善、試行錯誤、そして運用
14. Problems and Requirements
15. マルチプレイ実装における技術的課題
16. マルチプレイ実装における技術的課題１ 通信レイテンシ（遅延） 物理的に遠く離れたところにいるプレイヤー 同士を、仮想的に近付ける（ゲームの中では 近くにいるように感じさせる） • 光が遅く思えるほどには地球はでかい • 不安定なインターネットという通信環境 • 多数のプレイヤーへのリアルタイムな通信 を処理するための莫大なマシンリソース ※ もちろんそれ以外にもマルチプレイ特有の 様々な課題や要件がある： マッチメイキング、 チート、セキュリティ、etc.
17. マルチプレイ実装における技術的課題１ 通信レイテンシ（遅延） 物理的に遠く離れたところにいるプレイヤー 同士を、仮想的に近付ける（ゲームの中では 近くにいるように感じさせる） • 光が遅く思えるほどには地球はでかい • 不安定なインターネットという通信環境 • 多数のプレイヤーへのリアルタイムな通信 を処理するための莫大なマシンリソース ※ もちろんそれ以外にもマルチプレイ特有の 様々な課題や要件がある： マッチメイキング、 チート、セキュリティ、etc. FPS TPS 格ゲー / レーシング MO / MMO CCG / ターンベース ※上記はあくまで目安。 ゲーム性によっても全然変わる。 より低遅延が 要求される
18. マルチプレイ実装における技術的課題２ 大量の同時接続 レイテンシ（遅延）にシビアな接続を、同時かつ多 数維持し、それらの間で相互にデータを同期や処理 させ続けれなければいけない • １ゲームセッションあたりのプレイヤー数が多い ほど、単位マシンあたりの処理は重くなる • P2P の場合、クライアント端末の性能限界 （後述） • ゲームセッションの寿命もポイント MOBA や CCG は数分〜 だが、 MMO は半永続的
19. マルチプレイ実装における技術的課題２ 大量の同時接続 レイテンシ（遅延）にシビアな接続を、同時かつ多 数維持し、それらの間で相互にデータを同期や処理 させ続けれなければいけない • １ゲームセッションあたりのプレイヤー数が多い ほど、単位マシンあたりの処理は重くなる • P2P の場合、クライアント端末の性能限界 （後述） • ゲームセッションの寿命もポイント MOBA や CCG は数分〜 だが、 MMO は半永続的 MMO バトルロワイヤル MO レース / MOBA CCG ※上記はあくまで目安。 ゲーム性によっても全然変わる。 １ゲームセッション あたりのプレイヤー数
20. P2P or Server/Client
21. Offline or Online 友達の家に集まって
22. Offline or Online 友達の家に集まって Internet
23. Peer to Peer (P2P) or Client/Server Internet ゲームサーバ (リレー / TURN)
24. Peer to Peer (P2P) or Client/Server Internet ゲームサーバ (リレー / TURN) Internet
25. 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 構成はシンプル。 プレイヤー数分のコネクション サーバを経由する通信オーバーヘッド サーバでロジックをチェックすることで チートを防ぎやすい ✨ ゲームロジックの大半をサーバに持たせ ることができるので、更新やデプロイが 容易かつ迅速 ✨ 同様に不具合の調査も相対的に楽
26. 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 出来ない場合にはリレーサーバが 通信を仲介する構成にフェイルオーバーする。
27. Hole Punching • いわゆる NAT 越えの方法の１つ • 昨今のエンドユーザ端末は、だいたいなん らかの NAT 配下にいることが多い • 各端末が自分のアドレスとポートを自己申 告 (xxx.xxx.xxx.xxx) してもそれが NAT で書 き換えられているのであれば、他の端末か らそこ宛 (xxx.xxx.xxx.xxx) に通信しても届 かない • そのため、一度サーバ (STUN サーバ) と通 信させることでそのサーバから見える （NATされた後の）アドレスとポートを収 集し、それを各端末に教える • 各端末は、そのアドレスとポートを使って お互いにダイレクトに通信しあう ※ NAT の状況によっては、STUN だけでは解決できないことも（→ TURN を使うなど） ※ NAT 越え (NAT traversal) の手法は、STUN 以外にも B2BUA など他にも複数ある
28. 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 など他にも複数ある
29. 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 など他にも複数ある
30. 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 サーバ を使うなどしなければならない
31. 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 より劣っている ということはなく一⾧一短ではあるが、、
32. 「Amazon GameLift （後述）を使用して、メッシュ化された ピアツーピアネットワークから専用サーバーへとインフ ラストラクチャを移行しました。これによって、安定性 や接続に関するさまざまな問題を解決し、『フォーオ ナー』のコアプレイヤーの環境をすべてのプラット フォームにおいて改善することに成功しました」 Exploring Trends of Multiplayer Game Infrastructure with Amazon Gamelift GDC2018 https://www.gdcvault.com/play/1024829/ 事例： UBISOFT様 For Honor
33. AWSグローバルインフラストラクチャ 22 リージョン リージョンとは、世界各地に 建設された物理的なロケーション、 複数のアベイラビリティゾーンから構成される 69 アベイラビリティゾーン リージョンの中にある複数の独立したロケーションで、 複数のデータセンター群から構成される 200 のPOP CDN や DNS などの拠点でユーザエクスペリエンス向 上のためネットワーク的にユーザにより近い位置で サービスを提供 ケープタウン、ミラノ、ジャカルタ、スペインにリージョンを新設予定 ユーザに近い位置でゲームサーバを稼働させることによりレイテンシを低減可能
34. AWSのグローバルネットワーク 100GbEのプライベート専用線で全てのリージョンを接続(中国除く) AWS バックボーンによる高速で安定した通信
35. 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 豊富なインスタンスラインナップと 高い処理能力
36. 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
37. C5n: 最も広帯域なN/Wを実現 最大サイズでは100 Gbps 、小さいサイズでも25 Gbps のピーク帯域 C5に比べ33% メモリ増量 Intel Xeon Scalable プロセッサ搭載 分析やビッグデータ処理に ネットワーク帯域性能 あたりのコストパフォーマンス AWSのスケーラビリティは そのまま C5n 同様の広帯域インスタンスとして R5n, M5n なども提供 ゲームサーバの大量の通信を支える広帯域のインスタンス
38. Implementation
39. AWS におけるゲームバックエンドの典型的構成の例
40. AWS におけるゲームバックエンドの典型的構成の例 PC Mobile (1) ゲームクライアント（プレイヤーの端末）
41. AWS におけるゲームバックエンドの典型的構成の例 PC Mobile Amazon CloudFront Asset Distribution S3 Bucket (2) 静的ファイル（DLCなど含む）の配信
42. 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 サーバ自体はステートレスであることが多い。 キューとワーカーによる非同期のバルク処理と併用さ れることも。
43. 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) ロビーやバトルルームのセッションなど をステートフルに管理するゲームサーバ。 インゲームを構成する。
44. 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) ランキング集計など様々 なバッチ処理。 日次バッチ/月次バッチなど
45. 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 や集計自体は通常定期バッチ処理。 ※ ストリーミング処理と併用される、いわゆる ラムダ・アーキテクチャのパターンも多い。
46. 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 サーバが主要コンポーネント
47. 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) コードのコンパイルやア セットのパッケージング、レ ンダリングなど様々なビルド 処理
48. 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
49. 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
50. Redis Pub/Sub? or Redis Streams? Amazon ElastiCache Redis
51. 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 など
52. 株式会社 Cygames 様 SHADOWVERSE AWS Summit Tokyo 2017 http://tech.cygames.co.jp/archives/3027/
53. 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/
54. 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
55. 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
56. Serverless or Server-based?
57. 抽象度 時代の流れ
58. 抽象度 時代の流れ
59. 抽象度 時代の流れ
60. 抽象度 時代の流れ
61. 抽象度 時代の流れ
63. 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 接続 切断
64. 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 接続要求
65. 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
66. 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 切断要求
67. Serverless WebSocket 通信 • WebSocket の接続のハンドリングを API Gateway に任せることができる。 AWS Lambda のコードもシンプルに。 • サーバの運用保守がなくなり、スケーリングの 管理の負担が大幅に低下 • DynamoDB は通常1桁ミリ秒のレイテンシで 応答する WebSocket Amazon API Gateway メッセージ Amazon DynamoDB 接続 切断
68. Managed Service or Amazon EC2
69. Amazon GameLift 数百万のプレイヤーに対応できるよう 専用ゲームサーバーをスケーリング・ホスティング AWS グローバルインフラストラクチャ上で稼働 DDoS 攻撃から保護するように設計 待機時間とレイテンシを 最小に抑えたゲーム体験を実現 柔軟にカスタマイズできる マッチメイキング機能を提供 クラウド内でセッションベースのマルチプレイヤー専用のゲームサーバーを デプロイ、操作、スケーリングするマネージドサービス
70. Managed Service or Amazon EC2 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 オンプレミス ゲームサーバ on EC2 Amazon GameLift お客様がご担当 AWS が提供する機能 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装 電源、ネットワーク ラック導入管理 サーバメンテナンス OS のパッチ クライアントのレイテンシの考慮 柔軟なマッチメイキング ゲームサーバ特有の処理の実装 SpotInstance の活用 ゲームロジックに 合わせたスケーリング OS の導入 そのゲーム特有の処理の実装
71. GameLift の担当範囲 Session Session Session Session Session Session Session Session Session マッチメイキング チャット 認証 ゲームサーバー群 GameLiftのカバー範囲 プレイヤーのマッチメイキング機能と マッチメイキング後に振り分けられる ゲームセッションが稼働する専用 ゲームサーバの管理機能の２つを提供
72. ２種類のゲームサーバーのホスティング Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 カスタムゲームサーバー リアルタイムサーバー
73. ２種類のゲームサーバーのホスティング Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 カスタムゲームサーバー リアルタイムサーバー
74. カスタムゲームサーバーの主要コンポーネント 主要コンポーネント 役割 ゲームサーバー クラウドで実行されるゲームのサーバーソフトウェア ゲームセッション プレイヤーの接続先となるゲームサーバーのインスタンス Amazon GameLift サービス ゲームサーバーをホストするための リソースを管理するコアサービス ゲームクライアント デバイスで実行されているゲームのソフトウェア クライアントサービス （ゲームサービス） GameLift サービスとゲームクライアント間の 通信を仲介するサービス 認証認可などゲーム固有のロジックも処理
75. カスタムゲームサーバーにおける ゲームへの統合と役割 ゲームサーバ クライアントサービス ゲームクライアント AWS SDK を使って Amazon GameLift のコントロール プレーンと通信、 その他、認証などの必要なサービス と適宜通信し (Optional) 、 ゲームサーバのアドレス/ポートな どの、接続のために必要な情報を クライアント（左）に返す Amazon GameLift Server SDK を使って、Amazon GameLift の コントロールプレーンと通信し、 プレイヤー及びゲームのセッション の状態を教えるともに指示を受け取 る クライアントサービス（中央） に対してマルチプレイをリクエ スト、 レスポンスの情報を使って ゲームサーバに直接接続。 AWS SDK Amazon GameLift Server SDK
76. カスタムゲームサーバーにおける ゲームのアーキテクチャ ① ③ ② ④ ⑤ ⑥
77. カスタムゲームサーバーの開発 主要なゲームエンジンをベースにして実装可能 Amazon GameLift Server SDK • C# (.NET) • C++ for Unreal Engine • C++ • Unity • Unreal Engine • Amazon Lumberyard • C++ または C# ライブラリを サポートするエンジン ゲームエンジン
78. フリートメトリクス • インスタンスの数 • ゲームセッション, プレイヤーセッション • サーバープロセス • インスタンスのパフォーマンス 時間経過にともなうメトリクスの変化をリアルタイムに追跡
79. フリート容量のスケーリング インスタンスをスケーリングしてコスト削減とプレイヤー体験をバランシング 手動で設定するかフリートメトリクスに基づく2種類の Auto Scaling を使用 • フリートメトリクスを用いた 評価式を作成して詳細に制御 • 特別な状況に対処するためターゲット 追跡の補助として有効 ターゲット追跡 ルールベースのスケーリング • フリートが維持する バッファのサイズを指定 • 多くのゲームでシンプルで効果的に機能
80. フリートでスポットインスタンスを活用 フリートタイプにスポットインスタンスを指定 最大で 90% の割引料金でゲームサーバーを稼動できる Amazon GameLift Spot Fleet スポットインスタンスを使うために • キューを使用してゲームセッションを配置 • ゲームサーバーで スポットの中断を処理できるようにする Amazon GameLift サービス ゲームサーバ onProcessTerminate
81. Amazon GameLift FlexMatch カスタマイズ可能なマッチメイキングサービス マッチングやリソースの手配を通じて最善のプレイヤー体験を実現 プレイヤーマッチングの評価方法を ゲームに合わせた柔軟な表現が可能 キューを使用して 最適なゲームセッションを効率的に配置 マッチメイキングのアクティビティに関する メトリクスを収集してリアルタイムに監視 最大 200 人の大規模なマッチングが可能 マッチングされたゲームの 空きプレイヤースロットを埋める マッチバックフィル機能を提供 （現在はカスタムゲームサーバーのみ）
82. FlexMatch ルールセット • プレイヤーのスキルレベルを マッチングに使いたい • 2つのチームを 4～8 人で構成したい • チームのスキルレベルの平均の差が 10 を超えないようにマッチングさせたい • 2つのチームが同じ人数になるように マッチングさせたい • もし一定時間マッチングしなかったら スキルレベルの差の条件を緩めたい マッチングを構築する一連の手順 チームのサイズと構造を定義しプレイヤーの評価方法を指定
83. 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
84. 事例： 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/
85. “Custom Game Server“ or “Realtime Server“ Amazon GameLift
86. ２種類のゲームサーバーのホスティング Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 カスタムゲームサーバー リアルタイムサーバー
87. マネージドサービス（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 の導入 そのゲーム特有の処理の実装
88. マネージドサービス（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 を提供
89. マネージドサービス（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.
90. Amazon GameLift リアルタイムサーバーとは 数行のスクリプトでゲームサーバーを作成できる軽量サーバーソリューション カスタムゲームサーバーと比較して複雑な処理を必要としないゲームに最適 Node.js ベースの JavaScript で実装 TCP, UDP によるメッセージング処理を提供 ステートレスとしてもステートフルとしても稼働 カスタムゲームサーバーと同様の GameLift の機能を利用可能（一部を除く） CCG、ターンベースの戦略ゲーム、 軽量のモバイルゲームなどに最適 Realtime Servers
91. Custom Game Server or Realtime Server Amazon GameLift は 2 種類の方法でサーバーをホスティング可能 ゲームのジャンルや仕様、スキルセットに合わせて選択 カスタムゲームサーバー • ゲームエンジンを使用して サーバーのビルドバイナリを開発 • パッケージ化したビルドをアップロードし フリートをデプロイ • 詳細なゲームロジックを備え 完全にカスタマイズさせた 本格的なゲームサーバーとして最適 リアルタイムサーバー • Node.js ベースの JavaScript で サーバーのスクリプトを記述 • 記述したスクリプトをアップロードし フリートをデプロイ • 複雑さを必要とせず 簡単で迅速にゲームを起動させたい 軽量のゲームサーバーとして最適
92. ご利用料金について • 従量課金制 • 稼働しているインスタンス（ゲームサーバー）の使用時間 • Auto Scaling とスポットインスタンスでコストを削減 • インスタンスからインターネットへのデータ転送量 • ゲームクライアントとゲームサーバー間の アウトバウンドデータ転送に対して課金 • AWS 無料利用枠 • Amazon GameLift 向け c4.large オンデマンドインスタンスの使用 125 時間/月 EBS 汎用 (SSD) ストレージ 50 GB https://aws.amazon.com/jp/gamelift/pricing/
93. Wrap up
94. まとめ 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 サービスのアップデートによって全く変わってきますことにご注意ください。
95. まとめ • オンラインマルチプレイ と言っても様々 • オンラインマルチプレイ の課題を解決する AWS における多様な解決手段と実装方法 • 開発チームの特性や、ゲーム内容に合った選択を！
96. Thank you!