CloudWatch Synthetics の Canary を大規模に管理する

Amazon CloudWatch Synthetics では、アプリケーションエンドポイント、REST API、ウェブサイトコンテンツのパフォーマンスと可用性を自動的に監視できるため、顧客よりも先に問題を発見できます。アプリケーションとそれに付随するCanary の数が時間とともに増加するにつれて、それらを大規模に管理することはより困難で時間のかかるものになります。このソリューションは、Synthetic テストの対象範囲を維持するための一貫した自動化されたアプローチをどのように使用できるかを示すために設計されました。

CloudWatch Synthetics を使用して Canary を作成できます。Canary は、Puppeteer または Selenium Webdriver を介してヘッドレスの Google Chrome ブラウザにプログラム的にアクセスできるようにする設定可能なスクリプトです。Canary ブループリントや Chrome 用の Synthetics Recorder extension など、いずれかの方法を使用して Canaryを作成できます。これらのアプローチにより、最初の Canary テストをわずか数分で実行できるようになります。

組織のソフトウェア開発ライフサイクルに Synthetic テストを組み込む際には、複数の環境やアプリケーションにまたがる数百または数千の異なる Canary でも、一貫して Synthetic テストを実施できるかを検討することが重要です。Canary テストをソースコードリポジトリに保存し、CI/CD パイプラインを通じて自動的にビルド・デプロイすることで、チームはより効率的にスケーリングできます。

概要

この記事では、CloudWatch Synthetics Canary を大規模に開発、デプロイ、および保守するための反復可能なプロセスを提供するソリューションについて説明します。その仕組みと、独自の Canary テストの基盤としてどのように使用できるかを紹介します。このソリューションを使用すると、次のことに役立ちます。

CloudWatch Synthetics Canary の作成とメンテナンスに必要な時間と労力を最小限に抑えます。
AWS CloudFormation を使用して AWS リソースをモデル化およびセットアップすることで、インフラストラクチャ管理を簡素化します。
再利用可能な Canary テストとアラームのテンプレートを活用して、一貫性のあるビルドを行い、スクリプトの重複を減らします。
ランタイムバージョンやアーティファクトの保存期間など、すべての Canary にわたる設定の一括更新を効率化します。
CI/CD パイプラインを使用して Canary のデプロイを自動化します。
Canary をセカンダリ AWS リージョンにデプロイし、リージョンのパフォーマンス問題をより適切に特定して切り分けられるようになります。

ソリューション

このソリューションでは、AWS CodePipeline を使用して、Canary を AWS アカウントにデプロイするのに必要なステップを管理します。CodePipeline は、リリースパイプラインの自動化に使用されるフルマネージド型の継続的デリバリーサービスです。このパイプラインは、他のいくつかのマネージドサービスを結び付けて、包括的なデリバリーソリューションを構築します。

AWS CodeCommit – マネージドプライベート Git リポジトリ
AWS CodeBuild – マネージド継続的インテグレーションサービス
AWS CodeDeploy – マネージドデプロイサービス

AWS CloudFormation テンプレートを使用して、前述のサービスを含む CI/CD パイプラインの作成と、Amazon S3 バケット、AWS Systems Manager パラメーター、 Amazon EventBridge ルール、AWS Identity and Access Management (IAM) ロールなどの他のサポートリソースを作成します。CloudFormation は、テストライブラリからCanary を追加、更新、削除するためにも使用されます。CloudFormation テンプレートまたは基礎となる Canary テストコードへの変更が CodeCommit リポジトリにチェックインされると、CodePipeline 自動リリースプロセスが開始され、変更をビルドしてデプロイします。オプションで Canary をセカンダリ AWS リージョンにデプロイして、複数の地理的な場所からテストスクリプトを実行することができます。

このチュートリアルでは、AWS Cloud9 を使用して CloudFormation テンプレートと Canary スクリプトコードを編集します。また、CodeCommit リポジトリとのやり取りに使用する AWS への直接のターミナルアクセスも可能になります。

