障害から自動復旧するアーキテクチャの設計

1. 自己修復は「障害を自動で直す」だけではない

自己修復は、壊れたリソースを再起動するだけではありません。ユーザーへの影響を小さくするには、検知 → 隔離 → 置換 / 復旧 → サービスへ復帰 までを一続きで設計します。

ヘルスチェック
↓
異常判定
↓
ロードバランサーが新規トラフィックから除外
↓
Auto Scalingが置換インスタンスを起動
↓
ヘルスチェック通過
↓
トラフィックへ復帰

障害を検出した後に自動処理でリソースを再起動・削除・置換し、正常なキャパシティへ戻すところまでが自己修復です。

2. 自動復旧はヘルスチェックから始まる

自動化を用意していても、障害を検知できなければ復旧は開始できません。ヘルスチェックは単なる監視ではなく、復旧ワークフローのトリガー として扱います。

障害発生
     ↓
検知できない
     ↓
自動化起動しない
     ↓
ユーザーが先に障害を発見

監視間隔と障害検知時間は復旧時間へ直接影響するため、RTOを考える際にも検知時間を含めます。

3. 「サーバーが動いている」と「アプリケーションが正常」は違う

EC2インスタンス自体が正常でも、アプリケーション関数が失敗していることがあります。

EC2
稼働

OS
正常

ウェブ処理
起動中

しかし

データベース接続失敗
↓
アプリケーション APIは500 エラー

この場合、Amazon EC2 ステータスチェックでは正常でもアプリケーションとしては異常です。どの障害を検出する必要があるかからヘルスチェックのレイヤーを決めます。

4. ヘルスチェックはユーザーが必要とする機能を測る

例えば注文 APIのヘルスチェックが単にウェブサーバーから200を返すだけなら、データベース接続失敗を検出できない場合があります。

一方ですべての依存関係をヘルスチェックへ含めると、一時的な依存関係障害で大量の正常インスタンスを同時に異常扱いし、障害を拡大する可能性があります。

何を正常とするか
↓
どの障害ならトラフィックから外すべきか
↓
どの障害ならリソースを交換すべきか

自己修復では「ヘルスチェックを入れる」ことではなく、復旧アクションと整合する正常性シグナルを作ることが重要です。

5. ロードバランサーは異常対象をトラフィックから隔離する

Application Load Balancerなどは対象グループへヘルスチェックを行い、通常は正常対象だけへリクエストを送信します。

              ALB
          /  |    \
         /   |     \
        ▼      ▼      ▼
     EC2-A   EC2-B   EC2-C
     正常正常異常
       ▲       ▲
       └─ トラフィック ─┘

ロードバランサーの責任は、壊れた対象を修理することではなく、正常対象へトラフィックを振り分けることです。

6. ロードバランシングだけでは自己修復は完成しない

対象が3台あり1台故障した場合、ALBが故障対象を除外しても残り2台のままではキャパシティが減っています。

トラフィック分離
≠
キャパシティ復旧

そこでAuto Scalingを組み合わせ、希望するキャパシティを回復させます。

7. Auto Scalingは希望するキャパシティを回復する

Amazon EC2 Auto ScalingはAuto Scalingグループ内のインスタンス正常性を監視し、異常と判断したインスタンスを交換して希望するキャパシティを維持できます。

希望するキャパシティ = 3

EC2-A 正常
EC2-B 正常
EC2-C 異常
        ↓
Auto Scaling
        ↓
EC2-Cを置換
        ↓
EC2-D起動
        ↓
希望するキャパシティ = 3

Auto Scalingはトラフィック増加時のスケールアウトだけでなく、故障リソースの置換仕組みとしても重要です。

8. EC2 Auto Scalingはデフォルトではアプリケーション障害をすべて認識しない

Auto Scalingグループの基本正常性シグナルはAmazon EC2 ステータスチェックです。Application Load BalancerがHTTPヘルスチェック障害で対象を異常と判断していても、その結果をAuto Scalingの正常性判断へ利用する設定がなければ置換されません。

ALB
対象異常

しかし

Amazon EC2 ステータスチェック
正常

↓
ALB → トラフィックは送らない
Auto Scaling → インスタンスは交換しない

9. ELB ヘルスチェックをAuto Scalingへ連携する

アプリケーション障害を検出した対象も自動交換したいなら、Elastic Load Balancing ヘルスチェックをAuto Scalingグループの正常性判断へ組み込みます。

ALB 対象正常性
        ↓
EC2 Auto Scalingヘルスチェック
        ↓
異常判定
        ↓
インスタンス置換

これにより、検知 = ALBヘルスチェック / 隔離 = ALB / 置換 = Auto Scaling / 復元キャパシティ = 新しいインスタンス という自己修復ループが成立します。

10. ヘルスチェックの猶予期間は起動直後の誤判定を防ぐ

新しいインスタンスはEC2起動直後からアプリケーションリクエストを処理できるとは限りません。OS ブート、アプリケーション起動、依存関係接続、ウォームアップなどが必要です。

インスタンス起動
↓
まだアプリケーション準備中
↓
異常
↓
終了
↓
新インスタンス起動
↓
また異常

ヘルスチェックの猶予期間などを使い、正常な起動途中のリソースを障害と誤認しないようにします。検知速度と誤判定防止のバランスが必要です。

11. マルチAZでは正常キャパシティを別AZにも持つ

同じ障害ドメインだけに正常リソースを置くと、AZ障害時にすべて失う可能性があります。

             ALB
          /     \
         ▼         ▼
       AZ-A       AZ-B
       EC2-A      EC2-B

ロードバランサーは正常リソースへトラフィックを送り、Auto Scalingは正常キャパシティを維持します。インスタンス単位の置換だけでなく、障害ドメインを跨いでキャパシティを持つことが重要です。

12. 自己修復には障害範囲を合わせる

ヘルスチェックを1つ作るのではなく、障害範囲 → 検知範囲 → 復旧範囲 を一致させます。

13. リージョン単位の自動フェイルオーバーにはAmazon Route 53を利用できる

プライマリリージョン全体を利用できない障害では、同一リージョン内のAuto Scalingだけでは復旧できません。Amazon Route 53フェイルオーバールーティングを利用すると、プライマリの正常性に応じてセカンダリエンドポイントを返すアクティブ/パッシブフェイルオーバーを構成できます。

プライマリ正常
↓
プライマリへDNS応答

プライマリ異常
↓
セカンダリへDNS応答

フェイルオーバーを人間のDNS変更作業へ依存させず、場所単位の自動フェイルオーバーを構成できます。

14. Amazon Route 53フェイルオーバーはプライマリ / セカンダリで構成する

アクティブ/パッシブフェイルオーバーでは、同じレコード名 / タイプに対してプライマリレコードとセカンダリレコードを作ります。プライマリが正常ならプライマリ、プライマリが異常でセカンダリが正常ならセカンダリを返します。

example.com
     ↓
Amazon Route 53
     ↓
プライマリエイリアス → リージョン A ALB
セカンダリエイリアス → リージョン B ALB

15. エイリアスレコードでは評価対象正常性を利用できる

Amazon Route 53 エイリアスレコードがApplication Load BalancerなどのAWSリソースを参照している場合、評価対象正常性を利用してエイリアス対象の正常性をルーティング判断へ反映できます。

Amazon Route 53フェイルオーバーエイリアス
     ↓
評価対象正常性
     ↓
ALB 対象正常性
     ↓
プライマリ / セカンダリ判断

Amazon Route 53で別の独立ヘルスチェックを必ず作るという意味ではなく、エイリアス対象の正常性を利用できるケースを区別します。

16. Amazon Route 53 ヘルスチェックはDNSクエリごとに実行されるわけではない

Amazon Route 53 エンドポイントヘルスチェックはヘルスチェッカーが定期的にエンドポイントを監視します。ヘルスチェック間隔は10秒または30秒で設定でき、障害しきい値も正常性状態変更に影響します。

ヘルスチェッカー
↓ 定期監視
エンドポイント正常性状態
↓
Amazon Route 53 ルーティング判断
↓
DNS応答

ユーザー DNSクエリの瞬間にエンドポイントへヘルスチェックを実行しているわけではありません。

17. DNSフェイルオーバーは「瞬時の切り替え」ではない

自動フェイルオーバーでも障害発生から0秒で全クライアントがセカンダリへ移るわけではありません。

障害
↓
ヘルスチェック間隔
↓
障害しきい値
↓
Amazon Route 53が異常判定
↓
DNS応答変更
↓
Resolver / クライアントキャッシュ更新

