Route 53のヘルスチェック機能を使用してDNSフェイルオーバー(アクティブ/パッシブ)が出来ることは知っていましたが、実際にどの程度の時間で切り替えられるかを知らなかったので実際に測定したほうが早いと思い検証してみました。
前提
そこそこ厳しめのRPO/RTOが要求されるシステムでの採用を検討しているため、最短での切り替えを目指します。
以下のような構成で切り替え時間を計測します。
EC2
非機能要件の制約でRDSを利用できないと仮定して、Mariadb on EC2を2台でレプリケーションを構成します。
監視方法
CloudWatch AgentのProcstatプラグインでmariadbのプロセスを監視します。
メトリクスのインターバルは60秒とします。
CloudWatch Alarm
Procstatプラグイン収集したメトリクスに対してCloudWatch Alarmを設定します。
Route 53ヘルスチェック側で高解像度メトリクスに対応していないため、メトリクスの期間はAgentのインターバルと同様に60秒とします。
このアラームがmariadbの異常を検知し、Route 53のヘルスチェックに反映させるためのトリガーとして機能します。
Route 53 ヘルスチェック
上記で作成したCloudWatch AlarmをモニタリングするRoute 53 ヘルスチェックを作成します。
フェイルオーバーレコード
Route 53 プライベートホストゾーンを作成してプライマリ/セカンダリのフェイルオーバーレコードを作成します。
キャッシュによる影響を極力減らすためにTTLは0秒としておきます。
ただし、TTLを極端に短く設定するとRoute 53の料金が高額になる可能性があるため注意です。
切り替え検証
EC2のmariadbを手動停止したタイミングでタイマーをスタートします。
同一VPC内のEC2からRoute 53 Resolver経由でdigを叩いて切り替え時間を計測します。
ログやアラーム等から確認を試みましたが、秒単位の精度で計測が難しそうだったため、人力による原始的な方法で計測することにしました。
検証結果
10回ほど計測した結果はこちらです。
| 切り替え時間(秒) |
|---|
| 2:03 |
| 2:39 |
| 1:58 |
| 4:56 |
| 1:39 |
| 1:51 |
| 1:55 |
| 1:42 |
| 1:30 |
| 1:57 |
最も早い切り替え時間が1:30
最も遅い切り替え時間は4:56という結果となりました。
上振れて遅かった4:56秒については、CloudWatch Alarm側ですぐに異常を検知していましたが、ヘルスチェック側の反応が遅れているような挙動でした。
このような原因不明の外れ値を除けば、プロセス停止から概ね1:30~:2:30で切り替わる傾向が見られました。切り替え時間のばらつきもCloudWatchインターバル(60秒)内で収まっているようです。
まとめ
今回の検証で、1:30〜2:30程度で切り替えが行われることを確認できました。
ただし、再現性と原因も不明ですが、まれに切り替え時間が遅くなることもあるため、厳密なRPO/RTOが求められるようなシステムでの採用は慎重に検討したほうが良さそうです。
また、TTLを短くしすぎるとRoute 53の料金が高額になるリスクもある点はご注意ください。今回の検証ではTTLを0秒に設定しましたが、本番環境では60秒以下で適切な値を設定することをお勧めします。
とはいえ、DNSフェイルオーバー設定自体も容易ですし、CloudWatchをトリガーにすることができるため採用の幅はとても広いのかなと思いました。AWSが提供しているCloudWatch推奨アラーム等を参考にするのも良さそうですね。
参考
CloudWatch 推奨アラーム
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Best_Practice_Recommended_Alarms_AWS_Services.html