2024.05.26 Load Balancing Challenges in Apache Kafka

How We Solve Load Balancing Challenges in Apache Kafka

How We Solve Load Balancing Challenges in Apache Kafka

호텔예약 사이트인 Agoda에서의 작성했다.

kafka 컨슈머별로 처리량이 다를 수 있는데 이를 해결하기 위한 로드밸런싱에 관한 글이다.

프로듀서와 컨슈머를 커스텀하는 방법인데 나름 흥미롭다.

프로듀서의 라운드로빈은 완벽한 성능 분배를 이뤄내지는 못한다. 특정 컨슈머가 느릴 수 있기 때문이다. 

 

 

컨슈머가 성능이 달라질 수 있는 원인 중 하나는 하드웨어가 다르기 때문일 수 있다. 

또 DB의 연동작업이 필요한 경우는 매개변수에 따라 응답속도가 다를 수 있다.

 

이를 해결하기 위해서..

동일한 하드웨어를 유지한다. -> 유연성과 비용효율성이 떨어진다.

 

Weighted Load Balancing

대부분 성능이 좋은 소비자에게 더 트래픽(파티션 할당)을 보낸다.

다만 성능 측정 시 매번 메시지는 동일하지 않고, 네트워크는 불안정하다는 것을 인지해야 한다. 또 가중치는 항상 최신 상태로 유지되어야 한다.

 

이를 구현할 수 있는 방법은 2개가 있다.

Lag-aware Producer

lag을 확인하고 적절한 파티션에 분배한다.

Lag-aware Consumer

lag을 확인하고 사용자 정의 리밸런싱을 한다.

 

Lag-aware Producer는 항상 정답은 아니다. pure 한 consumer에게는 사용해서는 안되고 여러 consumer group이 있을 때도 사용하면 안 된다. 여러 그룹이 있다면 특정 그룹에게 편향된 로드밸런싱을 할 수 있기 때문이다.

파티셔너는 커스텀할 수 있기 때문에 lag으로 판단하는 것이다. 

lag 정보는 항상 broker에게 가져오기보다 cache를 사용할 수 있다.

 

구현 방법 1. Same-Queue Length Algorithm

queue를 사용하는 것인데. 내부에서 메시지 발행을 할 때 queue를 사용하는 것을 볼 수 있다. 

이 방법은 consumer 별로 하드웨어가 다를 때 유용하다.

lag 캐시를 보고 메시지를 발행할지 말지 정하고 남는 queue에 메시지를 넣는 구현 같다.

 

구현 방법 2. Outlier Detection Algorithm

이것은 파티션에게 상태값을 줘서 상태를 관리하는 거 같다. 

느린 파티션, ok파티션, good파티션.

 

Lag-aware Producer의 장점을 보니 특정 느린 컨슈머로 인해서 발생하는 성능 문제를 해결했다는 것이다.

 

 

 

Lag-aware Consumer는 Lag-aware Producer을 도입할 수 없는. 여러 consumer group이 동일 토픽을 구독할 때 사용할 수 있다.

일단 이것은 지연이 있는 컨슈머가 구독을 취소하면서 리밸런싱을 유도하는 방법이다.

리밸런싱 중에는 같은 consumer group의 모든 처리를 중지하기 때문에 비용이 많이 드는 작업이다. 

다만 kafka 2.4에서 incremental-cooperative-rebalancing 이 추가되어서 성능 영향이 최소화되었다고 한다.

다만 리밸런싱으로 인한 메시지 손실등은 대비를 더 해야겠다.

리밸런싱의 유연성을 높이려면 파티션의 수가 컨슈머보다 많아야 한다.