【入門編】Datadog API Testsを用いたCI/CDパイプラインでのE2E自動テスト連携とロールバック判定の実装手順 – 運用監視・オブザーバビリティ活用バイブル

こんにちは！プロダクトを世に送り出すデプロイの瞬間、あなたの心臓はドキドキしていませんか？

「テストは通ったけれど、本当に本番環境でユーザーが問題なくログインできているか？」
「デプロイした瞬間に500エラーの嵐が起きていないか？」

この恐怖、エンジニアなら誰もが共感するはずです。従来の「デプロイして、祈って、アラートが鳴ったら慌ててロールバックする」というスタイルは、もう過去のものにしましょう。

今回は、Datadog API Tests（Synthetic Monitoring）をGitHub ActionsなどのCI/CDパイプラインに組み込み、「デプロイ直後の外形監視が失敗したら、人間が気づく前に自動でロールバックする」という、モダンで最高にクールな仕組みの作り方を解説します。

これをマスターすれば、デプロイボタンを押した後の冷や汗が消え去り、毎日のリリースが劇的に安心してスピーディーになりますよ。さあ、一緒にその扉を開けましょう！

—

1. そもそも「Datadog API Tests」とCI/CD連携の役割とは？

まず前提として、なぜ単なるユニットテストやインテグレーションテストだけでなく、DatadogのAPI TestsをCI/CDに組み込む必要があるのかを整理しておきます。

  • ユニットテスト（Jestなど）: コードの部品が正しいかを確かめる。
  • API Tests（外形監視）: デプロイされた「生きた本番・ステージング環境」に対して実際にHTTPリクエストを投げ、DB接続や外部API連携を含めたシステム全体が正常に生きているかを外側から検証する。

CI/CDパイプラインの中でこれを実行する最大のメリットは、「ユーザーが異変に気づく前に、悪い変更を自動で無かったことにできる（ロールバック）」点にあります。Datadogの強みは、単なる死活監視（Ping）にとどまらず、「ログインして、特定のAPIを叩き、レスポンスのJSONの中身まで検証する」という複雑なシナリオを、APIテストとして簡単に定義できる点にあります。

—

2. 基礎セットアップ：DatadogでAPI Testを作成する

まずは、Datadog上でテストの「土台」を作ります。ここでは例として、「ユーザーのヘルスチェックAPI（`/api/v1/health`）を叩き、ステータスが200で、かつレスポンスに `status: “ok”` が含まれているかを確認するテスト」を作るとしましょう。

ステップ1: API Testの作成

1. Datadogの管理画面から [UX & Test] > [API Tests] に移動します。
2. [New Test] ボタンを押し、[HTTP Test] を選択します。
3. 以下のように設定します。

  • Request Type: `GET`
  • URL: `https://your-staging-or-production-url.com/api/v1/health`
  • Assertions (検証条件):
  • `StatusCode` is `200`
  • `Asserts body` `jsonpath` `$.status` `is` `ok`

4. テストの名前を `Production Health Check` など分かりやすいものにし、保存します。

ステップ2: Public IDの取得とAPI/App Keyの用意

CI/CDからこのテストをピンポイントでトリガーするために、2つの重要情報を手に入れます。
1. Public ID: 作成したテストの詳細画面のURLや設定タブから確認できる、一意のID（例: `abc-123-def`）です。
2. Datadog API Key & Application Key: GitHub Secretsなどに格納するための認証キーです。

—

3. CI/CD連携の実装：GitHub Actionsでの自動テスト＆ロールバック

それでは、今回のメインディッシュであるGitHub Actionsのワークフローを構築します。

ここでは、「①デプロイ実行 ➔ ②Datadog API Testのトリガー（CI用非同期実行） ➔ ③テスト結果のポーリング判定 ➔ ④失敗したらロールバック」という一連の流れを実装します。

ワークフローファイルの全体像 (`.github/workflows/deploy.yml`)

name: Deploy and Validate with Datadog

on:
push:
branches:

  • main

jobs:
deploy:
runs-on: ubuntu-latest
steps:

  • name: Checkout code

uses: actions/checkout@v3

# 1. アプリケーションのデプロイ処理（例: AWS, Render, Vercelなど）

  • name: Deploy to Production

id: deploy
run: |
echo “Deploying application to production…”
# ここに実際のデプロイコマンドが入ります
# 例: 成功したらデプロイ先のURLやバージョンを環境変数にセットするなど

synthetics-test:
needs: deploy
runs-on: ubuntu-latest
steps:

  • name: Run Datadog Synthetic Test via CLI

