Kafka 파티션 불균형 문제 처리를 위한 모범 사례

Apache Kafka의 강점은 토픽 파티셔닝을 통해 달성되는 분산 특성에 있습니다. 파티션을 사용하면 데이터를 여러 브로커에 분산하여 병렬 소비와 높은 처리량을 가능하게 합니다. 그러나 이러한 파티션이 균등하게 분산되지 않거나 시간이 지남에 따라 불균일한 부하 패턴이 나타나면 파티션 불균형이 발생합니다. 이 불균형은 성능을 심각하게 저하시키고, 과부하된 파티션에서 소비자 지연을 증가시키며, Kafka 확장의 이점을 무효화할 수 있는 중요한 운영 문제입니다.

이 가이드에서는 구분해야 할 두 가지 유형의 불균형, 즉 브로커 간의 불균등한 파티션 배치와 파티션 간의 불균등한 트래픽에 대해 설명합니다. 해결 방법이 다르므로 진단이 중요합니다.

Kafka 파티션 불균형 이해

파티션 불균형은 워크로드(데이터 볼륨, 메시지 속도 또는 소비자 부하)가 토픽 내의 모든 사용 가능한 파티션에 균등하게 분산되지 않거나, 파티션 자체가 브로커 클러스터 전체에 물리적으로 균등하게 분산되지 않을 때 발생합니다.

불균형의 원인

여러 요인이 파티션 불균형을 유발하거나 악화시킬 수 있습니다.

초기 토픽 생성 구성 오류: 원하는 병렬 처리 수준이나 사용 가능한 브로커 수에 비해 부적절한 수의 파티션으로 토픽을 생성하는 경우.
불균등한 키 분배(편향된 프로듀서): 프로듀서가 단일 파티션에 불균형적으로 많은 메시지를 매핑하는 키를 사용하는 경우(키 편향). 예를 들어, 특정 고객 ID나 식별자가 다른 것보다 훨씬 더 활성화된 경우.
소비자 그룹 동작: 소비자 그룹에서 한 소비자가 실패하거나 재시작되면 이전에 할당된 파티션이 재분배됩니다. 재할당이 느리거나 파티션 수가 많으면 한 소비자가 일시적으로 다른 소비자보다 훨씬 더 많은 파티션을 처리할 수 있습니다.
브로커 장애 및 복구: 브로커 중단 또는 재시작 중에 해당 브로커에 호스팅된 파티션을 이동하거나 재할당해야 하므로 클러스터가 완전히 복구될 때까지 일시적으로 부하가 편향됩니다.

시스템 성능에 미치는 영향

심각한 파티션 불균형의 결과는 상당합니다.

처리량 병목 현상: 과부하된 파티션을 호스팅하는 브로커가 병목 현상이 되어 다른 브로커가 아무리 유휴 상태이더라도 전체 토픽의 전체 처리량을 제한합니다.
소비자 지연 증가: 과부하된 파티션에 할당된 소비자는 따라잡기 위해 어려움을 겪어 허용할 수 없는 종단 간 지연이 발생합니다.
리소스 포화: 특정 브로커의 높은 I/O, CPU 또는 네트워크 사용률로 인해 불안정 위험이 증가합니다.

초기 토픽 구성을 위한 모범 사례

불균형에 대한 최선의 방어는 사전 예방적이고 정보에 기반한 초기 설정입니다.

1. 최적의 파티션 수 선택

파티션 수는 가장 중요한 결정입니다. 이는 소비자의 최대 병렬 처리 수와 브로커 간의 분배를 직접적으로 결정합니다.

경험 법칙: 하나의 소비자 그룹에서 예상되는 최대 소비자 수 이상으로 파티션 수를 선택합니다. 일반적인 소비자 수의 배수는 할당을 균등하게 유지하는 데 도움이 될 수 있지만 각 소비자 그룹은 독립적으로 균형을 이룹니다.
브로커 용량: 파티션 수가 클러스터를 압도해서는 안 됩니다. 각 파티션은 할당된 브로커의 리소스(메모리 및 디스크 공간)를 소비합니다. I/O 용량이 제약 조건인 경우 브로커당 더 적은 수의 파티션을 목표로 합니다.
향후 성장: 처리량이 높은 토픽의 경우 수평 확장(브로커 추가)이 중간에 파티션 수를 변경하는 것보다 훨씬 쉽습니다. 파티션 증가는 지원되지만(kafka-topics.sh --alter 통해) 기존 파티션을 자동으로 재조정하지는 않습니다.

2. 프로듀서를 위한 전략적 키 선택

키 편향을 방지하려면 프로듀서가 모든 파티션에 걸쳐 메시지의 균일한 분포를 생성하는 키를 선택해야 합니다.

핫 키 방지: 불균형적으로 많은 메시지를 생성하는 키를 식별합니다. user_id와 같은 높은 카디널리티 키는 일반적으로 잘 분산되지만, 매우 활동적인 사용자나 테넌트 하나가 여전히 핫 파티션을 만들 수 있습니다.
적절한 경우 무작위성 사용: 전체 데이터 세트 내에서 엄격한 순서가 필요하지 않은 경우 무작위화되거나 해시된 키를 사용하여 파티션 전체에 더 나은 분포를 강제합니다.

