짧은 처리 지연 시간

전파 지연은 다음과 같이 정의됩니다.end-to-end레코드가 스트림에 쓰여진 후 소비자 애플리케이션에서 레코드를 읽을 때까지 지연 시간입니다. 이 지연은 여러 요인에 따라 달라지만 주로 소비자 애플리케이션 폴링 간격의 영향을 받습니다.

대다수 애플리케이션에서 애플리케이션마다 각 샤드를 초당 1회씩 폴링하는 것이 좋습니다. 그러면 Amazon Kinesis Data Streams 의 5개를 초과하지 않고 여러 소비자 애플리케이션에서 동시에 스트림을 처리할 수 있습니다.GetRecords초당 호출. 또한 더 큰 데이터 배치를 처리하는 것이 네트워크와 애플리케이션의 다른 다운스트림 지연 시간을 줄이는 데 보다 효율적입니다.

KCL 기본값은 1초마다 폴링하는 모범 사례를 따르도록 설정됩니다. 이 기본값을 사용하면 일반적으로 평균 전파 지연이 1초 미만입니다.

Kinesis Data Streams 레코드를 쓴 후 즉시 읽을 수 있습니다. 이 점을 이용해 데이터를 사용할 수 있게 되면 즉시 스트림에서 데이터를 소비해야 하는 몇몇 사용 사례가 있습니다. 다음 예제와 같이 더 자주 폴링하도록 KCL 기본 설정을 재정의하여 전파 지연을 크게 줄일 수 있습니다.

Java KCL 구성 코드는 다음과 같습니다.

kinesisClientLibConfiguration = new
        KinesisClientLibConfiguration(applicationName,
        streamName,               
        credentialsProvider,
        workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);

Python 및 Ruby KCL의 속성 파일 설정:

idleTimeBetweenReadsInMillis = 250

참고

Kinesis Data Streams 스트림의 한도가 5이기 때문에GetRecords초당 호출 수, 샤드 당idleTimeBetweenReadsInMillis200ms보다 낮은 속성으로 인해 응용 프로그램이 다음을 관찰 할 수 있습니다.ProvisionedThroughputExceededException예외. 이 예외가 너무 많으면 지수 백오프가 발생하여 예기치 않게 처리가 많이 지연됩니다. 이 속성을 200ms 또는 더 높게 설정하고 처리 애플리케이션이 2개 이상인 경우 유사한 조절이 발생합니다.