可用性を学ぶとき、HAとDRは似た言葉に見えます。
ざっくり分けると、以下です。
- HA: 普段起きうる故障でも、なるべく止めない設計
- DR: 大規模障害や災害で本番環境が使えなくなったときに復旧する設計
本記事では、HAとDRの違いと、代表的なDRパターンを図で整理します。
HAとDRの違い
HAは小〜中規模の障害に耐える設計です。
| 事象 | 主に見る設計 |
|---|---|
| VMが1台落ちた | HA |
| Podが落ちた | HA |
| 1つのzoneが落ちた | HA |
| DBインスタンス障害 | HA |
| VPN tunnelが1本落ちた | HA |
| region全体が長時間使えない | DR |
| 地震などで地域全体が使えない | DR |
| 本番環境全体が壊れて復旧が必要 | DR |
ただし、境界は重なります。複数region active-activeはHAでもありDRでもあります。
RTO / RPO
DRパターンを選ぶときは、RTOとRPOを見ます。
| 用語 | 意味 |
|---|---|
| RTO | どれくらいの時間で復旧するか |
| RPO | どれくらいのデータ損失を許容するか |
- RTO: 止まってよい時間
- RPO: 失ってよいデータ量
Backup / Restore
flowchart TB
user["User"]
subgraph r1["Primary Region"]
app1["App"]
db1["Primary DB"]
backup["Backup / Snapshot"]
app1 --> db1
db1 --> backup
end
subgraph r2["Recovery Region"]
restore["Restore DB from backup"]
app2["Rebuild App"]
end
user --> app1
backup -. "disaster occurs<br/>restore later" .-> restore
restore -. "after recovery" .-> app2
普段、復旧先はほぼ空です。障害後にバックアップから復元して環境を作ります。安い代わりに復旧は遅くなります。
Pilot Light
flowchart TB
user["User"]
subgraph r1["Primary Region"]
app1["Active App"]
db1["Primary DB"]
app1 --> db1
end
subgraph r2["Recovery Region"]
base["Minimal infrastructure<br/>VPC / IAM / config"]
db2["DB Replica / Critical data"]
app2["App not running<br/>or not fully deployed"]
end
user --> app1
db1 -. "replication" .-> db2
base -. "ready for rebuild" .-> app2
Pilot Lightは「種火」です。復旧に必要な最小部品だけを別regionに置きます。障害時にアプリを立ち上げ、DBを昇格し、入口を切り替えます。
Warm Standby
flowchart TB
user["User"]
dns["DNS / Failover"]
subgraph r1["Primary Region"]
app1["Full-size App"]
db1["Primary DB"]
app1 --> db1
end
subgraph r2["Standby Region"]
app2["Small standby App<br/>reduced capacity"]
db2["Replica DB"]
app2 --> db2
end
user --> dns --> app1
db1 -. "replication" .-> db2
dns -. "failover + scale up" .-> app2
Warm Standbyは、復旧先に小さい本番相当環境を常時動かしておく構成です。障害時にスケールアップして本番相当に近づけます。
Active-Passive
flowchart TB
user["User"]
dns["DNS / Failover"]
subgraph r1["Primary Region"]
app1["Active App"]
db1["Primary DB"]
app1 --> db1
end
subgraph r2["Passive Region"]
app2["Passive App<br/>ready"]
db2["Replica DB<br/>ready"]
app2 --> db2
end
user --> dns --> app1
db1 -. "replication" .-> db2
dns -. "failover" .-> app2
Active-Passiveは、通常はprimary側だけを使い、障害時にpassive側へ切り替える構成です。Warm Standbyより待機系の準備度が高いイメージです。
Active-Active
flowchart TB
user["User"]
glb["Global Load Balancer"]
subgraph r1["Region A"]
app1["Active App"]
db1["DB / Data store"]
app1 --> db1
end
subgraph r2["Region B"]
app2["Active App"]
db2["DB / Data store"]
app2 --> db2
end
user --> glb
glb --> app1
glb --> app2
db1 <-. "multi-region replication" .-> db2
Active-Activeは、複数regionで常時本番稼働する構成です。強い一方で、DB整合性、競合解決、運用、コストの難易度が高くなります。
まとめ
| パターン | 状態 | コスト | 復旧速度 |
|---|---|---|---|
| Backup / Restore | バックアップから復元 | 低 | 遅い |
| Pilot Light | 最小部品だけ待機 | 低〜中 | 中〜遅い |
| Warm Standby | 縮小環境を常時起動 | 中 | 中〜速い |
| Active-Passive | 待機系をほぼ準備済み | 中〜高 | 速い |
| Active-Active | 複数regionで常時稼働 | 高 | 最速 |
HAは普段の障害に耐える設計、DRは大規模障害から復旧する設計です。クラウドの可用性設計では、Compute、Data、NetworkのHAを積み上げたうえで、必要に応じてDRパターンを選びます。