[アップデート] Amazon CloudWatch Synthetics Canary の新しいブループリント「Multi checks」が追加されシンプルな Canary をひとつにまとめやすくなりました
いわさです。
ワークロードの外形監視に CloudWatch Synthetics をご利用されている方は多いのではないでしょうか。
非常に便利で私もよく使うのですが、CloudWatch Synthetics は Canary の実行ごとに料金が発生するのですが数分ごとなどの頻度で継続的に実行しようとするとまずまず料金が発生します。
この時複数のエンドポイントを監視対象にする時、手軽なハートビートモニタリングのブループリントを使う場合は最大5つのエンドポイントまでチェック対象に出来ますが、HTTP 以外のチェックが必要な場合はその種類の数だけ Canary が必要になり料金が膨らんでいきます。あるいは完全にカスタムでスクリプトを構築する必要などがありました。
先日のアップデート新しいブループリント「Multi checks」が追加されました。
JSON 形式で複数のステップを簡易的に定義することが出来るので、カスタムスクリプトの実装までは不要でありながら従来のブループリントより色々な種類のチェックをひとつの Canary にまとめることが出来るようになりました。
Canary をひとつにまとめることでコスト削減をすることも出来そうです。
今回使ってみたので設定方法などを紹介します。
新しいブループリント
まず、Amazon CloudWatch Synthetics は CloudWatch コンソールの Application Signals (APM) メニュー内にある「Synthetics Canaries」からアクセス出来ます。

Canary で実行される内容の実体は Lambda 関数なのですが、新規 Canary 作成時にブループリントから選択することで Lambda 関数の実装を意識せずに Canary を構築することが出来ます。
このブループリントがいくつか提供されているのですが、ここに Multi chacks が追加されました。

ランタイムバージョンとしては Node.js の syn-nodejs-3.0 のみが本日時点ではサポートされています。