Architecture for automated canary deployment using AWS CodePipeline and AWS CloudFormation.

図 1. AWS CodePipeline と AWS CloudFormation を使用してCanary を自動でデプロイするためのアーキテクチャ

このソリューションを実装するには、次のことを行います。

継続的デリバリーパイプラインをセットアップします。
Canary テストリポジトリをクローンして探索します。
新しい Canary テストを定義します。
Canary のテンプレートを確認します。
Canary テストスクリプトを書きます。
Canary をグループに追加します。
変更をビルドしてデプロイします。

前提条件

AWS アカウントとデフォルト VPC が必要です。

ウォークスルー

開始するには、AWS アカウントにログインします。これらのリソースは、CloudFormation テンプレートを使用して自動的に作成されます。

ビルドアーティファクト、ビルド結果、Canary テストアーティファクトを格納する S3 バケット
デフォルトの Canary テストコードベースを含む CodeCommit リポジトリ
関連する IAM ロールを持つ CodeBuild プロジェクト
関連する IAM ロールを含む CodePipeline の自動リリースプロセス
ビルドの開始に使用される IAM ロールが関連付けられた EventBridge ルール
CloudFormation のデプロイロール
Systems Manager (SSM) Parameter Store のエントリ
Canary の実行に使われる CloudWatch Synthetics IAM ロール
スタックパラメーターに設定されたセカンダリ AWS リージョンでリソース (S3 バケットと SSM パラメーター) を作成するために使用される IAM ロールが関連付けられた Lambda 関数
AWS Cloud9 クラウドベース統合開発環境 (IDE) インスタンス

次のステップで使用する以下のファイルをダウンロードしてローカルに保存します。

cfn-pipeline-stack-v2.yaml – 前述の AWS リソースを作成する CloudFormation テンプレート
synth-at-scale-repo-v2.zip – デフォルトの Canary テストプロジェクト

ステップ１：継続的デリバリーパイプラインのセットアップ

AWS コンソールにログインしたら、S3 サービスに移動します。バケットリストから バケットを作成 を選択し、一意の名前で新しい S3 バケットを作成します。ダウンロードした synth-at-scale-repo-v2.zip ファイルの名前を synth-at-scale-repo.zip に変更し、新しい S3 バケットにアップロードします。作成したバケットの名前は覚えておいてください。次のステップで利用します。

次に、AWS コンソールの CloudFormation サービスに移動します。スタックリストから、スタックの作成 > 新しいリソースを使用 (標準) を選択し、デプロイウィザードを開始します。

図 2. 新しいCloudFormationスタックの作成

CloudFormation テンプレートを指定するには、テンプレートファイルのアップロード を選択し、ファイルの選択 を選択します。以前にダウンロードした cfn-pipeline-stack.yaml ファイルを選択し、次へを選択します。

スタックのデプロイプロセスのステップ 2 では、名前で始まるスタックの詳細を指定します。図 3 では スタック名 を canary-pipeline と指定しましたが、必要に応じて変更できます。この CloudFormation テンプレートには 5 つのパラメーターがあります。

S3 Bucket Name フィールドに、synth-at-scale-repo.zip をアップロードした、先ほど作成した S3 バケットの名前を入力します。CodeCommit Repository Name [canary-tests] と Branch Name [main] のデフォルト値は、CloudFormation テンプレートの一部として提供されています。これらの値は必要に応じて変更できます。この CloudFormation テンプレートは同じ AWS リージョンに複数回デプロイすることはできませんが、固有の スタック名 と Repository Name を使用して異なる AWS リージョンにデプロイできます。

URL は、Canary でテストしたいアプリケーションやエンドポイントになります。サイト上でトラフィックが発生するので、あなたが所有する URL でなければなりません。また、Canary をインストールする Secondary Region [us-east-2] も設定しました。これは、現在スタックを作成している AWS リージョンとは異なる必要があります。Canary を複数のリージョンに展開することで、リージョンのパフォーマンスの異常を特定しやすくなります。現在の AWS リージョンでのみ Canary を実行するには、パラメーターを空白にします。

