[Kafka] 토픽 (Topic)과 토픽 랙 (Topic Lag)

토픽 (Topic)

Kafka에서 토픽은 데이터(메시지)가 저장되는 가장 기본적인 단위이다.

이는 DB의 테이블 혹은 파일 시스템의 폴더와 유사한 역할이다.

특징

• 논리적 구분 : Producer는 특정 토픽을 지정하여 메시지를 전송하고, Consumer는 특정 토픽을 구독하여 메시지를 가져감. 데이터의 목적에 따라 명시적인 이름을 붙여 관리함
• 파티션 (Partition) 구조 : 하나의 토픽은 병렬 처리를 위해 여러 개의 파티션으로 나뉨. 데이터는 파티션 내 순차적으로 기록됨.
• 로그 (Log) : Consumer가 데이터를 읽어도 데이터는 즉시 삭제되지 않고, 설정된 보존 주기나 용량 제한까지 디스크에 저장됨. 또한 새로운 데이터는 항상 맨 뒤에 추가.
• 오프셋 (Offset) : 파티션 내 각 메시지가 가지는 고유한 번호(주소). Consumer는 Offset을보고 어디까지 읽었는지 확인.

파티션 (Partiton)

토픽 내에서 메시지를 순차적으로 지정하는 로그, 각 메시지는 오프셋(Offset)으로 식별
하나의 토픽은 최소 1개의 파티션으로 시작, 여러 브로커(서버)에 분산 배치되어 리더/팔로워 복제를 통해 고가용성 보장

파티션이 1개인 경우 (Partition = 1)

모든 데이터가 하나의 줄(Queue)에 순서대로 쌓임

• 특징 : 토픽에 들어온 모든 메시지 순서가 완벽하게 보장
• 한계 : 병렬 처리 불가능. Consumer를 늘려도 동시에 1명의 Consumer만 데이터 읽기 가능
• 적합한 시나리오 : 순서가 중요한 저트래픽 로그

파티션이 여러 개인 경우 (Partition > 1)

Kafka 실제 운영 시 보통 파티션을 여러 개로 설정함

• 병렬 처리 : 파티션이 3개라면 Consumer 3대가 각각 파티션에 붙어 데이터를 동시 처리 가능. (처리 속도가 파티션 개수에 비례)
• 부하 분산 : 데이터가 여러 파티션에 나누어 저장되므로, 특정 브로커(서버)에 부하가 쏠리는 것 방지
• 적합한 시나리오 : 고트래픽 실시간 처리

파티션 수 결정

• 초기 설정 : 예상 트래픽의 2~3배로 시작
• 증가 방법 : 운영 중 --alter 명령으로 동적 추가 가능, 하지만 기존 데이터 재배분 없으므로 Lag 감소에 효과적
• 금융 시스템 적용: 계정계/배치 처리에서 파티션 수를 Consumer 인스터스 수와 동기화해 Lag 최소화, EAI 통합 시 키 기반 해싱으로 데이터 편향 방지

토픽 랙 (Topic Lag)

Lag은 지연이라는 뜻으로,
Producer가 전송한 메시지 양를 Consumer가 읽은 메시지 양이 따라가지 못하는 것

해당 파티션에서 Producer가 마지막으로 기록한 Offset과 Consumer가 마지막으로 읽어간 Offset의 차이

주요 용어

• Log End Offset (LEO) : Producer가 데이터를 넣어 마지막으로 저장된 지점
• Current Offset : Consumer가 현재 읽고 처리한 마지막 지점
• Lag = Log End Offset - Current Offset

Lag 발생 원인

• Consumer의 처리 속도가 Producer의 생산 속도보다 느린 경우 (비즈니스 로직의 무거움, 외부 I/O 지연, Consumer 수 부족 등...)
• Producer의 트래픽이 급증하거나, 특정 파티션에 키가 쏠려 "hot partition"이 생기는 경우

Lag가 중요한 이유

Topic Lag는 Kafka 기반 시스템의 성능 지표 중 가장 중요한 요소

• 실시간성 저하 : Lag가 높다는 것은 사용자가 보낸 요청이 시스템에 즉각 반영되지 않을 가능성이 높다는 뜻
• 시스템 장애 감지 : 특정 Consumer 그룹이 죽었거나, 에러로 인한 처리를 못 할 경우 Lag가 수직 상승함 => 장애 판단 가능
• 확장 기준 : Lag가 계속 쌓인다면 Consumer를 늘리거나 (Scale-out), 파티션 수 조정해야 한다는 신호

Lag 줄이는 방법

• Consumer 인스턴스 수 증가 : 파티션과 매칭되는 병렬 소비 확보하되, 파티션 수보다 Consumer 수가 많지 않도록 설계 필요
• Consumer 로직 최적화, 배치 크기, Poll interval, Commit 전략 등 조정
• Topic 파티션 수 늘림 : 부하를 분산할 수는 있지만, 근본적인 해결이 아니므로 전체 아키텍쳐 검토 필요
• Kafka Lag 모니터링 도구 활용 (ex. Burrow, Prometheus/Grafana ...)