この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
福岡のyoshihitohです。re:Invent 2018のセッション「Globalizing Player Accounts at Riot Games While Maintaining Availability」についてレポートします。
セッション情報
セッション名
Globalizing Player Accounts at Riot Games While Maintaining Availability
スピーカー
- Tyler Turk - Senior Infrastructure Engineer, Riot Games
概要
原文の引用です。
The Player Accounts team at Riot Games needed to consolidate the player account infrastructure and provide a single, global accounts system for the League of Legends player base. To do this, they migrated hundreds of millions of player accounts into a consolidated, globally replicated composite database cluster in AWS. This provided higher fault tolerance and lower latency access to account data. In this talk, we discuss this effort to migrate eight disparate database clusters into AWS as a single composite database cluster replicated in four different AWS regions, provisioned with terraform, and managed and operated by Ansible.
以下、意訳です。
- Riot Games のプレイヤーアカウントチームは、 League of Legends (リージョンごとの)アカウント基盤を1つにまとめ、グローバルアカウントに統合する必要があった
- これを実現するため数億に渡るプレイヤーアカウントを統合し、AWS上に構築した世界中のデータベースクラスタに複製した。これによって高い耐障害性と、アカウント情報の低レイテンシアクセスを実現した
- このセッションでは、8つ(のリージョン)に分離したデータベースクラスタを、AWS上の1つのデータベースクラスタに移行する際の努力について議論する
以降がセッション内容です。
Riot Gamesのプレイヤーアカウント基盤で、運用を維持しながら裏側でグローバル化対応を進める
登壇者紹介
アジェンダ
- League of Legendsのアカウントの歴史
- グローバルなサービスを設計する
- グローバルなサービスを実装する
- 学んだこと
- まとめ
アカウントのはじまり
- 10個のユニークなデータベース
- 数億に渡るプレイヤー
- 不審なログインの通信
- 他プレイヤーのアカウントを乗っ取ろうとする形跡
早期のチャレンジ (小さなインディー会社だった頃)
- 各チームがレガシーシステムを調査していた
- セキュリティ弱め
- 柔軟性に欠ける設計
- サードパーティ製品と統合できない
RiotSignOnの開始
- OpenID Connect の仕組みで構築する
- すべての認証・認可サービスを置き換えた
- セキュリティ標準を採用した
RiotSignOnのインフラストラクチャ
Global Data Protection Regulartion (GDPR) 対応
- プレイヤーのデータを保護するためスキーマを変更
- 個人情報を暗号化
- グローバルなコンプライアンス対応
望ましい機能
- グローバルに一意なプレイヤー識別子 (PUUID)
- グローバルなアカウント検索システム
- サードパーティ対応
我々は何を求めていたか
- 再現性のあるインフラストラクチャ
- Infrastructure as Code
- 高いポータビリティ性(可搬性)
- 再利用可能なモジュール
- 高可用性
- 地域に応じたルーティング
- 耐障害性
- 世界中のどこにでもデプロイできる
- 国際化対応
- データの一貫性
- 世界中での書き込み、マルチマスター
- マスターへの単一の書き込みをレプリケーションする
- フェデレート、もしくはシャード
- キャッシュする、もしくはキャッシュしない
- 機能性を検証する方法
- 自動テスト
- スループットの制限を検証する
- 世界中のサービスを世界中でテストする
Atlasの開始
- シャード方式のアカウントシステムを全面的に見直した
- 真のグローバルなアカウントシステム
- ゲームプラットフォームから分離
インフラストラクチャの管理
- Terraformで管理
- グローバルな設定
- Ansibleで自動化
可用性
- AWS Direct Connect経由で接続
- 4つのAWSリージョン
- NS1を利用することで、世界中で低レイテンシを実現
一貫性
- フロントエンドサービスのルーター
- アカウント管理用のグローバルなMySQL
- 認可のためのグローバルなDynamoDB
負荷テスト
- 画面はNewRelicのAPM
- 負荷テストには Gatling を使用
カオステスト
なぜ○○でなくMySQLを使う？
- Riot Games社内で広く使われている
- Tencentで大規模に利用している
- ACIDコンプライアンスを保証する
Continuent database clustering
アーキテクチャ
スペック
スキーマの移行
- 最初のデータ移行でスキーマを変更した
- スキーマは最終型ではない
バックアップ: 起源
- バックアップサーバーを選択する
- xtrabackupを実行する
- pigzで圧縮する
- S3にアップロードする
バックアップ: 恐ろしい話
データソースがオンラインとオフラインをいったりきたりする
バックアップ: 復旧
コンテナ化のメリットとデメリット
- イミュータブル(変更できない)アプリケーション
- 予定した環境へのポータビリティ
- 完全な再起動が必要
設計
- 実装をドキュメント化・可視化する
- 一般的でない方法を避ける
- 繰り返し改善できるようにする
アーキテクチャ
- サブネットに気をつける
- アドレスが不足してインスタンスを配置できなくなる
- SecurityGroup・ネットワークの制約を評価する
- CPU・メモリ・ネットワーク性能がどれくらい必要か理解する
ロードテスト
- ユースケースにマッピングする
データベースの管理
- データのアクセスパターンを理解する
- できるだけサービスを活用する
- WANのレプリケーションは壊れやすい
セッションのまとめ
- 最終的な目標を考える
- 設計を可視化・ドキュメント化する
- 繰り返し改善しテストする
- 失敗は再挑戦するちょうど良い機会だ、今回はもっと賢くやろう
おわりに
League of Legendsの規模で運営を続けながらも改善のため認証/認可基盤という重要なコンポーネントを刷新していく姿勢は素晴らしいですね。
League of Legendsは以前から遊んでいるゲームで、一時期を境にメニュー部分とゲーム部分のプロセスが分離されなんでだろう？と疑問に思っていましたが、本セッションを聞いて解決しました。
自己紹介にあった好きなチャンピオンの紹介やスライドの節々からLeague of Legendsが好きなんだなーという雰囲気が伝わってきました。 これからもより良いSummoners Liftの運営を楽しみにしています！
0
