【実務・中級編】GitHub ActionsとDatadogの連携:CI/CDパイプラインのメトリクス収集とデプロイ追跡 – 運用監視・オブザーバビリティ活用バイブル

泥沼の「デプロイ後障害」を撲滅せよ:Datadog × GitHub Actionsで築くCI/CDオブザーバビリティの神髄

「デプロイ直後にサービスが重くなったが、原因はコードか、CIのビルド設定か、それとも突発的な負荷か……?」

この問いに即答できないエンジニアは、オブザーバビリティを語る資格がない。CI/CDパイプラインは開発の「心臓部」だ。ここをブラックボックスにしている限り、君たちのデプロイは常にロシアンルーレットと変わらない。

本稿では、GitHub ActionsとDatadogを「ただ繋ぐ」のではなく、「障害の相関を秒で特定できる」レベルまで昇華させるための極限の知見を授ける。

—

1. なぜ「CIメトリクス」が最強の武器になるのか

単なる成功・失敗のログだけでは不十分だ。「ビルド時間の微増」は、依存関係の肥大化やテストコードの腐敗を予兆する先行指標である。

実践的実装:Datadog CI Visibility

GitHub ActionsのワークフローにDatadogの専用Actionを組み込むだけで、実行時間、失敗率、ボトルネックをDatadog上で可視化できる。

.github/workflows/main.yml
jobs:
build:
runs-on: ubuntu-latest
steps:

  • uses: actions/checkout@v4
  • name: Datadog CI Visibility

uses: DataDog/datadog-ci-action@v2
with:
api-key: ${{ secrets.DD_API_KEY }}
app-key: ${{ secrets.DD_APP_KEY }}
site: datadoghq.com
# 以降、通常のビルド処理を記述

【プロの知見】:これを導入すると、Datadogの「CI Visibility」画面で、どのジョブが平均より遅いか、どのテストケースが最も不安定(Flaky)かを一撃で特定できる。「テストが落ちた」と嘆く前に、そのテストが「なぜ」落ちたのかのトレンドを追え。

—

2. 「デプロイ追跡」なしの監視は盲目と同じ

デプロイのタイミングをメトリクス上にオーバーレイ表示(Event Overlay)させることは、現場のエンジニアにとっての生命線だ。

APIを利用した「デプロイマーカー」の自動注入

デプロイ完了時にDatadogへイベントを飛ばす。これにより、エラー率のスパイクが「コードのせい」なのか「外部要因」なのかが、グラフ上で一目瞭然になる。

デプロイ成功後に実行するシェルスクリプトの例
curl -X POST “https://api.datadoghq.com/api/v1/events” \
-H “DD-API-KEY: ${DD_API_KEY}” \
-H “Content-Type: application/json” \
-d @- <【神設定のコツ】:タグに必ず `version` や `commit_sha` を含めろ。DatadogのAPMで、特定のリリースバージョンごとのエラー傾向を比較できるようになり、ロールバックの判断が劇的に速くなる。

—

3. チーム開発を加速させる「設定の神ルール」

ツールは使いこなさなければただのゴミだ。組織として生産性を最大化するためのルールを定義する。

1. 共有化ルール:Service Catalogの徹底

GitHubリポジトリごとに `service.yaml` を作成し、DatadogのService Catalogと同期させろ。

  • 誰がオーナーか?
  • どのSlackチャネルにアラートを投げるか?
  • 依存先サービスは何か?

これらがDatadog上で統合されているだけで、障害時の「誰に聞けばいい?」という無駄なコミュニケーションがゼロになる。

2. 絶対に入れるべき神プラグイン・拡張機能

  • Datadog Dashboards (VS Code Extension): 開発中にIDEからダッシュボードのメトリクスを覗ける。コンテキストスイッチを減らすのが最強の効率化だ。
  • GitHub Pull Request Decorator: GitHub上で、該当PRのデプロイ後のエラー数やレイテンシ変動が直接表示されるようにしろ。コードレビューの質が変わる。

—

4. 最後に:テックリードから君たちへ

オブザーバビリティとは「監視」ではない。システムを「理解可能」な状態に保ち続けるための哲学だ。

CI/CDとメトリクスを連携させることで、君たちは「障害が起きてから右往左往する運用者」から、「障害の予兆を察知し、未然に防ぐエンジニア」へと進化できる。

今日のタスク:
1. CI Visibilityを導入し、上位10%の「遅すぎるビルド」を特定せよ。
2. デプロイマーカーを設置し、グラフの谷間と山を見える化せよ。

この二つをやるだけで、君のチームのデプロイに対する恐怖心は消滅するはずだ。技術は、恐怖を取り除くためにある。さあ、コードを書け。そして、そのコードがどう呼吸しているかを、Datadogで見届けてやるんだ。

タイトルとURLをコピーしました