# 예: 일관되고 높은 카디널리티 ID를 사용하면 균일한 분포가 보장됩니다.
# 나쁨: 모든 것을 'SYSTEM_WIDE_CONFIG'로 키 지정
# 좋음: 볼륨이 균등하게 분포된 경우 'user_id' 또는 'session_id'로 키 지정

기존 토픽 재조정을 위한 실행 가능한 전략

불균형이 발생하면 평형을 복원하기 위해 특정 관리 작업이 필요합니다.

3. 파티션 할당 재조정 활용(소비자 수준)

소비자 그룹이 재조정될 때(소비자 참여/이탈로 인해) Kafka는 해당 소비자 그룹 내의 활성 멤버 간에 파티션을 균등하게 분배하려고 시도합니다.

구성 조정: 불필요하고 혼란스러운 재조정을 방지하기 위해 특히 세션 시간 초과 및 하트비트와 관련하여 소비자가 올바르게 구성되었는지 확인합니다.
고정 파티션 할당: 클라이언트 버전에서 지원하는 경우 고정 또는 협력적 고정 할당자를 고려합니다. 이러한 할당자는 소비자가 참여하거나 이탈할 때 파티션 소유권을 안정적으로 유지하여 불필요한 이동을 줄입니다.

4. 물리적 균형을 위한 브로커 재할당

문제가 파티션이 브로커 전체에 물리적으로 불균등하게 위치한 경우(예: 브로커 추가 또는 제거 후) kafka-reassign-partitions.sh 도구를 사용해야 합니다.

이 프로세스는 데이터 복제본 세트를 현재 브로커에서 새 브로커로 이동하여 물리적 저장 부하를 효과적으로 재조정합니다.

수동 재할당 단계(개념적 예):

현재 계획 생성: 토픽의 현재 파티션 할당을 결정합니다.
선호 복제본 목록 생성: 원하는 균형 잡힌 할당을 정의합니다(예: 과부하된 브로커 A에서 활용도가 낮은 브로커 B로 파티션 이동).
이동 실행: 생성된 JSON 계획으로 재할당 도구를 실행합니다.
완료 확인: 모든 복제본이 대상 브로커로 성공적으로 이동될 때까지 재할당 도구를 모니터링합니다.

경고: 파티션 재할당은 I/O 및 네트워크 집약적인 작업입니다. 복제 트래픽이 일시적으로 클라이언트 성능에 영향을 미칠 수 있으므로 유지 관리 기간 또는 트래픽이 적은 시간에 이러한 작업을 수행합니다.

5. 파티션 수 증가(확장)

현재 부하를 처리하기에 파티션 수가 실제로 너무 적은 경우(완벽한 분포에도 불구하고 높은 소비자 지연이 발생하는 경우) 파티션 수를 늘려야 합니다.

파티션을 안전하게 늘리는 단계:

새 수 결정: 새 총 파티션 수를 결정합니다(예: 12에서 24로).
토픽 변경: kafka-topics.sh 도구를 사용하여 수를 늘립니다. 새로 생성된 파티션은 현재 브로커 목록을 기반으로 브로커에 할당됩니다.

kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic my_topic --partitions 24

소비자 그룹 재조정: 변경 사항이 소비자 그룹에 적용되려면 그룹이 재조정을 트리거해야 합니다(일반적으로 소비자를 다시 시작하거나 시간 초과를 기다림). 새 파티션이 기존 소비자에게 할당되어 부하를 더 잘 분산합니다.
브로커 재할당(중요한 후속 조치): 파티션을 늘리면 새 부하만 분산됩니다. 새로 사용 가능한 브로커 슬롯 전체에 기존 부하를 분산하려면 브로커 재할당 계획(4단계)을 후속 조치하여 원래 파티션을 새 브로커 토폴로지로 이동해야 합니다.

모니터링 및 예방

서비스 저하를 일으키기 전에 불균형을 포착하려면 지속적인 모니터링이 필수적입니다.

추적할 주요 지표

모니터링 도구(Prometheus/Grafana 또는 내장 Kafka 도구)를 사용하여 다음 지표를 추적합니다.

파티션별 소비자 지연: 가장 직접적인 지표입니다. 동일한 소비자 그룹 내에서 파티션 간 지연이 크게 다르면 불균형이 있는 것입니다.
브로커 I/O 및 네트워크 사용량: 동일한 토픽을 호스팅하는 브로커 간 사용률의 높은 변동은 파티션 부하 편향을 나타냅니다.
브로커 수준 파티션 수: 특히 브로커를 확장 또는 축소한 후 각 브로커에 호스팅된 파티션 수가 시간이 지남에 따라 상대적으로 유사한지 확인합니다.

모범 사례: 정기적인 상태 점검

브로커를 추가하거나, 브로커를 폐기하거나, 프로듀서 키를 변경한 후 파티션 분포를 검토합니다. 하나의 테넌트, 장치 또는 고객이 토픽을 지배하기 시작하면 과부하된 파티션이 처리량 상한이 되기 전에 키 지정 전략을 수정하거나 해당 워크로드를 분할합니다.