フェイルオーバー時間には正常性検知時間とDNS TTL / DNSリゾルバーのキャッシュが影響します。RTOにはこの時間も含めて評価します。

18. 現行仕様：すべて異常なら「トラフィックを送らない」とは限らない

Application Load Balancerでは、対象グループ内のすべての対象がすべての有効なAZでヘルスチェックに失敗すると、フェイルオープンして異常対象にもトラフィックを送る場合があります。

Amazon Route 53フェイルオーバーでもプライマリとセカンダリの両方が異常の場合にはプライマリレコードが返される挙動があります。

通常時の主設計を変える知識ではありませんが、正常性ベースのルーティングにも最終障害モードがあることを理解しておきます。

19. 自己修復とフェイルオーバーは同じ責任ではない

自己修復は壊れたリソースを正常状態へ戻す処理、フェイルオーバーは利用できない場所から別の正常場所へトラフィックを移す処理です。

これらを組み合わせることで、障害範囲ごとの自動復旧アーキテクチャになります。

20. 自動復旧でも誤検知を考える

ヘルスチェックを敏感にしすぎると、一時的なネットワーク遅延や依存関係障害を恒久障害と誤認し、不要なフェイルオーバーや置換を繰り返す可能性があります。

一時的な障害
↓
異常
↓
フェイルオーバー
↓
すぐプライマリ正常
↓
フェイルバック
↓
再び障害

ヘルスチェック間隔、障害しきい値、猶予期間、フェイルバック条件を障害特性とRTOに合わせます。

21. 復旧自動化は検証可能である必要がある

自動化が設定されていることだけではなく、期待した障害で期待した検知・トラフィック切替・置換が起き、アプリケーションが正常へ戻ることを確認します。

障害を注入
↓
復旧を観測
↓
RTOを測定

自動復旧は設定しただけで完成ではありません。テスト済み・観測可能・再現可能な復旧ワークフローとして成立させます。

22. 代表シナリオ

企業は2つの可用性ゾーンにウェブアプリケーションを展開し、各AZのEC2がApplication Load Balancerの背後で動作しています。さらに別リージョンにも復旧環境があります。

アプリケーション 処理 障害
→ ユーザートラフィックから自動除外

壊れたEC2
→ 自動交換

1 AZ障害
→ 別AZで継続

プライマリリージョン障害
→ セカンダリリージョンへ自動トラフィック切替

この要件なら、ALBヘルスチェックでアプリケーション障害を検知し、ALBが異常対象を隔離、EC2 Auto ScalingがELB ヘルスチェックを利用してインスタンスを置換します。マルチAZでAZ障害へ耐え、Amazon Route 53フェイルオーバーと正常性評価でリージョン障害時にセカンダリへDNSフェイルオーバーします。

23. 混同ポイント

24. SAP-C02判断フロー

障害要件
        ↓
何が壊れる？
        ↓
インスタンス？ アプリケーション？ AZ？ リージョン？
        ↓
どのレイヤーで検知する？
        ↓
ヘルスチェック
        ↓
ユーザートラフィックへの影響をすぐ止める？
        ↓
負荷分散
        ↓
壊れたリソースを交換する？
        ↓
Auto Scaling
        ↓
ロケーション全体が利用不能？
        ↓
Amazon Route 53 自動フェイルオーバー
        ↓
復旧が本当に自動で成立するかテスト

25. まとめ

自動復旧アーキテクチャは、ヘルスチェック / ロードバランシング / Auto Scaling / Amazon Route 53というサービス名を並べることではありません。

ヘルスチェック
→ 検知

負荷分散
→ 隔離 / 正常対象へのルーティング

Auto Scaling
→ 置換 / 復元キャパシティ

Amazon Route 53
→ 拠点間フェイルオーバー

全体
→ 自己修復

最も重要なのは、障害範囲に合った正常性シグナルを使い、トラフィックを正常リソースへ逃がし、壊れたリソースを自動修復し、必要なら別場所へ切り替えることです。

26. 主要AWS公式資料

• AWS Well-Architected — 障害管理
• AWS Well-Architected — 自動化された復旧
• Amazon EC2 Auto Scaling — 正常性チェック
• Application Load Balancer — 対象の正常性チェック
• Amazon Route 53 — フェイルオーバーエイリアスレコード
• Amazon Route 53 — 正常性評価とレコード選択