Kinesis Data Streams の IteratorAgeMilliseconds 値が増加し続けるのはなぜですか?
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 クライアントライブラリのモニタリング」を参照してください。ただし、処理時間を短縮できない場合は、シャード数を増やして Kinesis ストリームをアップスケールすることを検討してください。
- 重複処理の増加: コンシューマーのレコード処理ロジックを確認することを検討してください。processRecords.Time 値の増加がトラフィック負荷の増加と相関しない場合は、レコード処理ロジックを確認します。レコード処理ロジックによる同期ブロック呼び出しが原因で、コンシューマーレコード処理の遅延が発生することがあります。この問題を軽減するもう 1 つの方法は、Kinesis Data Streams のシャード数を増やすことです。必要なシャード数の詳細については、「リシャーディング、拡張、並列処理」を参照してください。
- GetRecords リクエスト回数の不足: コンシューマーによる GetRecords リクエストの送信頻度が十分でない場合、コンシューマーアプリケーションで遅延が発生することがあります。検証するには、KCL の設定 (withMaxRecords および withIdleTimeBetweenReadsInMillis) を確認します。
- スループット不足または高い MillisBehindLatest: SQL 用 Amazon Kinesis Data Analytics を使用している場合、トラブルシューティングの手順については、「スループット不足または高い MillisBehindLatest」または「コンシューマー記録処理の遅延」を参照してください。
コンシューマーの処理が遅いために、データの有効期限が切れるリスクがある場合は、ストリームの保持期間を延長します。保持期間はデフォルトで 24 時間に設定されており、最大 1 年にまで延長できます。データ保持期間の詳細については、「データ保持期間の変更」を参照してください。
読み込みのスロットリング
ReadProvisionedThroughputExceeded メトリクスをチェックし、ストリームで読み込みスロットリングが起きているかどうかを確認します。
読み取りスロットリングは、1 つ以上のコンシューマーが 1 秒あたり 5 回の GetRecords 呼び出しの制限に違反したことが原因である可能性があります。Kinesis ストリームの読み込みのスロットリングの詳細については、「Kinesis Data Streams の ReadProvisionedThroughputExceeded 例外を検出してトラブルシューティングするにはどうすればよいですか?」を参照してください。
Lambda 関数でのエラー
CloudWatch で、IteratorAgeMilliseconds カウントが増加し続けているストリームと関係のある Lambda 関数を確認します。CloudWatch でエラーの概要を確認することで、IteratorAgeMilliseconds 値の増加の原因となっているエラーを特定できます。処理が遅いのは、Lambda トリガーの設定 (バッチサイズが小さいなど)、呼び出しがブロックされている、または Lambda メモリのプロビジョニングが原因である可能性があります。Lambda 関数エラーのタイムスタンプが、Kinesis データストリームの IteratorAgeMilliseconds メトリクスが増加した時刻と一致しているかを確認します。タイムスタンプが一致していれば、このエラーが増加の原因です。詳細については、「Lambda 関数オプションの設定」を参照してください。
注: Lambda 関数では、再試行される際にエラーをスローすることがあります。Lambda 関数は Kinesis のコンシューマーとしてレコードをスキップしないため、再試行が発生します。レコードが再試行されると、処理の遅延も増加します。コンシューマーがストリームに対し遅延するので、IteratorAgeMilliseconds メトリクスが増加します。
断続的な接続タイムアウト
Kinesis データストリームからレコードをプルする際に、コンシューマーアプリケーションに接続タイムアウトの問題が発生する場合があります。断続的な接続タイムアウトエラーにより、IteratorAgeMilliseconds カウントの大幅な増加につながることがあります。
この増加が接続タイムアウトに関連しているかどうかは、GetRecords.Latency および GetRecords.Success メトリクスを見ることで確認できます。これらの両方のメトリクスが影響を受けている場合、接続が復元された後に IteratorAgeMilliseconds カウントは増加しなくなります。
シャード間の不均等なデータ分散
Kinesis データストリームの一部のシャードは、他のシャードよりも多くのレコードを受信する場合があります。これは、Put 操作で使用されるパーティションキーがデータをシャード全体に均等に分散していないためです。この不均等なデータ分散により、Kinesis データストリームシャードへの並列 GetRecords 呼び出しが少なくなり、IteratorAgeMilliseconds カウントが増加します。
ランダムパーティションキーを使用して、ストリームのシャードにデータを均等に分散できます。ランダムパーティションキーは、コンシューマーアプリケーションがレコードをより速く読み取るのに役立ちます。
関連情報
関連するコンテンツ
- AWS公式更新しました 4年前
