SAP既存のソリューションの継続的改善
ある小売企業は、商品カタログを提供するパブリックREST APIを、Amazon API GatewayとAWS Lambdaで構成し、バックエンドにAmazon Aurora PostgreSQL（Multi-AZ）を使用しています。通常時のパフォーマンスは良好ですが、大規模セール時にはLambdaの同時実行数が急増し、AuroraのデータベースコネクションがすぐにMax connectionsに達して接続エラーが発生します。また、同一の人気商品に対する読み取りクエリが繰り返し実行され、プライマリインスタンスのCPU使用率が高騰しています。アプリケーションの大幅な改修は避けたうえで、ピーク時の読み取りレイテンシーを低減し、コネクション枯渇とデータベース負荷の両方を改善する必要があります。最も適切な対応はどれですか。
AAuroraの前段にAmazon RDS Proxyを導入してLambdaからのコネクションをプールし再利用したうえで、人気商品の読み取りにはAmazon ElastiCache for Redisのキャッシュアサイドを追加して負荷を軽減する
✓ 正解
RDS ProxyがコネクションをプールしてLambdaの急増によるMax connections到達を防ぎ、ElastiCache for Redisのキャッシュアサイドが繰り返される人気商品の読み取りを吸収してプライマリのCPU負荷とレイテンシーを下げるため、2つの課題に最小改修で対処できる。
BカタログテーブルをAmazon DynamoDBへ移行してDynamoDB Accelerator（DAX）を有効化し、Lambdaからの読み取りをマイクロ秒のレイテンシーで処理してリレーショナルのコネクション上限を解消する
DynamoDBへの移行はテーブル設計やクエリの全面書き換えを伴い「大幅な改修は避ける」制約に反する。DAXはマイクロ秒読み取りを実現するがDynamoDB専用であり、既存のリレーショナル資産をそのまま活かせない。
CAuroraのインスタンスクラスをスケールアップして3台のリードレプリカを追加し、Lambdaの読み取りをリーダーエンドポイントに振り分けてコネクションとクエリ負荷を複数のインスタンスへ分散させる
リードレプリカは読み取りを分散できるが、Lambda急増時のコネクション枯渇そのものは平準化されず接続エラーは残る。スケールアップも一時しのぎで、繰り返しクエリのキャッシュ効果は得られずコスト効率も低い。
DAurora Serverless v2のオートスケーリングを有効化し、Lambdaにプロビジョニングされた同時実行を設定してピーク時もコネクションをウォームに保ち接続エラーを回避する
Aurora Serverless v2はキャパシティを自動調整し、プロビジョニングされた同時実行はコールドスタートを抑えるが、コネクションのプーリングや再利用は行わない。繰り返しクエリによるCPU負荷も解消されないため根本対策にならない。
解説
課題はコネクション枯渇と同一クエリの繰り返しによるCPU高騰の2点であり、両方に対処する必要がある。
RDS ProxyはLambdaの急激なスケールに対してコネクションプールを維持・再利用し、データベースへの接続数を平準化して枯渇を防ぐ。加えてElastiCache for Redisのキャッシュアサイドで人気商品の読み取りをキャッシュから返せば、繰り返しクエリがプライマリに到達せずCPU負荷とレイテンシーを同時に低減できる。アプリ改修も最小限で済む。
選択肢1のDynamoDB／DAXはデータモデルの全面移行を伴い大幅改修となるため制約に反する。
選択肢2のリードレプリカは書き込み・接続の根本負荷を減らせず、コネクション数の平準化にも寄与しない。
選択肢3のAurora Serverless v2はキャパシティ調整のみで、繰り返しクエリの負荷やコネクション再利用の課題を直接は解決しない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →