Amazon CloudWatch Synthetics を使用して複数ステップの API を監視する

アプリケーションが増えるにつれて、API やウェブページの数は指数的に増加します。Amazon CloudWatch Synthetics を使用した、複数のステップで構成される HTTP モニタリングは、このような問題の解決に役立ちます。柔軟なスクリプト実行による API の常時監視を実現することは、エンジニアリングチームが SLA を保つ助けになります。

この記事では、複数の HTTP エンドポイントを対象とするブループリントを使って、Amazon CloudWatch Synthetics によるアプリケーション監視を行う方法を紹介します。

HTTP ステップは、syn-nodejs-2.2 以上で使用できます。この機能により、複数のステップで構成される API の柔軟な監視や、ステップ毎のメトリクス収集を行うことができます。さらに、複数の HTTP リクエストに対して、リクエスト / レスポンスヘッダー、DNS ルックアップや TCP コネクションの時間、最初の 1 バイトを受信するまでの時間 ( Time to First Byte : TTFB ) を含む詳細なレポートを、単一のスクリプトで作成することができます。

概要

このセクションでは、HTTP ステップを使った Canary を作成する手順を説明します。

HTTP ステップの作成

CloudWatch Synthetics は、すぐに使用可能な Canary の設計図を提供していますが、コンソール上のエディターや Amazon Simple Storage Service (Amazon S3) バケットからのインポートを使用して、スクリプトを一から作成することもできます。CloudWatch Synthetics は、Node.js または Pyrthon で作成された Canary をサポートしますが、HTTP ステップは現在 Node.jsのみサポートしています。

CloudWatch Synthetics がテストの失敗をどのように扱うかを確認するために、この記事では httpbin.org の 2つの API を使用します。最初の API コールは期待通りのレスポンスを返しますが、2回目の API コールはエラーを返します。これによって、意図的にテストを失敗させます。

HTTP ステップのスクリプトを作成する手順 :

CloudWatch コンソールの Synthetics メニューを開きます。
Canaryを作成 をクリックします。
設計図のリストから API Canary を選択します。
Canaryの名前を入力します。(例 : http-steps-test )
HTTP リクエスト の HTTP リクエストを追加 をクリックします。
GET メソッドを選択します。
テストするアプリケーションまたはエンドポイントURL に https://httpbin.org/anything を入力します。
ヘッダー のキーに Content-Type、値に application/json を入力します。
リクエストデータ に {“foo”:”bar”} を入力します。
レポート設定 の ヘッダーとレスポンス本文をキャプチャ を有効にします。
別の呼び出しを保存して追加 をクリックします。
手順 6、7、10 をもう一度実施します。ただし、URL は https://httpbin.org/status/400 を入力します。
保存をクリックします。
作成画面の末尾にある アクティブトレース を有効にします。
Canary を作成 をクリックします。

Canary の作成には 1分程度かかる場合があります。完了すると、図1 のように作成された Canary がリストに表示されます。API canary の設計図に関する詳細は、Amazon CloudWatch ユーザーガイドの API canary を参照してください。

図 1 : CloudWatch コンソールの Canary ページ

結果の確認

Canary の詳細ページを確認する

Canary の詳細ページでは、全てのステップ (今回は2ステップ) と API コールの結果 (今回は成功と失敗が1つずつ) が表示されます。また、ログ、AWS X-Ray トレース、設定の確認や、スクリプトの更新が可能です。

図 2 : http-steps-test のレポート

可用性タブ (HTTP リクエスト)

2回の API コールで返却された HTTP ステータスコードは、それぞれ 200 (OK) と 400 (Bad request) です。httpbin.org の所定の API コールにより返却された 400 エラーが Canary 実行の失敗の原因であり、スクリプトに記述された URL を HTTP ステータスコード 200 を返却するように変更すれば Canary 実行は成功するでしょう。しかし、この記事の後半では、400 エラーが返却されることで成功と判定する、ネガティブテストを作成する手順を紹介します。

Synthetics は以下の情報を含む、それぞれの HTTP リクエストの詳細を記録します。

リクエスト、レスポンスヘッダー
リクエスト、レスポンスボディ
DNS ルックアップ、TCP 接続、TLS ハンドシェイク、TTFB、コンテンツ転送の時間で構成される、リクエストにかかった時間
ステータスコード

リクスト時間の詳細は、各ステップの期間のチャートをマウスオーバーすることで確認できます。

スクリプトで実行された各ステップの分析には、可用性 タブ内の HTTP ステップ または HTTP リクエスト タブの情報が使用できます。HTTP ステップ タブと HTTP リクエスト タブの内容は似ていますが、HTTP リクエスト タブは、スクリプトの実行中に発生した、ステップ以外の HTTP 呼び出しも表示されます。例えば、スクリプトが AWS Secrets Manager に対してシークレットを取得する API コールを実行した場合、HTTP リクエスト にはそれらの API コールも表示されます。

図 3 : Canary の実行結果