図 3. CloudFormation スタックのパラメーターを設定

スタックのパラメータを設定したら、次へを選択して次のステップに進みます。

ステップ 3 では、デフォルトのスタックオプションから変更せずに、もう一度次へを選択します。

最後に、設定したパラメータの値を確認し、ページの一番下までスクロールします。チェックボックスをオンにして IAM リソースの作成を確認し、送信を選択してスタックの作成を開始します。

Final confirmation before creating CloudFormation stack

図 4. CloudFormation スタックの作成時の最終確認

CloudFormation コンソールでデプロイのステータスを確認してください。進行状況をトラックするには、イベント タブに切り替えます。リソース タブを確認して、作成されたリソースを確認します。

List of CloudFormation stack creation events

図 5. CloudFormation スタックの作成イベントのリスト

AWS CodePipeline のセットアップが完了すると、パイプラインが開始され、最初の実行が開始されます。ビルドプロセスが完了すると、2つ目の CloudFormation テンプレートのデプロイが開始されます。これは Canary スクリプトのライブラリのルートテンプレートとして機能します。各 Canary スクリプトは、ルートテンプレートの下に独自のネストスタックとしてデプロイされます。ルートスタックの名前は、CodeCommit リポジトリの名前と一致します。

CodePipeline の初期実行が正常に完了したら、AWS コンソールで CloudFormation > スタック に移動すると、パイプラインインフラストラクチャ、Cloud9 IDE、Canary テストスイート、および最初の Canary テストを表す 4 つの新しくデプロイされた CloudFormation テンプレートが表示されます。

CloudFormation stack list including canary pipeline and canary tests stacks

図 6. Canary パイプラインと Canary テストスタックを含むCloudFormation スタックリスト

AWS コンソールで CloudWatch > Synthetics Canaries に移動して、プライマリリージョンとセカンダリリージョンの両方に 1 つの Canary テストがデプロイされていることを確認します。各 Canary は、CloudFormation スクリプトで作成した Canary グループ内に表示されます。

グループを使用すると、Canary をわかりやすいコレクションに整理できます。また、グループ内のすべての Canary の実行結果を集計して表示できます。これは、リージョンのパフォーマンスの問題や障害を特定する場合に特に役立ちます。図 7 では、Canary の結果を Canary グループ別の内訳で見ることができます。

CloudWatch Synthetics Canaries Dashboard with first canary

図 7. 最初の Canary を含む CloudWatch Synthetics Canary ダッシュボード

ステップ２：Canary テストリポジトリのクローンを作成して探索する

Canary パイプラインと最初の Canary テストがデプロイされたので、プロジェクトの背後にあるソースコードを見て、2 つ目の Canary テストをデプロイする手順を見ていきましょう。

Cloud9 はクラウドベースの統合開発環境 (IDE) で、ブラウザからコードを記述、実行、デバッグできます。この例では Cloud9 を使用しているため、ソフトウェアをインストールする必要はなく、事前認証された AWS Command Line Interface (AWS CLI) を活用できます。この例では Cloud9 を使用していますが、最も使い慣れた開発者ツールを使用することもできます。

AWS コンソールで Cloud9 > 環境に移動し、作成した IDE 環境の開くを選択します。IDE 名は、デプロイ時に入力したスタック名と一致します(この例では canary-pipeline) 。

図8. Cloud9 IDE 環境のリスト

クラウド IDE インターフェイスが読み込まれると、終了できる Welcome メッセージが表示されます。AWS Cloud9 メニューに移動して Welcome Page を選択すれば、いつでも再び開くことができます。

The Cloud9 integrated development environment

図 9. Cloud9 の統合開発環境

