デブサミ2017「グランブルーファンタジーを支えるインフラの技術」講演メモ #devsumi

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インフラが大切にしていること

  • 当たり前のことを当たり前にやる
    • ボトルネックを作らないシステム設計
    • 枯れた技術を採用し、安定化を目指す
  • アプリケーションロジックを抽象化する
    • 冗長化・分散等のロジックはシステムで吸収・抽象化
    • 他プロジェクトへの展開を容易にする
  • コア技術は自分たちで実装する