Kafka 운영: 복제, 컨슈머 그룹, 튜닝, 모니터링

이 노트의 자리

메시지 큐와 Kafka가 「Kafka가 무엇이고 왜 빠른가」를 다룬다면, 이 노트는 클러스터를 돌릴 때 정하는 값과 보는 지표를 다룬다. 설정 이름과 기본값은 Kafka 4.x 기준이다.

복제와 ISR

토픽의 파티션마다 복제 계수(replication factor) 만큼 복제본(replica)을 서로 다른 브로커에 둔다. 복제본 하나가 리더(leader) 로 모든 읽기·쓰기를 받고, 나머지 팔로워(follower) 는 리더의 로그를 가져와(fetch) 따라 쓴다. 보통 복제 계수는 3이고, broker.rack을 지정하면 복제본을 랙·가용 영역(AZ)마다 흩어 둔다.

ISR이 복제의 일관성 단위다. 쓰기 확인, 리더 선출, 컨슈머 가시성이 모두 ISR을 기준으로 정해지므로, ISR이 자주 줄었다 늘었다 하면 내구성과 가용성이 함께 흔들린다.

acks와 min.insync.replicas

프로듀서의 acks는 「어디까지 기록되면 성공으로 보나」, 토픽·브로커의 min.insync.replicas는 「acks=all 쓰기에 ISR이 최소 몇 개 있어야 하나」를 정한다.

복제 계수 3, min.insync.replicas=2, acks=all이 내구성의 표준 조합이다.

min.insync.replicas는 acks=all에만 적용된다. acks=1 프로듀서는 ISR이 하나뿐이어도 쓰기에 성공하므로, 클러스터 설정만으로 내구성이 보장되지 않는다.

컨트롤러와 장애 조치

ZooKeeper에서 KRaft로

클러스터 메타데이터(브로커 목록, 토픽, 파티션 리더, ISR, 설정, ACL)를 누가 관리하느냐가 바뀌었다. Kafka 4.0부터는 KRaft만 지원한다.

컨트롤러 쿼럼은 과반이 살아 있어야 메타데이터를 바꿀 수 있다. 3대면 1대, 5대면 2대까지 견딘다. 중요한 클러스터에서는 컨트롤러를 브로커와 같은 프로세스에 두는 결합 모드(combined mode)보다 전용 컨트롤러 노드를 둔다.

ZooKeeper 클러스터는 4.x로 바로 올릴 수 없다. 3.x에서 KRaft로 먼저 옮긴 뒤 올린다. 브리지 릴리스로는 3.9를 쓴다.

1. 3.9로 올린다
2. KRaft 컨트롤러 쿼럼을 마이그레이션 모드로 띄운다 (ZooKeeper 메타데이터를 복사하고, 이후 변경을 양쪽에 쓴다)
3. 브로커를 하나씩 KRaft 모드로 재시작한다
4. 마이그레이션을 끝내고 ZooKeeper 연결을 끊는다 (이 뒤로는 되돌릴 수 없다)
5. 4.x로 올린다

전환 전에는 ZooKeeper 전용 기능·도구를 쓰는 곳(ZooKeeper 주소로 접속하는 옛 스크립트, ZooKeeper에 저장한 SCRAM 자격 증명, 외부 도구)을 찾아 바꿔 둔다.

브로커 장애 조치

flowchart TB
  d["브로커 2 다운"] --> d1["활성 컨트롤러가 하트비트 끊김을 감지<br/>(broker.session.timeout.ms, 기본 9초)"]
  d1 --> d2["브로커 2가 리더였던 파티션마다<br/>ISR에 남은 복제본 중 새 리더를 뽑는다"]
  d2 --> d3["메타데이터 로그에 기록, 브로커들이 따라 읽는다"]
  d3 --> d4["프로듀서·컨슈머는 NOT_LEADER_OR_FOLLOWER 오류를 받고<br/>메타데이터를 새로 받아 새 리더로 재시도한다"]
  r["브로커 2 복구"] --> r1["팔로워로 돌아와 따라잡고 ISR에 다시 들어간다"]
  r1 --> r2["선호 리더 선출(auto.leader.rebalance.enable)이<br/>리더 자리를 원래 배치로 되돌린다"]