Git は各コミットにユーザー ID を関連付けるので、まずは環境内で名前とメールアドレスを設定します。Window > New Terminal に移動し、ターミナルウィンドウで次のコマンドを実行します。これらの詳細は、今後の Git コミットに関連付けられます。

git config --global user.name <YOUR_NAME>
git config --global user.email <YOUR_EMAIL>

次に、新しい CodeCommit リポジトリをクローンします。別の AWS リージョンまたはリポジトリ名を使用した場合は、それに応じて URL を調整する必要があります。リポジトリの URL は、AWS コンソールで CodeCommit > リポジトリ に移動すると確認できます。HTTPS オプションを選択して URL をクリップボードにコピーします。

ターミナルウィンドウで、リポジトリを Cloud9 ワークスペースにクローンします。

git clone <YOUR_REPOSITORY_URL>

プロセスが完了すると、IDE の左側にプロジェクト構造が表示されます。プロジェクトのルートディレクトリは Repository Name (この場合は canary-tests) と一致します。

Cloning a Git repository from the Cloud9 terminal

図10. Cloud9 ターミナルから Git リポジトリを Clone

プロジェクトのルートディレクトリにある cfn-pipeline-stack.yaml ファイルは、作業中の環境をデプロイするために使用されたのと同じ CloudFormation テンプレートです。このスタックを再度デプロイする必要はありませんが、テンプレートの内容を確認して、作成されたリソースをより深く理解することができます。

cfn-canary-stack.yaml CloudFormation テンプレートは、自動ビルドおよびリリースプロセスの一環として CloudWatch Synthetics Canary をデプロイするために使用されます。Canary テストの作成とデプロイがいかに簡単かを説明するために、2 つ目の Canary テストを作成するプロセスを順を追って説明します。

ステップ３：新しい Canary テストの定義

cfn-canary-stack.yaml ファイルをダブルクリックして開き、FirstCanary という名前のリソースを見つけます。このセクションのすぐ下に、2 つ目の Canary の定義を追加します。新しいセクションは、この例で強調表示されているように、1 レベルインデントを増やし、最初の Canary と一致させる必要があります。このセクションでは、新しいネストされた CloudFormation スタックを宣言します。ネストされたスタックを追加するたびに、競合を避けるために一意のリソース名を使用する必要があります。変更が完了したら、ファイルを保存します。

FirstCanary:
  Type: AWS::CloudFormation::Stack
  Properties:
    Parameters:
      CanaryName: "first_canary"
      CanarySchedule: "rate(60 minutes)"
  TemplateURL: !Sub 'https://${RepositoryName}-scripts-${AWS::AccountId}-${AWS::Region}.s3.amazonaws.com/cfn/first-canary.yaml'
 
SecondCanary: Type: AWS::CloudFormation::Stack Properties: Parameters: CanaryName: "second_canary" CanarySchedule: "rate(60 minutes)" TemplateURL: !Sub 'https://${RepositoryName}-scripts-${AWS::AccountId}-${AWS::Region}.s3.amazonaws.com/cfn/second-canary.yaml'

この例では、新しいスタックに SecondCanary という名前を付け、TemplateURL を通じて CloudFormation テンプレートを参照しています。この CloudFormation テンプレートは、この後すぐに作成します。各 Canary には、次の 2 つのパラメーターが公開されています。

CanaryName
- それぞれの固有のテストケースを識別するために使用される Canary 名
CanarySchedule
- テストを実行する頻度を指定する Canary スケジュール

次に、宣言したばかりのネストされたスタックを定義する CloudFormation テンプレートを作成します。テンプレートを 1 から作成するのではなく、プロジェクトの cfn ディレクトリにある既存の Canary テストを複製します。これを行うには、first-canary.yaml ファイルを右クリックし、ポップアップメニューから Duplicate を選択します。作成した新しいファイルを右クリックし、ポップアップメニューから Rename を選択し、ファイルに second-canary.yaml という名前を付けます。

