Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
DynamoDB ストリームの処理に時間がかかる原因を教えてください。
Amazon DynamoDB ストリームの処理に時間がかかっている理由を把握したいです。
解決策
AWS Lamdba で DynamoDB ストリームを使用する場合、レコードがテーブルに書き込まれても、Lambda では処理されない場合があります。これらのレコードの処理には、数時間かかる場合もあります。原因をトラブルシューティングするには、 Lambda IteratorAge メトリクスを確認します。
IteratorAge が増加している場合、Lambda が DynamoDB ストリームに書き込まれるレコードを効率的に処理していないことを示しています。IteratorAge は、次の原因で増加する場合があります。
呼び出しエラー
Lambda は、レコードのバッチを順番に処理し、エラー発生時には再試行するように設計されています。関数が呼び出されるたびに毎回エラーを返す場合も、Lambda 関数はレコードの処理を試みます。関数は、レコードの有効期限が切れるか、レコードがイベントソースマッピングで設定された最大保存期間を超えるまで、継続してレコードの処理を試行します。ストリーム内のレコードが処理されていないことが原因で、Iteratorage メトリクスが急増する場合があります。Lambda エラーメトリクスを参照することで、エラーメトリクスの急増を確認できます。Lambda ログでも詳細を確認できます。
呼び出しエラーによる Iteratorage メトリクスの急増を防ぐには、レコードをデッドレターキュー (DLQ) に送信します。イベントソースマッピングの作成時に、特定のパラメータに次の情報を入力します。
- 再試行回数: このパラメータにより、Lambda 関数にエラーがあるときに、その関数を実行する回数を指定します。ユースケースに基づいてこの値を更新することで、関数が特定の回数再試行した場合はレコードを DLQ に送信します。
- エラー発生時にバッチを分割する: このパラメータにより、関数がバッチを再試行する前に、そのバッチを 2 つのバッチに分割します。このパラメーターを使用すると、バッチが分割され、小さいバッチで呼び出しを続行します。バッチを分割することで、呼び出しエラーの原因となった不良レコードを切り分けることができます。
スロットリングエラー
DynamoDB ストリームを使用する場合、スロットリングを避けるため、シャードあたりのコンシューマーの数は 2 以内にすることがベストプラクティスです。Lambda はレコードを順番に処理するため、現在の呼び出しがスロットリングされている場合は、Lambda はレコードの処理を続行できません。3 つ以上のコンシューマーを使用する必要がある場合は、Amazon Kinesis またはファンアウトパターンを使用してください。または、Lambda で同時実行制限を使用してスロットリングを防止します。
Lambda のスループット
Lambda のスループットは、Lambda 関数を 1 回呼び出して単一のレコードまたはレコードのバッチを処理するのにかかる時間です。Lambda 関数のスループットに影響する可能性がある要因を次に示します。
実行時間
Duration メトリクスの値が高い場合、関数のスループットが低いことが原因で、その関数の IteratorAge メトリクスが増加します。関数の実行時間を短縮するには、関数に割り当てられるメモリを増やします。
関数コードを最適化することでも、レコードの処理に必要な時間を短縮できます。
Lambda の同時実行数
同時実行数は、Lambda 関数が同時に処理している進行中のリクエストの数です。Lambda の同時呼び出し数を増やすことで、ストリームレコードの処理を改善できる場合があります。各同時リクエストに対し、Lambda は実行環境の個別のインスタンスをプロビジョニングします。Lambda の同時実行の最大数は次のように計算されます。
同時実行数 = シャード数 x シャードあたりの同時バッチ数 (並列化係数)
DynamoDB ストリームでは、テーブルのパーティション数とストリームシャードの数は 1 対 1 でマッピングされます。パーティションの数は、テーブルのサイズとそのスループットによって決まります。テーブルの各パーティションは、最大 3,000 の読み取りリクエストユニットまたは 1,000 の書き込みリクエストユニット、または両者の線形組み合わせを処理できます。したがって、テーブルのプロビジョニング容量を増やし、シャードの数を増やすことで同時実行数を増やすことができます。イベントソースマッピングでは、シャードあたりの同時バッチの数を設定できます。デフォルトは 1 で、最大 10 まで増やすことができます。たとえば、テーブルに 10 個のパーティションがあり、シャードあたりの同時バッチが 5 に設定されている場合、最大 50 件の同時実行が可能です。
アイテムレベルの変更をいつでも正しい順序で処理するために、同じパーティションキーを持つ項目は同じバッチに移動します。テーブルパーティションキーには高いカーディナリティが必要であり、トラフィックはホットキーを生成できません。たとえば、シャードあたりの同時バッチ数の値を 10 に設定しており、書き込みトラフィックが 1 つのパーティションキーを対象としている場合、シャードあたりの同時実行は 1 件のみとなります。
バッチサイズとバッチ期間
Lambda のバッチ処理動作を正しく調整していない場合、関数のスループットが低下する場合があります。DynamoDB ストリームの処理を最適化するには、ユースケースに応じてバッチ期間とバッチサイズを調整します。
バッチサイズの設定値が小さすぎると、少数のレコードで関数が頻繁に呼び出されます。頻繁な呼び出しにより、ストリームの処理が遅くなります。バッチサイズの値が高すぎると、関数の実行時間が長くなる可能性があります。
バッチ期間の値とその期間内のレコード数が最適化されていない場合、同じシャードが不必要に呼び出される場合があります。このような不必要な呼び出しにより、ストリームの処理が遅くなる可能性があります。バッチ期間の値が高すぎる場合、関数がストリームを処理するまでの待ち時間が長くなる可能性があります。このように処理時間が長くなると、IteratorAge が増加します。
スループットを向上させて IterAtorage を減らすには、バッチ期間とバッチサイズの複数の組み合わせをテストすることがベストプラクティスです。
