[レポート] ゲームのバックエンドを支えるスケーラブルかつ柔軟な AWS でのインフラ構築 #AWSSummit

5/30 から 6/1 まで、東京・品川で開催されております AWS Summit Tokyo 2018。こちらで講演されたセッション「AWS を使った動画配信入門」を聴講しましたのでレポートします。
2018.06.06

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

5/30 から 6/1 まで、 AWS Summit Tokyo 2018 が東京・品川で開催されました。こちらで講演されたセッション「ゲームのバックエンドを支えるスケーラブルかつ柔軟な AWS でのインフラ構築」を聴講しましたのでレポートします。

今回のAWS Summitでは全セッションにて撮影が禁止されておりました。資料は後ほど公開されるとは思いますが、いまのところは文字だけのご報告となります。

概要

近年、ゲーム市場において PC、モバイル、コンソールと多様化しており、ゲームのネットワーク接続が当たり前になってきています。本セッションでは、ゲームのバックエンドで高トラフィックなインフラを AWS 上で、どのように構築し運用するか、またゲームの分析基盤などの構築について事例を交えてご紹介します。

スピーカ

  • 森 祐孝
    • アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
    • 担当 : ソーシャルゲーム、コンソール系ゲーム会社

※敬称略

レポート

  • 「ゲームの開発は楽しい」
    • しかし…
    • 長い時間をかけて開発し、リリースした瞬間に「サーバーエラー」
      • わび石、延期、、、
  • ゲームのリリースの準備は大丈夫か??
    • メディアのレビュー
    • ユーザ評価
    • アプリストアのフィーチャリング(お勧め)
    • 想定した最悪のシナリオ の 50 倍 のアクセスが来たりもする
  • ユーザの需要に合わせてサーバをスケール
    • 過剰なキャパシティ、無駄な投資
    • 需要に対応できない、ゲームプレイヤーに不満
  • 従来 : Rigid
  • AWS : Elastic

インフラはどう作るか

  • アンチパターン = モノリシック
    • 認証モジュールなどはリリース・メンテ明けに急に負荷が高くなる、他がそこに引きづられる
  • アンチパターン = モノリシックスケーリング
    • モノリシックなサーバをそのまま並列(スケールアウト)
    • ユーザが増えれば、マッチメイキングやマルチプレイヤーロジックなどがネックとなる
  • サービス指向のアーキテクチャ
    • モジュールを分割
      • API化してサーバを分ける
      • モジュールごとに開発、OSを変更することすらできる
    • 認証 -> マッチメイキング間の通信
      • 認証に規模が必要 -> 認証モジュールだけを負荷分散(ELB追加)
      • マッチメイキングの前にELBを置くことも可能
      • 必要に応じてバラバラに構築・スケールを考えることができる
    • 一番弱いところのスループットに全体が引っ張られる
      • -> 弱いところの前段にキューを追加 = SQS
    • ELB -> 認証 -> SQS -> マッチメイキング
      • = イベント駆動アーキテクチャ
  • 基本的なゲームバックエンドサーバのコンセプト
    • クライアントとの通信はAPI経由
    • HTTP + JSON、gRPC
    • フレンドリスト、リーダボード
    • バイナリアセットデータ
    • マルチプレイヤー
    • 高可用性
    • 拡張性
  • S3 + CloudFront
    • アセット、DLC、セーブデータ
  • マルチプレイヤーゲームサーバ
    • ダイレクトソケット
  • ゲームAPIバックエンドサーバ
    • 認証、マッチメイキング
    • 最適なリージョンを選択
    • 2つ以上のAZ
    • アプリ用EC2
    • ELB
    • Amazon RDS (MySQL, MariaDB, Aurora...)
      • Multi-AZ
      • 最近だとAuroraを使う案件が増えている(ゲームのワークロードに適している)
  • スケールアウト!
    • S3 ゲームデータ格納
      • ゲームデータ、アセット、ログや分析データ
    • CloudFront コンテンツ配信
    • Auto Scaling Group
    • ElastiCache (Memcached, Redis)
  • ElasticCache(Redis)をつかったチャット、リーダーボード、ランキングボード
  • マネージドサービスを用いたデータのキャッシュ方法
    • RDSのストアドプロシジャを使ってLambdaを起動、DynamoDBを参照しS3へ

データベース

  • DBの更新頻度が課題に
    • ゲームはライト(write)ヘビー
  • シャーディングはつらい。。。
    • データのJOINが難しい
    • データの集計でDBをまたぐ
    • オートインクリメントが使えない
  • 解決策 : DynamoDB
    • フルマネージド
    • NoSQLデータストア、容量無制限
    • プロビジョンドスループット
    • セカンダリインデクス
    • PUT/GET Keys
    • TTLサポート
    • ドキュメント型のサポート
    • 400KBアイテム
    • PITRサポート
    • DynamoDB Accelerator(Cache)
  • DynamoDBはゲームに向いている
    • ユーザデータをDynamoDBで管理
    • Partition Key に UserIDを使用
    • スキーマレス(カラムを増やすことも簡単)
    • TTLを活用、いらなくなったデータを削除
  • DynamoDBをつかったマイクロサービス構成
    • QueryとOLTPを分ける

API

  • API Gateway
  • マルチプレイヤーゲームサーバ
    • APIを使ったログイン
    • マッチメイキング
    • ゲームサーバのIPを取得
  • gRPCを使ったAPI接続の注意点
    • ALB と バックエンド間の通信はHTTP/1.1になる = gRPCは使えない
    • NLBを推奨

事例・その他

  • 事例 - 株式会社グラニ
  • グローバル展開
    • 適したリージョンに構築、バックエンドはリージョン間通信
    • 事例 : PUBG
      • 全ての非同期メッセージング処理はSQS
    • Nexon
      • Echo System Simulator
        • 植生のシミュレーションを非同期で実行
    • CloudFrontのGeoIPで適したAPIへ誘導
    • DynamoDB Global Tables
      • フルマネージド、マルチマスター、マルチリージョンデータベース
  • Game Analytics
    • S3を中心としたデータレイク
      • 分析、バックアップ、BI、機械学習 etc
      • 事例 : ユーザがゲーム内でどこで死んだかを分析、ゲームマップを改善
        • ヒートマップ表示
        • Kinesis + Redshift
  • Gaming Analytics Pipeline – AWS Answers
    • 実績ある分析プラットフォームをワンクリックで構築

まとめ : Amazon Game Tech