ファイル名をダブルクリックして編集用に開きます。まず、テンプレートの Description セクションを更新して、今回が 2 回目のテストであることを示してください。次のセクションでは、4 つのパラメーターが宣言されていることがわかります。CanaryName パラメーターと CanarySchedule パラメーターには値がありません。これらは親スタック (cfn-canary-stack.yaml) から渡されるためです。CodeRepoName パラメーターと ExecRole パラメーターは、動的な参照を使用して SSM Parameter Store から値を取得します。これらのパラメータを外部化する利点は、変更を一元管理でき、各パラメータを使用するすべての CloudFormation テンプレートに自動的に反映されることです。

テンプレートの Resources セクションでは、AWS CloudFormation によってホストされているマクロである AWS::Include transform を利用しています。CloudFormation テンプレートマクロを使用すると、テンプレートに対してカスタム処理を実行できます。今回は、複数の CloudFormation テンプレートに含めることができる再利用可能なスニペットを設計する機能を活用しています。これにより、各 Canary テストに必要なスクリプトの量が減り、テンプレートの長期的な保守性が向上します。

テンプレートの最初のリソースには一意の名前が必要なので、まずそれを変更することから始めます。一貫性を保つため、ネストスタックに使用したのと同じ名前「SecondCanary」を使用しています。

SecondCanary:
  Fn::Transform:
    Name: AWS::Include
    Parameters:
      Location: !Sub 's3://${CodeRepoName}-scripts-${AWS::AccountId}-${AWS::Region}/cfn/_canary_template.yaml'

AWS::Include を参照する CloudFormation スタックを作成または更新する場合、CloudFormation は指定されたファイルの内容をテンプレート内の transform の位置に挿入します。この場合、_canary_template.yaml スニペットの内容が SecondCanary リソースに挿入されます。2つ目のの AWS::Include transform では _canary_alarms.yaml スニペットが挿入されます。

Fn::Transform:
  Name: AWS::Include
  Parameters:
    Location: !Sub 's3://${CodeRepoName}-scripts-${AWS::AccountId}-${AWS::Region}/cfn/_canary_alarms.yaml'

テンプレートにスニペットを動的に挿入することで、多くの Canary テストで同じコードを繰り返す必要が無くなり、長期的なメンテナンスの負担が軽減されます。これらのスニペットの内容については、この記事の後半で見ていきます。

テンプレートの最後のセクション Outputs では、新しい CloudWatch Synthetics Canary の Amazon Resource Name (ARN) を返します。この出力情報は、後で親スタックで参照します。

Outputs:
  CanaryArn:
    Value: !Sub 'arn:${AWS::Partition}:synthetics:${AWS::Region}:${AWS::AccountId}:canary:${SecondCanary}'

この時点で、図 11 に示すように、second-canary.yaml CloudFormation テンプレートが完成しているはずです。

Completed second canary CloudFormation template

図11. 2つ目の Canary CloudFormation テンプレートの完了

ステップ４：Canary テンプレートを探索する

CloudWatch Synthetics Canary

次に進む前に、_canary_template.yaml ファイルを詳しく見てみましょう。このスニペットでは、AWS::Synthetics::Canary CloudFormationリソースを定義しています。スクリプト全体を通して、すでに宣言されている他の CloudFormation パラメータやリソースを使用できるようにする組込み関数 Ref が使用されているのがわかります。AWS::Include transform を使用する場合、省略記法の関数表記はサポートされていないことに注意が必要です。インクルードされる YAML スニペットは、組み込み関数を使用する場合、完全な関数名の構文を使用する必要があります（例えば、!Sub ではなく Fn::Sub: など）。

Code エンティティは、Canary に使用されるスクリプトコードを識別するために使用されます。スクリプトコードは、Script プロパティを使用して CloudFormation テンプレートに含めるか、S3 バケットに外部保存することができます。このケースでは、全てのスクリプトコードを S3 上の .zip ファイルに保存しています。スクリプトコードが更新されてデプロイされると、.zipファイルの中身は最新のビルドで更新されます。一方、Canary リソースのプロパティには変更が加えられていないため、新しいスクリプトコードはデプロイされません。これを解決するために、テンプレートに Canary バージョンの自動タグ付けを追加しています。ビルドプロセスの一部として自動的に更新される Version タグが作成されます。

