Lambda IteratorAge メトリクスが増加しているのはなぜですか? またそれを減らすにはどうすればよいですか?
最終更新日: 2022 年 6 月 9 日
AWS Lambda 関数の IteratorAge メトリクスに増加 (または急上昇) が見られます。関数のイテレーターの経過時間が増加するのはなぜですか? また、それを減らすにはどうすればよいですか?
簡単な説明
Lambda 関数のイテレーターの経過時間は、関数を呼び出すストリームに書き込まれたデータを関数が効率的に処理できない場合に増加します。関数の IteratorAge メトリクスを減少させるには、ストリーム処理のスループットを増やす必要があります。
次の要因が関数の IteratorAge メトリクスに影響します。
この記事を読み、各要因がイテレーターの経過時間にどのように影響するかを理解してください。その後、関数またはデータストリームを再設定して、ユースケースに基づいて関数のイテレーターの経過時間を減少させます。詳細については、「AWS Lambda 関数のメトリクスの使用」を参照してください。
解決方法
関数の実行時間を短縮する
ランタイムの継続時間が長いと、関数のイテレーターの経過時間が長くなります。継続時間を短くすると関数のスループットが向上し、関数のイテレーターの経過時間が短くなります。
関数のランタイムの継続時間を短縮するには、次のいずれかまたは両方を実行します。
2. レコードの処理にかかる時間を短縮するために、関数コードを最適化します。
注: 詳細については、「AWS Lambda and AWS X-Ray」(AWS Lambda と AWS X-Ray) および「Instrumenting AWS Lambda functions」(AWS Lambda 関数のインストルメント化) を参照してください。
ストリームのシャード数を増やす
ストリーム内のシャードの数が少ないと、関数のイテレーターの経過時間が長くなります。ストリーム内のシャードの数を増やすと、関数のスループットが向上し、関数のイテレーターの経過時間が減少します。
ストリームのシャード数を増やすには、「Resharding a stream」(ストリームのリシャーディング) の指示に従ってください。
注: シャードを分割しても、関数のイテレーターの経過時間には直接影響しません。既存のレコードは、書き込まれたシャードに残ります。これらのシャードは、シャードのイテレーターの経過時間が減少する前に、バックログに追いつく必要があります。詳細については、「ストリームの使用」を参照してください。
ストリームのバッチサイズを増やす
関数のランタイムの継続時間がイベント内のレコード数に依存しない場合、関数のバッチサイズを増やすと、関数のイテレーターの経過時間が短くなります。
関数のバッチサイズを増やすには、「イベントソースとしてストリームを設定する」の指示に従ってください。
注: 関数の継続時間がイベント内のレコード数に依存する場合、関数のバッチサイズを増やしても関数のイテレーターの経過時間は減少しません。詳細については、「ストリームの使用」を参照してください。
関数が呼び出しエラーを正常に処理していることを確認する
呼び出しエラーは、Lambda 関数でイベントの処理や同じイベントの複数回の処理に長時間かかる原因となることがあります。イベントのレコードはシーケンシャルに読み取られるため、レコードのバッチが再試行のたびにエラーを発生させていると、関数は後のレコードに進むことができなくなります。この状況では、イテレーターの経過時間はそれらのレコードの経過時間に比例します。
関数が、ストリームに書き込まれるレコードをエラーなしで処理することが重要です。開発時に、ログ記録とコードのインストルメント化を行うことで、エラーの診断に役立ちます。
詳細については、次の記事をご参照ください。
- Lambda アプリケーションのモニタリングとトラブルシューティング
- Instrumenting AWS Lambda functions (AWS Lambda 関数のインストルメント化)
- New AWS Lambda controls for stream processing and asynchronous invocations (ストリーム処理と非同期呼び出しのための新しい AWS Lambda コントロール)
- Optimizing batch processing with custom checkpoints in AWS Lambda (AWS Lambda のカスタムチェックポイントによるバッチ処理の最適化)
- サーバーレスアプリケーションでエラーに対処する
スロットリングの発生を管理する
イベントレコードは順番に読み取られるため、現在の呼び出しがスロットリングされている場合、関数は後のレコードに進むことができません。この状況では、Lambda がスロットリングされた呼び出しを再試行する間、イテレーターの経過時間が長くなります。
Lambda 関数のスロットリングを管理するには、同時実行数の増加をリクエストするか、関数のパフォーマンスの問題を確認することができます。
さまざまな並列化係数設定をテストし、拡張ファンアウトを使用して、ストリーム処理のスループットを向上させます。
並列化係数の設定をテストするには
ストリームの処理を改善するには、関数の並列化係数を設定して、ストリームの各シャードに対する同時実行 Lambda 呼び出しの数を増やします。また、Lambda が各シャードからポーリングする同時実行バッチの数を指定することもできます。
例えば、並列化係数が 10 に設定されている場合、5 つの Kinesis データシャードを処理するために、最大 50 の Lambda 呼び出しを同時実行できます。
詳細については、「Amazon Kinesis で AWS Lambda を使用する」および「New AWS Lambda scaling controls for Kinesis and Amazon DynamoDB event sources」(Kinesis および Amazon DynamoDB イベントソース用の新しい AWS Lambda スケーリングコントロール) を参照してください。
注: シャードあたりの同時実行バッチ数を増やすと、Lambda はパーティションキーレベルで順序どおりの処理を管理します。
拡張ファンアウトを使用するには
強化されたファンアウトでデータストリームコンシューマーを作成することによって、レイテンシーを低減し、読み取りスループットを向上させることができます。ストリームコンシューマーは各シャードへの専用接続を取得します。これは、ストリームから読み取っている他のアプリケーションに影響を与えません。
詳細については、「Developing custom consumers with dedicated throughput (enhanced fan-out)」(専用スループット (拡張ファンアウト) を使用したカスタムコンシューマーの開発) および「Amazon Kinesis で AWS Lambda を使用する」を参照してください。
注: 同じデータを読み取るアプリケーションが多数ある場合や、大きなレコードを含むストリームを再処理する場合は、拡張ファンアウトを使用するのがベストプラクティスです。