Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

hata

May 11, 2020
Tweet

More Decks by hata

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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)

    View full-size slide

  5. Popular?
    or Not?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. Problems
    and
    Requirements

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  20. P2P
    or
    Server/Client

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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 構成はシンプル。
    プレイヤー数分のコネクション
    サーバを経由する通信オーバーヘッド
    サーバでロジックをチェックすることで
    チートを防ぎやすい
    ✨ ゲームロジックの大半をサーバに持たせ
    ることができるので、更新やデプロイが
    容易かつ迅速
    ✨ 同様に不具合の調査も相対的に楽

    View full-size slide

  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 出来ない場合にはリレーサーバが
    通信を仲介する構成にフェイルオーバーする。

    View full-size slide

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

    View full-size slide

  28. Hole Punching
    • いわゆる NAT 越えの方法の1つ
    • 昨今のエンドユーザ端末は、だいたいなん
    らかの 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 など他にも複数ある

    View full-size slide

  29. Hole Punching
    • いわゆる NAT 越えの方法の1つ
    • 昨今のエンドユーザ端末は、だいたいなん
    らかの 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 など他にも複数ある

    View full-size slide

  30. Hole Punching
    • いわゆる NAT 越えの方法の1つ
    • 昨今のエンドユーザ端末は、だいたいなん
    らかの 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 サーバ
    を使うなどしなければならない

    View full-size slide

  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 より劣っている
    ということはなく一⾧一短ではあるが、、

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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
    豊富なインスタンスラインナップと
    高い処理能力

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  38. Implementation

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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 サーバ自体はステートレスであることが多い。
    キューとワーカーによる非同期のバルク処理と併用さ
    れることも。

    View full-size slide

  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) ロビーやバトルルームのセッションなど
    をステートフルに管理するゲームサーバ。
    インゲームを構成する。

    View full-size slide

  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) ランキング集計など様々
    なバッチ処理。
    日次バッチ/月次バッチなど

    View full-size slide

  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 や集計自体は通常定期バッチ処理。
    ※ ストリーミング処理と併用される、いわゆる
    ラムダ・アーキテクチャのパターンも多い。

    View full-size slide

  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 サーバが主要コンポーネント

    View full-size slide

  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) コードのコンパイルやア
    セットのパッケージング、レ
    ンダリングなど様々なビルド
    処理

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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 など

    View full-size slide

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

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  56. Serverless
    or
    Server-based?

    View full-size slide

  57. 抽象度
    時代の流れ

    View full-size slide

  58. 抽象度
    時代の流れ

    View full-size slide

  59. 抽象度
    時代の流れ

    View full-size slide

  60. 抽象度
    時代の流れ

    View full-size slide

  61. 抽象度
    時代の流れ

    View full-size slide

  62. 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
    接続 切断

    View full-size slide

  63. 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
    接続要求

    View full-size slide

  64. 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

    View full-size slide

  65. 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
    切断要求

    View full-size slide

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

    View full-size slide

  67. Managed Service
    or
    Amazon EC2

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    クライアントサービス(中央)
    に対してマルチプレイをリクエ
    スト、
    レスポンスの情報を使って
    ゲームサーバに直接接続。
    AWS SDK
    Amazon GameLift
    Server SDK

    View full-size slide

  75. カスタムゲームサーバーにおける
    ゲームのアーキテクチャ






    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  82. 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

    View full-size slide

  83. 事例: 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/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  86. マネージドサービス(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 の導入
    そのゲーム特有の処理の実装

    View full-size slide

  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 の導入
    そのゲーム特有の処理の実装
    Unity, Unreal Engine, Amazon Lumberyard などの
    主要なゲームエンジンをベースにして
    カスタムゲームサーバを実装
    できるように専用の SDK を提供

    View full-size slide

  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 を提供
    Node.js ベースの Javascript の
    フレームワーク・レイヤが
    予め組み込まれている。
    カスタマイズしたいタイミングについて
    必要ならコールバック関数を JS で書くだけ
    例) onMessage, onSartGameSession, etc.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide