Question#31(SAP-C02)
ある電力会社は、時間帯別料金の計測のために、スマートメーターから 5 分ごとに使用量データを収集したいと考えています。メーターが AWS にデータを送信すると、データは Amazon API Gateway に送られ、AWS Lambda 関数で処理され、Amazon DynamoDB テーブルに保存されます。パイロット段階では、Lambda 関数の処理時間は 3～5 秒でした。
スマートメーターの台数が増えるにつれ、Lambda 関数の処理時間が 1～2 分に伸びました。さらに、収集するメトリクスの種類が増えるにつれて処理時間も増加しています。DynamoDB への PUT 処理では多数の ProvisionedThroughputExceededException が発生し、Lambda でも多数の TooManyRequestsException が発生しています。 これらの問題を解決するために必要な変更の組み合わせはどれですか。（2 つ選択）（2つ選択）
正解：A, D
現状の障害は大きく 二層にあります。まず、DynamoDB で ProvisionedThroughputExceededException が出ているのは、書き込み要求が WCU の上限を超過しているためです。よって A（WCU の増強） は直接的な是正策です。次に、Lambda の TooManyRequestsException は、同時実行のスパイクや呼び出し頻度の増大でスロットリングされ、関数の滞留・再試行・処理時間の悪化を引き起こしている典型です。D（Kinesis を介した取り込みとバッチ処理） を導入すると、API Gateway からの要求をまず 耐久性のあるストリームに吸収し、Lambda はイベントソースマッピングで バッチ単位に処理できます。これにより 呼び出し回数と同時実行の平準化、DynamoDB への書き込みのバッチ化（BatchWriteItem など） が可能になり、スロットリングとスパイクによる遅延を抑制できます。結果として、DynamoDB 側は WCU 増強（A）、アプリ側は取り込みの平滑化とバッチ処理（D） という両輪で、発生している 2 種類の例外を根本から緩和します。
コメント