리더가 한 브로커에 몰리면 그 브로커만 바빠지므로, 장애 뒤에는 선호 리더(preferred leader) 로 리더를 되돌리는 것까지가 복구다. 활성 컨트롤러가 죽으면 쿼럼 안에서 Raft 선거로 새 활성 컨트롤러를 뽑는다.

프로듀서

전송 경로와 전송 방식

send()는 레코드를 레코드 누산기(record accumulator) 의 파티션별 배치에 넣고 바로 돌아온다. 별도 송신 스레드가 배치를 브로커별로 묶어 보낸다.

기본은 비동기 전송 + 콜백이다. 동기 전송은 건수가 적고 결과를 바로 확인해야 하는 곳에만 쓴다.

배치와 지연

배치가 크면 요청 수가 줄고 압축률이 올라 처리량이 늘지만, 레코드가 기다리는 시간만큼 지연이 는다. 브로커 부하는 바이트보다 요청 수에 민감하므로, 작은 레코드를 많이 보내는 프로듀서는 배치를 키우는 것이 가장 큰 개선이다.

압축 코덱

압축은 프로듀서가 배치째 하고, 브로커는 토픽의 compression.type=producer(기본값)이면 받은 그대로 저장하며, 컨슈머가 푼다. 토픽에 프로듀서와 다른 코덱을 지정하면 브로커가 다시 압축하느라 CPU를 쓴다. 레코드가 비슷할수록(JSON 로그) 배치가 클수록 압축이 잘 된다.

멱등 프로듀서와 순서

재시도는 중복과 순서 뒤바뀜을 만든다. 첫 요청이 기록됐는데 응답만 잃으면 재전송이 같은 레코드를 한 번 더 쓰고, 요청 여러 개가 동시에 날아가는 중에 앞 요청만 실패해 재전송되면 뒤 요청보다 늦게 기록된다.

멱등 프로듀서(enable.idempotence=true, 기본값)는 프로듀서마다 ID(PID)를 받고 파티션별 일련번호를 레코드에 붙인다. 브로커는 이미 받은 번호를 버리고, 번호가 건너뛰면 거절한다. 그래서 max.in.flight.requests.per.connection이 5 이하인 한 재시도해도 중복 없이 파티션 안 순서가 지켜진다. 멱등성이 꺼진 채 재시도와 동시 요청 수 2 이상을 쓰면 순서가 뒤바뀔 수 있다.

멱등 프로듀서가 막는 것은 한 프로듀서 세션 안의 재전송 중복뿐이다. 애플리케이션이 실패를 보고 같은 내용을 새로 send()하거나, 프로듀서가 재시작해 새 PID를 받으면 브로커는 다른 레코드로 본다. 이런 중복은 메시지에 업무 키를 넣고 소비자가 걸러야 한다. 여러 파티션에 걸친 원자적 쓰기는 트랜잭션이 맡는다(메시지 큐와 Kafka의 전달 보장).

처리량과 지연 튜닝

acks=1로 바꿔도 종단 지연은 생각만큼 줄지 않는다. 컨슈머는 하이 워터마크까지만 읽으므로 팔로워 복제가 끝나야 메시지가 보이기 때문이다.

컨슈머 그룹

리밸런스

컨슈머 그룹의 파티션 배정을 다시 정하는 일이 리밸런스(rebalance) 다. 그룹 코디네이터(브로커 하나)가 관리한다.

리밸런스를 줄이는 방법은 다음과 같다.

• 정적 멤버십(static membership): group.instance.id를 고정하면 세션 타임아웃 안에 같은 ID로 돌아온 컨슈머는 리밸런스 없이 원래 파티션을 다시 받는다. 롤링 배포에 효과가 크다.
• max.poll.records(기본 500)를 줄이거나 max.poll.interval.ms를 늘려, 한 번 가져온 묶음을 처리하는 시간이 간격을 넘지 않게 한다.
• 파티션을 내려놓는 콜백(onPartitionsRevoked)에서 처리한 오프셋을 커밋해, 새 담당자가 같은 메시지를 다시 처리하는 범위를 줄인다.

