元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2017/02/16

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

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

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20170216/p1

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)