Tags:
  - Key: Version 
    Value: '{{VERSION}}'

自動ビルド中に、独自のバージョンが生成されてターゲットファイルに挿入され、{{VERSION}} 文字列トークンが現在のタイムスタンプに置き換えられます。新しいビルドがデプロイされると、Version タグの値の変更が CloudFormation によって認識され、Canary コードの最新バージョンがインストールされます。この置き換えの仕組みについては、この記事の後半で説明します。

CloudWatch Alarms
- Cloud9 で _canary_alarms.yaml を開いて調べてください。ここでは、Canary によって発行されるメトリクスを監視し、異常な結果を警告する 2 つの CloudWatch アラームを宣言しています。
CanarySuccessAlarm
- SuccessPercent メトリクスの監視に使用される静的なしきい値に基づくアラーム。
CanaryDurationAlarm
- Duration メトリクスの異常検出に基づくアラーム。

Canary ごとにこれらのアラームの作成を自動化することで、一貫性が保たれ、重複が最小限に抑えられます。異常検出を使用することで、パフォーマンスのしきい値をハードコーディングする必要がなくなり、同じアラーム定義を他の Canary テストに再利用できます。

テストケースの数が増え、要件が変わるにつれて、必要に応じてまとめることができる複数の Canary テンプレートとアラームテンプレートを開発する必要がある場合があります。たとえば、REST API テストと Web ワークフローテストには異なる Canary テンプレートを使用できます。また、監視対象のメトリクスとしきい値に基づいて異なるアラームセットも用意されています。

ステップ５：Canary テストスクリプトを書く

Canary をデプロイする CloudFormation テンプレートができたので、次は Canary スクリプト自体を書く必要があります。Synthetics は複数のランタイムバージョンをサポートしています。この例では、Node.js ランタイムと Puppeteer フレームワークを使用していますが、Python ランタイムと Selenium Webdriver フレームワークでも同じアプローチをとることができます。

Canary ファイルをパッケージングする場合、Node.js スクリプトは nodejs/node_modules ディレクトリの下にある必要があるため、そのディレクトリ構造をプロジェクト内に複製しています。Canary のスクリプトエントリポイント (Handler 関数名) は、スクリプトのファイル名と一致する必要があります。first_canary.js ファイルを複製し、名前を second_canary.js に変更して、新しいスクリプトを作成します。次に、それを Cloud9 で開いて編集します。second_canary.js ファイル名と一致するように、関数名とhandler の参照を second_canary に変更する必要があります。

テスト対象の URL の管理を簡単にするために、Canary スクリプトでは {{HOST_URL}} という別の文字列トークンを定義しています。canary-pipeline CloudFormation スタックで以前に設定した URL パラメーターは、ビルドプロセス中に各 Canary クリプトに自動的に挿入されるため、個々のテストスクリプトを変更する必要はありません。

CloudWatch Synthetics canary test script written in Node.js for Puppeteer

図 12. Node.js for Puppeteerで書かれた CloudWatch Synthetics Canary テストスクリプト

ステップ６：Canary グループに追加する

最後に、Canary を定義した cfn-canary-stack.yaml テンプレートに戻り、second-canary.yaml で定義した出力値を参照して新しい Canary を既存の Canary グループに追加し、ファイルを保存します。

CanaryGroup:
  Type: AWS::Synthetics::Group
  Properties: 
    Name: !Sub ${RepositoryName}-${AWS::Region}
    ResourceArns: 
      - !GetAtt FirstCanary.Outputs.CanaryArn
      - !GetAtt SecondCanary.Outputs.CanaryArn

