SAA-C03 · LESSON 2

レジリエントなアーキテクチャの設計26% · 2項目

スケーラブルで疎結合なアーキテクチャと、高可用性・耐障害性のアーキテクチャの設計を学びます。

2.1スケーラブルで疎結合なアーキテクチャを設計する

2.1 Design scalable and loosely coupled architectures.

概念

疎結合は、構成要素の間に SQS（キュー）・SNS（通知）・EventBridge（イベント）を挟み、一方の遅延や障害が他方に波及しないようにする設計です。処理はステートレスにしてセッションを ElastiCache や DynamoDB に置き、Auto Scaling で水平に拡張します。サーバーレス（Lambda・API Gateway・Step Functions）や、コンテナ（ECS・EKS・Fargate）も選択肢です。

仕組み・手順

同期の呼び出しを、必要に応じて SQS を挟んだ非同期の処理にする
1 つのイベントを複数の処理に配るときは SNS から複数の SQS へ（ファンアウト）
アプリをステートレスにして、セッションを外部に置く
SQS のキューの長さなどを指標に Auto Scaling する
複数の手順は Step Functions で制御し、失敗時の再試行を定義する

業務での例

注文を SNS に発行し、在庫・請求・通知の各 SQS にファンアウトして、各処理を独立に拡張する。請求の処理が停止しても注文はキューに残る。

紛らわしい点・試験の注意

SQS 標準キューは少なくとも 1 回の配信（重複の可能性）、FIFO キューは順序と 1 回だけの処理
可視性タイムアウトは処理時間より長くする
処理に失敗し続けるメッセージはデッドレターキューへ

ミニクイズ

Q1. EC2 で動く Web アプリを Auto Scaling で水平スケーリングしたい。ログイン状態がサーバーのメモリに保存されているため、台数が変わるとログアウトされてしまう。最も適切な対策はどれか。

セッション情報を ElastiCache や DynamoDB に保存して、サーバーをステートレスにする
利用者にログイン状態を保存しないよう、ブラウザの設定変更を依頼する
ALB のヘルスチェックを無効にして、Auto Scaling でサーバーが入れ替わらないように固定する
Auto Scaling をやめて、最も大きなインスタンス1台で運用する

答えと解説を見る

正解：A　セッション情報を ElastiCache や DynamoDB に保存して、サーバーをステートレスにする

セッションを外部のデータストアに置くと、どのサーバーでも同じセッションを扱えるため、台数を自由に増減できる。スティッキーセッションは一時的な回避策にとどまる。

Q2. ECS で動くコンテナ化された受注アプリのタスク数を、SQS キューに溜まったメッセージの数に応じて増減させたい。最も適切な方法はどれか。

CPU の使用率を目標にしたターゲット追跡で、ECS のタスクを増減する
ECS の容量プロバイダーで、EC2 のインスタンスの数だけを増減する
キューのメッセージ数をもとに、ECS サービスの Auto Scaling を設定する
EventBridge のスケジュールで、平日の昼だけタスク数を増やす

答えと解説を見る

正解：C　キューのメッセージ数をもとに、ECS サービスの Auto Scaling を設定する

ECS サービスの Auto Scaling は、CloudWatch のメトリクス（キューの深さなど）に基づいてタスク数を増減できる。【他の選択肢】CPU の使用率はキューの溜まり具合を反映しないことがある。スケジュールでは実際の流量に追従しない。容量プロバイダーは基盤のインスタンスの調整で、タスク数は増えない。

参考リンク

2.2高可用性・耐障害性のアーキテクチャを設計する

2.2 Design highly available and/or fault-tolerant architectures.

概念

高可用性の基本は複数の AZ への分散（ALB＋Auto Scaling グループ、RDS マルチ AZ）です。リージョン規模の災害への対策（DR）には、コストと RTO・RPO に応じて、バックアップと復元 → パイロットライト → ウォームスタンバイ → マルチサイト（アクティブ/アクティブ）の 4 つの戦略があります。Route 53 のヘルスチェックとフェイルオーバーのルーティングで切り替えます。

仕組み・手順

RTO（復旧までの時間）と RPO（失ってよいデータの期間）を決める
Web・アプリは複数 AZ の Auto Scaling グループと ALB で構成する
DB は RDS マルチ AZ（同期レプリケーション・自動フェイルオーバー）にする
DR の戦略を RTO・RPO とコストで選び、別リージョンにレプリケーションする
Route 53 のフェイルオーバーで DR のリージョンに切り替え、定期的に訓練する

業務での例

RTO 1 時間・RPO 15 分の要件に対し、別リージョンに縮小した構成を常時動かすウォームスタンバイと Aurora グローバルデータベースを採用する。

紛らわしい点・試験の注意

RDS のリードレプリカは読み取りの拡張が主目的（マルチ AZ が可用性）
RTO・RPO が短いほど DR のコストは高い（バックアップと復元が最も安い）
パイロットライトはコアの DB だけを常時複製し、サーバーは災害時に起動する

ミニクイズ

Q1. Web アプリの可用性を高めるため、単一障害点をなくしたい。最も適切な構成はどれか。

性能の高いインスタンス1台に、すべての処理を集約する
ALB と Auto Scaling グループを複数の AZ に配置し、データベースはマルチ AZ にする
2台の EC2 を同じ AZ に置き、片方は停止しておく
データベースを1台の EC2 のインスタンスストアに置き、毎日の業務終了後に手作業で別のサーバーへコピーする

答えと解説を見る

正解：B　ALB と Auto Scaling グループを複数の AZ に配置し、データベースはマルチ AZ にする

複数の AZ に分散し、ロードバランサー・自動スケーリング・マルチ AZ の DB で、どこか1か所の障害でもサービスを続けられるようにする。

Q2. RPO と RTO の説明として正しいものはどれか。

RPO は許容できるデータ損失の時間幅、RTO は停止から復旧までに許容できる時間である
RPO は復旧までの時間、RTO は保存できるデータの量である
RPO は利用するリージョンの数、RTO は利用するアベイラビリティーゾーンの数を表す指標である
RPO と RTO は同じ意味で、どちらも費用の上限を表す

答えと解説を見る

正解：A　RPO は許容できるデータ損失の時間幅、RTO は停止から復旧までに許容できる時間である

RPO（目標復旧時点）はどこまで遡ってデータを失ってよいか、RTO（目標復旧時間）はどれだけの時間で復旧すべきか。これらで DR の方式を選ぶ。

参考リンク

レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。

ご利用上の注意（非公式・独自問題・合格保証なし）

本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
Amazon Web Services、AWS、および関連するマークは、米国その他の国における Amazon.com, Inc. またはその関連会社の商標です。本サイトは AWS（Amazon Web Services）と提携しておらず、AWS による承認・推奨を受けたものではありません。
本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
本模擬試験の正答率は、公式試験の換算（スケール）スコア（合格 720）とは換算できず、合否を予測するものではありません。
未ログイン時の進捗はこのブラウザ内（localStorage）に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。