Kinesis Data Streams의 IteratorAgeMilliseconds 값이 계속 증가하는 이유는 무엇입니까?

4분 분량

Amazon Kinesis Data Streams에서 IteratorAgeMilliseconds 지표가 계속 증가하고 있습니다.

간략한 설명

Kinesis Data Streams에서 IteratorAgeMilliseconds 지표가 다음과 같은 이유로 증가할 수 있습니다.

느린 레코드 처리
읽기 스로틀
AWS Lambda 함수 오류
연결 시간 초과
샤드 간의 불균일한 데이터 분포

해결 방법

느린 레코드 처리

소비자 처리 로직의 과부하로 인해 레코드 처리 속도가 느려질 수 있습니다. Amazon Kinesis Client Library(KCL)를 사용하여 소비자를 구축하는 경우 다음과 같은 근본 원인을 확인하십시오.

물리적 리소스 부족: 수요가 최고조에 달할 때는 인스턴스에 물리적 리소스가 충분한지 확인합니다(예: 메모리 또는 CPU 사용률).
규모 조정 실패: Amazon Kinesis 데이터 스트림의 로드 증가로 인해 소비자 레코드 처리 로직이 규모 조정에 실패할 수 있습니다. 규모 조정 실패를 확인하려면 KCL에서 다른 사용자 지정 Amazon CloudWatch 지표를 모니터링할 수 있습니다. 이러한 지표는 processTask, RecordProcessor.processRecords.Time, Success 및 RecordsProcessed 작업과 연관됩니다. 또한 IncomingBytes 및 IncomingRecords CloudWatch 지표를 모니터링하여 Kinesis 데이터 스트림의 전체 처리량을 확인할 수 있습니다. KCL 및 사용자 지정 CloudWatch 지표에 대한 자세한 내용은 Amazon CloudWatch로 Kinesis Client Library 모니터링을 참조하십시오. 처리 시간을 줄일 수 없으면 샤드 수를 늘려 Kinesis 스트림을 업스케일링하십시오.
중복 처리 증가: processRecords.Time 값이 증가하지만 트래픽 부하 증가와 상관 관계가 없는 경우 소비자 레코드 처리 로직을 확인합니다. 레코드 처리 로직은 소비자 레코드 처리를 지연시킬 수 있는 동기식 차단 호출을 수행할 수 있습니다. Kinesis Data Streams의 샤드 수를 증가시켜 이 문제를 해결할 수도 있습니다. 필요한 샤드 수에 대한 자세한 내용은 리샤딩, 스케일링, 병렬 처리를 참조하십시오.
GetRecords 요청 부족: 소비자가 GetRecords 요청을 충분히 자주 전송하지 않으면 소비자 애플리케이션이 지연될 수 있습니다. withMaxRecords 및 withIdleTimeBetweenReadsInMillis KCL 구성을 확인하십시오.
처리량 부족 또는 높은 MillisBehindLatest: SQL용 Amazon Managed Service for Apache Flink를 사용하는 경우에는 처리량 부족 또는 높은 MillisBehindLatest 또는 소비자 레코드 처리 지연을 참조하십시오.

소비자에게 지연이 발생하여 데이터 만료의 위험이 있는 경우 스트림 보존 기간을 늘리십시오. 기본적으로 보존 기간은 24시간이며 최대 1년까지 보존 기간을 구성할 수 있습니다. 데이터 보존 기간에 대한 자세한 내용은 데이터 보존 기간 변경을 참조하십시오.

읽기 스로틀

ReadProvisionedThroughputExceeded 지표를 확인하여 스트림에 읽기 스로틀이 있는지 확인합니다.

소비자가 초당 5회의 GetRecords 호출 할당량을 초과하면 읽기 스로틀이 발생할 수 있습니다. Kinesis 스트림의 읽기 스로틀에 대한 자세한 내용은 Kinesis Data Streams에서 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 수가 증가합니다.

무작위 파티션 키를 사용하여 스트림의 샤드에 데이터를 균등하게 분배할 수 있습니다. 무작위 파티션 키는 소비자 애플리케이션이 레코드를 더 빠르게 읽는 데 도움이 될 수 있습니다.