오프셋 관리

컨슈머 그룹의 커밋 오프셋은 압축 토픽 __consumer_offsets에 (그룹, 토픽, 파티션) 키로 저장된다. 재시작하거나 파티션을 새로 받은 컨슈머는 커밋된 오프셋부터 읽는다. 커밋이 없거나 그 오프셋이 보존 기간이 지나 사라졌으면 auto.offset.reset을 따른다(latest 기본, earliest, 예외를 내는 none). 특정 시점부터 다시 읽으려면 seek()이나 kafka-consumer-groups.sh --reset-offsets를 쓴다.

처리 루프에서는 commitAsync, 종료·리밸런스 때는 commitSync로 마무리하는 조합이 흔하다. 처리한 뒤 커밋하면 유실 대신 중복이 생기므로 처리는 멱등하게 만든다.

컨슈머 랙

컨슈머 랙(consumer lag) 은 파티션별로 「로그 끝 오프셋 − 커밋된 오프셋」이다. read_committed 컨슈머는 로그 끝 대신 마지막 안정 오프셋(LSO, 아직 끝나지 않은 트랜잭션의 시작점)을 기준으로 한다.

• 확인: kafka-consumer-groups.sh --describe --group <그룹>이 파티션별 CURRENT-OFFSET, LOG-END-OFFSET, LAG를 보여 준다. 클라이언트 지표 records-lag-max, 그룹 단위로 랙 추세를 판정하는 Burrow, Prometheus 익스포터도 쓴다.
• 경보는 절댓값보다 추세로 건다. 순간 폭주로 늘었다가 줄어드는 랙은 정상이고, 계속 늘어나는 랙이 문제다. 랙을 「몇 초 늦었나」로 바꿔 보면 SLA와 비교하기 쉽다.

랙이 0이라고 처리가 끝난 것은 아니다. 랙은 커밋된 오프셋으로 계산하고, 커밋은 「처리 완료」가 아니라 「여기까지 다시 읽지 않아도 된다」는 표시일 뿐이다.

• 자동 커밋이나 「받자마자 커밋」은 처리 전에 오프셋을 올린다. 레코드를 스레드 풀로 넘겨 비동기로 처리하면 랙 0인 순간에도 작업은 큐에 쌓여 있다.
• 처리에 실패해 재시도 토픽이나 DLQ로 보낸 레코드도 원래 토픽에서는 커밋된다.
• 그래서 실제 완료는 처리 결과 쪽 지표(처리 성공 건수, 종단 지연, DLQ 적재량)로 따로 본다.

공유 그룹: 큐처럼 읽기

컨슈머 그룹은 파티션 하나를 컨슈머 하나에 묶으므로 병렬도가 파티션 수에 갇힌다. 공유 그룹(share group, KIP-932 「Queues for Kafka」) 은 같은 파티션을 여러 컨슈머가 레코드 단위로 나눠 받고, 레코드마다 확인(acknowledge)·해제·거절한다. 파티션 수보다 많은 컨슈머로 작업 큐처럼 처리할 수 있지만, 파티션 안 순서는 보장하지 않는다. 4.0 조기 공개, 4.1 미리보기를 거쳐 4.2에서 정식 기능이 됐다.

보존과 로그 컴팩션

파티션 로그는 세그먼트(segment) 파일들로 나뉜다. 지금 쓰고 있는 활성 세그먼트가 segment.bytes(기본 1GiB)나 segment.ms(기본 7일)에 이르면 닫히고 새 세그먼트가 열린다. 정리는 닫힌 세그먼트 단위로 일어난다.

• 세그먼트는 안의 가장 새 레코드가 보존 기간을 넘어야 지워지고, 활성 세그먼트는 지워지지 않는다. 그래서 데이터는 설정한 보존 기간보다 오래 남을 수 있다.
• 보존 기간은 컨슈머가 읽었는지와 상관없다. 컨슈머가 보존 기간보다 오래 멈춰 있으면 읽지 못한 메시지가 사라지고 auto.offset.reset이 적용된다.

