こんにちは、AWSグループの藤岡です。
Webサービスにおける外形監視は欠かせませんが、「サービス的にそこまで凝った監視は要らない」「プロジェクト規模的に高額なオブザーバビリティサービスを導入できない」といった場面はよくあると思います。 そういった時に有効なアプローチとして挙げられるのが、AWSのサービスを活用した、安くかつAWSで完結した外形監視を実現することです。
そこで今回は、AWSサービスで完結した外形監視のアプローチを3つご紹介します。
先に結論を書くと
執筆時点でのAWSサービスを使うと、長所・短所が異なる以下3つの外形監視アプローチが有効です。 監視要件、コスト、運用手間を踏まえて、それぞれのアプローチから適切な選択することがオススメです。（より詳細な比較観点は後半のまとめで。）
| アプローチ | 特徴 | 料金 | カスタマイズ性 | 手軽さ |
|---|---|---|---|---|
| Route53 ヘルスチェック | シンプルな設定でエンドポイントの監視が可能 | ◎ | △ | ◎ |
| Lambda（＋Step Functions） | カスタマイズ性が高く、複雑なシナリオにも対応可能 | ○ | ◎ | × |
| CloudWatch Synthetics Canary | 高度なシナリオの監視が可能で、詳細なレポートを提供 | △ | ○ | ○ |
外形監視とは・なぜ必要か
いちど外形監視についておさらいをしましょう。
外形監視とは、以下のように、WebサイトやAPIのエンドポイントを対象に、利用するユーザー目線から正常に応答しているかを定期的にチェックする監視です。
サービスのレイテンシー増加やダウンへの初動対応が遅れると、ユーザー離れ、ひいては損失に繋がります。 そのため最近では、オブザーバビリティサービスを導入して、高機能な監視・運用を実現しているサービスが増えています。
ただしこれらオブザーバビリティサービスは非常に高価であることが多いです。そのため、Webサービスの規模が小さいケースなどでは、コスト収支が釣り合わずに導入に至らないことがあります。そういった事情がある中で、AWS内のネイティブなサービスを活用して、コストを抑えつつ、かつAWSサービス内で料金や管理を一まとめにしたいニーズも一方で増えています。
外形監視のアプローチ
3つのアプローチを、コスト効率が高いものから順にご紹介します。
1. Route53 ヘルスチェック
もっともシンプルな外形監視のアプローチです。Route53のヘルスチェック機能を使って、エンドポイントの可用性を監視します。
設定方法
Route53のコンソールから作成できます。
以下キャプチャが作成画面です。最小限の設定から、エンドポイントの監視が始められます。非常にシンプルですね。
ヘルスチェックの仕組み
デフォルト設定でWebサイトを監視する場合、以下条件をクリアすると正常と判定されます。
- 4秒以内にエンドポイントとTCP接続を確立する
- 接続後2秒以内に、2xx or 3xx ステータスコードで応答する
他にも、レスポンスボディに対する文字列一致による正常性判断の設定や、チェック対象のリージョン選択などをカスタマイズ可能です。詳細は、コンソールのヘルスチェック設定画面や以下公式ドキュメントを参照ください。
メリット・デメリット
◼︎メリット
- 導入や設定変更がシンプルで簡単
- コスト効率が高い（AWS以外のエンドポイントを対象とする場合、0.75もしくは2.0ドル/月 が発生します）
- ヘルスチェック結果の可視化・メトリクスの取得が容易
ヘルスチェックを作成すると、CloudWatchメトリクスと連携されて、キャプチャのようにヘルスチェック結果を確認することができます
◼︎デメリット
- 高度なヘルスチェックのカスタマイズが難しい
- チェック結果を保存するのが難しい
- アカウントで200件のチェックが上限（緩和申請可能）
2. Lambda（＋Step Functions）
Lambdaを使い、自前の実装によって監視します。また、ワークフローサービスのStep Functionsと組み合わせることによって、複数エンドポイントの一括監視や、監視結果に応じて他AWSサービスを呼び出すことができる、自由度がもっとも大きいアプローチです。
設定方法
通常のLambdaデプロイ（＋Step Functionsデプロイ）によって設定します。なお、ヘルスチェックのロジック（エンドポイントへのリクエスト、レスポンスの解析によるヘルスチェックの判定）は、自前で実装する必要があります。
メリット・デメリット
◼︎メリット
- APIキーやトークンを必要とするような、アクセス要件が特殊なエンドポイントに柔軟に対応可能
- 監視対象数が増えた場合に、コスト効率が高い（他2つは、エンドポイント数に比例して料金が増えるため）
- 自前の実装やStep Functionsとの組み合わせによって、自由にカスタマイズした監視＆サービス連携が可能 例えばですが、以下イメージのようなワークフローを組むことで、複数のサイトを一括に監視することや、判定結果のファイル保存、通知などが出来ます。
◼︎デメリット
- 実装が必要なため、導入や設定変更、メンテナンスが煩雑（他2つと比較して大きく手間が掛かる）
- ヘルスチェック結果の可視化・メトリクスの取得が、他のアプローチと比較して容易ではない
3. CloudWatch Synthetics Canary
WebサイトのUXやAPIの利用シナリオなど、実際の利用ケースに沿った監視を実現できる、簡単かつ高機能なアプローチです。
設定方法
対象リージョンで、コンソールからSynthetics Canaryを開きます。今回は、利用するケースが多いと思われます、ブループリントを使用した設定方法2つをご紹介します。
①ハートビートモニタリング
対象のエンドポイントを入力するだけで、ブラウザ操作できるPlaywrightやSelenuimを用いた、ページロードを行う監視スクリプトが作成されます。 ページロード主体の簡易な監視なので、複数エンドポイントを対象に指定することができます。 出力されたスクリプトをそのまま使うことも出来ますし、カスタマイズすることも可能です。
②Canaryレコーダー
ページロードをターゲットとするハートビートと比較して、ブラウザベースの利用者目線での監視できるメリットを活かせるのが、Canaryレコーダーです。 これはExcelマクロの記録と同じようなものです。つまり、ユーザーのブラウザ操作を記録して、その操作シナリオを監視します。
以下スクショのように、プラグインをインストール後、対象サイトを開いて操作を記録することができます。
レコーダーを起動 → 監視したいシナリオを操作 → レコーダーを終了 すると、以下のようなスクリプトが作成されます。これを貼り付ければ設定完了です。
メリット・デメリット
◼︎メリット
- 導入や設定変更が、シンプルなものから実装、レコーダーまであって幅広い
- ブラウザ操作/API利用を想定したシナリオを監視できるため、3つのアプローチにおいて、最も実際のユーザー利用体験に近い形で監視を実現できる
- メトリクス連携やアーティファクト保存ができて、実運用で必要となる
◼︎デメリット
- 他の2アプローチと比較して、コスト効率が低い（それでもサードパーティ製のオブザーバビリティサービスに比較すると比較的安いと思います）
0.0019ドル/Canary実行（東京リージョン）になります。1回当たりの課金のため、実行頻度によって月額料金が変化します。
- 1分おき → 84.8ドル/月（約13,600円/月）
- 10分おき → 8.5ドル/月（約1,360円/月）
各アプローチの比較・整理
改めて3つのアプローチを整理・比較してみます。
| アプローチ | 特徴 | 料金 | カスタマイズ性 | 手軽さ |
|---|---|---|---|---|
| Route53 ヘルスチェック | ①シンプルな設定 ②あくまでページロードレベルに限定 |
◎ | △ | ◎ |
| Lambda（＋Step Functions） | ①カスタマイズ性が高い ②SDKによってAWS他サービスやサードパーティと連携できる |
◯ | ◎ | × |
| CloudWatch Synthetics Canary | ①ユーザー利用体験に最も近い監視 ②機能と扱いやすさの両立 |
△ | ◯ | ◯ |
3つのアプローチいずれも、以下のような監視ケースで役立ちそうですね！
◼︎Route53 ヘルスチェックを採用するケース
- 一時的に開設したページを、とにかく安く監視したい
- ユーザー操作が少なく、コンテンツを見るためだけのページを監視したい
◼︎Lambda（＋Step Functions）を採用するケース
- 大量のサービスを一まとめに安価に監視したい
- レスポンスやチェック結果に応じて、別の処理/サービスを発火させたい
◼︎CloudWatch Synthetics Canaryを採用するケース
- ページロードだけでなく、ログインや投稿などといったユーザー操作も監視したい
まとめ
AWSサービスに完結した外形監視を実現するアプローチを整理・比較しました。 今回紹介した3つのアプローチは、コスト、カスタマイズ性、手軽さといった観点で異なる強みを持っています。したがって、以下のように状況に応じて選択すると良いと思います。
低コスト＆シンプルな監視 → Route 53ヘルスチェック
柔軟なカスタマイズが必要 → Lambda＋Step Functions
ユーザー視点のシナリオ監視 → CloudWatch Synthetics Canary
各プロジェクトの要件に合わせて、これらのサービスを使い分け、最適な外形監視を行いましょう。
