485-AWS SAP AWS 「理論・実践・一問道場」TooManyRequestsException

type

status

date

slug

summary

理論

1. DynamoDB のスループット制限

ProvisionedThroughputExceededException は、DynamoDB の設定された書き込みキャパシティ（WCU）を超えたときに発生します。これを解決するために、DynamoDB の書き込みキャパシティユニット（WCU）を増加させることが効果的です。

DynamoDB Auto Scaling を使用すると、トラフィックに応じて自動でキャパシティをスケーリングできます。

2. Lambda のメモリ設定

AWS Lambda のパフォーマンスは、割り当てたメモリに依存します。メモリを増加させると、より多くの CPU リソースも利用可能になり、処理が高速化します。

Lambda 関数のタイムアウト設定も確認し、適切な時間を設定することが重要です。

3. Kinesis とバッチ処理

Amazon Kinesis は、リアルタイムでのデータストリーミングを処理するためのサービスです。Kinesis のデータストリームを利用することで、リアルタイムデータを効率的に処理し、バッチ処理にてデータをまとめて処理することができます。

Kinesis はスケーラブルであり、データの流れを効率的に管理し、Lambda や他のサービスに負荷をかけすぎずにデータ処理が可能です。

4. API Gateway と Lambda の統合

Amazon API Gateway を使用してデータを受信し、その後 Lambda で処理する方法は一般的ですが、大量のリクエストが来ると Lambda に過負荷がかかる場合があります。このような場合、Kinesis や SQS などのメッセージングサービスを使用してデータフローを効率的に管理することが推奨されます。

まとめ：

DynamoDB の書き込みキャパシティを増やす と Lambda にメモリを増やす ことで、エラーや遅延を減らすことができます。

Kinesis を使用してデータをストリーム処理し、Lambda での負荷を分散させることが効率的です。

これらの知識を適用することで、データ処理のパフォーマンスを最適化し、エラーを減少させることができます。

実践

略

一問道場

問題 #485

あるユーティリティ企業が、スマートメーターから5分ごとに使用データを収集し、時間帯別メーター測定を行いたいと考えています。メーターがデータをAWSに送信すると、そのデータはAmazon API Gatewayに送られ、AWS Lambda関数によって処理され、Amazon DynamoDBテーブルに保存されます。パイロットフェーズでは、Lambda関数の実行には3～5秒かかりました。スマートメーターの数が増えると、エンジニアはLambda関数の実行時間が1～2分かかるようになったことに気づきました。さらに、新しいタイプのメトリクスがデバイスから収集されることで、実行時間が増加しています。DynamoDBでPUT操作を行う際に、多くのProvisionedThroughputExceededExceptionエラーが発生し、Lambdaからは多くのTooManyRequestsExceptionエラーが発生しています。

これらの問題を解決するためには、どの変更を行うべきですか？（2つ選んでください。）

A. DynamoDBテーブルの書き込み容量単位を増やす。

B. Lambda関数に割り当てるメモリを増やす。

C. スマートメーターから送信するペイロードサイズを増やす。

D. データをAmazon KinesisデータストリームにAPI Gatewayからストリーミングし、バッチで処理する。

E. Amazon SQS FIFOキューでデータを収集し、各メッセージを処理するLambda関数をトリガーする。

解説

この問題では、Lambda関数の処理時間が増加し、DynamoDBやLambdaからのエラーが発生している状況に対応するため、適切な変更を選ぶ必要があります。具体的には、ProvisionedThroughputExceededExceptionエラー（DynamoDBでのスループット超過）やTooManyRequestsExceptionエラー（Lambda関数がリクエストに過負荷）に対処する方法を考えます。

選択肢ごとに解説します。

A. DynamoDBテーブルの書き込み容量単位を増やす

解説: DynamoDBでは、データの読み書きにプロビジョンドスループットが使用されます。このエラー（ProvisionedThroughputExceededException）は、DynamoDBの書き込み容量（Write Capacity Units）が不足している場合に発生します。スマートメーターが増えてデータ量が増加するため、DynamoDBの**書き込み容量単位（WCU）**を増加させることで、スループットを確保し、エラーを回避できます。

結論: この選択肢は、DynamoDBでのエラー解決に有効です。

B. Lambda関数に割り当てるメモリを増やす

解説: Lambda関数の実行時間が長くなる原因の一つとして、メモリ不足が考えられます。メモリを増やすことで、関数の実行速度が改善される可能性があります。Lambdaの処理が速くなることで、実行時間を短縮できるため、TooManyRequestsExceptionエラーを軽減する効果も期待できます。

結論: Lambda関数のメモリ増加は、処理の効率を上げ、エラーを減らすために有効です。

C. スマートメーターから送信するペイロードサイズを増やす

解説: ペイロードサイズを増加させることは、必ずしも問題を解決する方法ではありません。むしろ、ペイロードが大きくなると、処理にかかる時間が増え、Lambdaのタイムアウトやエラーが発生するリスクが高くなります。この場合、ペイロードサイズの増加は問題を悪化させる可能性があるため、適切な解決策ではありません。

結論: この選択肢は問題解決にはつながりません。

D. データをAmazon KinesisデータストリームにAPI Gatewayからストリーミングし、バッチで処理する

解説: Kinesisは、高スループットでデータをストリーム処理するためのサービスです。API Gatewayから直接Kinesisにデータを流し、Lambda関数でバッチ処理を行うことで、リクエストのスパイクを分散させることができます。これにより、DynamoDBの負荷を分散し、Lambda関数へのリクエストを効率的に処理できるようになります。

結論: Kinesisを利用することで、データ処理をバッチ化し、システム全体のスループットを向上させることができるため、適切な解決策です。

E. Amazon SQS FIFOキューでデータを収集し、各メッセージを処理するLambda関数をトリガーする

解説: Amazon SQS（Simple Queue Service）は、メッセージのキューイングに使用されます。SQS FIFO（First-In-First-Out）キューを使用すると、メッセージの順序を保証しつつ、バックエンドで並列処理を行うことができます。この方法を使用することで、Lambda関数の負荷を分散し、TooManyRequestsExceptionエラーを軽減できます。さらに、各メッセージを個別に処理できるため、処理の効率化が図れます。