Kafka 파티션 불균형 문제 해결을 위한 모범 사례

Apache Kafka의 강점은 토픽 파티셔닝을 통해 구현되는 분산 특성에 있습니다. 파티션은 데이터를 여러 브로커에 분산하여 병렬 소비와 높은 처리량을 가능하게 합니다. 하지만 이 파티션들이 고르게 분산되지 않거나 시간이 지남에 따라 불균형한 부하 패턴이 발생하면 파티션 불균형으로 이어집니다. 이러한 불균형은 성능을 심각하게 저하시키고, 과부하된 파티션에서 컨슈머 랙을 증가시키며, Kafka 스케일링의 이점을 약화시킬 수 있는 중요한 운영 문제입니다.

이 가이드는 Kafka 파티션 불균형의 메커니즘을 탐구하고, 그 영향을 상세히 설명하며, 분산 스트리밍 플랫폼이 최적의 처리량과 복원력을 유지하도록 초기 구성부터 지속적인 모니터링 및 재조정 전략에 이르기까지 실행 가능한 모범 사례를 제공합니다.

Kafka 파티션 불균형 이해

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

불균형의 원인

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

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

시스템 성능에 미치는 영향

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

처리량 병목 현상: 과부하된 파티션을 호스팅하는 브로커가 병목 현상이 되어, 다른 브로커가 얼마나 유휴 상태인지와 상관없이 전체 토픽의 전반적인 처리량을 제한합니다.
컨슈머 랙 증가: 과부하된 파티션에 할당된 컨슈머는 속도를 따라잡는 데 어려움을 겪게 되어 허용할 수 없는 종단 간 지연을 초래합니다.
리소스 포화: 특정 브로커에서 높은 I/O, CPU 또는 네트워크 활용률이 발생하여 불안정성의 위험을 증가시킵니다.

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

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

1. 최적의 파티션 수 선택

파티션 수는 단연코 가장 중요한 결정입니다. 이는 컨슈머의 최대 병렬 처리와 브로커 전반의 분배를 직접적으로 결정합니다.

경험 법칙: 좋은 시작점은 파티션 수가 토픽을 병렬로 읽을 최대 컨슈머 그룹 수의 배수가 되도록 하는 것입니다 (그룹 내 컨슈머 간의 균등한 분배를 보장하기 위해).
브로커 용량: 파티션 수가 클러스터에 과부하를 주어서는 안 됩니다. 각 파티션은 할당된 브로커에서 리소스(메모리 및 디스크 공간)를 소비합니다. I/O 용량이 제약 조건인 경우 브로커당 파티션 수를 줄이는 것을 목표로 하십시오.
미래 성장: 높은 처리량의 토픽에 대해 실행 중에 파티션 수를 변경하는 것보다 수평적으로 확장(브로커 추가)하는 것이 훨씬 쉽습니다. 파티션 증가는 지원되지만 (kafka-topics.sh --alter를 통해), 기존 파티션을 자동으로 재조정하지는 않습니다.

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

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

핫 키 방지: 메시지의 작은 하위 집합에 매핑되는 경우, 카디널리티가 높고 자주 사용되는 식별자를 키로 사용하는 것을 식별하고 피하십시오.
적절할 때 무작위성 사용: 전체 데이터셋 내에서 엄격한 순서가 필요하지 않다면, 파티션 전반에 더 나은 분배를 강제하기 위해 무작위 또는 해시된 키를 사용하십시오.

# 예시: 일관되고 카디널리티가 높은 ID를 사용하여 균등한 분배 보장
# 나쁜 예: 모든 것을 'SYSTEM_WIDE_CONFIG'로 키잉
# 좋은 예: 'user_id' 또는 'session_id'가 볼륨 면에서 균등하게 분배되는 경우 이들로 키잉

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

불균형이 발생하면 균형을 회복하기 위해 특정 관리 조치가 필요합니다.

3. 파티션 할당 재조정 활용 (컨슈머 레벨)

컨슈머 그룹이 재조정될 때 (컨슈머의 가입/탈퇴로 인해), Kafka는 해당 컨슈머 그룹 내 활성 멤버들에게 파티션을 균등하게 분배하려고 시도합니다.

구성 튜닝: 불필요하고 방해적인 재조정을 방지하기 위해 특히 세션 타임아웃 및 하트비트와 관련하여 컨슈머가 올바르게 구성되었는지 확인하십시오.
Sticky 파티션 할당: 최신 Kafka 버전은 기본적으로 Sticky 파티션 할당을 사용합니다. 이는 컨슈머가 가입하거나 탈퇴할 때 파티션 할당을 안정적으로 유지하여 데이터 이동 및 부하 급증을 최소화하고, 반드시 이동해야 하는 파티션만 이동하는 것을 목표로 합니다.

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 및 네트워크 사용량: 동일한 토픽을 호스팅하는 브로커 간에 활용률의 높은 편차가 있다면 파티션 부하가 비대칭적임을 나타냅니다.
브로커 수준 파티션 수: 시간이 지남에 따라, 특히 브로커를 스케일 업 또는 다운한 후에 각 브로커에 호스팅된 파티션 수가 상대적으로 비슷하게 유지되는지 확인하십시오.

모범 사례: 정기적인 상태 확인

특히 주요 인프라 변경(예: 브로커 추가 또는 폐기) 후에는 파티션 분배에 대한 분기별 또는 반기별 검토를 예약하여 선제적으로 재할당을 실행하고 장기적인 비대칭을 방지하십시오.