【レポート】 GAM301: 「League of Legends」 PlatformのAWSへの移行 #reinvent #gam301

森永です。
遂にre:InventのBreakout Sessionが始まりました。 今年は例年よりさらに人が多くてなかなか大変です。。。

最初に選んだセッションは世界中で非常に人気のあるRiot Game社製ゲーム「League of Legends(LoL)」のセッションです。
ゲーム好きとして完全に個人的な興味で聞きに行きました。

登壇者

Rob Cameron氏
Senior Infrastructure Engineer, Riot Games

セッション内容

• 何を解決しようとしたのか
  • LoLのコンポーネントは大きく3つある
    • Platform
      • ログイン/ログアウト
      • チャット
      • ストア
      • マッチメイキング
      • プレイヤー統計
    • rCluster
      • Riotが独自開発したコンテナ環境
        • Docker+Software Defined Networking
      • マイクロサービスアーキテクチャ
      • All new services
    • Game Server
      • 非常にレイテンシに厳しい
      • 60ms以下のレイテンシ目標
      • サーバごとに数百のゲームが実行される
• Riot shared locations
  • 世界中に独自のDCを持っている
    • 基本的にはRiot GamesのDC
    • 東南アジアはGarena
    • 中国はTencent
• どのように解決したのか
  • AWS API driven architecture
    • あらゆる操作がAPIでできる
  • インフラ管理のツールを検討
    • 以下の要件が必要
      • Configuration as code
      • 外部の人がコントリビュートできる
      • 長期間のサポート
      • ベアメタルのサポート
      • 全ての主要パブリッククラウドサポート
      • すぐにデリバリ出来る
  • 選ばれたツール
    • Packer
      • 以下のイメージビルドが可能
        • AMI
        • VMware OVF
        • Vagrant Virtualbox
        • MAAS(Metal as a Service)イメージ
      • うまくいったこと
        • Riot社の中で採用された
        • イメージ作成の要件を満たせた
      • 課題
        • ビルとする際のパイプラインをどうするか
        • Windowsのイメージ作成
    • Terraform
      • Infrastructure as code
        • 簡単に編集、バージョン管理ができる
        • 他製品とコラボレーション
        • 一つのリポジトリでたくさんのデプロイが可能
      • うまくいったこと
        • Riot社の中で採用された
        • AWSとMAASの両方で使える
      • 課題
        • ステートの管理
        • 長期間変更に耐えうるようにするのが困難
  • インフラのワークフロー
    • Code（コードを書く）
    • Review（レビューする）
    • Validate（検証する）
    • Apply（適用する）
  • Terraform ステートシステム
    • Codeでステートを記述
    • Terraform側のステートとAWS側の実際のステートが違う可能性がある
  • Terraform ステート継承
    • VPCからWeb Server、Web ServerからELBのようにステートを継承できる
    • 例）VPCで作成したSubnetのIDをWeb Serverで指定
  • Terraformの機能拡張
    • Power DNS
      • DNSのエントリー作成
      • カスタムJWT(JSON Web Token)認証
      • Route 53のように使える
    • F5 configuration
      • VIP作成
      • 自動でサーバを追加
      • ELB/ALBのように使える
    • MAAS provider
      • ベアメタルのデプロイ
      • ユーザデータ
      • デプロイするOSの定義
      • EC2インスタンスのように使える
  • 独自のツールを作る
    • どんな時に独自ツールを作るか
      • ニッチな問題を解決
      • 今あるツールがワークフローにマッチしない
      • あらゆる状況でフルコントロールしたい
      • ツールのファン？
    • 何を使って独自ツールを作るか
      • 自分のエコシステム内の言語
      • 自分の組織でサポートできる言語
      • あなたが学習した言語？
• アーキテクチャ
  • Platform/ツール/Mock Game Server/Test ClientsはAWS
  • それ以外はDC
  • DCとAWSはDXで接続
  • 機能ごとにVPCを分けている
  • 相互接続が必要な各機能はVPC Peeringで接続
  • Shared services
    • DNS
    • NTP
    • Chef
    • AutoScaling Proxy
  • Platform
    • FrontEnd Apps
    • BackEnd Apps
    • Store Services
    • Matchmaking
    • Chat Services
    • Persistance Data Stores
  • Platform 2
    • Platform DB
    • Store DB
    • Matchmaking DB
    • Chat DB
  • Load testing harness
    • LT Harnessを大量に並列にプロビジョニング
  • Load testing game servers
    • Game serverを数台並列にプロビジョニング
  • Load testingの流れ
    • LT harnessからInternet Gatewayへ
    • Internetを通ってRiot DCへ
    • DXを通ってVPCへ
  • 長期間運用での課題
    • VPN Gatewayの喪失
    • インスタンスがスタック
    • インスタンスの増減
    • ELBのスケーリング
    • DXのフラッピング
    • ボリュームの喪失

最後に

LoLの裏側の一端をしれて楽しかったです。
rClousterの話などこちらに色々裏話が書かれていますので興味のある方はぜひ御覧ください。