既存ArchitectureのReliabilityを評価する

ゴール

どの業務機能を評価するか
↓
期待する可用性と実績を比較
↓
処理経路と依存関係を確認
↓
障害ドメインを確認
↓
障害履歴と実際の影響を確認
↓
障害時の回復・影響範囲を評価
↓
現在のアーキテクチャで
信頼性が不足する領域を特定

という評価ができるようにします。

前提

可用性、信頼性、レジリエンスの基本的な意味、RTO / RPO、障害範囲、必須依存関係と縮退可能な依存関係、単一障害点という概念、マルチAZ / マルチリージョン、フェイルオーバー、自動スケーリング、データレプリケーションなどは既習として扱います。

ここでは再講義せず、既存の実環境が現在どの程度それらを満たしているかを評価することへ進みます。

1. アーキテクチャレビューは「構成図を見ること」だけではない

アーキテクチャ図は重要な出発点ですが、構成図に複数AZと書かれているだけで高信頼性とは判断できません。

設計上の構成
+
現在の実装状態
+
監視された可用性
+
依存関係
+
障害履歴
+
障害・復旧テストの結果

を合わせて確認し、現在の実装が期待された信頼性特性を本当に持っているかを評価します。

2. 評価対象は「リソース」ではなく業務機能から決める

Amazon EC2、Amazon RDS、Amazon S3、AWS Lambdaを1つずつ確認するだけでは、利用者から見た信頼性を評価できません。

利用者
↓
ログイン
↓
商品確認
↓
注文
↓
決済
↓
注文保存

のように、利用者へ価値を提供する業務経路を評価単位にし、その経路を成立させるコンポーネントと依存関係を確認します。

3. 最初に期待する可用性と実績を比較する

注文機能
要求 99.95%
直近12か月実績 99.82%

なら、現在の信頼性が要求に届いていないという明確な証拠があります。

一方、要求99.9%に対して実績99.95%であっても、アーキテクチャに信頼性上の弱点が存在しないとは限りません。可用性実績だけでレビューを終了しません。

4. 高い可用性実績だけでは潜在的な弱点を否定できない

過去に障害が起きていなくても、障害に耐えられる構成と、たまたま対象障害が発生しなかった構成は同じではありません。

アプリケーション
AZ-A / AZ-Bへ分散

しかし
両方
↓
同じ必須依存先

なら、依存先が一度も停止していないだけで年間可用性が高く見える可能性があります。まだ観測されていない依存関係や障害経路も評価します。

5. 業務経路から依存関係を洗い出す

注文API
↓
認証
↓
在庫
↓
決済
↓
注文データ

のように依存関係を整理し、各依存先が利用不能になったとき、保護対象の業務機能がどうなるかを確認します。

商品推薦が停止しても注文可能なら主要業務は継続できます。一方、認証停止で注文不能なら、認証は信頼性評価上の重要な依存関係です。

6. 依存関係の「数」ではなく実際の影響を見る

依存先が多いこと自体が直ちに問題なのではありません。

共通依存先の障害
↓          ↓
注文       決済
停止       停止

のように、依存先障害がどの業務機能へどこまで影響するかを確認します。

7. 障害ドメインをアーキテクチャへ重ねる

AZ-A アプリケーション
AZ-B アプリケーション
        │
        └── 必須依存関係
                ↓
              AZ-A

なら、AZ-A障害時にアプリケーション層だけが残っても業務機能は成立しない可能性があります。コンポーネント単体ではなく、業務経路全体の障害ドメインを見ます。

8. 意図した分離と実際の分離を比較する

複数AZへ分離されていても、共通依存関係、共通制御経路、共通データ、共通外部サービスを通じて同じ障害の影響を受ける可能性があります。

ある障害が発生したとき、影響が意図した範囲内に留まるかを確認し、意図した障害分離が成立しているかを評価します。

9. レジリエンスは「障害後の実際の振る舞い」で評価する

既存アーキテクチャでは、障害を防げるかだけでなく、障害発生後にどう振る舞うかも確認します。

1コンポーネント障害
↓
別の正常な処理経路へ継続
または
短時間で自動回復

できるなら、その障害に対する回復力を持っています。

1コンポーネント障害
↓
人が気付くまで停止
↓
手動判断
↓
手動復旧

となり要求された可用性を維持できないなら、現在のアーキテクチャには改善対象があります。ここでは自動復旧方式を設計せず、現在の回復能力が要求を満たしているかを評価します。

10. 障害履歴はアーキテクチャの実証データとして使う

障害件数だけでなく、アーキテクチャが実際の障害にどう反応したかを確認します。

11. 運用改善の障害履歴分析とは目的が違う

運用改善では検知の遅れ、手順の属人化、手作業ミスなどを運用プロセス改善へつなげます。

このページでは、どの依存関係が停止したか、どの障害ドメインまで影響したか、アーキテクチャが障害を吸収できたか、どの業務機能が利用不能になったかを確認し、アーキテクチャ上の信頼性不足へつなげます。

12. 障害履歴から繰り返すアーキテクチャ上の弱点を探す

障害1 認証タイムアウト
障害2 注文APIタイムアウト
障害3 決済開始失敗

調査結果
共通依存サービスの劣化
↓
複数業務へ影響

なら、3種類の別障害として見るだけではなく、共通依存関係の障害が複数業務へ伝播するアーキテクチャとして評価します。

13. 「障害が起きた場所」と「利用者影響」を分けて見る

1台のAmazon EC2インスタンス障害でも、利用者影響なしで正常処理先へ自動継続できれば、その障害へのレジリエンスは機能しています。

逆に、小さな依存サービス障害で注文機能全体が停止するなら、コンポーネントの規模は小さくてもアーキテクチャ上の影響は大きいと判断します。

14. アーキテクチャレビューでは設計と実態を照合する

設計書だけを正として扱いません。

設計書
+
現在の設定
+
監視データ
+
障害履歴
+
障害・復旧テスト結果

を照合し、意図されたアーキテクチャと現在の実態との差を確認します。

15. レビュー結果は「信頼性の不足領域」として残す

どこが不十分で、何を根拠にそう判断したかを説明できる形で残します。

16. 可用性目標未達とアーキテクチャ上の弱点を区別する

信頼性不足には、実績として可用性目標を外している場合と、現在は目標内でもレビューで要求された障害へ耐えられない経路が見つかる場合があります。

既存アーキテクチャの評価では、過去の実績と潜在的な障害経路の両方を確認します。

17. 現在の問題と将来の問題を分ける

ここで見るのは、現在のアーキテクチャ、現在の利用条件、現在までの障害・可用性データです。

「今はキャパシティに余裕があるがデータ量が毎月20%増加している」のような将来予測は別の分析です。ここでは、現在のアーキテクチャに既に存在する信頼性不足を評価します。

18. 信頼性レビューの評価表

19. シナリオ：複数AZなのに可用性目標を満たさない

可用性目標 99.95%
実績 99.82%

認証サービス障害
↓
注文API停止

認証サービス
↓
AZ-A内の単一経路へ依存

なら、「アプリケーションはマルチAZだから問題なし」とは判断しません。可用性目標未達、必須依存関係の障害分離不足、実障害での注文停止を合わせ、既存アーキテクチャには信頼性が不十分な領域が存在すると評価できます。

20. シナリオ：障害実績がなくても不足領域を特定できる

直近12か月
可用性 99.99%
目標 99.9%

障害・復旧テスト
主要コンポーネント停止
↓
自動切替なし
↓
手動復旧
↓
復旧完了まで18分

要求
5分以内にサービス復旧

本番で同じ障害がまだ発生していなくても、要求された回復能力を満たせない潜在的な信頼性の不足領域として記録します。

21. 判断フロー

既存アーキテクチャを評価
↓
保護対象の業務機能を決める
↓
期待する可用性 / 信頼性条件を確認
↓
実績を確認
↓
業務経路と依存関係を確認
↓
障害ドメインを重ねる
↓
障害が起きた場合
影響は意図した範囲に収まる？
↓
障害履歴を確認
↓
実際の障害時や障害・復旧テストで
期待どおり回復した？
↓
設計 / 実装 / 実績を照合
↓
現在の信頼性が
不十分な領域を特定
↓
後続の改善判断へ渡す

22. 混同ポイント

23. このページで扱わないこと

利用量の増加傾向から将来の障害を予測すること、単一障害点の具体的な除去方法、マルチAZやロードバランサーの導入方法、Auto Scalingや自己修復の実装、データレプリケーション方式の改善、DR戦略の再設計、サービスクォータ引き上げ、信頼性改善戦略の最終選択は扱いません。

ここで完成させるのは、現在のアーキテクチャを証拠に基づいて評価し、信頼性が不十分な領域を特定することです。

まとめ

既存アーキテクチャの信頼性は構成図だけでは評価しません。

期待する可用性
+
実際の可用性
+
業務経路
+
依存関係
+
障害ドメイン
+
障害履歴
+
障害時の回復動作
+
障害・復旧テスト結果

をアーキテクチャレビューで照合します。

その障害が起きたとき、現在のアーキテクチャは要求された業務機能を維持・回復できるかを確認し、どこが十分に信頼できず何を根拠にそう判断したのかを、信頼性の不足領域として後続へ渡します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• AWS Well-Architected フレームワーク — 信頼性の柱
• AWS Well-Architected — ワークロードリソースのモニタリング
• AWS Well-Architected — コンポーネント障害に耐えられるワークロード設計
• AWS Prescriptive Guidance — レジリエンス分析フレームワーク