Route 53によるService Continuity

1. トラフィック 切り替えより先に正常性シグナルを選ぶ

フェイルオーバールーティングのプライマリ / セカンダリという基本構成だけでは、どの障害で切り替えるべきかは決まりません。サービス継続性では、障害範囲に合う正常性シグナルを選びます。

2. 計算済みヘルスチェックで複数シグナルを集約する

1つのエンドポイントだけではサービス正常性を表現できない場合、計算済みヘルスチェックで複数の子ヘルスチェックを集約できます。

API 正常性 ───────┐
データベース経路 ────┼─→ 計算済みヘルスチェック
依存関係正常性 ┘

必要数以上が正常
        ↓
親ヘルスチェック = 正常

「どれか1つ失敗したらフェイルオーバー」なのか、「複数系統のうち一定数が生きていれば継続」なのかをビジネス要件に合わせます。単純なエンドポイント到達性より、サービス全体の利用可能性を表現しやすくなります。

3. プライベートエンドポイントはCloudWatchのデータストリームで正常性を表現する

Amazon Route 53の正常性 チェッカーはVPC内のプライベート IPへ直接到達する仕組みではありません。プライベートエンドポイントの状態をフェイルオーバー判断へ使う場合は、アプリケーションや依存関係のメトリクスをCloudWatchへ出し、そのアラームデータストリームをAmazon Route 53 ヘルスチェックで評価する構成を検討します。

プライベートアプリケーション
↓
CloudWatch メトリクス
↓
サポート対象 CloudWatch アラームデータストリーム
↓
Amazon Route 53 ヘルスチェック
↓
フェイルオーバールーティング

ただし、CloudWatchで作成できるアラームがすべてAmazon Route 53 ヘルスチェックの入力になるわけではありません。ヘルスチェックとアラームは同じAWSアカウントに置き、標準解像度メトリクスと基本統計を前提にします。N個中M個のアラーム、メトリクス計算、高解像度メトリクス、拡張統計を利用するアラームはこの連携の候補にしません。

4. ヘルスチェック対象とDNS レコード対象は同じとは限らない

非エイリアスレコードへヘルスチェックを関連付けても、Amazon Route 53がレコード値を自動的に監視対象へ変換するわけではありません。ヘルスチェックで指定したエンドポイントの状態が、そのレコードをルーティング候補として扱うかどうかに使われます。

DNS レコード
example.com → 203.0.113.10

関連付けられたヘルスチェック
監視 → 正常性.example.internal / 198.51.100.20

ヘルスチェック対象の状態
        ↓
203.0.113.10をDNS 答え候補として扱うか判断

ヘルスチェックエンドポイントが実際のビジネストランザクションの可用性を正しく代表しているかを確認します。レコード名そのものと同じドメイン名前をヘルスチェックへ安易に指定すると、構成によっては予測しにくい評価になるため、監視用エンドポイントを明確に分離します。

5. エイリアス対象の正常性 評価をルーティング判断へ組み込む

エイリアス対象の正常性をルーティング判断へ反映する基本は既存の自己修復設計と同じです。ここではサービス継続性固有の障害モードだけ確認します。

ALB / NLBでは、対象を持つ対象グループに正常対象が存在するかがエイリアス対象の正常性へ影響し、登録済みターゲットが0件の対象グループも異常として評価されます。したがって「ロードバランサー リソースが存在する」だけでは正常とは限りません。

6. 明示的ヘルスチェックと評価対象正常性を併用するとAND条件になる

エイリアスレコードには、独立したAmazon Route 53 ヘルスチェックを関連付けつつ、Evaluate Target Health = Yesも設定できます。

エイリアスレコード正常性
=
明示的Amazon Route 53 ヘルスチェック
AND
エイリアス対象正常性

どちらか一方だけが正常でも、そのエイリアスレコードを正常として扱う条件を満たしません。アプリケーションレベルシグナルとインフラストラクチャレベルシグナルを両方満たしたときだけトラフィックを流したい場合に、このAND関係を理解して設計します。

7. セカンダリヘルスチェックの有無で障害モードが変わる

セカンダリレコードへヘルスチェックを付けるかどうかは運用上の意味を持ちます。

セカンダリヘルスチェックを省略することは、「セカンダリが正常であることをAmazon Route 53が保証する」という意味ではありません。また両方異常でもDNS 答えが消えるわけではないため、両サイト異常をDNSだけで解決しようとしません。

8. TTLは非エイリアスとエイリアスで設計方法が異なる

