겉보기엔 균형 잡힌 Kafka, Broker Metrics는 다르게 말한다

Kafka cluster를 운영하다 보면 가장 먼저 보는 balancing 지표 중 하나가 broker별 leader partition 수입니다.

Broker A: leader 100개
Broker B: leader 100개
Broker C: leader 100개

이 숫자만 보면 꽤 좋아 보입니다. 각 broker가 같은 수의 leader partition을 갖고 있으니 균형이 맞는 것처럼 보입니다.

그런데 실제 metric을 보면 전혀 다른 그림이 나올 수 있습니다.

Broker A: network out 높음, disk growth 빠름
Broker B: 보통
Broker C: 거의 여유 있음

이 글은 제가 Kafka Summit에서 발표한 Is Your Kafka Truly Load Balancing? Pro Tips for Leader Partition Distribution의 내용을 블로그용으로 풀어낸 글입니다. 핵심은 단순합니다. Kafka에서 leader partition을 골고루 나눴다고 해서 cluster load가 정말 균형 잡힌 것은 아닙니다.

먼저 가져갈 결론

Kafka balancing을 볼 때는 이 다섯 가지를 기억하면 좋습니다.

• leader partition count는 좋은 시작점이지만 충분한 기준은 아닙니다.
• partition마다 produce rate, consume rate, message size, retention footprint가 다릅니다.
• leader broker는 write path, replication source, fetch path에서 더 많은 network 부담을 가질 수 있습니다.
• storage 사용량과 growth rate를 같이 보지 않으면 큰 partition이 특정 broker에 몰릴 수 있습니다.
• 재분산은 leader count가 아니라 partition의 weight를 보고 해야 합니다.

한 줄로 줄이면 이렇습니다.

Kafka load balancing은 partition 개수를 맞추는 일이 아니라,
서로 다른 무게의 partition을 broker에 어떻게 올려둘지 결정하는 일입니다.

왜 leader count만 보면 부족한가

Kafka에서 partition은 모두 같은 이름을 갖지만 같은 무게를 갖지는 않습니다.

어떤 partition은 거의 idle 상태일 수 있습니다. 하루에 몇 MB만 들어오고 consumer도 가끔 읽습니다. 반대로 어떤 partition은 초당 수십 MB를 받고, 여러 consumer group이 계속 fetch하고, retention 때문에 disk도 빠르게 늘어납니다.

둘 다 leader partition 1개입니다. 하지만 broker 입장에서 같은 부하가 아닙니다.

Partition p0: 100 KB/sec in, 200 KB/sec out
Partition p1: 30 MB/sec in, 120 MB/sec out

이 두 partition을 같은 단위로 세면 balancing 판단이 왜곡됩니다. leader count는 “몇 개를 맡았나”를 말해주지만, “얼마나 무거운 일을 맡았나”를 말해주지는 않습니다.

leader broker는 어떤 부담을 갖나

Kafka에서 producer는 partition leader로 write합니다. follower는 leader에서 data를 fetch해 replica를 따라갑니다. consumer도 보통 leader에서 data를 fetch합니다.

단순화하면 leader broker는 이런 부담을 가질 수 있습니다.

• producer request 처리
• record append와 page cache pressure
• follower replication fetch 응답
• consumer fetch 응답
• network in/out
• disk read/write와 retention footprint

그래서 leader가 많은 broker는 부하가 높아질 가능성이 큽니다. 하지만 더 중요한 것은 “어떤 leader인가”입니다. hot topic의 leader인지, compacted topic의 큰 partition인지, retention이 긴 audit topic인지, consumer group이 많은 topic인지에 따라 metric이 달라집니다.

network는 leader count보다 빨리 진실을 말한다

leader partition 수가 균등한데 broker 하나의 network out만 유난히 높다면, 보통 hot leader가 몰려 있을 가능성을 봐야 합니다.

예를 들어 broker별 leader count가 모두 100개라고 해도 다음 상황은 균형이 아닙니다.

broker	leader count	network in	network out
A	100	350 MB/s	900 MB/s
B	100	210 MB/s	360 MB/s
C	100	120 MB/s	180 MB/s

이 경우 A에서 leader 몇 개를 옮긴다고 해서 반드시 해결되지는 않습니다. idle leader 20개를 옮겨도 A의 network out은 거의 줄지 않을 수 있습니다. 반대로 hot partition leader 2개만 옮겨도 큰 차이가 날 수 있습니다.

그래서 재분산 후보를 고를 때는 partition-level metric이 필요합니다.

topic-partition별 bytes in/sec
topic-partition별 bytes out/sec
consumer group fetch 패턴
replication fetch 영향
broker별 request handler saturation

storage도 같은 방식으로 본다

Network만 보면 또 다른 문제가 숨어 있을 수 있습니다. broker별 disk usage와 growth rate도 같이 봐야 합니다.

어떤 topic은 traffic은 크지 않지만 retention이 길어서 disk를 많이 씁니다. 어떤 topic은 message size가 크고 compaction이나 delete retention 때문에 broker disk footprint가 예상보다 커질 수 있습니다.

leader 이동은 network 부하에는 영향을 주지만, replica 배치와 partition reassignment는 storage 위치를 바꿉니다. 따라서 balancing 작업은 두 축을 나눠 봐야 합니다.

목적	봐야 할 것
leader 부하 완화	leader placement, bytes in/out, consumer fetch
disk 사용량 완화	replica placement, partition size, growth rate
장기 안정성	retention, topic growth, broker disk headroom
변경 비용	reassignment traffic, replication throttle, 운영 시간대