ステップ７：変更をビルドしてデプロイする

これで、以下の変更を CodeCommit リポジトリにプッシュする準備ができました。

second-canary.yaml CloudFormation テンプレートを追加しました。
second_canary.js テストスクリプトを追加しました。
SecondCanary というネストされたスタックを追加しました。
Canary グループに SecondCanary を追加しました。

変更をプッシュするには、Cloud9 内のターミナルウィンドウに戻り、以下のコマンドを実行します。

cd canary-tests 
git add .
git commit -m "add second canary"
git push origin main

ローカルの変更がリモートリポジトリにプッシュされるとすぐに、EventBridge は何が起こったかを詳細に示すイベントを受け取ります。このイベントは EventBridge ルールによって認識され、CodePipeline を呼び出すために使用されます。最新のソースコードが CodeCommit から取得され、ビルドプロセスが開始されます。

ビルドプロセスの一部として実行されるコマンドは、Buildspec ファイルによって決まります。buildspec.yml ファイルのこのスニペットは、sed を使ってCloudFormationテンプレートの {{VERSION}} トークンと Canary スクリプトの {{HOST_URL}} トークンを置き換える方法を示しています。これらの文字列トークンは、ビルド時に決定される動的な値に置き換えられるように、以前に定義したことを思い出してください。buildspec.yml ファイル全体は Cloud9 環境で確認できます。