로그 컴팩션

flowchart TB
  subgraph row1[" "]
    direction LR
    r1["컴팩션 전"] ~~~ a0["K1=a"] ~~~ a1["K2=b"] ~~~ a2["K1=c"] ~~~ a3["K3=d"] ~~~ a4["K2=null"] ~~~ a5["K1=e"]
  end
  subgraph row2[" "]
    direction LR
    r2["컴팩션 후"] ~~~ s1[" "] ~~~ s2[" "] ~~~ s3[" "] ~~~ b3["K3=d"] ~~~ b4["K2=null<br/>(tombstone, 일정 시간 뒤 사라진다)"] ~~~ b5["K1=e"]
  end
  subgraph row3[" "]
    direction LR
    r3["오프셋<br/>남은 레코드의 오프셋은 그대로다"] ~~~ o0["0"] ~~~ o1["1"] ~~~ o2["2"] ~~~ o3["3"] ~~~ o4["4"] ~~~ o5["5"]
  end
  row1 ~~~ row2 ~~~ row3

컴팩션 토픽은 처음부터 끝까지 읽으면 키별 최신 상태가 복원되는 테이블 역할을 한다. 반대로 「무슨 일이 있었나」 이력을 남겨야 하는 이벤트 토픽에 쓰면 중간 사건이 사라진다.

보안

리스너는 여러 개를 둘 수 있다. 브로커 사이 복제용, 내부 서비스용, 외부 클라이언트용 리스너를 나눠 보안 프로토콜을 다르게 준다(listener.security.protocol.map).

ACL은 자원 유형(Topic, Group, Cluster, TransactionalId)과 이름 패턴(정확히 일치 LITERAL, 접두사 PREFIXED)으로 건다.

# 주문 서비스는 orders 토픽에 쓰기만
kafka-acls.sh --bootstrap-server broker:9093 --command-config admin.properties \
  --add --allow-principal User:order-svc --operation Write --topic orders
 
# 정산 서비스는 orders 토픽을 settlement 그룹으로 읽기 (토픽과 그룹 둘 다 Read가 필요하다)
kafka-acls.sh --bootstrap-server broker:9093 --command-config admin.properties \
  --add --allow-principal User:settle-svc --operation Read --topic orders --group settlement

ACL이 하나도 없는 자원은 기본적으로 거부된다(allow.everyone.if.no.acl.found=false). 운영 계정은 super.users로 지정한다.

멀티 테넌시

공유 클러스터에 여러 팀·고객을 태울 때는 이름·권한·자원을 함께 나눈다.

클러스터 운영

하드웨어와 네트워크

롤링 재시작과 무중단 업그레이드

브로커를 내릴 때는 통제된 종료(controlled shutdown, 기본 켜짐) 가 그 브로커가 리더인 파티션의 리더십을 미리 다른 ISR로 옮긴다. 그래서 갑자기 죽을 때보다 사용 불가 시간이 짧다.

flowchart TB
  L["for 브로커 in 클러스터"] --> S1["1. 브로커를 정상 종료한다<br>(리더십이 먼저 옮겨진다)"] --> S2["2. 바이너리·설정을 바꾸고 다시 띄운다"] --> S3["3. UnderReplicatedPartitions가 0이 될 때까지 기다린다<br>이걸 건너뛰면 다음 브로커를 내릴 때 ISR이 부족해진다"] --> S4["4. 다음 브로커로"]
  S4 --> S1
  S4 -- "업그레이드라면 모든 브로커를 올린 뒤" --> U["메타데이터 버전을 올린다<br>(kafka-features.sh upgrade)"]

복제 계수 3, min.insync.replicas=2면 브로커 한 대가 내려가도 acks=all 쓰기가 계속된다. 한 번에 두 대를 내리면 쓰기가 멈추는 파티션이 생긴다. 메타데이터 버전을 마지막에 올리는 이유는 그 전까지 옛 버전으로 되돌릴 수 있게 하기 위해서다. 클러스터 자체를 바꿔야 하면 MirrorMaker 2로 새 클러스터에 데이터를 복제해 두고 클라이언트를 옮긴다.

