SAA高性能なアーキテクチャの設計
あるヘルスケアSaaS企業が500のクリニックに患者管理システムを提供しています。各クリニックの利用パターンは予測困難で、朝の診療時間に急激にスパイクするクリニックもあれば、夜間・週末はほぼアイドル状態になるクリニックもあります。大型クリニックが新患者500名を一斉に登録するなど、数秒以内に突発的な高負荷が発生することもあります。既存のSQLスキーマと複雑なJOINクエリをそのまま利用しつつ、コストを最適化しながら高い可用性を確保するデータベース構成として最も適切なものはどれですか？
AAmazon Aurora MySQL プロビジョンドインスタンス（r6g.4xlarge）でリードレプリカを設定し、Aurora Auto Scalingでピーク時の読み取り負荷に対応する
Aurora MySQLプロビジョンドインスタンスでリードレプリカをAuto Scalingしても、書き込みキャパシティはプライマリインスタンスのサイズに固定されます。突発的な書き込みスパイクへの秒単位の対応が困難で、ピーク負荷に合わせた常時プロビジョニングによるコスト増も発生します。
BAmazon RDS MySQL Multi-AZ デプロイメント（m6g.2xlarge）を使用し、CloudWatchアラームをトリガーにスケールアップ操作を自動化する
RDS MySQL Multi-AZはインスタンスサイズが固定でリアルタイムスケーリング機能を持ちません。CloudWatchアラームによるスケールアップには数分かかり、数秒で発生する突発的なスパイクに対応できません。スケールアップ中はサービス中断リスクも伴います。
CAmazon Aurora Serverless v2 を 0.5〜128 Aurora Capacity Unit（ACU）の範囲で自動スケーリングするよう構成し、マルチAZで展開する
✓ 正解
Aurora Serverless v2は0.5〜128 ACUの範囲で秒単位の自動スケーリングが可能で、突発的な負荷スパイクにも即座に対応できます。夜間・週末のアイドル時は最小ACUに縮小しコストを最適化し、MySQL互換で既存のSQLスキーマとJOINクエリもそのまま利用できます。
DAmazon DynamoDBをオンデマンドキャパシティモードで設定し、既存のSQLクエリをDynamoDB APIに変換するアダプターレイヤーをLambdaで実装する
DynamoDBはNoSQLデータベースのため複雑なJOINクエリや既存のリレーショナルSQLスキーマをそのまま移行できません。LambdaベースのSQL変換アダプターは開発コストが膨大で、全SQLパターンへの対応は現実的でなくこの要件には不適切です。
解説
選択肢CのAmazon Aurora Serverless v2はサーバーレスのリレーショナルデータベースで、0.5〜128 ACUの範囲で秒単位の高速自動スケーリングが可能です。突発的な負荷スパイク（新患者500名の一斉登録など）に対しても数秒以内でキャパシティを増強でき、夜間・週末のアイドル時は最小ACUまで縮小しコストを削減します。MySQL互換のため既存のSQLスキーマとJOINクエリをそのまま利用でき、マルチAZ展開でフェイルオーバー時間も短縮されます。
選択肢AのAmazon Aurora MySQLプロビジョンドインスタンスはリードレプリカのAuto Scalingで読み取りスケールには対応できますが、書き込みキャパシティはプライマリインスタンスのサイズに固定され突発的な書き込みスパイクへの秒単位の対応が困難です。
選択肢BのAmazon RDS MySQL Multi-AZはインスタンスサイズが固定でリアルタイムのスケーリング機能を持ちません。CloudWatchアラームによるスケールアップには数分かかり、数秒で発生する突発的なスパイクへの対応が間に合いません。
選択肢DのAmazon DynamoDBはNoSQLデータベースのため複雑なJOINクエリや既存のリレーショナルSQLスキーマをそのまま移行できません。LambdaベースのSQL変換アダプターは開発コストが膨大で全SQLパターンへの対応は現実的ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →