짧은 처리 지연 시간 - Amazon Kinesis Data Streams

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

짧은 처리 지연 시간

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

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

1초 마다 폴링하는 모범 사례에 따라 KCL 기본값이 설정됩니다. 이 기본값을 사용하면 일반적으로 평균 전파 지연이 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 호출 제한이 있으므로 idleTimeBetweenReadsInMillis 속성을 200ms보다 낮게 설정하면 애플리케이션에 ProvisionedThroughputExceededException 예외가 관찰될 수 있습니다. 이 예외가 너무 많으면 지수 백오프가 발생하여 예기치 않게 처리가 많이 지연됩니다. 이 속성을 200ms 또는 더 높게 설정하고 처리 애플리케이션이 2개 이상인 경우 유사한 조절이 발생합니다.