uses: datadog/synthetics-ci-github-action@v1
with:
api_key: ${{ secrets.DD_API_KEY }}
app_key: ${{ secrets.DD_APP_KEY }}
# あらかじめ作成したAPI TestのPublic IDを指定
public_id: ${{ secrets.DD_SYNTHETIC_TEST_PUBLIC_ID }}
# デプロイ直後のため、環境変数やベースURLを上書きすることも可能
override_options: |
{
“startUrl”: “https://api.yourdomain.com”
}
id: datadog-test

# テスト失敗時のハンドリング（ロールバック発動）

  • name: Trigger Rollback on Failure

if: failure()
run: |
echo “==========================================”
echo “⚠️ 警告: Datadogの外形監視テストが失敗しました！”
echo “システムに異常が検知されたため、自動ロールバックを開始します。”
echo “==========================================”

# ここに実際のロールバック処理を記述
# 例: AWS ECSのサービスを指定の旧リビジョンにロールバックするスクリプトなど
# ./scripts/rollback.sh

exit 1

—

4. 現場で役立つ！精度を高めるリトライ制御とペイロード解析の極意

上記のコードだけでも動きますが、実際の現場では「ネットワークの瞬間的な揺らぎによる、いわゆる『フランクな誤検知（Flaky Test）』」に悩まされることがよくあります。

デプロイ直後は、ロードバランサーのターゲットグループへの登録ラグなどで、最初の1回目のリクエストだけが運悪く失敗することがあります。ここで即座にロールバックを走らせるのは、夜中にインフラエンジニアを起こす原因（＝最悪の体験）になります。

対策：リトライ制御とポーリングの最適化

Datadogの公式GitHub ActionやAPIを利用する際は、「数秒待ってからリトライする（リトライ機構）」を必ず挟みましょう。

DatadogのSynthetic CI用アクションは、デフォルトでもテスト実行失敗時に数回のリトライや、非同期トリガー後の結果待ち（ポーリング）を行ってくれますが、カスタムスクリプトを挟む場合は以下のようにAPIを直接叩くアプローチも強力です。

例: Datadog APIでテストをトリガーし、結果をポーリングするシェルスクリプト

!/bin/bash
簡易的なポーリングとリトライの概念スクリプト

TEST_ID=”${DD_SYNTHETIC_TEST_PUBLIC_ID}”
MAX_RETRIES=3
RETRY_INTERVAL=10

for ((i=1; i<=MAX_RETRIES; i++)); do echo "Attempt $i: Triggering Datadog API Test..." # テストのトリガー（非同期） RESPONSE=$(curl -s -X POST "https://api.datadoghq.com/api/v1/synthetics/tests/trigger/ci" \ -H "Content-Type: application/json" \ -H "DD-API-KEY: ${DD_API_KEY}" \ -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" \ -d "{\"public_ids\": [\"${TEST_ID}\"]}") # 実行結果の確認（実際には少し待ってから結果取得APIを叩くか、公式Actionの組み込み機能を利用します） # テストが成功したら break 0 # 失敗したら sleep $RETRY_INTERVAL done

ペイロード解析：どこがコケたかをSlackに通知する

もしテストが失敗してロールバックが走ったとき、単に「失敗しました」とだけログに出ても、原因究明に時間がかかります。Datadog API Testが吐き出した失敗理由（どの Assertion が、どんな値でコケたか）をSlackなどの通知チャネルに飛ばすようにしておくと、神のように感謝されます。

Datadogのテスト結果ペイロードには、以下のような詳細なエラー理由が含まれています。

  • 予期していたステータスコード `200` に対し、返ってきたのが `502 Bad Gateway` だったのか
  • JSONパースエラーでキーが存在しなかったのか

公式GitHub Actionを使う場合、失敗時のステップでDatadogのダッシュボードやテスト結果のURL（`https://app.datadoghq.com/synthetics/details/…`）がログに出力されるため、そのURLをそのままSlack通知（`slack-action`などを使用）に載せるのが最もスマートです。

—

まとめ：安全なデプロイは、攻めの開発を加速する

今回は、Datadog API TestsをCI/CDに組み込み、外形監視の結果に基づいて自動ロールバックを判定する仕組みを解説しました。

  • API Testsで「実際のユーザー視点」の正常性を担保する
  • GitHub Actionsなどのパイプラインからシームレスにテストをキックする
  • 瞬間的なネットワークエラーに備えたリトライ制御を入れる
  • 万が一のときは迷わず自動ロールバックを発動させる

「テストが守ってくれる」という安心感があれば、私たちはもっと大胆に、もっとスピーディーに新しいコードをデプロイできるようになります。

「これをマスターすれば、毎日の作業が劇的に楽になりますよ」。
ぜひ今日のパイプラインに、この外形監視による自動防衛ラインを組み込んでみてください。あなたのプロダクトの信頼性が、一段も二段も跳ね上がることを約束します！

スポンサーリンク
タイトルとURLをコピーしました