Kinesis 데이터 스트림 소비자 문제 해결 - Amazon Kinesis Data Streams

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Kinesis 데이터 스트림 소비자 문제 해결

Kinesis Client Library를 사용할 때 일부 Kinesis Data Streams 레코드를

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

같은 샤드에 속한 레코드가 동시에 여러 레코드 프로세서에 의해 처리되는 경우

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

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

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

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

  2. '좀비' 작업자에서 검사하려고 시도하면 KCL이 던졌습니다.ShutdownException. 이 예외를 받은 후 코드가 현재 메서드를 확실하게 종료해야 합니다.

자세한 정보는 중복 레코드 처리을 참조하십시오.

소비자 애플리케이션이 예상보다 느린 속도로 읽는 경우

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

  1. 여러 소비자 애플리케이션의 읽기 합계가 샤드당 제한을 초과합니다. 자세한 정보는 할당량과 제한을 참조하십시오. 이 경우 Kinesis Data Streams의 샤드 수를 늘리십시오.

  2. 제한최대 수를 지정합니다.GetRecords통화당 값이 낮게 구성되었을 수 있습니다. KCL을 사용하고 있다면 작업자의 maxRecords 속성을 낮은 값으로 구성한 것일 수도 있습니다. 일반적으로 이 속성에 시스템 기본값을 사용하는 것이 좋습니다.

  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이어야 연속 루프가 종료됩니다. NextShardIteratorNULL이면 현재 샤드가 닫혀 있고 ShardIterator 값이 마지막 레코드를 지나 다른 항목을 가리킵니다. 소비하는 애플리케이션이 SplitShard 또는 MergeShards를 호출하지 않으면 샤드는 계속 열려 있으며 GetRecords 호출은 NULLNextShardIterator 값을 반환하지 않습니다.

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

샤드 반복자가 예기치 않게 만료되는 경우

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

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

소비자 레코드 처리 속도가 느려지는 경우

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

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

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

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

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

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

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

무단 KMS 마스터 키 권한 오류

소비자 애플리케이션이 KMS 마스터 키에 대한 권한 없이 암호화된 스트림에서 읽으면 이 오류가 발생합니다. KMS 키에 액세스할 권한을 애플리케이션에 할당하려면 를 참조하십시오.다음에서 키 정책 사용AWSKMSIAM 정책 사용AWSKMS.

소비자를 위한 일반적인 문제, 질문 및 문제 해결 아이디어