Reliability要件からArchitectureを選択する

ゴール

信頼性要件から、必要な制御を1つずつ選ぶだけでは十分ではありません。

例えば、

複数AZに配置
+
Auto Scaling
+
フェイルオーバー先を用意

していても、

必須依存先が同じ障害範囲にある
切り替え先のデータ状態が要件を満たさない
障害後のキャパシティが不足する
サービスクォータで拡張できない

なら、利用者から見たサービス継続は成立しません。

ここでは、これまで整理した信頼性条件を、

信頼性要件
↓
障害範囲
↓
復旧条件
↓
必要な信頼性制御
↓
制御間の不足を確認
↓
候補アーキテクチャ比較
↓
最適な構成

へ変換します。

目標は、要件を満たすために、どの信頼性制御をどの組み合わせで採用するか判断できることです。

1. サービス名ではなく要件を分解する

最初に、シナリオから設計条件を抽出します。

ここで、

高可用性
↓
マルチAZ

のように単語だけで構成を決めません。

複数条件を同時に満たす構成を探します。

2. 障害範囲から配置の候補を決める

最初の大きな分岐は、どこまでの障害に耐える必要があるかです。

AZ障害まで
↓
マルチAZを中心に評価

リージョン障害まで
↓
マルチリージョンを評価

ただし、

マルチリージョン
>
マルチAZ

という優劣ではありません。

リージョン障害が要件に含まれないのにマルチリージョン化すれば、

データ同期
構成同期
切り替え制御
運用手順
コスト

など、新しい設計条件が増えます。

したがって、要求された障害範囲を満たす候補だけを残すことが最初の判断です。

3. 信頼性制御は「単独効果」ではなく「残る不足」で比較する

各制御は、ある問題を解決しても、別の問題は残します。

そのため、次のように考えます。

ここで重要なのは、

ある制御を選んだ
↓
それで何が解決したか
↓
まだ何が解決していないか
↓
次に何を組み合わせるか

と考えることです。

4. 「業務が最後まで成立するか」で候補を落とす

信頼性アーキテクチャでは、AWSリソースが残っているだけでは不十分です。

確認するのは、

利用者
↓
正常な接続先
↓
アプリケーション
↓
必須依存関係
↓
必要なデータ
↓
必要な処理能力
↓
業務完了

までです。

例えばマルチAZ構成でも、

アプリケーション
→ 生存

データ
→ 生存

必須外部依存
→ 障害AZにしかない

なら、業務は成立しません。

逆に、停止を許容できる機能であれば、必須経路から外すことで主要業務を継続できる場合があります。

したがって候補アーキテクチャは、保護対象の業務経路全体が障害後も成立するかで評価します。

5. 障害後の状態で再評価する

正常時に成立している構成でも、障害後に条件が変わります。

例えば、

正常時
AZ-A 50%
AZ-B 50%

の構成でAZ-Aを失えば、

AZ-B
↓
100%の負荷を処理

する必要がある可能性があります。

リージョン切り替えでも同じです。

通常時
リージョンA 100%
リージョンB 待機

障害時
リージョンB 100%

となるなら、リージョンBについて、

必要台数まで増やせるか
サービスクォータは十分か
依存先も同じ負荷を処理できるか
必要なデータ状態を利用できるか

まで確認します。

つまり、正常時の成立性ではなく、対象障害が発生した後の構成で成立するかを確認します。

6. RTO / RPOも構成全体で判定する

RTOやRPOも、特定の機能だけを見て判定しません。

例えば、

正常な接続先への切り替え
→ 2分

必要データ
→ RPOを満たす

必要キャパシティ確保
→ 20分

であれば、利用者から見た復旧時間は2分ではありません。

逆に、

切り替え
→ 高速

キャパシティ
→ 十分

データ
→ RPO未達

でも候補から外れます。

したがって、

切り替え
+
データ状態
+
依存関係
+
必要キャパシティ

がすべて成立して初めて、RTO / RPOを満たす候補として残します。

