ゲームフリークによるSplunk活用術。ジョブ利用状況の可視化やログの自動収集により、Jenkinsのデータ分析を強化【CEDEC2023】

ゲームフリークは『ポケットモンスター』シリーズのほか、『ソリティ馬 Ride On!』、『リトルタウンヒーロー』などの企画・開発を手掛けています。

『ソリティ馬 Ride On!』などのタイトルは「ギアプロジェクト」と呼ばれる制度から誕生した

最初に、ゲームフリークにおけるJenkinsの運用体制や課題点などが立原氏から説明されました。

ゲームフリークでは、以前よりビルド、静的解析、テスト、デプロイといったジョブの保守運用にJenkinを採用しています。

Jenkinsを採用する理由には、SaaS（※）のCI/CDサービスでは、ゲーム開発における「高スペックマシンが必要」かつ「開発機がクラウドに非対応」であるシチュエーションに対応できないことが挙げられました。
※　Software as a Service（クラウドサービス型提供形態）の略称

また、GitやHelix Coreなど複数のバージョン管理システムが利用されていることも理由であるとのこと。

ゲームフリークにおけるJenkins運用体制は、「R&Dセクション」と複数の「タイトル開発チーム」に分かれています。

R&Dセクションには、CI/CD開発業務を専門で行う8名構成の「環境セクション」が設けられており、マスターサーバーやジョブ、ノードの管理を行っています。

各タイトルの開発チームには、CI/CDの技術提供やパイプラインの保守運用のために1～3名の「環境チーム」が置かれています。

全体では、マスターサーバーが1台、エージェントノードに関してはクラウドが約100台（オートスケール機能による変動あり）、オンプレミスが64台で運用されています。

運用されるCI/CDの規模は、1タイトルあたり50～80ジョブ、全体でおおよそ200ジョブにのぼります。1日に2500～3000程度のビルドが稼働しているそうです。

ゲームフリークのJenkins運用における3つの課題

Jenkinsの運用にあたっては、以下の3点が課題となっていたと立原氏は言います。

ジョブの実行時間、頻度の把握が難しい

Jenkinsの機能のみでは、運用規模の拡大とともに実行時間や頻度を確認・比較しづらくなっていったそう。ジョブの保持期限なども考えると、標準機能のみでは限界がありました。

ノードの利用状況の把握が難しい

ノードの利用状況を可視化する手段がないため、特定のノードを使用するジョブが把握できず、ジョブの停止に伴う影響を判断できない問題が発生していました。

ログ検索の効率が悪い

分析のために、ビルドログに対して検索をかけるシチュエーションは多々あります。同社では独自の分析ジョブを運用していましたが、ログ検索の効率が悪い課題がありました。

そこで、以上の課題に対する解決策として、データ分析基盤「Splunk」が導入されました。

Splunkのダッシュボード上に時系列順で並んだJenkinsのノード一覧

ノードの利用・待機状況などもSplunkのダッシュボードで確認できる

もっとも使う頻度が高かった、ジョブ実行時間の推移グラフ（上部）とテーブル（中部）

続いて、ゲームフリークがログ分析基盤としてSplunkを選んだ理由が高山氏から語られました。

ログ分析基盤の選定にあたっては、以下の4つの基準が重視されました。

環境構築が容易である

Splunkはセルフホストが可能であり、AWS MarketplaceにてAmazon マシンイメージ（AMI）が提供されています。そのため、AMIからインスタンスを立ち上げるのみですぐ利用できる利点があります。

また、Splunkのライセンス料は1日に取り込むデータ量に基づきます。気軽にデータを投入できるため、検証に踏み出すハードルが低かったそうです。

インストール時、1日500MBまでの転送量を2ヶ月間無料で使えるライセンスが付与される点もハードルの低さに寄与している

ログ収集の設定が容易である

サーバー内のログは、一般にETL（※）を介して分析可能な状態に変換します。
※　データをExtract（抽出）、Transform（加工）、Load（格納）の順に処理する一連の流れ

SplunkはあらゆるETLをサポートしています。そのため、Jenkins用プラグインをインストールし、サーバー設定を追加するのみでETLの仕組みを実装することなくログ転送を行うことが可能です。

グローバルの転送設定を用いることで、すべてのジョブに関するログを一括で収集できる

ログを閉域網で管理できる

同社の運用では、ビルドログに開発中タイトルのプレイログが多く含まれます。そのため、自社閉域網内でログを管理できることがセキュリティ上の必要条件でした。

セルフホスト可能なオンプレミス版ライセンスを持つSplunkは、この要件を満たしていました。

ログを長期間保管できる

もうひとつの要件として、過去プロジェクトの類似するジョブを確認できるよう、最低でも過去4年分のログを保持できることが求められました。一般的なSaaS型のサービスと異なり、オンプレミス版のSplunkであれば保存期間を自社で管理できます。

比較検討された他サービス

講演では、ゲームフリークが比較検討したそのほかのサービスについても触れられました。

Elasticsearch + Kibana

オープンソースのElasticsearchとKibanaは、同社でも処理負荷の分析に使用されている構成でした。

今回は、ETL処理を自前で実装する必要がある点や、Elasticsearchでは入れ子構造になったJSONの取り扱いに癖がある点から見送られました。

Datadog / Sumo Logic

クラウドベースの監視・ログ管理サービスであるDatadogとSumo Logicは、Jenkinsとの連携も充実しているなど機能面では申し分なかったとのこと。

しかし、要件のひとつ「自社閉域網内でログを管理する」を満たせなかったため、採用は見送られました。

髙山氏は今回の選定について、「サービス選定は各企業の情報管理の考え方や、人的・金銭的なコストによって判断が変わる」と補足しました。

ここで、実際のタイトル開発で活用したSplunkのダッシュボード機能について、金丸氏から解説がありました。

最初に、個別のジョブ情報を確認できるダッシュボードが紹介されました。任意の期間とジョブを指定することで、ジョブに対する期間内の総実行数、成功数、失敗数、ステージごとの平均実行時間、ステージごとのエラー率などが表示されます。

下段には期間内のビルド全体の所要時間推移が表示され、ビルド時間の増減や安定性を確認できます。

このダッシュボードにより、実行のボトルネックになっているステージや、不安定なステージをチェックできるようになりました。

続いて、複数ジョブの待機時間を比較できるダッシュボードも紹介されました。上の棒グラフが期間内のジョブごとの平均待機時間、下の折れ線グラフが待機時間の推移を表しています。

棒グラフはジョブごとの平均待機時間を示している。横軸は期間、縦軸は平均待機時間を表す

特定のジョブのみ待ち時間が長い、特定の時刻にキューがたまりやすいなどの傾向が可視化されるため、ジョブに対するノードの割り当てや実行頻度を適切に判断できるようになりました。

最後に紹介されたのは、ノードの状態を示すダッシュボードです。

画像左上にノードの最新の状態、右上に割り当てられたジョブの利用割合が表示されています。画像下部には、期間内におけるノードごとのビルド数推移が棒グラフで示されます。

これらの情報は、ジョブのアサインやスケジューリング、ノード上限の検討材料として活用されました。

ここで、金丸氏からSplunk導入以前の課題が具体的に語られました。

Splunkを導入する以前は、「ジョブの実行時間、頻度の把握」「ノード利用状況の把握」「柔軟なログ分析」をJenkinsで行うのは困難でした。

JenkinsのWebダッシュボードは直近のジョブの使用時間を可視化できるものの、任意の期間におけるデータ推移の確認や、複数のジョブの比較には適しません。

加えて、WebダッシュボードはGroovy（※）スクリプトによるパイプラインを使用したジョブには対応していません。
※　Javaプラットフォーム上で動作する、動的型付けのプログラミング言語

ゲームフリークはほとんどのジョブ構成がGroovyスクリプトに依存しており、実質的にビルド履歴が確認できませんでした。

そこで、Webダッシュボードの代替としてJenkins APIの使用が検討されていました。しかし、工数の観点から、APIを使った解析スクリプトの実装は見送られてきました。

定点観測には、定期的にAPIを実行して結果を保存する仕組みが必要です。その仕組みを実装する工数がとれないことでその場限りの独自スクリプトが乱立し、結果としてスクリプトの保守コストや高い属人性が課題となっていました。

また、ビルドログに対する検索機能にも課題がありました。

