導入
DRが「リージョン規模の災害」に備える仕組みだとすれば、日常的に起きる小さな障害（1台のインスタンス障害、1つのAZの障害）への備えが高可用性（HA）設計です。SAPでは、この2つを区別しつつ、両方を組み合わせて設計できることが求められます。
説明
高可用性設計の基本パターンを整理します。
| パターン | やること | 効果 |
|---|---|---|
| Multi-AZ配置 | 同一リージョン内の複数AZにリソースを分散 | AZ単位の障害を吸収 |
| 自動復旧 | Auto Scaling・ELBヘルスチェック・RDS Multi-AZで異常系を自動置換 | 人手を介さず数分で復旧 |
| 疎結合化 | コンポーネント間をSQS/SNS/EventBridgeで非同期に接続 | 1コンポーネントの障害が他へ連鎖しない |
| フォールトインジェクション | 意図的に障害を注入して耐障害性を検証 | 「実際に壊して確認」で設計の穴を発見 |
flowchart TD
ELB["ELB"] --> AZ1["AZ-a: EC2"]
ELB --> AZ2["AZ-b: EC2"]
AZ1 & AZ2 --> Q["SQSキュー（疎結合）"]
Q --> W["ワーカー（複数AZ）"]
W --> DB["RDS Multi-AZ"]
疎結合化がなぜHAに効くかというと、コンポーネント同士が直接同期呼び出しで繋がっていると、1つが遅延・停止すると連鎖的に全体が詰まるからです。SQSやSNS、EventBridgeを間に挟むことで、片方が一時的に停止してもキューにメッセージが溜まるだけで、復旧後に処理を再開できます。
最後に、AWSには「本当に壊れても大丈夫か」を実際に検証するサービスがあります。AWS Fault Injection Service（FIS） は、EC2の強制停止・CPU負荷・ネットワーク遅延・AZ停止のシミュレーションなど、意図的に障害を注入する実験を安全に実行できるマネージドサービスです。カオスエンジニアリングの考え方をAWS上で実践するための道具として位置づけられます。
具体例
DR（リージョン規模）とHA（AZ・コンポーネント規模）は被害範囲が違います。あるサービスのHA設計と、その検証を追いましょう。
- 1つのAZが落ちてもサービス継続 → Multi-AZ＋自動復旧 … EC2を複数AZに分散しELBで振り分け、Auto Scalingとヘルスチェックで落ちたインスタンスを自動置換、DBはRDS Multi-AZ。人手を介さず数分で復旧。
- 1コンポーネントの障害が他へ波及しない → 疎結合化 … サービス間をSQS/EventBridgeで非同期接続。決済ワーカーが一時停止しても、キューに溜まるだけで注文受付は止まらない。
- 「本当に壊れても大丈夫か」を検証 → AWS Fault Injection Service（FIS） … 設計は良さそうでも、実際に壊してみないと穴は分からない。FISでAZ停止やインスタンス強制終了を意図的に注入し、Auto Scalingがちゃんと復旧するか、フェイルオーバーが機能するかを本番同等環境で確認（カオスエンジニアリング）。
見分け方は問題文の被害範囲。「AZが落ちる」ならHA（Multi-AZ）、「リージョンが落ちる」ならDR（前レッスンまでの戦略）、「コンポーネント連鎖」なら疎結合、「実際に壊して検証」ならFIS。範囲で答えが決まります。
読んでみよう
「1つのAZが落ちてもサービスを継続したい」はMulti-AZ＋自動復旧、「1つのコンポーネントの障害が他に波及しないようにしたい」は疎結合化、「本番同等の環境で実際に障害耐性を検証したい」はFISが、それぞれのキーワードに対応する定番の答えです。DR（リージョン規模）とHA（AZ・コンポーネント規模）は問題文の被害範囲で見分けてください。