信頼性・回復力・DRの設計指標

1. 信頼性は「期待された機能を正しく継続して提供できるか」

AWS Well-Architected Frameworkでは、信頼性は、ワークロードが期待されたときに意図した機能を正しく、一貫して実行できる能力として扱われます。単に「サーバーが落ちないこと」だけではありません。

例えばECサイトなら、次のビジネス機能全体が期待どおり提供される必要があります。

ウェブ画面が開く
+
注文できる
+
決済できる
+
注文結果が保存される

したがって信頼性を考えるときは、インフラストラクチャが動いているかだけではなく、ワークロードがビジネス機能を提供できているかを基準にします。

2. レジリエンスは障害が起きても回復・適応できる能力

レジリエンス（回復力）は信頼性を支える重要な要素です。

AWSでは、インフラストラクチャやサービスの中断から復旧し、需要に応じてリソースを取得し、設定ミスや一時的なネットワーク問題などの影響を軽減できる能力として説明されています。

障害が起きても
↓
影響を抑える
↓
必要なら復旧する
↓
ビジネス機能を維持・回復する

分散システムでは「絶対に壊れないコンポーネント」を目指すのではなく、壊れることを前提にアーキテクチャを設計するという考え方につながります。

3. 信頼性とレジリエンスは同じ意味ではない

両者は密接ですが、完全な同義語ではありません。

信頼性という大きな目標を達成するために、レジリエンスを備えたアーキテクチャを設計するイメージです。

4. 可用性はレジリエンスを数値で見る重要な指標

可用性は、必要なときにワークロードを利用できる時間の割合です。

可用性
=
利用可能だった時間
÷
総時間

例えば99.9%、99.99%のように一定期間の割合として表します。

重要なのは、可用性はアーキテクチャ名ではなく、達成したいサービスレベルだということです。「マルチAZを使うこと」が要件なのではなく、コンポーネント障害が起きてもビジネスサービスを継続したいという要件が先にあります。

5. 可用性は「一定期間」、DRは「災害イベント」を見る

可用性と災害復旧は混同しやすいですが、評価対象が異なります。

可用性はコンポーネント障害、負荷急増、ソフトウェアのバグなどに対応した一定期間のサービス継続性を見ます。一方、災害復旧は、大規模な技術障害、自然災害、人為的な重大イベントなどに対する一回の復旧イベントを中心に考えます。

6. 高可用性だけではDRは完成しない

高可用性とDRでは、障害検知、複数拠点、自動フェイルオーバーなど共通する設計要素もあります。しかし、高可用性はそのまま災害復旧ではありません。

可用性は主にワークロードコンポーネントの障害へ対応しますが、DRではワークロード全体を復旧できる別のコピーや復旧機能まで考える必要があります。

例えばデータを別場所へ即時レプリケーションしていても、誤削除がセカンダリへレプリケーションされる可能性があります。

誤削除
↓
削除内容もセカンダリへレプリケーション

この場合、セカンダリが存在するだけでは失われたデータを復旧できるとは限りません。したがって「冗長だからDR済み」とは判断しません。

7. 災害復旧は「何を災害とするか」から始める

DR戦略を考える前に、まず何を災害として扱うのかを定義します。

インスタンス障害
AZ障害
リージョン障害
データ破損
運用者エラー
サイバー攻撃

これらでは障害範囲も必要な復旧アーキテクチャも異なります。

「DRを構築してください」だけではアーキテクチャは決まりません。必要なのは、どの障害範囲まで想定するか、どこまで停止を許容できるか、どこまでデータ損失を許容できるかです。

8. RTOは「どれだけ停止してよいか」

復旧時間目標（RTO / 目標復旧時間）は、サービスが中断してから復旧するまでの最大許容時間です。

12:00
障害発生

↓

12:15
復旧

要件: RTO 30分
→ RTO以内

一方、12:00に障害が発生し13:00に復旧した場合は、RTO 30分という要件を満たしません。

