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

チャットボット特集

#AWS

森永大志

2017.11.28

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

森永です。
遂に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のフラッピング
  - ボリュームの喪失