セルフヒーリングアーキテクチャ設計入門｜クラウドの自己修復パターンとAWS実装で障害を自動回復させる実践ガイド

オンプレミス環境では、サーバーが落ちたら当直エンジニアへのアラートが鳴り、ログを確認してプロセスを再起動し、復旧後に報告書を書いて——という流れが当たり前でした。深夜2時に電話がかかってきた記憶のある方も多いはずです。

クラウドに移行しても同じ運用を続けていると、そのメリットを十分に活かせません。AWSをはじめとするクラウドプラットフォームには、障害を検知して人手なしに自動回復する「セルフヒーリング（自己修復）」の仕組みが複数のレイヤーに組み込まれています。

この記事では、セルフヒーリングアーキテクチャの設計思想と、AWSでの具体的な実装パターンをオンプレ経験者向けに整理します。設計の注意点や、陥りやすい「復旧ループ問題」まで踏み込んで解説します。

なぜセルフヒーリングが必要か？オンプレとクラウドの根本的な違い

オンプレミスの世界では、サーバーは物理的な資産です。1台が壊れれば修理または交換するしかなく、その間は代替機を手配するか縮退運転で耐えるかのどちらかです。このモデルでは「障害を防ぐこと」が最優先であり、冗長化もハードウェアの予備購入という形で実現されます。

クラウドでは考え方が根本的に変わります。AWSの設計思想を一言で言うなら「障害は起きるもの。起きたとき自動で回復できる設計にする」です。EC2インスタンスは仮想マシンなので、いつでも起動・廃棄できます。この特性を活かし、問題のあるインスタンスを強制終了して新しいインスタンスに置き換える方が、壊れたインスタンスを修復しようとするよりずっと速く確実です。

この「捨てて作り直す」思想をクラウド全体に応用したのがセルフヒーリングアーキテクチャです。

自己修復アーキテクチャの3つのレイヤー

セルフヒーリングは、インフラの異なる層でそれぞれ実装します。この3層を意識することが設計の出発点になります。

オンプレだと「サーバー担当」「アプリ担当」「DB担当」が別々に手動対応していた部分が、クラウドではそれぞれ自動化できます。

AWSでの実装パターン

1. インスタンスレイヤー：EC2 Auto RecoveryとAuto Scaling

EC2には「Auto Recovery」機能が組み込まれています。ハードウェア障害やネットワーク異常でインスタンスが応答しなくなった場合、CloudWatchアラームが検知し、別のホストに自動でインスタンスを再配置します。設定は単純で、CloudWatchアラームの「アクション」にAuto Recoveryを指定するだけです。

# AWS CLI: EC2 Auto Recovery アラーム設定例
aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-AutoRecovery-i-0abc123" \
  --namespace AWS/EC2 \
  --metric-name StatusCheckFailed_System \
  --dimensions Name=InstanceId,Value=i-0abc123 \
  --statistic Minimum \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions "arn:aws:automate:ap-northeast-1:ec2:recover"

ただし、Auto Recoveryはインスタンスを同一AZで再起動するだけです。AZ全体の障害（まれですが発生します）には対応できません。それをカバーするのがAmazon EC2 Auto Scalingです。Auto Scalingグループの「ヘルスチェック」で不健全なインスタンスを検知すると、そのインスタンスを終了して別のAZに新しいインスタンスを自動起動します。

2. アプリケーションレイヤー：ELBヘルスチェックとLambda自動修復

インスタンスが起動していても、その上のアプリケーションプロセスがクラッシュしていては意味がありません。Application Load Balancer（ALB）のヘルスチェックは、特定のHTTPエンドポイントに定期的にリクエストを送り、200番以外のレスポンスや無応答が続いた場合にそのターゲットをトラフィック対象から除外します。

これをAuto Scalingと組み合わせると、「ELBヘルスチェック失敗 → Auto Scalingがインスタンスを終了・再生成」という自動回復フローが完成します。

さらに、より細かい自動修復が必要な場合はLambda + EventBridgeを組み合わせます。

Amazon CloudWatchでアプリケーションのカスタムメトリクスを監視し、閾値を超えたらEventBridgeルールが発火してLambda関数を呼び出す構成です。Lambda関数の中でSSM Run CommandやSystems Manager Automation Runbookを実行し、プロセス再起動やキャッシュクリアなど任意の修復処理を自動化できます。

# 自動修復フロー概要（例: アプリプロセスが停止した場合）
# 1. EC2上のカスタムメトリクス送信: プロセス生存チェック → CloudWatch へ 0/1 値を送信
# 2. CloudWatch アラーム: 値が 0 に 1分以上 → ALARM 状態
# 3. EventBridge: ALARM 状態を検知 → Lambda 関数を呼び出し
# 4. Lambda: SSM Send Command で EC2 の systemd サービスを再起動

3. データレイヤー：RDS Multi-AZとAurora

データベースのセルフヒーリングは特に重要です。オンプレミスではDBの切り替えにDBAが手動で関与することが多く、復旧まで数十分かかるケースもありました。