RTOの決定打は、ダウンタイムをどこまで許容できるかです。

9. RPOは「どれだけデータを失ってよいか」

復旧ポイント目標（RPO / 目標復旧時点）は、最後に復旧できるデータポイントから災害発生までに許容できる最大時間です。

11:50
最後に復旧可能なデータ

↓

12:00
災害

要件: RPO 15分
→ 最大10分分のデータ損失なのでRPO以内

一方、最後に復旧可能なデータが11:30なら30分分失う可能性があり、RPO 15分には対応できません。

RPOの決定打は、データ損失をどこまで許容できるかです。

10. RTOとRPOは別の要件

RTOとRPOは同時に登場することが多いですが、意味は別です。

                     災害
                         │
         RPO             │             RTO
←────────────────────────┼────────────────────────→
復旧可能なデータポイント   │                   サービス復旧

RPOは災害より前のデータ損失を見ます。RTOは災害より後のダウンタイムを見ます。

11. RTO / RPOは技術が決める値ではない

RTO / RPOはAWSサービスの性能から自動的に決まるものではありません。

ビジネス影響、リスク、コンプライアンス要件、復旧コストなどから組織が定義する目標です。

例えば同じデータベースでも、社内検証システムならRTO 24時間 / RPO 24時間、決済システムならRTO 5分 / RPO 1分という要件になる可能性があります。

技術アーキテクチャは、この要件を満たすように後から選びます。

12. 復旧目標は依存関係まで含めて成立させる

ワークロード単体のRTO / RPOだけを決めても、必須の依存コンポーネントがその目標を満たせなければ、ビジネス機能全体として復旧目標を達成できません。

注文アプリケーション
RTO = 30分
     ↓
認証サービス
RTO = 60分
     ↓
代替手段なし

→ ワークロード全体として
  RTO 30分を成立させられない

重要な下流依存関係については、ワークロードの復旧目標と整合する復旧機能を持つか、障害時に利用できる回避策を設計する必要があります。

逆に、このワークロードを利用する上流ワークロードの要件によって、当初想定より厳しいRTO / RPOが必要になることもあります。

また、復旧目標は障害範囲によって異なる場合があります。

AZ障害
→ RTO 5分 / RPOほぼ0

リージョン障害
→ RTO 30分 / RPO 5分

何が壊れた場合の復旧目標なのかまで定義します。

13. RTO / RPOは定義しただけでは達成したことにならない

RTO / RPOはアーキテクチャへ与える復旧目標です。値を定義しただけで、そのワークロードが実際に目標を満たせることが証明されたわけではありません。

実装したDR戦略について復旧経路を定期的に実行し、実際に指定した時間・データ状態まで復旧できることを検証します。

復旧目標を定義
        ↓
DR戦略を実装
        ↓
復旧テスト
        ↓
実測した復旧時間 / データ損失
        ↓
RTO / RPOを満たすか確認

復旧テストで目標を満たせない場合は、復旧手順、キャパシティ、依存関係、自動化などを見直します。

14. 厳しいRTO / RPOほど一般にコストと複雑さが増える

RTO 24時間 / RPO 24時間と、RTO数分 / RPO数秒では、必要な復旧機能は大きく異なります。

より短いRTOでは、復旧時にインフラストラクチャを一から用意する時間を減らす必要があります。より短いRPOでは、データをより頻繁または継続的に復旧場所へ反映する必要があります。

厳しい復旧目標
        ↓
より多くの常時リソース
より高度なレプリケーション
より多くの自動化
        ↓
コスト / 複雑さ増加

そのため、復旧目標と復旧戦略のコストを合わせて判断します。

15. 「最短RTO / RPO」が常に最適ではない

SAP-C02では、技術的に最も強力なアーキテクチャが必ず正解とは限りません。