7. 候補を制御カバレッジで比較する

候補アーキテクチャを比較するときは、次のような表にすると判断しやすくなります。

この表で、

一部だけ強い候補

ではなく、

必須条件をすべて満たす候補

を残します。

8. シナリオ1：AZ障害と需要急増を同時に扱う

次の要件があります。

注文受付は停止させたくない
リージョン障害は対象外
1つのAZ障害には耐える
大型セールで負荷が4倍になる
配送通知は10分遅延してよい
必要以上の運用複雑性は避ける

候補A

2リージョン
+
固定キャパシティ
+
配送通知は同期処理

リージョン障害は要件に含まれていません。

さらに、

負荷増加
配送通知障害の伝播
障害時キャパシティ

が解決していません。

候補B

複数AZ
+
Auto Scaling
+
配送通知を必須同期経路から分離
+
AZ障害後とセール時の必要量まで
サービスクォータを確保

こちらは、

障害範囲
需要急増
依存障害
キャパシティ制約

を同時に満たします。

したがって候補Bを選択します。

9. シナリオ2：リージョン障害を含む場合

次の条件があります。

注文受付はリージョン障害でも継続
短いRTO
小さいRPO
切り替え後は1リージョンで全負荷を処理
分析処理は遅延可能

この場合、

2リージョンにリソースが存在する

だけでは候補として不十分です。

評価するのは、

別リージョンだけで注文処理が成立
+
RPOを満たすデータ状態
+
RTO内に正常な処理先へ切り替え
+
障害リージョンへ残る必須依存がない
+
全負荷を処理可能
+
サービスクォータを満たす
+
遅延可能処理が主要業務を止めない

ことです。

1つでも欠ければ、その候補は除外します。

10. 似た候補は「足りない1条件」で落とす

SAP-C02では、複数の選択肢が一見すると高可用に見えることがあります。

その場合は、

どの候補が優れているか

ではなく、

どの候補が必須条件を1つ落としているか

を探します。

例えば、

このように、候補から1つずつ不足条件を消していくと、最適なアーキテクチャを選びやすくなります。

11. よくある誤判断

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

信頼性要件を抽出
        ↓
何を保護する？
        ↓
どの障害範囲まで耐える？
        ↓
マルチAZ / マルチリージョン
の候補を決める
        ↓
障害後も必要な
アプリケーションとデータが残る？
        ↓
必須依存関係も生存する？
        ↓
停止可能な依存処理を
必須経路から外せる？
        ↓
正常な処理先へ
フェイルオーバーできる？
        ↓
障害後の必要負荷を
処理できる？
        ↓
Auto Scaling
サービスクォータ
実キャパシティ
は成立する？
        ↓
構成全体として
RTO / RPOを満たす？
        ↓
満たす候補だけ残す
        ↓
運用複雑性とコストを比較
        ↓
最適な信頼性アーキテクチャ

まとめ

信頼性アーキテクチャは、

マルチAZ
マルチリージョン
Auto Scaling
疎結合
フェイルオーバー
サービスクォータ

を個別に採用すれば完成するものではありません。

必要なのは、

要求された障害範囲
+
障害後に生存する業務経路
+
必要なデータ状態
+
依存関係の障害分離
+
正常な処理先への切り替え
+
障害後の必要キャパシティ
+
サービスクォータ

を同時に成立させることです。

判断するときは、

ある制御を入れた
↓
何が解決した？
↓
何がまだ不足している？
↓
どの制御を追加すれば成立する？

と進めます。

SAP-C02では、「どのAWSサービスを使うか」ではなく、「この信頼性要件に対して、どの制御の組み合わせなら業務経路全体が生存するか」まで判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• AWS Well-Architected Framework Reliability Pillar
• REL10-BP01 複数の場所にワークロードをデプロイする
• REL04-BP02 疎結合の依存関係を実装する
• REL07-BP03 ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する
• REL11-BP02 正常なリソースにフェイルオーバーする
• REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する