ビルドログは大量の文字列情報であるため、API経由で全ジョブに検索をかける設計では分析に時間がかかります。検索しやすい形式に変換したうえでデータベースに登録する手法も、ETL処理の実装コストが高くつきます。

そのため、緊急時にはssh接続でJenkinsマスターに直接ログインしコマンドを実行する、危険性の高い対応がとられていました。

続いて、Splunkの導入により前述の課題がどう解決されたのかが紹介されました。

「分析手段の実装と運用の手間」に対しては、SplunkのJenkins用プラグインにより、ジョブデータを自動アップロードすることで解決されました。

Splunkサーバーのインストールからダッシュボードの構築までは、5人日程度だったそう。想定よりも早く終わり、初期コストとしては十分許容できたと金丸氏は言います。

任意の期間における変化が可視化されるようになり、CIの課題分析が大きく改善した

ノード間の利用頻度の差を把握できるようになった結果、ノード管理に関する意思決定も行いやすくなりました。

また、ノードに割り振られたジョブが分かるため、ノード削減に伴う作業コストやリスクも推測できます。

ノードの使用頻度を一目で比較できるため、ノード削減による保守コストの節約が検討しやすくなった

ログ分析以外でもSplunkが活躍

ここで、髙山氏からログ分析以外のSplunk活用事例が紹介されました。

サーバーへの不正リクエスト調査

Jenkinsサーバーの運用では、時折不可解なAuditログを観測することがあり、都度アクセスログの調査が必要でした。高山氏は、調査にかける時間を減らしたいと考えていたそうです。

従来では、Jenkinsサーバーに直接ログインし、access.logに対してgrepを実行することでログを調査していました。

より高度な調査では、スプレッドシートで集計していた

Splunkの導入とともに、アクセスログの調査をその都度行うのではなく、ログの収集を自動化し、クエリで情報を得られるシステムが構築されました。

ログの自動収集には、Splunkが提供するUniversal Forwarder（UF）が採用されました。UFはマシンからデータを収集し、Splunkサーバーに転送する常駐エージェントです。

UFの導入により、リクエストの内容やIPアドレス、時間帯に加え、レスポンス時間などが集計できるようになりました。

リクエスト結果は、サービスレベルの指標にも活用されている

集計したデータとアクセスログを照合することで、問題になったAuditログが発生したIPアドレスとリクエストが特定できるようになりました。

サーバーの負荷上昇の原因調査

サーバー負荷上昇の原因調査にもSplunkが活用されています。

従来のシステムでは、負荷上昇によってアラートが発行されるものの、瞬間的な負荷のスパイクの原因を後から調査できませんでした。また、プロセス単位のCPUやメモリ使用率などのデータが取得できない課題もありました。

そこで、Linuxサーバーのシステムログやメトリクス情報の転送設定を簡略化するUFの拡張機能「Add-on for Unix and Linux」を用いて調査体制を刷新。サーバーのメトリクスを自動収集し、事後調査できる体制が作られました。

これにより、ダッシュボード上でサーバーのあらゆるログやメトリクスを確認できるようになりました。

負荷が上昇した際にどのプロセスがボトルネックとなったのか一目でわかる

以前の課題であった瞬間的なスパイクの調査が可能になったほか、サーバーにログインする必要もなくなり、調査コストが大きく削減されました。

最後に、高山氏は今回の取り組みにおける成果をまとめました。

ジョブの実行時間を時系列で把握できるようになったことで、定量的な実行時間の妥当性判断や、改善前後の評価が可能になりました。

また、利用頻度の低いノードを容易に割り出せるようになりました。あるプロジェクトでは、59台から44台までノードを削減できたそうです。クラウド費用に換算すると、月額およそ200万円削減されているとのこと。

加えて、実行ログの自動収集、クエリ検索に対応。不具合の時間、環境、発生したノードだけでなく、対処後に問題が再発していないかどうかも特定できるようになりました。

従来の課題解決のほかにも、パイプラインの品質向上、分析手順統一による運用属人性の低下、調査コストの低下などが成果として挙げられました。

wvigler

アンリアルエンジンにハマり、ぷちコンでゲーム作ってた男。映像編で2連覇したことも。
昔はよくアーケードゲームとかやってました。
一番やり込んだのは「ケツイ ～絆地獄たち～」「戦国BASARAX」あたり。ローグライトゲームとかも好きです。