DNS キャッシュがトラフィック 切り替えの反映速度へ影響する点は同じでも、TTLの設定方法はレコードタイプで異なります。

したがって「フェイルオーバーを速くしたいからエイリアスレコードのTTLを10秒へ変更する」という設計はできません。どのレコードタイプ / エイリアス対象を使うかまで含めてDNS キャッシュの影響を評価します。

9. DNS 答え変更と接続復旧を分離する

Amazon Route 53が切り替えるのはDNS 答えです。新しい名前解決は復旧先へ誘導できますが、障害前から確立済みのTCP 接続やアプリケーションセッションをセカンダリへ移送する機能ではありません。

DNS フェイルオーバー
→ 新しい DNS名前解決の宛先を変更

既存接続
→ 切断 / タイムアウト / 再試行 / 再接続はアプリケーション側の動作

RTOを評価するときは、正常性 評価とDNS キャッシュだけでなく、クライアント / アプリケーションの再試行、接続再確立、セッション状態も確認します。

10. プライマリ復旧時の正常性シグナルはフェイルバックゲートになる

フェイルオーバールーティングではプライマリが再び正常になればプライマリが優先されます。だからこそ、プライマリを正常へ戻す条件は「プロセスが起動した」だけでは不十分な場合があります。

プライマリインフラストラクチャ復旧
↓
データ / 依存関係 / アプリケーション状態確認
↓
ビジネストランザクションを処理可能
↓
正常性シグナル = 正常
↓
Amazon Route 53でプライマリが再び優先

データ整合性確認や依存関係復旧が終わる前に正常と判定すると、トラフィックが早すぎる段階でプライマリへ戻る可能性があります。正常性シグナルをフェイルバックのゲートとして設計します。

11. DNS トラフィック 切り替えだけではサービス継続性は完成しない

Amazon Route 53は復旧サイトを作成しません。セカンダリへトラフィックを送った後にビジネストランザクションを処理できることが前提です。

セカンダリサイト
├─ アプリケーション
├─ データ
├─ ネットワーク
├─ シークレット / KMS
├─ 依存関係
└─ キャパシティ
        ↓
正常性シグナルが復旧可能性を表す
        ↓
Amazon Route 53 トラフィック 切り替え
        ↓
ビジネスサービス復旧

DNSはエンドツーエンド復旧経路の一部です。データベースレプリケーション、バックアップ復元、コンピューティングキャパシティ、依存関係復旧をAmazon Route 53へ期待しません。

12. サービス継続性の判断フロー

障害範囲 / RTO
        ↓
復旧サイトはビジネストランザクションを処理可能か
        ↓
何を正常と判断するか
├─ パブリックエンドポイント
├─ 複数 シグナル → 計算済み
├─ プライベート / メトリクス → CloudWatch データストリーム
└─ AWS エイリアス対象 → 評価対象正常性
        ↓
明示的ヘルスチェックも併用するか
        ↓
セカンダリヘルスチェックを付けるか
        ↓
エイリアス / 非エイリアスとTTL 動作を確認
        ↓
DNS キャッシュ + 再試行 / 再接続を評価
        ↓
フェイルオーバー / フェイルバック時に
ビジネス RTOを満たすか

13. 混同ポイント

14. まとめ

Amazon Route 53をビジネス継続性へ組み込むときは、フェイルオーバールーティングという機能名よりも正常性シグナルが復旧可能性を正しく表しているかを重視します。

• 複数シグナルは計算済みヘルスチェックで集約できる。
• プライベートエンドポイントは対応するCloudWatch アラームデータストリームを利用できるが、クロスアカウント、N個中M個、メトリクス計算、高解像度等のアラームはヘルスチェック入力にできない。
• ヘルスチェック対象とDNS レコード対象は独立して設計する。
• エイリアスでは評価対象正常性を利用し、明示的ヘルスチェックとの併用時はAND条件になる。
• セカンダリヘルスチェックの有無と両方異常時の挙動を障害モードとして理解する。
• エイリアス / 非エイリアスでTTLの設定方法が異なる。
• DNS 答え変更と既存接続復旧は別責任である。
• プライマリへ戻す正常性シグナルはデータ / 依存関係を含むフェイルバックゲートとして設計する。

15. 主要AWS公式資料

• Amazon Route 53 — ヘルスチェックが正常かを判断する仕組み
• Amazon Route 53 — 正常性チェック設定時のレコード選択
• Amazon Route 53 — フェイルオーバーエイリアスレコードの値
• Amazon Route 53 — エイリアスレコードと非エイリアスレコードの選択
• Amazon Route 53 — 正常性チェックの種類