はじめに
先日、あるリソースに対してRoute53でヘルスチェックを行い、そのヘルスチェック結果を示すメトリクスをEC2から監視する仕組みを試していました。
しかし当該メトリクスを上手く取得できず、少々ハマりました。
結論、「メトリクスが送信されるリージョン」の考慮不足が原因でした。
本記事では、発生した事象とその原因、解決方法を整理します。
なお、Routet53だけでなく、CloudFrontなど他のグローバルサービスでも同様に注意が必要です。
正確には、異なるリージョンのメトリクスを取得する際に考慮すべき事項です。
グローバルサービスの場合は特に見落としやすいので、本記事でフォーカスしていますが、「グローバルサービス」を「他リージョンのサービス」と読み替えても同様です。
本記事は私の実体験をもとに、解決案や構成を示しています。
要件やシステム構成によって適切な解決案は異なるので、ご参考情報として読んでいただければと思います。
対象読者
- Route53,CloudFront等のAWSグローバルサービスを利用中/予定の方
- それらグローバルサービスのメトリクスを取得/監視する仕組みを取り入れようとしている方
起こった事象
構成要素
下記のように各リソースを構築していました。
なお、AZレベルのサービスは耐障害性を考慮してマルチAZ構成としました。
（図ではマルチAZなどの記載は省略しています）
| リソース | サービスの範囲 | 構築したリージョン | サブネット種別 |
|---|---|---|---|
| Route53 | グローバル | ー | ー |
| インターネット公開するリソース | AZレベル | 東京 | パブリック |
| 運用管理用EC2 | AZレベル | 東京 | プライベート |
| CloudWatch | リージョンレベル | 東京 | ー |
| CloudWatch用 VPCエンドポイント |
AZレベル | 東京 | プライベート |
やりたかったこと
-
インターネット公開するリソースに対してRoute53でヘルスチェックを実施し、フェイルオーバールーティングを実装 - ヘルスチェックの結果を
運用管理用EC2から監視 - それにより、障害でヘルスチェックNGとなった際(=フェイルオーバー発生時)に気付ける仕組みとする
なお運用管理用EC2から監視する理由は、運用管理用EC2にインストールした運用管理ソフトで管理したかったためです。
上記実現のため、 CloudWatch用VPCエンドポイント経由で、運用管理用EC2からCloudWatch API(GetMetricStatistics)を叩き、Route53メトリクス(HealthCheckStatus)を取得しようとしました。
しかし、Route53メトリクスは取得できませんでした。
原因
調査したところ、Route53メトリクスはバージニア北部のCloudWatchに送信されるとのこと。
現在のリージョンを米国東部 (バージニア北部) に変更します。
それ以外のリージョンを現在のリージョンとして選択した場合、Route 53 のメトリクスは利用できません。
つまり正確に記載すると下記であり、東京リージョンのCloudWatchではなく、バージニア北部のCloudWatchまで取得しに行く必要がありました。
| リソース | サービスの範囲 | 構築したリージョン | サブネット種別 |
|---|---|---|---|
| Route53 | グローバル | ー | ー |
| インターネット公開するリソース | AZレベル | 東京 | パブリック |
| 運用管理用EC2 | AZレベル | 東京 | プライベート |
| CloudWatch(東京) | リージョンレベル | 東京 | ー |
| CloudWatch(東京)用 VPCエンドポイント |
AZレベル | 東京 | プライベート |
| CloudWatch(バージニア北部) | リージョンレベル | バージニア北部 | ー |
なるほど、グローバルサービスって、メトリクスはグローバルじゃないのか…
ちなみに、CloudFrontのメトリクスも同様で、バージニア北部のみで利用可能なよう。
CloudFront はグローバルサービスであるため、サービスのメトリクスは米国東部 (バージニア北部) に送信されます。
解決案
解決案として、ざっと以下の３通りが考えられます。
※もちろん他の方法もありますが、代表的と思われるものをピックアップ
本システム構成の場合における、各案の採用/非採用も記載していますが、あくまでもご参考として読んでいただければと思います。
案A．インターネット経由で取得
-
運用管理用EC2からインターネット経由でCloudWatch(バージニア北部)へアクセス
しかし、運用管理用EC2は現状インターネット接続しておらず、セキュリティ的にむやみにインターネットへ晒したくないので不採用としました。
ちなみに、実際には運用管理用EC2とCloudWatch(バージニア北部)の通信はAWS管理のネットワーク上を通り、インターネットには出ないようです。
2つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックなAWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
案B．バージニア北部にVPCエンドポイントを作成
-
CloudWatch(バージニア北部)用VPCエンドポイントを作成 - 東京リージョンとバージニア北部リージョンをVPCピアリング等で繋ぎ、プライベートな経路を確立
-
運用管理用EC2から上記経路経由でCloudWatch(バージニア北部)へアクセス
しかし、このためだけにバージニア北部にVPC・サブネットを新規作成すると管理の手間も増えます。
また、インタフェース型VPCエンドポイントは作成するだけで、時間に応じた料金がかかってしまうので不採用としました。
案C．EventBridgeで東京リージョンへ情報連携
-
CloudWatch(バージニア北部)で、Route53メトリクスの状態遷移に反応するCloudWatchAlarmを作成 - このCloudWatchAlarmをトリガーとし、
EventBridge(バージニア北部)およびEventBridge(東京リージョン)で東京リージョンに連携 - さらに「東京リージョンのCloudWatchLogsに出力するルール」を
EventBridge(東京リージョン)に作成 - CloudWatchLogsに出力された情報を、
CloudWatchLogs(東京)用VPCエンドポイント経由で運用管理用EC2から取得
なお本システムでは、たまたま別要件でCloudWatchLogs(東京)用VPCエンドポイントを構築済だったため、「東京リージョンのCloudWatchLogsに出力するルール」としました。
システム構成によっては、また違ったルールの方が適するかもしれません。
本システムにとっては、この案が構成変更を少なく実装できる状況だっため、案Cを採用しました。
最終的な構成
構成要素
最終的に、下記の構成としました。
| リソース | サービスの範囲 | 構築したリージョン | サブネット種別 |
|---|---|---|---|
| Route53 | グローバル | ー | ー |
| インターネット公開するリソース | AZレベル | 東京 | パブリック |
| 運用管理用EC2 | AZレベル | 東京 | プライベート |
| CloudWatch(東京) | リージョンレベル | 東京 | ー |
| CloudWatchLogs(東京)用 VPCエンドポイント |
AZレベル | 東京 | プライベート |
| EventBridge(東京) | リージョンレベル | 東京 | ー |
| CloudWatch(バージニア北部) | リージョンレベル | バージニア北部 | ー |
| EventBridge(バージニア北部) | リージョンレベル | バージニア北部 | ー |
障害検知までの動き
障害発生時は下記の流れでリレー形式で情報が運ばれ、運用管理用EC2で検知できます。
-
Route53のヘルスチェックが失敗 -
CloudWatch(バージニア北部)のRoute53メトリクス(HealthCheckStatus)の状態が変化 -
CloudWatch(バージニア北部)のCloudWatchAlarmが状態変化を検知、EventBridge(バージニア北部)のイベントバスに状態変化したことを送信 -
EventBridge(バージニア北部)のルールがトリガーされ、EventBridge(東京)のイベントバスに状態変化したことを送信 -
EventBridge(東京)のルールがトリガーされ、CloudWatch(東京)のCloudWatchLogsに状態変化したことを出力 -
運用管理用EC2がCloudWatchLogsを定期的に監視し、状態変化を検知
上記は状態変化をトリガに動くため、正常→障害の時だけでなく、障害→正常に戻ったときも検知できます。
晴れて、インターネット公開するリソースの正常性を運用管理用EC2から監視することができました。
まとめ
・Route53やCloudFrontなどのグローバルサービスでは、メトリクスはバージニア北部のCloudWatchに送信される
・その場合、バージニア北部のCloudWatchまで取得しに行かなくてはいけない(案A,B)
・あるいは、EventBridgeで自分のリージョンまで情報を運んであげる(案C)
グローバルサービスと言われるとどのリージョンからでも使えるような気がしてしまいます。
しかしメトリクスはグローバルではない場合があるので、AWS公式ドキュメント等で「メトリクスが送信されるリージョン」をちゃんと確認しておくと安心ですね。