Reliability問題から改善戦略を選択する

ゴール

このページでは、既に確認済みの信頼性上の不足から、

単一障害点の除去

自己修復

スケーリング

データレプリケーション

災害復旧

サービスクォータへの対応

のうち、どれを組み合わせる必要があるかを判断します。

重要なのは、

使えそうな改善策を全部選ぶ

ことではありません。

確認されたすべてのギャップを解消できる

かつ

根拠のない改善策を追加しない

ことです。

1. 入力は「確認済みのギャップ」

このページでは、障害原因を一から調査しません。

入力となるのは、前段までで確認された事実です。

例えば、

ここから選ぶべき改善は、

認証サービスの単一障害点除去

障害インスタンスの自己修復

です。

ピーク性能、データ、DR、クォータについては、現在の証拠から改善理由がありません。

2. まず「ギャップ一覧」と「改善候補」を分離する

改善策を先に考えると、

Multi-AZにする

Auto Scalingを追加する

マルチリージョンにする

といった構成案に引っ張られます。

先に、

ギャップA
何が不足している？

ギャップB
何が不足している？

ギャップC
何が不足している？

を固定します。

その後で、

ギャップA → 改善軸1

ギャップB → 改善軸2

ギャップC → 改善軸3

と対応付けます。

3. 1つのワークロードに複数の改善軸が必要なことがある

例えば、次の評価結果が得られたとします。

認証サービス
→ 単一障害点

アプリケーション障害
→ 処理継続できるが
   置き換えは手動

スケール要求
→ サービスクォータで停止

この場合、

単一障害点除去
+
自己修復
+
サービスクォータへの対応

が必要です。

どれか1つだけ実施しても、残りのギャップは残ります。

4. 逆に「関係する技術を全部変更する」必要はない

同じ環境で、

ピーク時の処理能力
→ 十分

データ状態
→ RPO達成

リージョン障害からの復旧
→ RTO達成

まで確認できているなら、

スケーリング方式変更

データレプリケーション変更

DR方式変更

を追加する根拠はありません。

このページでは、

改善できそう

ではなく、

確認されたギャップを解消するために必要

かどうかで選びます。

5. 改善セットは「すべてのギャップを覆う」必要がある

例えば、

ギャップA
単一障害点

ギャップB
自己修復不足

ギャップC
サービスクォータ不足

に対して、

単一障害点除去
+
自己修復

だけを選ぶと、ギャップCが残ります。

したがって改善セットは、

確認されたギャップ
↓
すべてに対応先があるか

を確認します。

1つでも対応していないギャップがあれば、改善セットは不十分です。

6. 改善セットは「根拠のない変更を含まない」必要もある

反対に、

ギャップA
単一障害点

ギャップB
自己修復不足

しか確認されていないのに、

単一障害点除去
+
自己修復
+
マルチリージョンDR
+
データレプリケーション変更

まで選ぶのも適切ではありません。

選択した改善策
↓
どの確認済みギャップを
解消するためなのか

を説明できる必要があります。

7. 「不足している能力」と「実行を妨げる制約」を区別する

複数の問題が同時に見える場合、すべてが独立した改善対象とは限りません。

例えば、

Auto Scaling
↓
必要な追加リソースを要求

しかし
サービスクォータ到達
↓
追加できない

場合、

スケール要求が出ていない

わけではありません。

すでに必要なスケーリング機能が存在しているなら、現在確認された直接の制約は、

サービスクォータ

です。

この状態で、

Auto Scalingをもう1つ追加する

という改善は、確認されたギャップへの直接回答になりません。

8. 同じ考え方をデータとDRにも使う

例えば、

復旧先データ
→ RPO未達

復旧手順
→ RTOも未達

なら、

データレプリケーション
+
DR

の両方に改善理由があります。

一方、

復旧先データ
→ RPO達成

復旧手順
→ RTO未達

なら、現在確認された不足はDR側です。

別リージョンだから
レプリケーションも必ず変更

とは判断しません。

9. 1つの改善で別のギャップまで解消できるとは限らない

例えば、

単一障害点を除去

しても、

障害後の置き換えが手動

という自己修復不足まで自動的に解消されるとは限りません。

同様に、

サービスクォータを引き上げる

だけでは、需要に追従するスケーリング機能そのものが無い環境を改善できません。

したがって、

1つ変更した
↓
関連問題も全部解決

とは考えず、各ギャップが実際に解消されるかを確認します。

10. 改善戦略の対応表は「最終確認」に使う

この表は各技術を再学習するためではありません。

確認済みギャップ
↓
選択した改善軸

の対応漏れを最終確認するために使います。

11. 最小十分な改善セットを作る

このページで目指すのは、

最小
=
根拠のない改善を含めない

十分
=
確認されたギャップをすべて覆う

改善セットです。

例えば、

確認済みギャップ

1. 認証サービスが単一障害点
2. 障害インスタンス置き換えが手動
3. サービスクォータ到達で追加不能

なら、

単一障害点除去
+
自己修復
+
サービスクォータへの対応

が必要十分なセットです。

12. 改善セットを決める流れ

確認済みの信頼性ギャップを列挙
↓
各ギャップに必要な改善軸を割り当てる
↓
同じギャップへ不要な改善を重ねていないか確認
↓
すべてのギャップが覆われているか確認
↓
根拠のない改善策を除外
↓
必要十分な改善セットを確定

13. SAP-C02での判断フロー

既存アーキテクチャの
信頼性ギャップは特定済み
↓
ギャップを1つずつ確認
↓
何の能力が不足？
├─ 単一障害への耐性
├─ 障害後の自動復元
├─ 需要追従
├─ データ状態
├─ ワークロード全体の復旧
└─ AWS側の上限制約
↓
それぞれ対応する改善軸を割り当てる
↓
すべてのギャップを覆った？
│
├─ いいえ
│   ↓
│   改善不足
│
└─ はい
    ↓
    根拠のない改善が含まれる？
    │
    ├─ はい
    │   ↓
    │   過剰な改善を除外
    │
    └─ いいえ
        ↓
        必要十分な改善セット

14. 混同ポイント

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

ここでは、

既存アーキテクチャの
信頼性ギャップを発見する方法

単一障害点の具体的な除去方法

自己修復の具体的実装

スケーリング設計

同期 / 非同期レプリケーション

RTO / RPOの設計

DR方式の比較

サービスクォータの監視・引き上げ方法

コスト最適化

は扱いません。

このページで完成させるのは、

確認済みの信頼性ギャップ
↓
必要な改善軸を割り当て
↓
不足と過剰を除外
↓
必要十分な改善セットを選択

することです。

まとめ

信頼性問題の改善では、

改善策を1つ選ぶ

こと自体が目的ではありません。

1つのワークロードに複数のギャップがあれば、複数の改善軸が必要になります。

一方で、

念のため全部強化

する必要もありません。

判断基準は、

確認されたすべてのギャップを覆っているか

選択したすべての改善策に
確認済みの根拠があるか

です。

対応漏れなし
+
根拠のない改善なし
=
必要十分な信頼性改善セット

として判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• AWS Well-Architected Framework — Reliability
• AWS Well-Architected Framework — Design principles
• AWS Well-Architected Framework — Automatically recover from failure
• AWS Well-Architected Framework — Scale horizontally
• AWS Well-Architected Framework — Stop guessing capacity