1日5TBに及ぶログデータを収集して活用する仕組みとは？
スマホで遊べる本格RPGとして人気の「グランブルーファンタジー（以下、グラブル）」。登録ユーザー数1400万人超の大規模ソーシャルゲームであり、かつネイティブアプリに比べて通信量の多いブラウザゲームのため、そのシステムにかかる負荷は非常に大きい。佐藤氏によれば、クエリ数は秒間100万、リクエスト数は同8万、ピークトラフィックは12Gbpsに達するという。
こうした負荷に耐えうる環境を検討した結果として、グラブルのシステムはオンプレミス環境の物理サーバで構築されている。
「オンプレミスなら、ネットワーク遅延が少なく低レイテンシな環境を構築できる。加えて、パフォーマンスの課題もI/Oアクセラレータやマルチコアスケーリング対応NICを採用するなど、ハードウェアで容易に解消できる。これはクラウドでは難しいこと」（佐藤氏）
サーバの構成自体はシンプルなLAMP環境を基本としながら、障害があってもゲームが継続できるように単一障害点を排除し、どこまでもスケールアウト可能な設計にしているという。なお、双方向リアルタイム通信の機能はNode.jsで実装している。
Cygamesのインフラチームは、これまでグラブルのインフラ構築・運用においてさまざまな課題に直面し、改善を重ねてきた。その代表的な取り組みの1つが、膨大なログデータの収集・活用だ。
ソーシャルゲームの運用では、問い合わせなどで数か月前のログを調査する場合もあるため、長期間のログ保存が必要となる。保存するデータの形式は、「テキストログ」と「データベースインサートログ」の2種類。グラブルの場合、1日あたりのテキストログが4.8TB、データベースインサートログが180GBと、合計約5TBものログを日々保存しているという。
グラブルのテキストログは当初、オープンソースのログコレクターを使ったログ集約サーバにリアルタイムで送信し、深夜にrsyncでストレージに集約していた。しかし、ログ肥大化によりディスク容量が枯渇。rsyncによるログ転送遅延も起きていた。
データベースインサートログについても、インサート量が多くなり恒常的にディスク容量が枯渇。さらに、MySQLログのインサート処理が終わらないと、トランザクションが完了せずにクライアントが待たされる同期処理であったため、リクエストが増えるにつれてレスポンスの遅延も見られるようになっていった。
そこでCygamesインフラチームは、ログシステムの改善としてAmazon S3にログデータを集約。さらに、2つのログ転送エージェントを自前で開発した。1つは「Stalker」と名付けたテキストログ転送用エージェントで、1行で送信できるサイズ制限をなくすために（当初のログコレクターではサイズ制限があった）Go言語でS3ログ転送エージェントとして開発。もう1つは、非同期でMySQLログを転送するエージェントで、こちらは「Porter」と名付けられた。
Porterを利用した非同期ログシステムは、従来は同期処理でMySQLにインサートしていたものをローカルにテキストファイル（TSVファイル）として書き出す。PorterはTSVファイルを適度なサイズに分割し、Amazon S3に転送。同時にAmazon SQSを使ってメッセージキューを作成。最終的にバッチシステムがキューを処理し、ログデータベースとして採用したMySQL 5.6互換のAmazon Auroraにインサートする仕組みとなっている。
ログ取得をゲームシステムから分離してレスポンスを改善
こうして非同期処理を取り入れ、ログ取得をゲームシステムから分離したことによってレスポンスは改善。さらに、Amazon S3の採用はディスク容量枯渇の解消だけでなく、他にも大きな効果を生んだという。
「Amazon S3にログを集約したことでさまざまなツールとの連携が容易になり、データの可視化が促進された。オンプレミスのログストレージでは負荷やアクセス経路の問題もあり、ログ活用はここまで進まなかったと思う」（佐藤氏）
現在はアクセスログやアプリログを解析する「Google BigQuery」、不具合発生を検知する監視ツールの「Mackerel」、さまざまな統計情報を可視化できる「Kibana」などのツールが活用されているという。
リアルタイム通信の高速化とタグシステムによる運用効率化
続いて佐藤氏はリアルタイム通信高速化の取り組みを紹介。チャットやマルチバトルのパラメータ反映などで利用されるのが双方向リアルタイム通信だ。CygamesではWebSocketプロトコルを使って双方向リアルタイム通信を実装。サーバはNode.jsで、WebSocket通信とデータ送受信を実装している。
リアルタイム通信の基本的な仕組みとして、クライアントはRoomという単位でグループ化され、同じRoomIDを持ったクライアント同士でメッセージを共有する。大規模環境の場合はサーバを分散する必要があり、一般的によく使われているのがPub/Subメッセージングモデルだ。グラブルでも当初はRedisのPub/Sub機能を使って、このモデルを採用していたという。しかし、アクセス数の増加とともにRedis Pub/Sub（メッセージキュー）がボトルネック化。さらにタイミングを同じくして、東京ゲームショウで「数千人同時バトル」の開催が企画され、システムの改善が急務となった。
Cygamesインフラチームでは改善策として、Pub/Subメッセージングモデルを捨て、Nginxを使ったRoom対応L7ロードバランサを開発。アプリケーションはRoomIDをURLクエリストリングに付与し、NginxがWebSocket通信のロードバランサとして、URLクエリストリングを元に同一RoomIDのユーザーを同一Node.jsプロセスにルーティングする仕組みとした。なお、RoomIDに対応した分散ロジックは、高速スクリプトのLuaで実装。Consistent Hashingを使った分散ロジックであり、ノードの追加・削除を最小限の変更でマッピングするため、ノード障害による影響を最小限にできるというメリットもある。
Nginxに切り替え後のNodeサーバーの負荷状況は、ロードアベレージが1.8から0.1へ、CPU使用率も160％から5％へと減少。東京ゲームショウでの数千人同時バトルも無事にさばくことができた。現在では1台あたり12万同時接続を達成し、サーバの台数も260台から40台に減らせたという。
3つ目のトピックとして佐藤氏が取り上げたのは、「タグシステム」による運用効率化の取り組みだ。タグシステムとは、数千台規模のサーバ情報を一括管理可能な独自開発のサーバインベントリシステムである。
グラブルの運用では当初、Excelやテキストファイルにサーバ情報を記載して管理していたが、デプロイ漏れや設定漏れのサーバがプロダクション環境に入ってしまうなどのオペミスが発生していたという。
それを解消すべく開発したタグシステムでは、運用を考慮してCLIやAPIでサーバ情報を取得できるようにし、サーバリスト抽出を簡略化。また、サーバの故障や構築ステータスがわかるようにステータスを定義し、情報をホストに付加して可視化を行った。デプロイのステータスもタグで付加できるようになっている。
事前にスキーマの定義が不要で、任意にタグ情報を追加できるのも特徴の1つ。運用していく中で適宜、必要な情報を追加し、不要な情報を削除できる。さらに、Elasticsearchへサーバ情報を登録し、高速に検索できるようにしている。WebサーバやNodeサーバの一覧を把握できるWeb UIもあり、開発エンジニアと共有して、デプロイ状況などがわかるようにしているという。
CLIからは特定ホストのタグ情報を取得して、オンプレミス／クラウド、本番環境／開発環境などの種別を確認することや、「特定プロジェクトの本番環境Webサーバのリストを抽出して、並列にコマンドを実行」といったことも容易に行える。
「日々行われるデプロイ作業でサーバ情報を可視化し、開発エンジニアが安心してリリース作業できるようになった。また、サーバ情報のテキスト管理から脱却して、オペミスを未然に防げるようになった」と、佐藤氏はタグシステムの効果を語る。
最後に「Cygamesインフラが大切にしていること」として佐藤氏は次の3点を挙げ、セッションを終えた。
- 当たり前のことを当たり前にやる
- アプリケーションロジックを抽象化する
- コア技術は自分たちで実装する
本セッションの資料はこちら
お問い合わせ
株式会社Cygames
