SAAコスト最適化されたアーキテクチャの設計
あるスタートアップ企業がAmazon RDS MySQLを使用するWebアプリケーションを運営しています。データベースの利用パターンは次の通りです：
平日日中は高い負荷が継続する、
深夜・週末はほぼアイドル状態、
月に数回のマーケティングキャンペーン時に通常の50倍のトラフィックスパイクが突発的に発生する、
DB管理チームの運用負荷を最小化したい。コストと運用効率を最も最適化するデータベース移行先はどれか。
AAmazon RDS MySQLをdb.r6g.4xlargeのMulti-AZ構成にアップグレードし、ピーク時の負荷に備える
db.r6g.4xlargeはハイエンド固定インスタンスであり、深夜・週末のアイドル時も一定の課金が発生し続ける。月数回の50倍スパイクに合わせたサイジングでは通常時のリソース無駄が大きく、コスト最適化の観点で最も非効率な選択肢。
BAmazon Aurora MySQL Serverless v2（最小0.5 ACU〜最大128 ACU）に移行する（ACU：Aurora Capacity Unit、データベース処理能力の単位）
✓ 正解
Aurora Serverless v2はACU（Aurora Capacity Unit）を秒単位で自動スケールし、50倍のトラフィックスパイクに即応する。アイドル時は最小0.5 ACUまで縮退してコストを最小化でき、自動管理機能によりDB運用負荷も最小化される最適解。
CAmazon Aurora MySQL プロビジョニング済みインスタンスを使用し、Read Replicaを複数台追加してスケールアウトする
プロビジョニング済みAuroraインスタンスはアイドル時も固定コストが発生し続ける。Read Replicaの追加も常時稼働コストがかかり、突発的な50倍スパイクへの即座の自動スケールには対応できないためコストと運用効率の両面で劣る。
D現行RDS MySQLにAmazon ElastiCache for Redisを追加し、頻繁なクエリをキャッシュしてDB負荷を削減する
ElastiCacheはキャッシュヒット率が高い定常クエリには有効だが、突発的・不規則なマーケティングキャンペーンスパイクへの対応は不確実。既存RDSとの二重管理により運用負荷が増加し、DB管理負荷最小化の要件にも反する。
解説
Aurora Serverless v2はACU（Aurora Capacity Unit）を秒単位で自動スケールし、突発的な50倍スパイクにも即応できます。アイドル時は最小0.5 ACUまで縮退するため深夜・週末のコストを大幅に抑えられます。
選択肢Aは、db.r6g.4xlargeはハイエンド固定インスタンスのためアイドル時も常時課金され、突発スパイクへの即応性もなく最も非効率な選択肢です。
選択肢Bは、Aurora Serverless v2は秒単位のオートスケールにより50倍スパイク対応とアイドル時コスト最小化を両立でき、自動管理機能により運用負荷も最小化される最適解です。
選択肢Cは、プロビジョニング済みAurora + Read Replicaは常時稼働コストが発生し続け、突発的な50倍スパイクへの即座の自動スケールには対応できません。
選択肢Dは、ElastiCacheはキャッシュヒット率に依存し、突発・不規則なキャンペーンスパイクへの対応が不確実なうえ、既存RDSとの二重管理により運用負荷が増加します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →