フレームワーク活用ガイドひとことで言うと#
冗長性・フェイルオーバー・自動修復の3つの柱で、単一障害点を排除し、障害が起きても自動的にサービスを継続できるインフラを設計するフレームワーク。
押さえておきたい用語#
- Redundancy（リダンダンシー）
- 同じ機能を持つコンポーネントを複数用意する冗長構成のこと。1つが壊れても別が引き継ぐ。
- Failover（フェイルオーバー）
- 障害が発生した際に待機系に自動で切り替わる仕組みを指す。
- SPOF（Single Point of Failure）
- システム全体を停止させうる単一障害点。信頼性設計で最初に排除すべき箇所である。
- Self-Healing（セルフヒーリング）
- 障害を検知して人手を介さず自動的に復旧する仕組み。コンテナの自動再起動が典型例。
- Availability（アベイラビリティ）
- サービスが正常に稼働している時間の割合。99.9%なら年間約8.7時間のダウンタイムが許容される。
インフラ信頼性設計の全体像#
こんな悩みに効く#
- サーバー1台が落ちるとサービス全体が止まる
- 障害復旧が手動で、深夜のオンコール対応が負担になっている
- SLAで99.9%を約束しているが達成できていない
基本の使い方#
具体例#
月間売上10億円のEC。データベースが単一AZの単一インスタンスで稼働しており、AZ障害時に 6時間 のサービス停止が発生した。
マルチAZ構成に移行。
| コンポーネント | Before | After |
|---|---|---|
| DB | 単一AZ, 1台 | マルチAZ, Auto Failover |
| App Server | 単一AZ, 3台 | 2AZ分散, Auto Scaling |
| キャッシュ | なし | ElastiCache Multi-AZ |
移行後にAZ障害が発生した際、DBのフェイルオーバーが 28秒 で完了。ユーザーが認識できるダウンタイムは実質ゼロだった。年間可用性は 99.5% → 99.97% に改善。
エンジニア40名のBtoB SaaS。EC2インスタンス上で直接アプリケーションを動かしていたが、メモリリークで週に 2〜3回 プロセスが停止し、そのたびに手動で再起動していた。
Kubernetesに移行し、liveness probeとreadiness probeを設定。メモリリークでプロセスが応答しなくなると自動でPodが再起動される仕組みにした。
手動再起動が 週3回 → ゼロ に。Pod再起動は自動で行われるため、オンコール呼び出し回数が 月15回 → 月3回 に減少。エンジニアの深夜対応負担が大幅に軽減された。
月間1,000万トランザクションの決済企業。冗長構成を組んでいたが、フェイルオーバーが実際に動作するかテストしたことがなかった。年次の障害訓練でフェイルオーバーを試みたところ、設定ミスで切り替えに 12分 かかり、目標の30秒を大幅に超過。
Chaos Engineeringツール（Litmus）を導入し、月1回の定期障害注入テストを実施。DB・キャッシュ・メッセージキューそれぞれのフェイルオーバーを検証。3ヶ月で設定ミスを 7件 修正した結果、実際の障害時にフェイルオーバーが 15秒 で完了するようになった。
やりがちな失敗パターン#
- 冗長構成を作ったがフェイルオーバーをテストしない — 設定ミスが見つかるのは本番障害時。カオスエンジニアリングで定期的に検証する
- 可用性目標を過剰に設定する — 99.999%は99.9%の100倍のコストがかかる。ビジネス要件に見合った目標を設定する
- アプリケーション層のSPOFを見落とす — インフラは冗長でも、アプリケーションのシングルトン処理やファイルロックがSPOFになることがある
- セルフヒーリングに頼りすぎる — 自動再起動で症状は消えるが根本原因（メモリリーク等）は残る。自動復旧のログを定期的に確認し、根本対応を行う
まとめ#
インフラ信頼性設計は冗長性・フェイルオーバー・自動修復の3つの柱でSPOFを排除し、障害が起きても自動的にサービスを継続する構成を作るフレームワーク。可用性目標はビジネス要件とコストのバランスで決定し、カオスエンジニアリングでフェイルオーバーの動作を定期的に検証する。9を1つ増やすコストを理解したうえで、必要十分な信頼性を実現するのが正しいアプローチになる。