例えばビジネスがRTO 8時間 / RPO 4時間まで許容しているのに、ほぼ停止なし・ほぼデータ損失なしを実現するための高コストなアーキテクチャを採用すると、過剰なアーキテクチャになる可能性があります。

設計目標は最小のRTO / RPOではなく、ビジネス要件を満たすRTO / RPOを、妥当なコストと複雑さで実現することです。

16. 可用性要件とDR要件を同時に持つ

実際のワークロードでは、通常時の可用性と大規模災害時の復旧目標を別々に定義します。

通常時
↓
99.99% 可用性

大規模災害
↓
RTO 30分
RPO 5分

高可用性アーキテクチャだけを設計しても、大規模災害時の復旧要件が不明ならDR設計は完成しません。逆にDR戦略だけを用意していても、日常的なコンポーネント障害のたびにサービスが長時間停止するアーキテクチャでは信頼性要件を満たせない場合があります。

17. SAP-C02では要件を数字に変換する

シナリオでは、RTO / RPOがそのまま書かれない場合もあります。

「障害発生後15分以内に注文受付を再開する必要がある」なら、RTO ≤ 15分です。

「最大5分分の注文データ損失は許容される」なら、RPO ≤ 5分です。

「月間99.99%以上サービスを利用可能にする」なら、可用性要件です。

この3つを混同しないことが重要です。

18. 要件から設計指標を抽出する

シナリオを読んだら、次の順で分解します。

ビジネスへの影響
        ↓
障害範囲
        ↓
通常障害か / 災害か
        ↓
可用性要件
        +
RTO
        +
RPO
        ↓
復旧アーキテクチャの制約

この段階では特定のAWSサービスを先に選びません。先に復旧目標を決め、アーキテクチャをその目標へ合わせます。

19. 代表シナリオ

企業の注文システムについて次の要件があります。

通常のコンポーネント障害では
可能な限りサービスを継続する

リージョン規模の災害では
30分以内にサービスを再開する

最大5分分までの注文データ損失を許容する

ここから抽出する設計指標は、通常障害に対する可用性 / レジリエンス 要件、リージョン災害に対するDR要件、サービス復旧に対するRTO 30分、データ復旧に対するRPO 5分です。

この時点で初めて、具体的なアーキテクチャ候補を比較できる状態になります。

20. 混同ポイント

21. SAP-C02判断フロー

障害・復旧要件を読む
        ↓
ビジネス機能は何か
        ↓
想定障害範囲は何か
        ↓
通常運用の可用性か
大規模災害への復旧か
        ↓
停止時間 要件
→ RTO
        ↓
データ損失要件
→ RPO
        ↓
必要な復旧機能を定義
        ↓
具体的なアーキテクチャを比較

22. まとめ

最重要ポイントは、DRサービスやアーキテクチャパターンから考え始めないことです。

信頼性
↓
レジリエンス
↓
可用性 / 災害復旧
↓
RTO / RPO

シナリオから、どれだけ停止できるかをRTO、どれだけデータを失えるかをRPOとして抽出します。

RTO / RPOは技術が勝手に決める数字ではなく、ビジネス影響から定義する復旧目標です。

この復旧目標が、バックアップ、DRパターン、自動復旧などの具体的なアーキテクチャを選ぶ基準になります。

23. 主要AWS公式資料

信頼性・回復力・DRの設計指標を確認するための主要なAWS公式資料を以下に示します。

• SAP-C02 ドメイン 1 / タスク 1.3 — AWS Certification
• AWS Well-Architected Framework — 信頼性
• AWS Well-Architected 信頼性の柱 — レジリエンスと信頼性の構成要素
• AWS Well-Architected 信頼性 柱 — 可用性
• AWS Well-Architected 信頼性の柱 — 災害復旧目標
• AWS 災害復旧ガイダンス — 高可用性は災害復旧ではない
• AWS Well-Architected — ダウンタイムとデータ損失の復旧目標を定義する
• AWS Well-Architected — 災害復旧の実装をテストする