Kinesis Data Streams 소비자 문제 해결

Kinesis 클라이언트 라이브러리를 사용할 때 일부 Kinesis 데이터 스트림 레코드가 생략됩니다.

레코드를 건너뛰는 가장 일반적인 원인은 processRecords에서 발생한 예외가 처리되지 않았기 때문입니다. Kinesis 클라이언트 라이브러리 (KCL) 는 processRecords 코드를 사용하여 데이터 레코드 처리로 인해 발생하는 모든 예외를 처리합니다. 에서 발생한 모든 예외는 에서 processRecords 흡수됩니다. KCL 반복되는 실패에 대한 무한 재시도를 방지하기 위해 에서는 예외 발생 시 처리된 레코드 배치를 다시 보내지 KCL 않습니다. KCL그러면 레코드 processRecords 프로세서를 다시 시작하지 않고도 다음 데이터 레코드 배치를 호출합니다. 그래서 소비자 애플리케이션이 건너뛴 레코드를 효과적으로 관찰합니다. 레코드를 건너뛰지 않도록 하려면 processRecords 내의 모든 예외를 적절하게 처리하십시오.

동일한 샤드에 속하는 레코드는 다른 레코드 프로세서에서 동시에 처리됩니다.

실행 중인 Kinesis Client Library (KCL) 애플리케이션의 경우 샤드의 소유자는 한 명뿐입니다. 그러나 여러 레코드 프로세서가 같은 샤드를 임시로 처리할 수 있습니다. 네트워크 연결이 끊긴 작업자 인스턴스의 경우 는 페일오버 시간이 만료된 후 연결할 수 없는 워커가 더 이상 레코드를 처리하지 KCL 않는다고 가정하고 다른 작업자 인스턴스가 인계를 맡도록 지시합니다. 잠시동안 새로운 레코드 프로세서와 연결할 수 없는 작업자의 레코드 프로세서가 같은 샤드의 데이터를 처리할 수 있습니다.

애플리케이션에 적합한 장애 조치 시간을 설정해야 합니다. 지연 시간이 짧은 애플리케이션이라면 최대로 대기할 시간이 기본값 10초로 충분하지만 연결이 자주 끊어지는 지역에서 호출하는 경우처럼 연결 문제가 예상된다면 이 시간이 너무 짧습니다.

특히 전에 연결할 수 없었던 작업자로 네트워크 연결이 주로 복원되기 때문에 애플리케이션이 이 시나리오를 예측하고 처리해야 합니다. 레코드 프로세서가 다른 레코드 프로세서로 샤드를 인계하면 다음 두 가지 경우를 처리해야 정상적으로 종료됩니다.

1. 현재 호출이 processRecords 완료되면 종료 사유가 ''인 레코드 KCL 프로세서에서 shutdown 메서드를 호출합니다. ZOMBIE 레코드 프로세서는 모든 리소스를 적절하게 정리한 후 종료되어야 합니다.

2. '좀비' 워커로부터 체크포인트를 시도하면 문제가 발생합니다. KCL ShutdownException 이 예외를 받은 후 코드가 현재 메서드를 확실하게 종료해야 합니다.

자세한 내용은 중복 레코드 처리 단원을 참조하십시오.

소비자 애플리케이션이 예상보다 느린 속도로 읽히고 있습니다.

읽기 처리량의 속도가 예상보다 느린 가장 일반적인 이유는 다음과 같습니다.

1. 여러 소비자 애플리케이션의 읽기 합계가 샤드당 제한을 초과합니다. 자세한 내용은 할당량 및 제한 단원을 참조하십시오. 이 경우 Kinesis 데이터 스트림의 샤드 수를 늘립니다.

2. 호출당 최대 GetRecords 수를 지정하는 제한이 낮은 값으로 구성되었을 수 있습니다. 를 사용하는 경우 워커를 낮은 maxRecords 속성 값으로 구성했을 수 있습니다. KCL 일반적으로 이 속성에 시스템 기본값을 사용하는 것이 좋습니다.

3. processRecords호출 내의 로직이 예상보다 오래 걸리는 이유는 여러 가지로 인해 예상보다 오래 걸릴 수 있습니다. 로직이 CPU 집중적이거나 I/O 차단이 심하거나 동기화 시 병목 현상이 발생할 수 있습니다. 이 경우에 해당하는지 테스트하려면 빈 레코드 프로세서를 테스트 실행하고 읽기 처리량을 비교하십시오. 수신 데이터를 따라 잡는 방법에 대한 자세한 내용은 리샤딩, 스케일링, 병렬 처리를 사용하여 샤드 수를 변경합니다.를 참조하십시오.