특히 큰 partition을 옮길 때는 “옮긴 뒤의 균형”만 보면 안 됩니다. 옮기는 동안 발생하는 replication traffic이 consumer lag, produce latency, broker network를 악화시킬 수 있습니다.

균형을 partition weight로 다시 정의하기

실무에서는 partition마다 weight를 둬서 생각하는 편이 좋습니다.

partition weight =
  produce bytes/sec
  + consume bytes/sec
  + replication cost
  + storage size
  + growth rate

정확한 수식 하나로 모든 cluster를 설명할 필요는 없습니다. 중요한 것은 “leader 1개 = 같은 무게”라는 가정을 버리는 것입니다.

처음에는 단순한 scoring만으로도 충분합니다.

traffic score = bytes in/sec + bytes out/sec
storage score = partition size + growth rate
broker pressure = network utilization + disk utilization + request saturation

이렇게 보면 balancing 대화가 달라집니다.

나쁜 질문:
Broker A에는 leader가 몇 개 있나?

좋은 질문:
Broker A에는 어떤 hot leader와 large replica가 몰려 있나?

재분산할 때의 순서

제가 선호하는 순서는 이렇습니다.

1. broker별 leader count를 본다.
2. broker별 network in/out, request latency, request handler idle을 본다.
3. broker별 disk usage와 growth rate를 본다.
4. topic-partition별 bytes in/out과 size를 본다.
5. hot leader와 large replica가 같은 broker에 몰려 있는지 본다.
6. 작은 변경으로 효과가 큰 후보부터 옮긴다.
7. reassignment와 leader movement가 만드는 임시 부하를 제한한다.

여기서 “작은 변경으로 효과가 큰 후보”가 중요합니다. leader count를 맞추기 위해 partition 수십 개를 기계적으로 옮기는 것보다, network out을 지배하는 hot leader 몇 개를 옮기는 편이 더 안전하고 효과적일 수 있습니다.

preferred leader election만으로 충분하지 않을 수 있다

Kafka에는 preferred leader election이 있습니다. replica assignment에 정의된 preferred replica로 leader를 되돌려 leader distribution을 정리할 수 있습니다.

하지만 preferred leader election은 “preferred replica가 어디인가”를 따릅니다. preferred replica 배치 자체가 traffic weight를 고려하지 않고 만들어졌다면, election만으로 실제 부하 균형을 맞추기는 어렵습니다.

또 topic이 시간이 지나며 바뀝니다. 처음에는 평범했던 topic이 서비스 성장으로 hot topic이 될 수 있고, 특정 consumer group이 늘어나면서 fetch load가 커질 수 있습니다. 오늘의 preferred placement가 내일도 좋은 placement라는 보장은 없습니다.

알림과 대시보드에 넣을 것

Kafka balancing을 운영 관점에서 보려면 dashboard가 leader count만 보여주면 부족합니다.

최소한 다음을 함께 보는 편이 좋습니다.

• broker별 leader count
• broker별 bytes in/out
• broker별 request latency와 request handler idle
• broker별 disk used, disk available, disk growth rate
• topic-partition별 produce/fetch bytes
• top N hot partitions
• top N largest partitions
• reassignment traffic과 throttling 상태
• under-replicated partitions와 ISR shrink 이벤트

Kafka 같은 클러스터형 리소스는 단일 metric보다 여러 운영 신호를 같이 읽을 때 판단이 좋아집니다. Konduo는 Kafka 같은 운영 대상을 플러그인으로 연결해 broker, topic, consumer group, metric evidence, alert response를 하나의 흐름에서 확인할 수 있도록 설계된 통합 관리 운영 플랫폼입니다.

체크리스트

leader partition balancing을 검토할 때는 다음 질문을 던져봅니다.

• broker별 leader count가 비슷한가?
• leader count가 비슷한데 network in/out은 크게 다른가?
• 특정 broker가 top hot partitions를 많이 갖고 있는가?
• 특정 broker에 large partitions가 몰려 있는가?
• disk usage뿐 아니라 growth rate도 균형적인가?
• consumer fetch가 특정 broker의 network out을 밀어 올리고 있는가?
• preferred leader election이 실제 load를 개선하는가, 숫자만 보기 좋게 만드는가?
• reassignment 중 생길 replication traffic을 감당할 수 있는가?
• 변경 후 consumer lag, produce latency, request handler saturation을 확인했는가?

마지막 기준은 간단합니다.

Leader count는 균형의 지도일 뿐입니다.
진짜 지형은 broker metrics가 보여줍니다.

Kafka cluster가 정말 균형 잡혀 있는지 알고 싶다면 partition 개수에서 멈추지 말고, partition의 무게와 broker가 실제로 견디는 압력을 같이 봐야 합니다.

함께 읽기 좋은 글

이 글의 관점과 이어지는 주제를 더 보려면 아래 글도 함께 읽어볼 수 있습니다.

• Kafka Broker가 느려졌지만 Kafka가 원인은 아니었다 - Kafka 증상 뒤에 숨어 있던 storage path와 I/O 문제를 추적합니다.
• Consumer Lag은 건강 점수가 아니다: Kafka Consuming Pressure라는 관점 - consumer lag을 처리 압력 관점으로 다시 해석합니다.
• Kafka Client Metrics는 관측의 빈틈을 메울 수 있을까 - Kafka client metrics가 관측 빈틈을 얼마나 메울 수 있는지 검토합니다.