各ステップの + アイコンをクリックし、展開ボタンをクリックすると、スクリプト – エンドポイント間の通信の詳細を確認できます。また、各ステップで ヘッダーとレスポンス本文をキャプチャ オプションを有効にしたため、リクエストの詳細も確認できます。

図 4 : リクエストの詳細

可用性タブ (ログ)

ログタブには、Canary の実行中に発生したイベントが表示されます。ログには、スクリプトのエラー、接続の問題、各ステップの結果、ログの保存先の S3 バケットの情報が含まれます。

図 5 : ログタブ

可用性タブ (トレース)

CloudWatch Synthetics は アクティブトレース を Canary に追加できます。トレース タブの AWS X-Ray や Amazon CloudWatch ServiceLens による API コールのトレース情報は、より迅速なデバッグに有効です。各 API コールにはトレース ID が割り当てられており、トレースマップに移動 をクリックすることで詳細を表示します。X-Ray を使ったデバッグの詳細は、Debugging with Amazon CloudWatch Synthetics and AWS X-Ray のブログ記事を参照してください。

図 6 : トレースタブ

図 7 : セグメントの確認

モニタリングタブ

モニタリング タブには、スクリプトに関する CloudWatch メトリクスのダッシュボードが表示されます。表示される内容には、HTTP ステータスコード、各ステップの実行時間、成功率などが含まれます。これらのメトリクスに対して CloudWatch アラームを使用できます。例えば、エラーの発生時にアラート通知をすることは、ユーザーへの影響が大きくなる前に問題の解決を図る助けになります。

Canary によって発行される全メトリクスは、Amazon CloudWatch ユーザーガイドの Canary によって発行される CloudWatch メトリクスを参照してください。

図 8 : 指定した時間範囲の Canary メトリクス

ネガティブテスト

API をポジティブ、ネガティブの両面からテストすることは重要です。例えば、アプリケーションが不正な入力を適切に処理できることや、ユーザーやコネクションの予期しない振る舞いを検知可能であることの確認が挙げられます。これらの確認を早期に行うことは、アプリケーションの予期しない失敗を防ぎ、より良いユーザーエクスペリエンスの提供に繋がります。

ステータスコード 400 の返却をもって成功と判断するネガティブテストを、以下の手順で作成します :

CloudWatch コンソールの Synthetics メニューを開きます。
前述の手順で作成した Canary (例 : http-steps-test) を選択します。
アクション をクリックします。
編集をクリックします。
スクリプトエディタ を使って、Canary スクリプトに validateNegativeCase メソッドを追加します。

// Handle validation for negative scenario
const validateNegativeCase = async function(res) {
    return new Promise((resolve, reject) => {
        if (res.statusCode != 400) {
            throw res.statusCode + ' ' + res.statusMessage;
        }
        
        resolve();
        
    });
};

2番目のステップの executeHttpSteps() メソッド (例 : 検証 httpbin.org-2 ) を、以下の例を参考にして validateNegativeCase 関数を使用するように更新します。

await synthetics.executeHttpStep('検証 httpbin.org-2', requestOptionsStep2, validateNegativeCase, stepConfig2);

このメソッドは、ステータスコードが 400 ではない場合に例外をスローして、 Canary 実行を失敗として処理します。さらに、必要に応じてこのメソッドにビジネスロジックを追加して拡張することもできます。例えば、メッセージボディを確認して、内容に応じた処理を実行することが可能です。詳細は Amazon CloudWatch ユーザーガイドの Canary スクリプトのサンプルコードを参照してください。

スクリプトの更新および再実行後、Canary ページでステータスが成功になることを確認してみましょう。

クリーンアップ

AWS アカウントで請求が発生することを避けるため、この記事の手順で作成した Canary を削除してください :

CloudWatch コンソールの Synthetics メニューを開きます。
前述の手順で作成した Canary (例 : http-steps-test) を選択します。
アクション をクリックし、中止を選択します。
Canary が停止するまで待ちます。
アクション をクリックし、削除を選択します。
フィールドに Delete を入力し、削除をクリックします。

より詳細な情報は、Amazon CloudWatch ユーザーガイドの Canary の編集または削除を参照してください。

まとめ

このブログ記事では、複数ステップの API 監視を行う Canary の作成方法を紹介しました。はじめに作成した Canary スクリプトは httpbin.org の 2つの API を対象としていますが、片方の API が HTTP ステータスコード 400 を返却するため、テストの結果は失敗と判断されます。このブログ記事の後半では、HTTP ステータスコード 400 の返却をもってテストを成功と判断するように Canary スクリプトを更新することで、ネガティブテストを作成する方法を紹介しました。

著者について

翻訳はソリューションアーキテクトの加藤が担当しました。原文はこちらです。

Amazon Web Services ブログ

Amazon CloudWatch Synthetics を使用して 複数ステップの API を監視する

概要

HTTP ステップの作成

結果の確認

Canary の詳細ページを確認する

可用性 タブ (HTTP リクエスト)

可用性 タブ (ログ)

可用性 タブ (トレース)

モニタリング タブ