Multi checks ブループリントは今回公式ドキュメント上も専用ページが追加されています。
この Multi checks ブループリントでは複数のステップを JSON で定義し、Canary に実行してもらうことが出来ます。
ステップの数は最大10個までとなっていて、モニタリングのタイプとしては以下の 4 つがサポートされています。
- 基本的なHTTPリクエスト
- TCPリクエスト
- DNSレコードの検証
- SSL証明書の監視
一方で注意点としては、上記以外のプロトコルや複雑なもの(例えばユーザー操作をシミュレーションするような複雑なテストシナリオ)が必要な場合は Multi checks は不適切で、カスタムスクリプトや他のブループリントを選択しましょう。
HTTP リクエストの認証方法としては Secrets Manager に統合された Basic 認証、API Key、OAuth、Sigv4 などがサポートされています。
また、制限事項として HTTP レスポンスのサイズは 1 MB を超えることは出来ないので注意しましょう。
使ってみる
ではこのブループリントを使って Canary を新規作成してみましょう。
ハートビートだと URL 入力するだけで Canary を作成できるのですが、今回のブループリントでは JSON で定義する必要があります。
ハートビートに比べるとそこが少し敷居高く感じるかもしれませんが、そこまで難しい内容ではないので頑張りましょう...!
デフォルトでは次のような JSON が設定されていると思います。
こちらは本当に完全なサンプルなのでこのまま使うことはほぼないと思います。
{
"steps": {
"1": {
"stepName": "base_http_check_example",
"checkerType": "HTTP",
"httpMethod": "GET",
"url": "https://www.example.com",
"assertions": [
{
"type": "STATUS_CODE",
"operator": "EQUALS",
"value": 200
},
{
"type": "RESPONSE_TIME",
"operator": "LESS_THAN",
"value": 3000
}
]
},
"2": {
"stepName": "base_dns_txt_check_example",
"checkerType": "DNS",
"domain": "example.com",
"recordType": "TXT",
"nameserver": "8.8.8.8",
"timeout": 5000,
"port": 53,
"protocol": "TCP",
"assertions": [
{
"type": "RECORD_COUNT",
"operator": "GREATER_THAN",
"value": 1
},
{
"type": "RECORD_VALUE",
"operator": "CONTAINS",
"value": "v=spf1"
},
{
"type": "RECORD_VALUE",
"operator": "CONTAINS",
"value": "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
},
{
"type": "TTL",
"operator": "LESS_THAN",
"value": 3601
},
{
"type": "RESPONSE_TIME",
"operator": "LESS_THAN",
"value": 1000
}
]
},
"3": {
"stepName": "base_ssl_certificate_check_example",
"checkerType": "SSL",
"hostname": "www.example.com",
"port": 443,
"timeout": 100000,
"sni": true,
"verifyHostname": true,
"allowSelfSigned": false,
"assertions": [
{
"type": "CERTIFICATE_VALID",
"value": true,
"description": "Certificate should be valid"
},
{
"type": "CERTIFICATE_EXPIRY",
"operator": "GREATER_THAN",
"value": 30,
"unit": "DAYS",
"description": "Certificate should not expire within 30 days"
},
{
"type": "CERTIFICATE_SUBJECT",
"field": "CN",
"operator": "CONTAINS",
"value": "example.com",
"description": "Certificate CN should contain example.com"
},
{
"type": "CERTIFICATE_ISSUER",
"field": "O",
"operator": "CONTAINS",
"value": "DigiCert",
"description": "Certificate should be issued by DigiCert"
},
{
"type": "CIPHER_SUITE",
"operator": "CONTAINS",
"value": "AES",
"description": "Cipher suite should use AES encryption"
},
{
"type": "CERTIFICATE_TRANSPARENCY",
"value": true,
"description": "Certificate should have signed certificate timestamps"
}
]
},
"4": {
"stepName": "base_tcp_connection_check_example",
"checkerType": "TCP",
"hostname": "www.example.com",
"port": 80,
"timeout": 5000,
"sendData": "GET / HTTP/1.1\r\nHost: www.example.com\r\n\r\n",
"expectedResponse": "HTTP/1.1 200 OK",
"encoding": "UTF-8",
"assertions": [
{
"type": "CONNECTION_SUCCESSFUL",
"value": true,
"description": "TCP connection should be successful"
},
{
"type": "RESPONSE_TIME",
"operator": "LESS_THAN",
"value": 3000,
"description": "Response time should be less than 3 seconds"
},
{
"type": "RESPONSE_DATA",
"operator": "CONTAINS",
"value": "200 OK",
"description": "Response should contain 200 OK"
}
]
},
"5": {
"stepName": "basic_auth_http_check_example",
"checkerType": "HTTP",
"httpMethod": "GET",
"url": "https://httpbin.org/basic-auth/user/pass",
"authentication": {
"type": "BASIC",
"username": "user",
"password": "pass"
},
"assertions": [
{
"type": "STATUS_CODE",
"operator": "EQUALS",
"value": 200
},
{
"type": "RESPONSE_TIME",
"operator": "LESS_THAN",
"value": 5000
},
{
"target": "TEXT",
"type": "BODY",
"operator": "CONTAINS",
"value": "authenticated"
}
]
}
},
"variables": {
"domain": "example.com"
}
}
JSON の記述方法でうsがm,以下に詳しく記載があります。
ポイントとしてはcheckerTypeが事前に用意されていて、それを選択して複数ステップを構成する形になります。
- HTTP : 包括的なリクエストとレスポンスの検証を使用して、Web エンドポイントと API を監視
- DNS : DNS 解決を検証し、情報を記録
- SSL : SSL 証明書の健全性と構成を監視
- TCP : TCP ポートの接続と応答の検証をテスト
今回はクラスメソッドのホームページやブログ、あとドメインの状況をチェックを行う以下のようなものを作ってみました。
{
"steps": {
"1": {
"stepName": "http_check1",
"checkerType": "HTTP",
"httpMethod": "GET",
"url": "https://classmethod.jp",
"assertions": [
{
"type": "STATUS_CODE",
"operator": "EQUALS",
"value": 200
},
{
"type": "RESPONSE_TIME",
"operator": "LESS_THAN",
"value": 3000
}
]
},
"2": {
"stepName": "http_check2",
"checkerType": "HTTP",
"httpMethod": "GET",
"url": "https://dev.classmethod.jp/",
"assertions": [
{
"type": "STATUS_CODE",
"operator": "EQUALS",
"value": 200
},
{
"type": "RESPONSE_TIME",
"operator": "LESS_THAN",
"value": 3000
}
]
},
"3": {
"stepName": "base_dns_txt_check_example",
"checkerType": "DNS",
"domain": "classmethod.jp",
"recordType": "A",
"nameserver": "8.8.8.8",
"timeout": 5000,
"port": 53,
"protocol": "TCP",
"assertions": [
{
"type": "RECORD_COUNT",
"operator": "GREATER_THAN",
"value": 1
},
{
"type": "RECORD_VALUE",
"operator": "CONTAINS",
"value": "18.172.31.80"
}
]
}
}
}
Multi checks 実行の様子
実行方法は従来の Canary と同じなのですが、モニタリング画面が若干違っていました。
まず、Canary 一覧からの結果は次のように従来と同じです。

Canary の詳細モニタリング画面を見てみると、次のようにマルチステップ用の内容が表示されるようになっていますね。
複数ステップで構成しても、特定のステップで問題が起きたとかレイテンシーが増えているとか、確認しやすくなっていると思います。

そして、下部の詳細情報では Multi Check Steps のタブから各ステップの結果や時間を確認することが出来ます。

HTTP リクエストタブでは複数ステップのそれぞれのリクエスト詳細まで確認が出来ました。良いですね。

さいごに
本日は Amazon CloudWatch Synthetics Canary の新しいブループリント「Multi checks」が追加されシンプルな Canary をひとつにまとめやすくなったので使ってみました。
5エンドポイントまでのシンプルな HTTP チェックであれば従来のハートビートブループリントを使うで良いと思いますが、6件以上10件以下であれば今回の Multi checks を使うのは良いですね。
そして HTTP だけでなく TCP や DNS など他にもチェックタイプを増やしつつ、でもコード実装までは行いたくないという場合には助けてくれそうです。






