CAを離れて1年半。最近はどんな感じか知りたかったので聞いてきました。面白かったです。
グランブルーファンタジーを支えるインフラの技術
- (株)Cygames
- 佐藤太志 氏
グランブルーファンタジーについて
特徴
- スマホのRPG
- ブラウザゲーム
- 協力プレイ、マルチプレイ
システム規模
- 登録ユーザ数1400万人
- 月間300億PV
- 100万query/sec
- 8万req/sec
- トラフィック12Gbps (CDN除く)
システム構成
- LBはBIG-IP
- CDNはAkamai
- HTTP/WebSocketがフロントインターフェース
- Web: Apache + mod_php + mysqli
- Node: Node.js + twemproxy
- DB: MySQL + MHA
オンプレミス、仮想化環境は使っていない
- ネットワーク通信量が非常に多い
- 低レイテンシを求められている
- ハイパフォーマンスを実現するため
- NVMe SSDやFusion-ioを採用
- ネットワークIRQのマルチコアスケーリングに対応したNICを採用
ログデータの取り組み
ソーシャルゲームとログ
- CS対応、補填対応などのユーザ対応
- CS最優先、数ヶ月前のログを調査する必要あり
- KPI指標の取得
- システム不具合の調査
- エラーログやSQLログ
- バックアップ
- 不具合発生時の再現（スナップショットからの復元）
ログのデータ量は5TB/day
- テキストログ(4.8TB/day)
- DBインサートログ(180GB/day)
ログ肥大化による問題
- 当初は、ログ集約サーバに転送し、ログストレージに深夜にrsyncしてた
- ログ肥大化により、ログ集約サーバを分散したが、ログの転送が遅延し、CS対応に支障をきたし始めた
- DBでもログが肥大化し、ディスク容量が枯渇したり、インサート処理が遅延
ログシステムの改善
- Amazon S3にログを集約
- 独自ログ転送エージェントを開発
- テキストログ転送
- 一行で送信できるサイズ制限を取っ払うため
- S3オブジェクトのプレフィックスをつける
- 非同期MySQLログ転送
- TSVをS3に転送、SQSにメッセージキューを作成、EC2のアグリゲータでまとめて、Auroraへ
- テキストログ転送
ログを活用
- ログ転送エージェント => S3 => BQ, Mackerel, Kibana, Aurora, DWH分析等
Kibana
- アクセスログ、APログ、エラーログから統計情報をビジュアル化
- レスポンスタイムとか遅いURLとかエラー数とか
- 特定地域ごとのエラーを可視化
- 特定区域の通信障害などを特定させるため
Mackerel
- Apacheレスポンスタイムを集計
- 2秒以上の分布を可視化
- twitterのキーワード検索も可視化
- 「グラブル 重い」などのtweet
ログデータの取り組みまとめ
- Amazon S3に集約
- 非同期・マイクロサービス化
- 非同期処理でゲームシステムとは分離
- 独自エージェントの開発
- コア技術は自前で開発するポリシー
リアルタイム通信の高速化
双方向リアルタイム通信が必要なところ
- チャットでのメッセージ交換
- マルチバトルでのパラメータ反映
双方向リアルタイム通信
- WebSocketの導入
- Node.jsで実装
リアルタイム通信のサーバ構成
- サーバでは複数Roomが紐づく
- クライアントはRoom単位でグループ化
- アーキテクチャ
- バランシング管理サーバモデル
- Pub/Subメッセージモデル
バランシング管理サーバモデル
- 管理サーバがクライアントやRoomの紐付けを管理
- 管理サーバの冗長化を考慮すべきで複雑になる
Pub/Subメッセージモデル
- メッセージキューを介してサーバ間でやりとり
- メッセージキュがボトルネックになりやすい
- ブロードキャストによる通信量の増加
- Redis Pub/Subがボトルネックになった、またスケールアウトに課題
- セット構成でスケールさせるように、8セットまで増大
Room対応のL7ロードバランサーを開発
- アプリケーションはRoomIDをURLクエリストリングに付与
- RoomIDのハッシュ値を使って分散
Nginx L7 ロードバランサー + Lua
- NginxはWebSocketのLB
- RoomIDからNode.jsプロセスへのルーティング
- Luaで分散ロジックの実装
- Consistent Hashingを活用
- Nodeのヘルスチェックも行う (自動切り離し)
Nginxリソース状況
- 同時19,000TCPセッションで、サーバのCPU使用率は3%になった
- 負荷低いので、集約した結果、ポート枯渇に
- カーネルパラメータ調整したり、TIME_WAITの残留時間を短くするためにカーネルのリビルドを行うも追いつかず
- サーバに複数のIPアドレスを付与して、多くのポートを使えるようにした
- 現状では、12万セッション/1台を捌けるようになっている
タグシステムと運用
大規模環境の運用
- 複数サーバのリスト作成
- 複数サーバに並列にコマンド実行
- 故障機器の排除
- デプロイ対象から排除
- 運用情報の管理
- 解析ツールのインストール情報
- LBへの組み込み状況
タグシステム開発
- サーバ情報インベントリシステム
- サーバリスト抽出の簡略化
- サーバの構築情報の可視化
- 任意にタグ情報を付加できる
- 事前にスキーマ定義は不要にしている
- ElasticSearchにサーバ情報を登録し、全文検索できるようにしている
Kibanaで可視化
- 開発エンジニアとWeb UIを通して連携
- CLIでホスト情報(JSON)を取得できるようにした
- DCとかEnvとかLBへの紐付けとかタグ情報で確認できる
- サーバリストの取得
タグ運用のまとめ
- 大規模運用の効率化
- サーバ情報のテキスト管理からの脱却し、オペミスを防止
- 各種ツールとの連携を促進
Cygamesインフラが大切にしていること
- 当たり前のことを当たり前にやる
- ボトルネックを作らないシステム設計
- 枯れた技術を採用し、安定化を目指す
- アプリケーションロジックを抽象化する
- 冗長化・分散等のロジックはシステムで吸収・抽象化
- 他プロジェクトへの展開を容易にする
- コア技術は自分たちで実装する
