실시간 처리시 ReactiveKafka의 메시지 소비 지연 현상에 대해 알아보자

ReactiveKafka

Spring 환경에서 Kafka 사용이 편해졌다. 마치 WebMVC에서 Request 패턴처럼 사용하고, Partition을 나눠서 병렬 처리로 동시성 문제를 해결할 수 있다.

 

Streaming 플랫폼의 본질

Producer → stream 형태로 publish, subscribe → Consumer

 

Reactive의 본질은 대상을 Async하게 다루는거고, 이를 Stream 형태(Flux<T>)로 비동기 처리한다.

 

---

ReactiveKafka 사용시 생기는 메시지 소비의 지연 현상을 알아보자

ReactiveKafkaConsumerTemplate 자체가 Lazy하게 동작한다.

Kafka 클라이언트 설계상, receive()가 호출되기 전까지 내부적으로 KafkaReceiver가 구동하지 않는다.

 

subscribe()가 호출되고 나서야 실제 Subscription 및 Poll이 이뤄지는데 이때서야 Kafka Cluster와 Connection 초기화, Partition 할당, ReBalancing 등 일어나면서 수백 ms~ 수 초의 지연이 생길 수 있다.

 

Broker 연결, metadata 초기화, Partition 할당, Consumer Group Join 및 Rebalancing 과정이 poll(), send() 호출전까지 수행되지 않는다.(Lazy Initialization)

 

애플리케이션 시작 시점에서 강제로 subscribe해두면 실제 메시지 수신 시점에서는 파티션 할당이나 Kafka 연결이 이미 되어있어서 리밸런싱만 진행하면 된다.

 

첫 번째 요청시 메시지 지연 현상에 대한 해결 방법

시작하자마자 더미 메시지를 발행하고, 수신하도록 해서 CLuster 연결이나 파티션 할당이 미리 이뤄지도록 한다. (Kafka의 Lazy Behavior를 명시적으로 Eager 연결 유도)

Kafka 클러스터와의 연결 및 파티션 할당을 앞당겨서 첫 메시지 지연을 줄일려는 의도는 괜찮아보였다.

 

추가적으로 최초 지연에 영향을 주지는 않지만, 파티션 수가 많지 않고 균등 분배가 필요 없으면 partition.assignment.strategy를 StickyAssignor로 명시해서 리밸런싱 시간 자체를 줄일 수 있다.

• RangeAssignor (default) → StickyAssignor

 

 

warm-up 목적의 메시지를 소비시켜도 Kafka 클러스터 상태가 불안정하거나 Partition 리밸런싱이 자주 일어나는 경우에는 부하를 유발할 수 있다. 또 Consumer Group 멤버가 자주 교체된다면 리밸런싱이 반복되면서 지연이 생길 수 있다.