소비자 애플리케이션이 하나뿐이면 넣기 속도보다 항상 최소한 2배 더 빠르게 읽을 수 있습니다. 쓰기를 위해 초당 최대 1,000개의 레코드를 쓸 수 있고 최대 총 데이터 쓰기 속도는 초당 1MB(파티션 키 포함)이기 때문입니다. 열린 각 샤드는 읽기에 대해 초당 최대 5개의 트랜잭션을 지원할 수 있으며, 최대 총 데이터 읽기 속도는 초당 2MB입니다. 각 읽기(GetRecords 호출)는 레코드 배치를 가져옵니다. GetRecords가 반환하는 데이터 크기는 샤드 사용률에 따라 다릅니다. GetRecords가 반환할 수 있는 최대 데이터 크기는 10MB입니다. 호출이 그 한도를 반환하면 다음 5초 안에 이루어지는 호출에서 ProvisionedThroughputExceededException이 발생합니다.

GetRecords 스트림에 데이터가 있는 경우에도 빈 레코드 배열을 반환합니다.

레코드를 소비하거나 가져오는 것은 가져오기(pull) 모델입니다. 개발자는 백오프 없이 연속 루프로 GetRecords호출해야 합니다. 또한 모든 GetRecords 호출은 다음 루프 반복에서 사용해야 하는 ShardIterator 값을 반환합니다.

GetRecords 작업은 차단하지 않습니다. 관련 데이터 레코드나 빈 Records 요소를 즉시 반환합니다. 다음 두 가지 조건에서 빈 Records 요소가 반환됩니다.

1. 현재 샤드에 데이터가 더 이상 없습니다.

2. ShardIterator가 가리키는 샤드 부분 근처에 데이터가 없습니다.

두 번째 조건은 미미한 편이지만 레코드를 검색할 때 무한 탐색 시간(지연 시간)을 피하기 위해 설계상 필요한 사항입니다. 따라서 스트림을 소비하는 애플리케이션은 GetRecords를 반복하고 호출하여 당연히 비어 있는 레코드를 처리해야 합니다.

프로덕션 시나리오에서는 NextShardIterator 값이 NULL이어야 연속 루프가 종료됩니다. NextShardIterator가 NULL이면 현재 샤드가 닫혀 있고 ShardIterator 값이 마지막 레코드를 지나 다른 항목을 가리킵니다. 소비하는 애플리케이션이 SplitShard 또는 MergeShards를 호출하지 않으면 샤드는 계속 열려 있으며 GetRecords 호출은 NULL인 NextShardIterator 값을 반환하지 않습니다.

Kinesis 클라이언트 라이브러리 (KCL) 를 사용하는 경우 위의 사용 패턴이 추상화됩니다. 동적으로 변화하는 샤드 세트의 자동 처리가 여기에 포함됩니다. 를 KCL 사용하면 개발자가 들어오는 레코드를 처리하는 로직만 제공합니다. 이러한 상태는 라이브러리가 GetRecords를 연속으로 호출하기 때문에 가능합니다.

샤드 이터레이터가 예기치 않게 만료됩니다.

모든 GetRecords 요청에서 새로운 반복자가 NextShardIterator로 반환되며, 다음 GetRecords 요청에서 이 샤드 반복자를 ShardIterator로 사용합니다. 대개 이 샤드 반복자는 사용하기 전에 만료되지 않지만 하지만 5분 이상 GetRecords를 호출하지 않거나 소비자 애플리케이션의 다시 시작을 수행하면 샤드 반복자가 만료될 수 있습니다.

사용하기 전에 샤드 반복자가 즉시 만료되는 경우 Kinesis에 사용된 DynamoDB 테이블에 리스 데이터를 저장할 용량이 충분하지 않을 수 있습니다. 샤드 수가 많으면 이런 문제가 생기기 쉽습니다. 이 문제를 해결하려면 샤드 테이블에 할당된 쓰기 용량을 늘리십시오. 자세한 내용은 임대 테이블을 사용하여 소비자 애플리케이션에서 처리한 샤드를 추적할 수 있습니다. KCL 단원을 참조하십시오.

소비자 기록 처리가 뒤쳐지고 있습니다.

대다수 사용 사례에서 소비자 애플리케이션은 스트림에서 최신 데이터를 읽습니다. 바람직하지는 않지만 상황에 따라 소비자가 읽는 속도가 느려지기도 합니다. 소비자가 얼마나 느리게 읽는지 파악한 후에 속도가 느려지는 가장 일반적인 이유를 알아보십시오.

