Lambda 関数の IteratorAge メトリクスが上がるのはなぜですか ?

ストリームベースの呼び出しの場合、Lambda は IteratorAge メトリックスを発行します。イテレーターの経過時間とは、バッチの最後のレコードが記録されてから、Lambda がレコードを読み取るまでの間の時間です。イテレーターの経過時間は、Lambda 関数の実行時間、シャードの数、バッチサイズなどの他のパラメータによって変化します。詳細については、 AWS Lambda の CloudWatch メトリクスを参照してください。

一般に、イテレーターの経過時間は、ストリームに書き込まれるデータ量を関数が処理しきれない場合に長くなります。

これらの各 Lambda 関数のパラメータと利用方法がイテレーターの経過時間に及ぼす影響を確認します。次に、イテレーターの経過時間を減らすために関数を再設定します。

Duration

Lambda 関数の実行時間が長いと、イテレーターの経過時間が長くなる可能性があります。この時間は、レコードのバッチを処理するのに必要な時間です。実行時間を短くすると、スループットが向上し、イテレーターの経過時間は短くなります。

関数の実行時間を短くするには、次を試してみてください。

• 関数に割り当てられるメモリ量を増やします。これにより、関数はレコードをより高速に処理できるようになり、イテレーターの経過時間は短くなります。
• レコードを最適化して、レコードの処理時間を短くします (たとえば、並列呼び出しを使用する、非同期メソッドを使用するなど)。

AWS X-Ray も、関数の実行時間最適化に役立ちます。詳細については、 AWS Lambda と AWS X-Ray および AWS Lambda 関数の計測を参照してください。

シャード数

レコードが均等に分散されていると想定した場合、ストリーム内のシャード数を増やすと、イテレーターの経過時間は短くなります。これはベストプラクティスです。これは、ストリーム内のシャード数が、Lambda 関数の最大同時実行数に対応しているからです。基本的に、シャードが多いほど同時実行数は多くなり、スループットは高くなります。詳細については、ストリームイベントの呼び出しを参照してください。

注意 : シャードを分割しても、イテレーターの経過時間には直接影響しません。既存のレコードは書き込み先のシャードに保たれます。これらのシャードがバックログに追いつくと、それらのイテレーター経過時間は短くなります。

バッチサイズ

Lambda 関数の動作方法によっては、バッチサイズを変更すると、イテレーターの経過時間が短くなることがあります。

たとえば、ダウンストリーム呼び出しがバッチで行われる場合など、関数の実行時間がイベントのレコード数にはほとんど関係していないとします。この場合、バッチサイズを大きくすれば、スループットが向上し、イテレータの経過時間は短縮されます。

ただし、それぞれのレコードが同期したダウンストリーム呼び出しをトリガーしている場合など、関数の実行時間がイベントのレコード数に大きく依存していることもあります。この場合、バッチサイズを調整しても、イテレーターの経過時間が実質的には変わらないことがあり得ます。

詳細については、ストリームイベントの呼び出しを参照してください。

エラー

呼び出しエラーは、Lambda 関数でイベントの処理や同じイベントの繰り返し処理に長時間かかる原因となることがあります。イベントのレコードはシーケンシャルに読み取られるため、レコードのバッチが再試行のたびにエラーを生じていると、関数は後のレコードに進むことができなくなります。このような場合、イテレータの経過時間はそれらのレコードの経過時間に比例します。

関数が、ストリームに書き込まれるレコードをエラーなしで処理することが重要です。開発時に、ログとコードの計測を行えば、エラーの診断に役立ちます。詳細については、Lambda アプリケーションのモニタリングとトラブルシューティングおよび AWS Lambda 関数の計測を参照してください。