フェイルオーバー

フェイルオーバーとは

フェイルオーバー (Failover) は、プライマリシステムに障害が発生した際に、スタンバイシステムへ自動的に切り替えてサービスを継続する仕組みである。ダウンタイムを最小化し、高可用性 (HA) を実現する。

フェイルオーバーの種類

フェイルオーバーの種類を以下にまとめる。

種類	切り替え時間	コスト	例
ホットスタンバイ	数秒〜数分	高い (常時稼働)	RDS Multi-AZ・ElastiCache (Redis)
ウォームスタンバイ	分単位	中程度	EC2 + AMI
コールドスタンバイ	時間単位	低い (停止状態)	バックアップからの復元

同じホットスタンバイでも、切り替えに要する時間は製品によって桁が変わる。レプリカの昇格だけで済む ElastiCache (Redis) は数秒、スタンバイの昇格に DNS の切り替えとリカバリ処理を伴う RDS Multi-AZ は 60〜120 秒が目安である。表の時間は桁の目安として読み、設計時は採用する製品の公式ドキュメントの値を当たる。

RDS Multi-AZ フェイルオーバー

RDS Multi-AZ フェイルオーバーを図で示す。

通常時:
  アプリ → プライマリ DB (AZ-a) ← 同期レプリケーション → スタンバイ DB (AZ-c)

障害時:
  アプリ → スタンバイ DB (AZ-c) が新プライマリに昇格 (60〜120 秒)

AWS は切り替え時間の目安を 60〜120 秒としており、大きなトランザクションや長いリカバリ処理が走ると伸びる (2026 年 8 月時点のドキュメント)。

エンドポイント名は変わらないため、アプリケーションの接続先設定を書き換える必要はない。ただし切り替えではエンドポイントが指す IP アドレスが差し替わるため、既存のコネクションは張り直しになる。DNS の結果を長く抱えるクライアントは旧 IP をつかみ続ける。JVM は設定次第で DNS 解決結果をほぼ無期限にキャッシュするため、AWS は networkaddress.cache.ttl を 60 秒以下にすることを推奨している。

Route 53 ヘルスチェック + フェイルオーバー

Route 53 ヘルスチェック + フェイルオーバーを図で示す。

Route 53 (フェイルオーバールーティング)
  ├── プライマリ: ALB (ap-northeast-1) ← ヘルスチェック OK
  └── セカンダリ: S3 静的サイト (sorry ページ)

プライマリのヘルスチェックが失敗 → セカンダリに自動切り替え

Aurora のフェイルオーバー

Aurora はリーダーインスタンスをライターに昇格させる方式のため、RDS Multi-AZ より短い時間で切り替わる。公式ドキュメントの表現は「通常 60 秒未満、多くの場合 30 秒未満で復旧」であり、30 秒は保証された上限ではない (2026 年 8 月時点)。

Aurora クラスター:
  ├── ライター (AZ-a) ← 障害発生
  ├── リーダー 1 (AZ-c) ← 新ライターに昇格
  └── リーダー 2 (AZ-d)

落とし穴は、リーダーを 1 台も置いていないクラスターである。昇格させる相手が居ないため、Aurora は同じ AZ にプライマリを作り直す動きになり、復旧の目安は 10 分未満まで伸びる。ストレージ層が複数 AZ に冗長化されていても、それだけでは速い切り替えにはならない。リーダーは最低 1 台、プライマリとは別の AZ に置く。

ElastiCache (Redis) のフェイルオーバー

ElastiCache (Redis) のフェイルオーバーを図で示す。

Redis クラスター (Multi-AZ):
  ├── プライマリ (AZ-a) ← 障害発生
  └── レプリカ (AZ-c) ← 新プライマリに昇格 (数秒)