Kinesis Data Streams の IteratorAgeMilliseconds 値が増加し続けるのはなぜですか?

最終更新日: 2022 年 6 月 22 日

Amazon Kinesis Data Streams のメトリクス IteratorAgeMilliseconds が増加し続けています。この原因は何でしょうか?

簡単な説明

Kinesis データストリームにおける IteratorAgeMilliseconds メトリクスの増加には、以下のような理由が考えられます。

  • 遅いレコード処理
  • 読み込みのスロットリング
  • AWS Lambda 関数でのエラー
  • 接続タイムアウト

解決方法

遅いレコード処理

コンシューマー処理ロジックに対する過負荷は、レコード処理における速度低下の原因になる場合があります。コンシューマーが Amazon Kinesis Client Library (KCL) を使用して構築されている場合は、次に示す根本原因についてチェックします。

  • 物理リソースの不足: 需要のピーク時におけるメモリや CPU の使用率などをチェックし、インスタンスに十分な量の物理リソースがあるかどうかを確認します。
  • スケーリングの失敗: Amazon Kinesis データストリームの負荷が増加した場合に、コンシューマーレコード処理ロジックがスケーリングに失敗することがあります。これは、KCL によって出力される、Amazon CloudWatch からの他のカスタムメトリクスをモニタリングすることで確認できます。これらのメトリクスは、以下の各オペレーションに関連付けられています。processTaskRecordProcessor.processRecords.TimeSuccessRecordsProcessedCloudWatch メトリクスの IncomingBytes および IncomingRecords をモニタリングすると、Kinesis データストリームの全体的なスループットも確認できます。KCL および CloudWatch でのカスタムメトリクスの詳細については、「Amazon CloudWatch による Kinesis クライアントライブラリのモニタリング」をご参照ください。ただし、処理時間を短縮できない場合は、シャード数を増やして Kinesis ストリームをアップスケールすることを検討してください。
  • 重複処理の増加: コンシューマーのレコード処理ロジックを確認することを検討してください。processRecords.Time 値の増加がトラフィック負荷の増加と相関しない場合は、レコード処理ロジックを確認します。レコード処理ロジックによる同期ブロック呼び出しが原因で、コンシューマーレコード処理の遅延が発生することがあります。この問題を軽減するもう 1 つの方法は、Kinesis Data Streams のシャード数を増やすことです。必要なシャード数の詳細については、「Resharding, Scaling, and Parallel Processing (リシャーディング、スケーリング、並列処理)」をご参照ください。
  • GetRecords リクエスト回数の不足: コンシューマーによる GetRecords リクエストの送信頻度が十分でない場合、コンシューマーアプリケーションで遅延が発生することがあります。検証するには、Amazon Kinesis クライアントライブラリ (KCL) の設定 (withMaxRecords および withIdleTimeBetweenReadsInMillis) を確認します。
  • IteratorAgeMilliseconds: コンシューマーが Lambda 関数を使用している場合、Lambda トリガーの設定 (バッチサイズが小さいなど) が原因で処理が遅くなる場合があります。呼び出しがブロックされたり、Lambda メモリプロビジョニングが原因でレコード処理が遅くなることもあります。詳細とトラブルシューティングについては、「Lambda 関数オプションの設定」を参照してください。
  • スループット不足または高い MillisBehindLatest: SQL 用 Amazon Kinesis Data Analytics を使用している場合、トラブルシューティングの手順については、「スループット不足または高い MillisBehindLatest」を参照してください。

コンシューマーの処理が遅いために、データの有効期限が切れるリスクがある場合は、ストリームの保持期間を延長します。保持期間はデフォルトで 24 時間に設定されており、最大 1 年にまで延長できます。データ保持期間の詳細については「Changing the data retention period (データ保持期間の変更)」をご参照ください。

読み込みのスロットリング

ReadProvisionedThroughputExceeded メトリクスをチェックし、ストリームで読み込みスロットリングが起きているかどうかを確認します。

読み込みのスロットリングは、次の原因で発生する場合があります。

  • 1 つ以上のコンシューマーが 1 秒あたり 5 回の GetRecords 呼び出しの制限に違反している
  • 1 つ以上のコンシューマーが1 秒あたり 1,000 レコードの制限に違反している
  • 1 つ以上のコンシューマーが 1 秒あたり 1 MiB の制限に違反している

Kinesis ストリームの読み込みのスロットリングの詳細については、「Kinesis Data Streams の ReadProvisionedThroughputExceeded 例外を検出してトラブルシューティングするにはどうすればよいですか?」を参照してください。

Lambda 関数でのエラー

Amazon CloudWatch で、IteratorAgeMilliseconds カウントが増加し続けているストリームと関係のある Lambda 関数を確認します。CloudWatch でエラーの概要を確認することで、IteratorAgeMilliseconds 値の増加の原因となっているエラーを特定できます。Lambda 関数エラーのタイムスタンプが、Kinesis データストリームの IteratorAgeMilliseconds メトリクスが増加した時刻と一致しているかを確認します。タイムスタンプが一致していれば、このエラーが増加の原因です。

注: Lambda 関数では、再試行される際にエラーをスローすることがあります。Lambda 関数は Kinesis のコンシューマーとしてレコードをスキップしないため、再試行が発生します。レコードが再試行されると、処理の遅延も増加します。コンシューマーがストリームに対し遅延するので、IteratorAgeMilliseconds メトリクスが増加します。

断続的な接続タイムアウト

Kinesis データストリームからレコードをプルしているときに、コンシューマーアプリケーションに接続タイムアウトの問題が発生する場合があります。断続的な接続タイムアウトエラーにより、IteratorAgeMilliseconds カウントの大幅な増加につながることがあります。

この増加が接続タイムアウトに関連しているかどうかは、GetRecords.Latency および GetRecords.Success メトリクスを見ることで確認できます。これらの両方のメトリクスが影響を受けている場合、接続が復元された後に IteratorAgeMilliseconds カウントは増加しなくなります。

シャード間の不均等なデータ分散

Put オペレーションで使用されるパーティションキーがシャード間でデータを均等に分散させていないため、Kinesis データストリーム内の一部のシャードは他のシャードよりも多くのレコードを受け取る可能性があります。この不均等なデータ分散により、Kinesis データストリームシャードへの並列 GetRecords 呼び出しが少なくなり、IteratorAgeMilliseconds カウントが増加します。

Kinesis ストリームのシャード間でデータが不均等に分散されている場合は、ランダムなパーティションキーを使用します。ランダムパーティションキーを使用すると、顧客アプリケーションはより速くレコードを読み取ることができます。