SAA弾力性に優れたアーキテクチャの設計
あるスタートアップ企業が、ECサイト向けのWebアプリケーションをAWSで運用しています。データベース負荷は極めて変動が大きく、深夜帯はほぼアイドル状態ですが、ビジネスピーク時には通常の20倍のトランザクションが発生します。DBチームは小規模で、スケーリング操作の手動実行は避けたい考えです。可用性・コスト効率・運用負荷の3点を最もバランスよく満たすデータベース構成はどれか。
Aピーク負荷に合わせたサイズのAurora MySQL プロビジョンド（db.r6g.4xlarge、マルチAZ）を構成し、Compute Savings Plansで1年分のコストを前払いする
ピーク向けサイジングでは深夜帯も大型インスタンスが稼働し続けるためコスト非効率。Serverless v2のような細粒度の自動スケーリングがなく、変動負荷への対応としては不適切。
BAurora MySQL Serverless v2（マルチAZ）を最小ACU=0.5・最大ACUをピーク要件に合わせて設定し、Auroraレプリカを1台追加してフェイルオーバーを高速化する
✓ 正解
Aurora Serverless v2はACUをリアルタイムに自動増減し、アイドル時のコストを最小化しながらピーク時も即応できる。マルチAZ＋Auroraレプリカで高可用性と高速フェイルオーバーを確保でき、3要件を最もバランスよく満たす。
CRDS MySQL マルチAZ（db.m6g.2xlarge）にリードレプリカを2台追加し、アプリケーション側のロジックで読み取りクエリをレプリカに振り分けて負荷分散する
RDS MySQLはServerless v2相当の自動スケーリングに非対応。リードレプリカへのクエリ振り分けにはアプリケーション改修が必要で、運用負荷削減の観点から要件を満たしにくい。
DAurora MySQL プロビジョンド（db.r6g.xlarge、シングルAZ）を使用し、CloudWatchアラームを起点にLambdaがインスタンスクラス変更を自動実行する
シングルAZは単一障害点であり可用性要件を満たさない。Lambdaによるインスタンスクラス変更は変更中のダウンタイムを伴い、スケーリング速度も変動負荷への追従には不十分。
解説
Aurora Serverless v2はリクエスト負荷に応じてACU（Aurora Capacity Unit）を0.5単位で細かく増減させ、アイドル時のコストを最小化しながらピーク時も瞬時にスケールアップします。最小ACUを0.5に設定することで深夜帯の課金を抑え、最大ACUをピーク要件に合わせることで20倍の負荷増にも自動対応できます。マルチAZにAuroraレプリカを1台追加すると、Writerインスタンス障害時のフェイルオーバーが数十秒以内に完了し、高い可用性を維持します。DBチームによるスケーリング操作は不要で、運用負荷を大幅に削減できます。
選択肢Aの Aurora MySQL プロビジョンドは、ピーク向けサイジングだと深夜帯も大型インスタンスが稼働し続けるためコスト非効率で、Serverless v2のような細粒度の自動スケーリングができません。
選択肢Cの RDS MySQLは、Serverless v2相当の自動スケーリングがなく、リードレプリカへの振り分けにアプリケーション改修が必要なため運用負荷が高くなります。
選択肢Dの プロビジョンド＋Lambdaによるインスタンスクラス変更は、変更処理中にダウンタイムが生じるうえ、シングルAZは単一障害点となり可用性要件を満たせません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →