Amazon Kinesis Data Streams で、IteratorAgeMilliseconds メトリクスが増加を続けています。
簡単な説明
Kinesis データストリームの IteratorAgeMilliseconds メトリクスは、次の理由で増加する場合があります。
- レコード処理が遅い
- 読み取りでのスロットリング
- AWS Lambda 関数でのエラー
- 接続のタイムアウト
- シャード間の不均一なデータ分布
解決策
レコード処理が遅い
コンシューマー処理ロジックが過負荷になると、レコード処理が遅くなる場合があります。Amazon Kinesis Client Library (KCL) を使用してコンシューマーを構築している場合は、以下の根本原因を確認します。
- 物理リソースが不十分: 需要のピーク時には、インスタンスにおいて、メモリや CPU 使用率などの物理リソースが十分かどうかを確認します。
- スケーリングの失敗: Amazon Kinesis データストリームの負荷が増えると、コンシューマーレコード処理ロジックがスケーリングできなくなることがあります。スケーリングの失敗を確認するには、KCL から他のカスタム Amazon CloudWatch メトリクスを監視します。これらのメトリクスは、processTask、RecordProcessor.processRecords.Time、Success、RecordsProcessed 操作に関連付けられています。また、CloudWatch メトリクス IncomingBytes と IncomingRecords を監視し、Kinesis データストリームの全体的なスループットを確認することもできます。KCL とカスタム CloudWatch メトリクスの詳細については、「Amazon CloudWatch で Kinesis Client Library を監視する」を参照してください。処理時間を短縮できない場合は、シャードの数を増やして Kinesis ストリームをアップスケールします。
- 重複処理の増加: processRecords.Time 値の増加がトラフィック負荷の増加と相関していない場合は、コンシューマーレコード処理ロジックを確認します。レコード処理ロジックで同期ブロッキング呼び出しが発生し、コンシューマーレコード処理が遅延する場合があります。Kinesis データストリームのシャード数を増やしてこの問題を解決することもできます。必要なシャード数の詳細については、「リシャーディング、スケーリング、並列処理」を参照してください。
- GetRecords リクエストが不十分: コンシューマーが GetRecords リクエストを十分な頻度で送信していない場合、コンシューマーアプリケーションの処理が遅れる場合があります。KCL の設定で、withMaxRecords および withIdleTimeBetweenReadsInMillis を確認します。
- スループットが不足している、または MillisBehindLatest が高くなっている: SQL 用 Amazon Managed Service for Apache Flink を使用している場合、「スループットが不足している、または MillisBehindLatest が高くなっている」または「コンシューマーレコードの処理が遅延している」を参照してください。
コンシューマーが遅延しており、データが期限切れになるリスクがある場合は、ストリームの保持期間を長くします。デフォルトでは、保持期間は 24 時間です。保持期間は、最長 1 年間まで設定できます。データ保持期間の詳細については、「データ保持期間の変更」を参照してください。
読み取りでのスロットリング
ReadProvisionedThroughputExceeded メトリクスをチェックして、ストリームで読み取りのスロットリングが発生しているかどうかを確認します。
コンシューマーが 1 秒あたり 5 回の GetRecords 呼び出しクォータを超えると、読み取りにスロットリングが発生する可能性があります。Kinesis ストリームでの読み取りスロットリングに関する詳細については、「Kinesis データストリームで ReadProvisionedThroughputExceeded 例外を検出してトラブルシューティングする方法を教えてください」を参照してください。
Lambda 関数エラー
CloudWatch で、IteratorAgeMilliseconds カウントが増加し続けているストリームの Lambda 関数を確認します。IteratorageMilliSeconds 値の増加の原因となっているエラーを特定するには、CloudWatch でエラーの概要を確認します。Lambda トリガー、ブロックされた呼び出し、または Lambda メモリプロビジョニングの設定により、Lambda 関数が遅くなる可能性があります。Lambda 関数エラーのタイムスタンプが、Kinesis データストリームの IteratorageMilliSeconds メトリクスが増加した時間と一致しているかどうかを確認します。タイムスタンプが一致している場合は、それが増加の原因であると確認できます。詳細については、「Lambda 関数オプションの設定」を参照してください。
注: Lambda 関数の再試行が原因で、エラーが発生する可能性があります。Lambda 関数は Kinesis のコンシューマーとしてレコードをスキップしないため、再試行されます。これらのレコードの再試行により、プロセスの遅延も大きくなります。その後、コンシューマーはストリームに遅れをとるため、IteratorageMilliSeconds メトリクスが増加します。
断続的な接続タイムアウト
コンシューマーアプリケーションが Kinesis データストリームからレコードを取得するときに、接続タイムアウトの問題が発生する可能性があります。接続タイムアウトエラーが断続的に発生すると、IteratorAgeMilliseconds カウントが大幅に増加する可能性があります。
この増加が接続タイムアウトに関連しているかどうかを確認するには、GetRecords.Latency および GetRecords.Success メトリクスを確認します。両方のメトリクスも影響を受けている場合、接続が復元された後に IteratorageMilliSeconds カウントは増加しません。
シャード間の不均一なデータ分布
Kinesis データストリームの一部のシャードは、他のシャードよりも多くのレコードを受け取る場合があります。これは、PUT 操作で使用されるパーティションキーがデータをシャード全体に均等に分散していないためです。この不均一なデータ分散により、Kinesis データストリームシャードへの並列の GetRecords 呼び出しが少なくなり、IteratorAgeMilliseconds カウントが増加します。
ランダムなパーティションキーを使用すると、ストリームのシャード全体にデータを均等に分散できます。ランダムパーティションキーにより、コンシューマーアプリケーションがレコードをより速く読み取ることができます。
関連情報
Lambda イベントソースマッピング
Kinesis データストリームコンシューマーのトラブルシューティング
Amazon S3 で AWS Lambda を使用する