駅メモ！開発基盤チームの id:xztaityozx です。
今回は駅メモ！で利用している GitHub Actions の監視について書こうと思います。
前提
駅メモ！チームでは CI/CD 環境として Amazon EC2 を用いた Self-Hosted な GitHub Actions を構築しています。Webhook をトリガーに EC2 インスタンスが起動されるため、開発者は特に意識することなく CI/CD を利用することができるようになっています。
しかしながら、ノーメンテナンスで運用できるというわけではありません。日々 EC2 で使うイメージ(AMI)や IaC の更新、ワークフローの修正・改善などを行っています。CI/CD が速いことは開発者それぞれに大きなメリットとなるため、パフォーマンス改善は特に重要なタスクです。
こういった運用を行う上で重要になるのが、GitHub Actions の監視です。ワークフローの実行時間や成功率などを継続的に監視することで、問題の早期発見や改善効果の把握が可能になります。
監視の構築
先述の通り、GitHub Actions のパフォーマンス測定のためにワークフローの実行時間、EC2 インスタンスが起動してからジョブが開始されるまでの時間、ワークフローの成功率などを収集しなければなりません。これらの情報は GitHub Actions に関する Webhook のペイロードを収集・解析することで得ることができます。例えば、workflow_run はワークフローの実行に関する情報を提供してくれます。
// 例 { "action": "requested", "workflow_run": { "id": 123456789, "created_at": "2025-05-01T12:00:00Z", "updated_at": "2025-05-01T12:05:00Z", "status": "requested", // ... }, }
actionプロパティはざっくり言うとワークフロー全体の状態を示している値です。requested, in_progress, completed の 3 種類が存在し、それぞれの状態へ移行したときに Webhook が送られます。ここからワークフロー実行がリクエストされた時間、開始された時間、完了した時間がわかるため、ワークフローの実行時間やキューイング時間を計算できます。
他にも workflow_jobイベントのworkflow_job.stepsプロパティから、各ステップごとにどれくらい時間がかかったかを知ることができます。
// 例 { "action": "completed", "workflow_job": { "steps": [ { "name": "Checkout", "status": "completed", "conclusion": "success", "number": 1, "started_at": "2025-05-01T12:00:10Z", // 開始時間 "completed_at": "2025-05-01T12:00:20Z" // 完了時間。↑との差分がステップの実行時間 }, { "name": "Run tests", "status": "completed", "conclusion": "success", "number": 2, "started_at": "2025-05-01T12:00:21Z", "completed_at": "2025-05-01T12:04:50Z" } ] } }
これらの情報を計算するためには、一旦ペイロードを保存し、後で解析するようにします。駅メモ！チーム内にはこのような仕組みが既にあります。それは以前の記事で紹介した開発メトリクスのダッシュボードです。
詳しくはぜひ上記の記事を読んでいただきたいのですが、簡単に説明すると、API Gateway + Lambda + S3 でデータを収集し、EC2 上の Elasticsearch + Grafana で可視化を行うというものです。Elasticsearch へのデータ投入は EC2 上で行っています。
Elasticsearch にデータを載せてしまえばあとは好きなように可視化するだけです。作成されたダッシュボードは週 1 回のペースでチーム全体に共有され、改善点があれば都度対応しています。
まとめ
今回は GitHub Actions の監視ダッシュボードを構築している話を書きました。これにより、CI/CD のパフォーマンスを継続的に監視し、問題・異常・改善の効果を把握しやすくなりました。私自身も活用の場面がかなり増えてきています。
今後はまだ収集できていない情報(CPU, メモリ利用率など)の追加、ダッシュボードの確認の仕方など、改善を続けていきたいと思います。また何か知見があったら記事にしたいと思います。
余談
開発メトリクスダッシュボードの記事とこの記事の両方を読むと時系列がややおかしいので補足です。
実は GitHub Actions の監視ダッシュボードは開発メトリクスのダッシュボードを作成する前に作られていました。実験的に実装したものでしたが、ある程度うまく動いていたことから開発メトリクスダッシュボードの構築時に参考にされました。
今回、開発メトリクスダッシュボードの出来が良かったこと、複数のダッシュボードがあると管理が面倒ということで、古い実装を廃止し開発メトリクスダッシュボードに統合したという背景でした。
