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」などのツールが活用されているという。