스트림의 모든 샤드와 소비자에서 읽기 위치를 추적하는 GetRecords.IteratorAgeMilliseconds 측정치를 시작합니다. 반복자 수명이 보존 기간(기본적으로 24시간, 최대 365일까지 구성 가능)의 50%를 경과하면 레코드 만료로 인해 데이터가 손실될 위험이 있음을 알아 두세요. 보존 기간을 늘리는 것이 신속한 임시 조치입니다. 그러면 문제를 해결하는 동안 중요한 데이터가 손실되지 않습니다. 자세한 내용은 아마존을 통해 Amazon Kinesis 데이터 스트림 서비스를 모니터링하십시오. CloudWatch 단원을 참조하십시오. 다음으로 Kinesis Client Library () 에서 내보낸 사용자 지정 CloudWatch 메트릭을 사용하여 소비자 애플리케이션이 각 샤드를 읽는 데 얼마나 뒤쳐져 있는지 확인합니다. KCL MillisBehindLatest 자세한 내용은 Amazon에서 Kinesis 클라이언트 라이브러리를 모니터링하십시오 CloudWatch 단원을 참조하십시오.

다음은 소비자 속도가 늘려지는 가장 일반적인 이유입니다.

• 갑자기 크게 GetRecords.IteratorAgeMilliseconds 증가하거나 MillisBehindLatest 일반적으로 다운스트림 애플리케이션의 API 작업 실패와 같은 일시적인 문제를 나타냅니다. 두 측정치 중 하나가 지속적으로 이 동작을 나타내면 갑작스러운 증가를 조사해야 합니다.

• 이 측정치가 점차 증가하면 소비자가 충분히 빠른 속도로 레코드를 처리하지 않아 스트림을 따라 잡지 못하는 것입니다. 이 동작이 나타나는 가장 일반적인 근본 원인은 물리적 리소스가 부족하거나 레코드 처리 로직이 스트림 처리량의 증가에 따라 조정되지 않기 때문입니다. ,RecordProcessor.processRecords.Time, Success 등 processTask 작업과 관련하여 발생하는 다른 사용자 지정 CloudWatch 지표를 살펴보면 이 동작을 확인할 수 있습니다. KCL RecordsProcessed

  • 증가한 처리량과 상관 관계가 있는 processRecords.Time 측정치의 증가가 발견되면 레코드 처리 로직을 분석하여 이 로직이 증가한 처리량에 따라 조정되지 않는 이유를 파악해야 합니다.

  • 증가한 처리량과 상관 관계가 없는 processRecords.Time 값의 증가가 발견되면 중요한 경로에서 차단 호출이 이루어지고 있는지 확인하십시오. 차단 호출은 종종 레코드 처리가 종료되는 원인입니다. 샤드 수를 늘려 병렬 처리를 늘리는 것도 또 다른 방법입니다. 마지막으로, 수요가 최고조에 달할 때 기본 처리 노드에 적절한 양의 물리적 리소스 (메모리, CPU 사용률 등) 가 있는지 확인하십시오.

승인되지 않은 KMS 마스터 키 권한 오류

이 오류는 소비자 애플리케이션이 KMS 마스터 키에 대한 권한 없이 암호화된 스트림에서 읽을 때 발생합니다. 응용 프로그램에 키 액세스 권한을 할당하려면 에서 KMS 키 정책 사용 AWS KMS 및 IAM정책 사용을 참조하십시오 AWS KMS.

소비자가 겪는 기타 일반적인 문제를 해결하세요.

• Kinesis Data Streams 트리거로 Lambda 함수를 간접적으로 호출할 수 없는 이유는 무엇인가요?

• Kinesis Data Streams에서 ReadProvisionedThroughputExceeded 예외를 감지하고 문제를 해결하려면 어떻게 해야 합니까?

• Kinesis Data Streams에서 긴 지연 시간 문제가 발생하는 이유는 무엇입니까?

• Kinesis 데이터 스트림이 500 내부 서버 오류를 반환하는 이유는 무엇인가요?

• Kinesis Data Streams에서 차단되거나 중단된 KCL 애플리케이션의 문제를 해결하려면 어떻게 해야 합니까?

• 동일한 Amazon DynamoDB 테이블로 다른 Amazon Kinesis Client Library 애플리케이션을 사용하려면 어떻게 해야 하나요?