브로커 증설과 파티션

새 브로커는 붙여도 아무 파티션도 맡지 않는다. 기존 파티션은 그대로 있고, 이후 만든 토픽만 새 브로커에 배치된다. 부하를 옮기려면 파티션을 재배치해야 한다.

파티션 수를 늘릴 때는 다음을 안다.

• 파티션은 줄일 수 없다. 늘리기만 된다.
• 기본 파티셔너는 hash(key) % 파티션 수로 파티션을 고르므로, 늘리면 같은 키가 다른 파티션으로 간다. 키별 순서가 늘린 순간을 경계로 깨지고, 컴팩션 토픽은 한 키의 옛 값과 새 값이 다른 파티션에 남는다. 그래서 키 기반 토픽은 처음부터 파티션을 넉넉히 잡는다.
• 파티션이 너무 많으면 파일·메모리·리더 선출·복제 부담이 는다. 목표 처리량을 파티션 하나의 처리량(프로듀서 쪽과 컨슈머 쪽 중 느린 것)으로 나눠 수를 정한다.

모니터링과 장애 진단

핵심 지표

브로커 지표는 JMX로 나온다. Prometheus JMX 익스포터 + Grafana로 모으고, 랙은 Burrow나 컨슈머 그룹 익스포터, 파티션 균형은 Cruise Control로 본다. 웹 UI로는 Kafka UI, AKHQ 같은 도구가 있다.

프로듀서 전송이 느릴 때: 어느 쪽 병목인가

flowchart LR
  p["record-queue-time-avg 높음,<br/>bufferpool-wait-ratio #gt; 0"] --> pc["레코드가 누산기에서 오래 기다린다: 프로듀서 쪽<br/>(송신이 못 따라감, 배치가 작아 요청이 너무 많음,<br/>buffer.memory 부족, 직렬화·압축 CPU)"]
  l["request-latency-avg 높음"] --> lc["보낸 요청의 왕복이 느리다: 네트워크나 브로커 쪽<br/>브로커 Produce TotalTimeMs를 쪼개 본다"]
  lc --> q["RequestQueueTimeMs 높음"] --> qc["요청 처리 스레드 포화<br/>(num.io.threads, RequestHandlerAvgIdlePercent)"]
  lc --> lt["LocalTimeMs 높음"] --> ltc["리더의 디스크 쓰기가 느리다"]
  lc --> rt["RemoteTimeMs 높음"] --> rtc["acks=all에서 팔로워 복제를 기다린다<br/>(느린 팔로워, ISR 문제)"]
  lc --> rs["ResponseSendTimeMs 높음"] --> rsc["네트워크 스레드나 대역폭 포화"]

배치 크기 평균(batch-size-avg)과 요청당 레코드 수(records-per-request-avg)가 작으면 브로커가 아니라 배치 설정부터 고친다.

흔한 장애와 대응

정리

• 내구성은 복제 계수 3, min.insync.replicas=2, acks=all, 언클린 선출 금지의 조합으로 얻고, 일관성의 기준은 ISR과 하이 워터마크다.
• 4.0부터 메타데이터는 KRaft 컨트롤러 쿼럼이 관리한다. ZooKeeper 클러스터는 3.9에서 먼저 옮긴다.
• 프로듀서 처리량은 배치·압축·비동기 전송에서, 순서와 중복 방지는 멱등 프로듀서에서 나온다.
• 리밸런스는 정적 멤버십·협력적 리밸런스·새 그룹 프로토콜로 줄이고, 오프셋은 처리한 뒤 커밋한다.
• 랙이 0이어도 처리가 끝났다는 뜻은 아니고, 컨슈머를 늘려도 파티션 수·핫 파티션·하류 병목은 풀리지 않는다.
• 운영의 눈은 URP, UnderMinIsr, 오프라인 파티션, 요청 시간 분해, 랙 추세다.

관련 노트: 메시지 큐와 Kafka, 이벤트 기반 아키텍처 설계, 데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성, 분산 시스템의 시간과 장애: 8가지 착각부터 논리 시계까지, 고가용성 이중화 구조와 장애 감지