version: 0.2
phases:
  build:
    commands:
      - echo Building CloudWatch Synthetics Canaries
      - echo Version Tag - Token Replacement - Cfn Templates
      - sed -i "s/{{VERSION}}/$(date +%Y-%m-%dT%T)/g" cfn/*.yaml
      - echo HOST_URL - Token Replacement - Canary Scripts
      - sed -i 's@{{HOST_URL}}@'"$HOST_URL"'@g' nodejs/node_modules/*.js
      - echo Finished Building CloudWatch Synthetics Canaries

AWS コンソールでビルドの進行状況を確認するには、デベロッパー用ツール > CodePipeline > 履歴に移動して、パイプラインの実行が進行中であることを確認します。実行 ID を選択すると、パイプラインのステージとステータスの詳細が表示されます。

図13. CodePipeline のパイプライン実行アクション

パイプラインの実行が完了したら、CloudFormation > スタック に戻って、デプロイされた新しいネストされたスタック (canary-tests-SecondCanary) を確認します。

CloudFormation stack list including new canary test

図14. 新しい Canary テストを含むCloudFormationスタック

また、CloudWatch > Synthetics Canaries に戻ると、各リージョンに 2 つ目の Canary スクリプト second_canary が表示されます。

CloudWatch Synthetics Canaries Dashboard with first and second canaries

図15. 1 つ目の Canary と 2 つ目の Canary を含むCloudWatch Synthetics の Canary ダッシュボード

この基盤が整っていれば、継続的デリバリーパイプラインによって自動的にビルドおよびデプロイされるので、テストライブラリに新しい Canary を追加できるようになります。

コスト

このソリューションで使用されるサービスには、最小コミットメントや長期契約は不要で、使用した分だけお支払いいただくだけです。ソリューションを実行するための総コストは、Synthetics Canary と他のサービスの実行回数に基づいています。また、Canary を実行するたびに Lambda 関数が起動され、ログと結果が CloudWatch Logs と S3 に書き込まれます。

新しい AWS アカウントで作業する場合、AWS 無料利用枠の制限内で期間限定で運用できます。AWS 無料利用枠の詳細については、こちらをご覧ください。CloudWatch の料金詳細ページの Synthetics を利用したエンドユーザーのモニタリング の例では、長期間使用した場合の詳細なコスト内訳が記載されています。設定したとおりにセットアップした Canary を継続して実行するための推定コストは、1 か月あたり 2 ～ 3 ドルですが、導入するテストの数と複雑さによって費用が変わります。

また、Canary を実行するたびに AWS Lambda 関数を実行し、ログと結果を CloudWatch ログと指定された Amazon S3 バケットに書き込みます。Canaryを更新してデプロイする際には、自動デリバリーパイプラインとCloud9 IDEが活用されます。AWS Lambda、Amazon S3、CloudWatch Logs、AWS CodeCommit、 AWS CodeBuild、AWS CodePipeline、AWS Cloud9、AWS Systems Manager Parameter Store を含む関連する AWS サービスの料金の詳細については、各 AWS サービスの詳細ページの料金セクションを参照してください。

このソリューションに関連する継続的なコストが発生しないように、次のクリーンアップ手順を実行してください。

クリーンアップ

自動デプロイパイプラインと Canary テスト結果の調査が終わったら、次の手順に従って、プライマリデプロイリージョンとセカンダリデプロイリージョンの両方からこのプロジェクトを削除します。Cloud9 ワークスペース上の cleanup.sh を開き、これらの値を CloudFormation スタック、CodeCommit リポジトリ、および AWS アカウント ID の値と一致するように編集します。

# VARIABLES
STACK=canary-pipeline 
REPO=canary-tests 
ACCT=000000000000 
REG1=us-east-1 
REG2=us-east-2

次に、Cloud9 ターミナルウィンドウで次のスクリプトを実行して、Canaryテスト、アラーム、S3 バケットとアーティファクト、および Canary パイプラインを削除します。

sh cleanup.sh

スクリプトの実行が開始された直後に、Cloud9 インスタンスが終了し、「環境にアクセスできません」というエラーメッセージが表示されます。これは予想通りです。Return to dashboard を選択して続行します。

Running cleanup.sh from the Cloud9 terminal

図 16. Cloud9 ターミナルから cleanup.sh を実行する

AWS コンソールに戻り、CloudFormation > スタック に移動して、以前にデプロイした CloudFormation スタックが削除されていることを確認します。

cleanup.sh スクリプトの実行が終了しても、ソリューションによって生成された CloudWatch Logs データは引き続き使用できます。ログデータを削除するには、CloudWatch > ログ > ロググループ に移動し、リストから cwsyn- で始まるロググループをフィルタリングします。ロググループを選択し、アクション > ロググループ の削除を選択します。使用した両方の AWS リージョンでこれらの手順を実行してください。

最後に、CloudFormation で使用されていた IAM ロールを削除します。IAM > ロール に移動し、<STACK_NAME>-CloudFormationDeployRole-<STACK_ID> という名前のロールを検索します。ロールを確認して削除を選択します。

結論

Canary スクリプトをソースコードリポジトリに保存し、自動化された CI/CD パイプラインを通じてデプロイすることで、ソフトウェア開発者とアプリケーションチームはテストスクリプトの作成と管理に費やす時間を減らすことができます。今回検討したソリューションでは、CloudWatch Synthetics Canary を大規模に開発、デプロイ、保守するための反復可能なプロセスを実現しています。以下を目的とした独自のスイートCanary テストの基盤として使用することをお勧めします。

Canary スクリプトの作成と管理に費やす時間を最小限に抑えます。
新しい Canary を書くときも、一貫性を保ちます。
AWS インフラストラクチャ管理を簡素化します。
すべての Canary にわたって設定の一括更新を効率的に実行できます。
CI/CD パイプラインを使用して Canary のデプロイを自動化します。

API とウェブワークフローのテストを自動化すれば、迅速に行動できると同時に、ポジティブなユーザーエクスペリエンスを大規模に保証できます。

CloudWatch による Synthetic モニタリングの詳細については、CloudWatch Synthetics ユーザーガイドをご覧ください。

自動の継続的デリバリーパイプラインの設定の詳細については、AWS CodePipeline の開始方法をご覧ください。

AWS のオブザーバビリティ機能の詳細と実際の経験を積むには、 AWS One Observability Workshop をご覧ください。

著者について

翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文はこちらです。

Amazon Web Services ブログ