Amazon RDSのMulti-AZ構成では、プライマリインスタンスの障害を検知してから通常60秒以内にスタンバイへのフェールオーバーが完了します。接続エンドポイント（DNSレコード）が自動で書き換わるため、アプリケーション側はエンドポイントを変更する必要がありません。

Amazon Auroraはさらに進んでおり、リードレプリカを複数持つ構成では、プライマリ障害時にリードレプリカを自動でプライマリに昇格させます。フェールオーバー時間は20秒以内が目安です（実際の値は執筆時点の公式ドキュメント参照）。

設計の注意点：復旧ループとフラッピングを防ぐ

セルフヒーリングを実装する上で最も気をつけるべき落とし穴が「復旧ループ」です。これは、修復処理が完了してもすぐに同じ障害が再発するサイクルが繰り返される状態です。

典型的な失敗例を示します。

・アプリケーションに不具合があり、起動直後に必ずクラッシュする状態になっている
・Auto Scalingがインスタンスを終了→新規起動を繰り返す
・新しいインスタンスも同じコードで起動するためすぐクラッシュ
・また終了→起動のループに入る

これを防ぐには以下の設計を組み合わせます。

Cooldown（冷却期間）の設定
Auto Scalingのスケーリングポリシーに適切なCooldown期間を設け、短時間に連続して再起動が繰り返されないようにします。

起動失敗回数の上限設定
ECS サービスでは、タスクが連続して一定回数起動失敗するとサービスを「Stopped」状態に移行させる「サーキットブレーカー」機能があります。無限ループを防ぐ有効な仕組みです。Auto Scalingグループも、ヘルスチェック失敗が続く場合のアクション上限を設定できます。

サーキットブレーカーパターンとの組み合わせ
マイクロサービス間の呼び出しに対してもサーキットブレーカーを実装し、依存先サービスの異常が自サービスへ連鎖することを防ぎます。

フラッピング（頻繁な状態変化）の抑制
CloudWatchアラームの評価期間（evaluation periods）を短く設定しすぎると、一時的な負荷スパイクで何度もアラームのON/OFFが繰り返されます。評価期間と閾値は、実際の障害パターンに合わせて慎重に設定してください。

SLO・SLIとの連携：「どこまで自動化するか」の判断基準

セルフヒーリングはすべての障害に対して自動修復すればよい、というものではありません。SLO（サービスレベル目標）とSLI（サービスレベル指標）を定義した上で、「自動修復が適切なケース」と「人間が判断すべきケース」を明確に分けることが重要です。

自動修復が適切なケース
・インスタンス/コンテナのクラッシュ（コードに問題がなく、インフラ起因の場合）
・DBフェールオーバー（Multi-AZ構成で許容）
・ELBヘルスチェック失敗による対象切り離し

人間が判断すべきケース
・コードの不具合に起因するクラッシュ（自動修復しても再発する）
・データ破損が疑われる場合（フェールオーバー先も同じ問題を持つ可能性）
・セキュリティインシデントの可能性がある異常

自動修復が発動したら必ずアラートを送り、エンジニアに通知することも忘れてはいけません。静かに回復して誰も気づかないままでは、根本原因の修正が後回しになります。

コストへの影響

セルフヒーリング構成を採用するとコストが増える部分があります。代表的な箇所を確認しておきます。

・Multi-AZ RDS: スタンバイインスタンスの料金が加算される。プライマリと同スペックのインスタンスが常時起動するため、シングルAZ比で約2倍のインスタンス費用
・Auto Scalingの最小台数: 冗長性を確保するため、最小2台以上の設定が必要になることが多い
・CloudWatch カスタムメトリクス: 独自メトリクスを送信する場合、1メトリクスあたり月額$0.30（2026年3月時点）が加算される
・Lambda + EventBridge自動修復: 修復実行頻度が低ければ、無料枠内に収まることが多い

AWS Resilience Hubを使うと、現在のアーキテクチャの回復力をRPO/RTO目標に対して自動評価できます。コストとの兼ね合いで「どこまで自動化すべきか」を数値で判断する際に役立ちます。

本記事のまとめ

セルフヒーリングアーキテクチャの要点を整理します。

クラウドでのセルフヒーリング実装で特に大切なのは次の3点です。

・3つのレイヤー（インスタンス・アプリ・データ）それぞれに適切な自動回復を設ける
・復旧ループを防ぐClooldown・サーキットブレーカー・回数上限を組み合わせる
・自動修復が発動したら必ずエンジニアに通知し、根本原因の把握を続ける

「障害が起きないシステム」を目指すよりも、「障害が起きても自動で回復し、影響を最小化できるシステム」を目指す——これがクラウド時代の設計思想です。カオスエンジニアリング（AWS Fault Injection Serviceで実装できます）を使えば、自動回復の動作を本番前に意図的に検証することもできます。ぜひ自動修復設計の精度を高める手段として取り入れてみてください。