SAP新しいソリューションのための設計
ある保険会社は、契約者向けの新しいクレーム処理APIをAWS上に構築します。APIはAmazon API Gateway（REST API）とAWS Lambdaで実装され、バックエンドはAmazon Aurora PostgreSQLです。ピーク時には数千件/秒の同時リクエストが瞬間的に発生し、Lambdaの同時実行数が急増するとAuroraの接続数が枯渇してエラーが頻発します。要件は次の通りです。突発的なトラフィックスパイクでもAuroraの接続数を一定以下に抑えること、クレーム登録処理は重複実行されてはならないこと（同一クレームIDの二重登録を防ぐ）、ピーク以外の時間帯のコストを最小化すること。これらをすべて満たす構成はどれですか。
ALambdaの予約済み同時実行数を高く設定してスループットを上げ、Lambda内でクレームIDをキーにAuroraへINSERTし一意制約違反を握りつぶす。AuroraはWriterインスタンスを大型化する
予約済み同時実行数を増やすとむしろAuroraへの同時接続が増えて枯渇を悪化させる。一意制約違反を握りつぶす設計は例外処理が脆弱で、Writer大型化は常時コスト増を招きピーク外コスト最小化の要件に反する。
BAPI GatewayとLambdaの間にAmazon SQS標準キューを挟み、Lambdaのイベントソースマッピングのバッチサイズと同時実行数で流量制御し、クレームIDをパーティションキーにDynamoDBの条件付き書き込みで冪等性を確保してからAuroraへ書き込む
SQS標準キューで流量制御と冪等性は実現できるが、同期的なクレーム処理APIにキューを挟むと即時応答が返せず、APIの応答モデルと要件に合致しない非同期化になってしまう。
CAPI GatewayとLambdaの間にAmazon SQS FIFOキューを挟み、メッセージグループIDをクレームIDにして順序保証と重複排除を行い、Lambdaのイベントソースマッピングの同時実行数を制限してAuroraへ書き込む
SQS FIFOはメッセージグループ単位の順序保証と重複排除を持つが、同期APIの非同期化問題に加え、FIFOのスループット上限により数千件/秒の瞬間スパイクで処理が詰まりやすく要件を満たせない。
DLambdaとAuroraの間にAmazon RDS Proxyを配置して接続をプールし、Lambda内でクレームIDをキーにDynamoDBの条件付き書き込みで冪等性を確保してからAuroraへ書き込む。Lambdaはオンデマンド同時実行のまま運用する
✓ 正解
RDS Proxyが接続をプーリングしてLambda急増時もAurora接続数を一定に抑え、DynamoDB条件付き書き込みでクレームID単位の冪等性を保証する。Lambdaはオンデマンドのままでピーク外コストも最小化でき全要件を満たす。
解説
突発的なLambda同時実行の急増でAuroraの接続が枯渇する典型的な問題には、Amazon RDS Proxyが最適です。RDS Proxyは確立済み接続をプーリングして再利用し、Lambdaの同時実行数が急増してもバックエンドへの実接続数を一定範囲に抑えます。
冪等性はDynamoDBの条件付き書き込み（attribute_not_exists）でクレームIDの一意性を保証してから処理することで、リトライや重複到達があっても二重登録を防げます。
Lambdaはオンデマンドのままなので、ピーク以外は呼び出し回数に応じた課金となりコストを最小化できます。
選択肢Aの予約済み同時実行数の引き上げとWriter大型化は、接続枯渇の根本対策にならず、常時大型インスタンスでコストも増える。一意制約違反の握りつぶしは例外処理が複雑で堅牢性に欠ける。
選択肢BのSQS標準キューは流量制御と冪等性確保はできるが、同期APIに非同期キューを挟むとレスポンスが即時返らずクレーム処理APIの応答モデルに合わない。
選択肢CのSQS FIFOキューも同様に非同期化の問題に加え、FIFOはスループット上限があり数千件/秒のスパイクで詰まりやすい。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →