Global outage event

If you're experiencing issues with your AWS services, then please refer to the AWS Health Dashboard. You can find the overall status of ongoing outages, the health of AWS services, and the latest updates from AWS engineers.

Lambda Iteratorage メトリックスが増えているのはなぜですか? また、それを減らすにはどうすればいいですか?

所要時間1分

AWS Lambda 関数の IteratorAge メトリックスが増加 (または急増) しています。

簡単な説明

Lambda 関数のイテレーターの有効期間は、関数を呼び出すストリームに書き込まれたデータを関数が効率的に処理できない場合に長くなります。関数の Iteratorage メトリクスを減らすには、ストリーム処理のスループットを増やす必要があります。

以下の要因が関数の** IteratorAge** メトリクスに影響します:

この記事を読んで、各要因がイテレーターの経過時間にどのように影響するかを理解してください。次に、ユースケースに応じて関数またはデータストリームを再構成して、関数のイテレーターの経過時間を減らします。Lambda 呼び出しの詳細については、「AWS Lambda 関数メトリクスの使用」を参照してください。

**メモ:**Amazon DynamoDB ストリームについては、「Amazon DynamoDB ストリームの Lambda Iteratorage メトリックスが増えているのはなぜですか?」を参照してください。

解像度

関数の実行時間を短くする

実行時間が長いと、関数のイテレータの有効期間が長くなります。期間を短くすると関数のスループットが上がり、関数のイテレータの経過時間が短くなります。

関数の実行時間を短縮するには、次のいずれかまたは両方を行います:

関数に割り当てられるメモリ量を増やしてください。Lambda はメモリに比例して CPU パワーを割り当てます。
関数コードを最適化して、レコードの処理に必要な時間を短縮します。

メモ: Lambda の実行時間とパフォーマンスの詳細については、「AWS Lambda と AWS X-Ray の使用」を参照してください。

ストリームのバッチサイズを増やす

関数の実行時間がイベント内のレコード数に依存しない場合は、関数のバッチサイズを大きくするとイテレータの有効期間が短くなります。

関数のバッチサイズを増やすには、「ストリームをイベントソースとして設定する」の指示に従ってください。

**メモ:**関数の実行時間がイベント内のレコード数に依存する場合、関数のバッチサイズを増やしてもイテレータの経過時間は短くなりません。詳細については、「ストリームの操作」を参照してください。

関数が呼び出しエラーを正常に処理することを確認してください

呼び出しエラーにより、Lambda 関数がイベントを処理するのに時間がかかったり、同じイベントを複数回処理したりする可能性があります。イベントレコードは順番に読み込まれるため、レコードバッチが再試行されるたびにエラーが発生した場合、関数は後のレコードに進めません。この状況では、これらのレコードが古くなるにつれて、イテレータの存続期間が直線的に増加します。

関数がエラーを返した場合、Lambda はバッチを継続的に再試行します。バッチ再試行は、処理が成功するか、再試行回数が最大数に達するか、ストリームのデータが期限切れになるまで続きます。

関数がストリームに書き込まれたレコードを正常に処理することを確認してください。関数を開発する際、コードのロギングとインストルメンテーションを行うと、エラーの診断に役立ちます。

詳細については、以下を参照してください:

スロットルの発生を管理

イベントレコードは順番に読み込まれるため、現在の呼び出しがスロットルされている場合、関数は次のレコードに進めません。この状況では、Lambda がスロットルされた呼び出しを再試行する間、イテレーターの経過時間が長くなります。

Lambda関数のスロットリングを管理するには、同時実行数の増加をリクエストするか、関数のパフォーマンスの問題を確認できます。

ストリーム内のレコードを均等に分散する

各データレコードのパーティションキーによって、レコードが書き込まれるストリーム内のシャードが決まります。同じパーティションキーを含むレコードでストリームへのトラフィックが増加すると、シャードが不釣り合いな数のレコードを受け取ることになります。その結果、ホットシャードが生成されます。

Kinesisの拡張シャードレベルのメトリックスにより、各シャードへの取り込み速度を検証し、ホットシャードのトラブルシューティングを行うことができます。

詳細については、「内部処理:Kinesis データストリームのスケーリング」を参照してください。

ストリームのシャード数を増やす

ストリーム内のシャードの数が少ないと、関数のイテレーターの有効期間が長くなります。ストリーム内のシャードの数を増やすと、ストリームから同時に処理する Lambda 関数の数が増え、関数のイテレーターの有効期間が短くなります。

ストリームのシャード数を増やすには、「ストリームのリシャーディング」の指示に従ってください。

**メモ:**シャード分割は、関数のイテレーターの存続期間にすぐには影響しません。既存のレコードは、書き込まれたシャードに残ります。これらのシャードは、シャードのイテレーター有効期間が短くなる前にバックログに追いつく必要があります。詳細については、「ストリームの操作」を参照してください。

さまざまな並列化係数設定をテストし、強化されたファンアウトを使用することで、ストリーム処理のスループットを向上させます

並列化係数の設定をテストするには

関数の並列化係数を設定して、ストリームの各シャードでの同時 Lambda 呼び出しの数を増やすことで、ストリーム処理を改善できます。これは、 Lambda が各シャードからポーリングする同時バッチの数を指定することによって行われます。これはイベントソース設定で設定されます。

並列化係数が 10 に設定されている場合、最大 50 回の Lambda 呼び出しで 5 つの Kinesis データシャードを処理できます。

たとえば、同時実行 = シャード数 x シャードあたりの同時バッチ (並列化係数)。

詳細については、「Amazon Kinesis で AWS Lambdaを使用する」および「Kinesis と Amazon DynamoDB イベントソース用の新しい AWS Lambda スケーリングコントロール」を参照してください。

**メモ:**シャードあたりの同時バッチ数を増やすと、Lambdaはパーティションキーレベルで順序どおりの処理を検証します。

拡張ファンアウトを使用するには

ファンアウトが強化されたデータストリームコンシューマーを作成することで、レイテンシーを減らし、読み取りスループットを向上させることができます。ストリームコンシューマーは、ストリームから読み込んでいる他のアプリケーションに影響を与えないように、各シャードへの専用接続を取得します。

詳細については、「専用スループット (拡張ファンアウト)によるカスタムコンシューマーの開発」と「Amazon Kinesis で AWS Lambdaを使用する」を参照してください。

**メモ:**同じデータを読み取るアプリケーションが多数ある場合や、レコードが大きいストリームを再処理する場合は、拡張ファンアウトを使用するのがベストプラクティスです。