SAA対策
SAAで重要なMulti-AZ高可用性設計を整理する
SAA-C03で問われやすいMulti-AZ、冗長化、単一障害点の考え方を初心者向けに整理します。
Solutions Architect Associateでは、高可用性設計が頻繁に問われます。特にMulti-AZ構成、冗長化、単一障害点の排除は必須です。
結論
高可用性を高めるには、1つのAZ、1つのインスタンス、1つのコンポーネントに依存しない構成にします。AWSでは、複数AZにまたがる設計が基本になります。
単一障害点とは
単一障害点とは、そこが止まるとシステム全体が止まる箇所です。1台だけのEC2、1つのAZだけにあるDB、冗長化されていないNAT Gatewayなどが例です。
SAAでは「この構成の弱点はどこか」「どうすれば可用性が上がるか」という形で問われます。
Multi-AZとは
Multi-AZは、複数のアベイラビリティゾーンを使う構成です。アベイラビリティゾーンはリージョン内で分離されたインフラの単位であり、複数AZにまたがって配置することで、1つのAZの問題がアプリケーション全体へ波及するリスクを下げます。AWS グローバルインフラストラクチャでリージョンとAZの関係を確認しておくと、設問の前提を読み取りやすくなります。
VPCでは、ロードバランサーやアプリケーションを複数AZのサブネットへ配置します。RDS Multi-AZは、データベースの高可用性を高める代表的な構成です。障害時にはDBインスタンスのフェイルオーバーが行われますが、接続の瞬断や復旧中の影響があり得るため、アプリケーション側でも接続エラーを適切に扱う必要があります。構成の詳細はAWS公式のAmazon RDS Multi-AZ配置を確認してください。読み取り性能向上を目的とするRead Replicaとは役割が違います。
ALBとAuto Scaling
Webアプリでは、ALBを複数AZのサブネットに配置し、複数AZへまたがるAuto ScalingグループのEC2へトラフィックを分散します。ALBのヘルスチェックで異常なインスタンスを振り分け対象から外し、Auto Scalingで必要な台数を維持します。アプリケーション層の可用性と、RDS Multi-AZによるデータベース層の可用性を別々に確認するのがポイントです。
典型的な流れは、利用者のリクエストをALBが受け、正常なAZのアプリケーションインスタンスへ転送し、アプリケーションがMulti-AZ構成のRDSへ接続する形です。障害時にどの層で切り替えが起きるかを図にせず言葉で説明できるようにしておくと、SAAの設問で選択肢を絞り込みやすくなります。
バックアップと高可用性は別の目的
バックアップは、削除やデータ破損などからデータを復元するための手段です。一方、高可用性は、コンポーネント障害が起きてもサービスを継続しやすくする設計です。RDS Multi-AZを選んだからといって、誤操作への復元手順や保持方針が不要になるわけではありません。
また、Multi-AZは停止時間を必ずゼロにする仕組みでも、特定の復旧時間やデータ損失量を保証する説明でもありません。対象サービス、障害の種類、アプリケーションの接続処理を踏まえ、必要な復旧目標を別途検討します。
コストと運用で確認すること
複数AZにまたがる構成では、単一AZ構成より利用するリソースやデータ転送の条件が増える場合があります。可用性要件に対して必要な範囲を選び、最新の料金は導入時に公式の料金ページで確認します。
運用では、AZごとの偏り、ロードバランサーのヘルスチェック、Auto Scalingの最小・最大容量、フェイルオーバー時のアプリケーションログとアラートを確認します。障害を待って初めて動作を知るのではなく、許容できる範囲で復旧手順や接続再試行を検証しておくことが大切です。
単一障害点を層ごとに洗い出す
可用性設計では「EC2を2台にする」で終わらせず、利用者からデータベースまでの経路を層ごとに確認します。DNS、ロードバランサー、アプリケーション、データベース、外部API、ネットワーク出口のどこか1つが停止したとき、サービス全体が使えなくならないかを考えます。
Web層では、ALBが複数AZのサブネットで受信し、アプリケーションインスタンスが複数AZへ分散しているかを見ます。インスタンスが複数台でも、同じAZに集中していればAZ障害には耐えられません。Auto Scalingは障害で失われたインスタンスを補うだけでなく、需要変動に応じた台数調整にも使われますが、配置先のAZやサブネットが適切でなければ高可用性の効果は限定されます。
データ層では、RDS Multi-AZのようなマネージド機能を利用する場合でも、アプリケーションが再接続できるかを確認します。フェイルオーバーの瞬間には接続エラーが発生し得るため、短時間の失敗を即座に利用者向けエラーへ固定せず、適切なタイムアウトと再試行を設計します。ただし、書き込みを無条件に再試行すると二重登録につながるため、操作の冪等性やトランザクションの状態をあわせて考える必要があります。
障害シナリオから構成を評価する
設計が要件を満たすかは、具体的な障害シナリオで確認すると分かりやすくなります。1台のアプリケーションインスタンスが異常になった場合、ALBのヘルスチェックがそのインスタンスへの転送を止め、残りの正常なインスタンスがリクエストを処理できるかを確認します。1つのAZが利用できない場合は、別AZのインスタンスに十分な余力があり、ロードバランサーとデータベースへの接続経路が残るかを見ます。
DBインスタンス側の障害では、Multi-AZのフェイルオーバー後に同じ接続先を通じてアプリケーションが復旧できるかを考えます。ここでRead Replicaを追加しても、主目的は読み取りトラフィックの分散であり、書き込み先の自動切り替えを期待する回答にはなりません。問題文が読み取り遅延の改善を求めるのか、障害時の継続運転を求めるのかを区別します。
さらに、リージョン全体の障害や誤操作、外部のSaaS障害はMulti-AZだけで解決する範囲ではありません。要件に応じて、バックアップ、別リージョンへの復旧計画、疎結合化、縮退運転など別の対策を組み合わせます。すべての障害に同じ構成で備えるのではなく、どの障害までを設計対象にするかを明確にします。
可用性と性能を混同しない
台数を増やすことは性能向上に寄与する場合がありますが、必ずしも可用性の向上を意味しません。たとえば、読み取り負荷が高いデータベースにRead Replicaを追加するのは性能のための選択です。反対に、処理量が少なくても1つのAZしか使っていないWebアプリは、AZ障害という可用性の問題を抱えます。
設問では「低レイテンシー」「急なアクセス増加」「障害時も継続」といった要件が混在することがあります。そのときは、ALB、Auto Scaling、Multi-AZ、Read Replica、キャッシュのそれぞれがどの要件を直接満たすかを対応付けます。1つのサービス名を暗記するより、性能、可用性、耐久性、運用負荷のどれに効く選択肢かを説明できることが重要です。
運用手順も設計に含める
高可用性の構成でも、デプロイ時にすべてのインスタンスを同時に停止させればサービスは停止します。ヘルスチェックを通過したインスタンスから段階的に切り替える、必要容量を確保してから更新する、異常があれば戻せるようにする、といった手順が可用性を支えます。
また、監視ではCPU使用率だけでなく、ALBの正常なターゲット数、HTTPエラー、接続失敗、DBのフェイルオーバーイベントなどを関連付けます。アラートを受け取った後に誰が何を確認するか、利用者への影響をどう判断するかまで決めておくと、構成図だけでは見えない運用上の単一障害点を減らせます。
可用性要件を言葉にする
「止まりにくくしたい」だけでは、どこまで冗長化すべきか判断できません。対象は利用者向けの画面なのか、管理画面なのか、夜間バッチなのかを区別し、停止した場合の影響を整理します。復旧にかけられる時間、失われてもよいデータの範囲、障害中に提供すべき最小機能を関係者で合意すると、Multi-AZが必要な層と、バックアップ復元で許容できる層を分けられます。
可用性を高めるほど、構成と運用の確認項目は増えます。複数AZに置いたつもりでも、設定変更が片方にしか適用されない、障害時の容量が足りない、といった運用上の問題は残ります。要件に見合う構成を選び、定期的にその前提を見直すことが実務では重要です。
SAAの選択肢を消去する例
「単一のEC2を複数AZに分散したALBの背後へ移し、DBの可用性を上げたい」という要件なら、ALB、複数AZのAuto Scaling、RDS Multi-AZを含む選択肢が要件に対応します。単一AZのインスタンスを大きくするだけの選択肢は性能に寄与してもAZ障害への対策になりません。Read Replicaだけを追加する選択肢も、読み取り負荷に関する条件がなければ主目的がずれます。
このように、各選択肢が「どの障害点を減らすか」を一文で説明してから比較すると、名称の似たサービスに引きずられません。高可用性、バックアップ、性能、耐久性のキーワードを問題文から拾い、それぞれに直接対応する仕組みを選びます。
構成変更時の注意
高可用性は、初回構築時の設定だけでは維持できません。新しいサブネットやインスタンスを追加したときに、複数AZへの配置、セキュリティグループ、ヘルスチェックの対象がそろっているかを確認します。片方のAZだけに新しい設定が入り、障害時に別AZで処理できない状態は、通常時の画面確認だけでは気付きにくい問題です。
また、利用量の増加でAuto Scalingの上限に達すると、冗長化していても十分な処理能力を維持できません。負荷試験や監視結果をもとに、障害時に残るAZだけで最低限のトラフィックを扱えるかを見直します。固定の台数を正解として覚えるのではなく、必要容量をどう確認するかを運用手順にします。
サーバーレスでも高可用性を意識する
Lambda、S3、DynamoDB、API Gatewayのようなマネージドサービスは、AWS側で可用性が高く設計されています。ただし、設定や依存先の設計を間違えると可用性は下がります。
たとえばLambdaをVPC内に配置してNAT Gatewayに依存させる場合、NAT Gatewayの冗長化を考える必要があります。
SAAで混同しやすい点
- 複数のEC2があっても、同じAZや同じサブネットだけに置かれていればAZ障害への備えとしては不十分です。
- Multi-AZは高可用性の選択肢であり、Read Replicaは主に読み取り負荷の分散に使います。
- バックアップは高可用性の代替ではありません。復元と継続運転の目的を分けて判断します。
- マネージドサービスを選んでも、VPC、名前解決、外部依存先などの単一障害点が残っていないか確認します。
試験で問われるポイント
- 単一AZ構成は障害に弱い
- Multi-AZは高可用性向上に使う
- Read Replicaは主に読み取り性能と読み取り分散に使う
- ALB + Auto ScalingはWeb層の冗長化に使う
- マネージドサービスでも依存関係を確認する
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。