はじめに
URL監視でHTTPステータスコード200 OKの確認だけを、低コストで行いたいと思ったことはないでしょうか。私は下記のようなことを思ったことがあり、今回Route53ヘルスチェックとレイテンシーベースルーティングを利用し、低コストでURL監視を行う方法を考えてみました。
URL監視を利用しようとして思ったこと
- 合成監視（Synthetic Monitoring）のツールを使うと高い
- 自身で監視プログラムを作ったとしても実行環境が正常に動作しているかが心配
- 検知した後に、それをトリガーに何かしらの処理を実現したい
注意事項
本記事では、Route53ヘルスチェックの送信元を参照して、1つのヘルスチェックを分割する例を記載しております。通常、Route53ヘルスチェックを用いて静的安定性の確保を行う場合は、誤検知などがないように今回のような分割はせずに利用するべきだと思います。
レイテンシーベースルーティングの利用用途の一例としてお読みください。
一般的なRoute53ヘルスチェックによるURL監視
ALB4台に対して、Route53ヘルスチェックを利用し200 OKが返るかを監視したいとします。
一般的な監視の方法では、Route53ヘルスチェックを4つ利用しそれぞれのURLに対して監視を行います。
レイテンシーベースレコードを利用したURL監視
上記の監視コストを削減するため、Route53ヘルスチェックのURL監視にレイテンシーベースレコードを利用することで、1つのURL監視で4つのALBを監視する構成を考えてみました。
Route53ヘルスチェックのURL監視設定は、example.comの一つだけです。
対象のプロトコルはhttpsで、監視を行うURLと対象のALBが設定しているカスタムドメインのSSL証明書は別のFQDNとなりますが、Route53ヘルスチェックでは証明書の検証を行わないため、監視の動作に問題はありません。
何ができるのか
Route53のヘルスチェッカーが複数のリージョンにあることを利用し、レイテンシーベースルーティングでDNSクエリに対する回答をクライアントの位置をもとに制御します。
これにより、Route53ヘルスチェックの設定は１つのFQDNのみで、複数のALBの応答を確認することができます。
具体的な実施手順の例を示します。
- Route53ヘルスチェックでヘルスチェッカーを4つに設定（ここでは東京、シンガポール、シドニー、アイルランドを選択）
- レイテンシーベースレコードを利用して、ヘルスチェッカーの位置情報に基づいたDNS応答を行うように設定
Route53ヘルスチェックの仕組みはこちらをご確認ください。
実際に監視設定を作成してみた
レイテンシーベースレコード
※ レコード名は変更しています。
同一のレコードで別のルーティング先（ALB）にルーティングをしています。詳細ページではないと確認できませんが、それぞれのレコードはリージョンを東京、シンガポール、シドニー、アイルランドとしています。
ここで、すべてのALBがあるリージョンは、東京（ap-northeast-1）です。
上記のリージョン設定は、DNSのリゾルバがどのリージョンに近いかをもとに応答するレコードを制御するために利用されます。
ヘルスチェックを設定してしまうと、そのヘルスチェックに基づいて応答するレコードが変更されてしまうので、レイテンシーベースレコードにヘルスチェックは設定しません。
レコードはAliasAレコードとしてください。レイテンシーベースレコードであってもAliasレコードであればクエリに対する費用は掛かりません。
Route53ヘルスチェック
Route53ヘルスチェックを作成し、ヘルスチェックの状態を確認します。
行けてそうです！東京からはALB#1、シンガポールからはALB#2と、ヘルスチェッカーと確認先のALBを固定することができました。これで、ヘルスチェッカーから障害になったALBを判別できます。
ヘルスチェックでの検知確認
では、実際に障害を起こしてみましょう。
アイルランド想定のALB#4のSecurityGroupを外して、ヘルスチェックをNGにしてみました。
想定通り、アイルランドのヘルスチェックのみが落ちました！
監視方法
Route53ヘルスチェックが正常と判断するのは、ヘルスチェッカーの18%以上が正常である場合です。ALB4つに対して、1つが落ちただけではどうやってもNGにはなりません。
そこで、HealthCheckPercentageHealthyメトリクスを確認する方法が取れそうです。これは、名前の通りヘルスチェックの何パーセントが正常としているかを見るメトリクスですので、1/4台以上落ちた状態を想定し、80%以下になったらCloudwatchAlarmで検知してアクションを行うことで、ALBの監視を行います。
障害ALBの確認方法
上記のAlarmでは、どのレコードへのURL監視に問題があるかは分かりません。検知後にマネジメントコンソールにログインして確認してもよいですが、Route53のget-health-check-statusを利用することで、どのヘルスチェッカーからの監視が失敗しているかが分かります。紐づけを管理しておけば、CloudwatchAlarmをトリガーに、Lambdaを利用して対象のALBを特定することも可能です。
get-health-check-statusの表示例を下記に示します。
$ aws route53 get-health-check-status --health-check-id <Health-Check-ID> --output text
HEALTHCHECKOBSERVATIONS 15.177.54.111 ap-southeast-1
STATUSREPORT 2024-12-24T12:50:36.062000+00:00 Failure: HTTP Status Code 503, Service Temporarily Unavailable. Resolved IP: 15.168.xxx.xx
HEALTHCHECKOBSERVATIONS 15.177.58.64 ap-southeast-2
STATUSREPORT 2024-12-24T12:50:34.751000+00:00 Success: HTTP Status Code 200, OK. Resolved IP: 54.248.xxx.xx
HEALTHCHECKOBSERVATIONS 15.177.50.198 ap-southeast-1
STATUSREPORT 2024-12-24T12:50:20.969000+00:00 Success: HTTP Status Code 200, OK. Resolved IP: 54.248.xxx.xx
HEALTHCHECKOBSERVATIONS 15.177.46.65 ap-northeast-1
STATUSREPORT 2024-12-24T12:50:41.501000+00:00 Failure: HTTP Status Code 503, Service Temporarily Unavailable. Resolved IP: 15.168.xxx.xx
まとめと今後に向けて
- レイテンシーベースで、ヘルスチェックのリージョンに基づいて応答するレコードを制御することで、１つのRoute53ヘルスチェックで4台のALBの監視を行うことができました。
- ヘルスチェッカーのリージョンは8箇所あるため、レイテンシーベースレコードを増やせば8台のALBまで監視できそうです。※1つレイテンシーベースレコードに8つのAlias Aレコードの設定は可能でした。
- Cloudwatchでの検知をもとにLambda、SNSなどを組み合わせることで、対象の特定や通知を適切に行うことができます。※今回は実現しておりませんので、別途検証したいと思います。
以上、ご確認いただきありがとうございました。