Kafka 기초 (6) - Operations Basics: 유실 방지, Retention, 함정
replication과 acks로 유실을 막는 조합, retention과 디스크 계획, advertised listener 함정, 관리형 서비스 선택까지 Kafka 운영의 기초를 정리하고 시리즈를 마무리합니다.
Kafka 기초 시리즈의 마지막 6편입니다. 전체 목차는 0편에 있습니다.
유실 방지: Replication과 acks
지금까지의 실습은 broker 하나였고, 3편의 describe에서 ReplicationFactor: 1을 확인했습니다. 이 구성에서 broker의 디스크가 죽으면 이벤트도 함께 사라집니다. 운영에서 유실을 막는 것은 세 설정의 조합입니다.
| 설정 | 값 (관행) | 뜻 |
|---|---|---|
| replication factor | 3 | partition마다 복제본을 3개 두어 서로 다른 broker에 저장 |
min.insync.replicas | 2 | 쓰기가 성공으로 인정되려면 최소 2개 복제본에 저장돼야 함 |
producer acks | all | producer는 그 저장 확인까지 기다림 |
셋이 한 몸으로 움직입니다. producer가 acks=all로 보내면 broker는 복제본 2개 이상에 저장된 뒤에야 성공을 응답하고, 그 상태에서는 broker 하나가 통째로 죽어도 남은 복제본에 데이터가 있습니다. 하나라도 빼면 구멍이 생깁니다 — 복제본이 3개라도 acks=1이면 leader에만 저장된 순간 성공 처리되므로, 그 직후 leader가 죽으면 유실됩니다.
단일 broker 실습 환경은 이 조합이 불가능하므로 어디까지나 학습용입니다. 운영의 시작은 broker 3대입니다.
Retention: 디스크 계획의 출발점
이벤트를 지우는 기준은 소비 여부가 아니라 시간과 용량입니다 (1편).
| 설정 | 기본값 | 뜻 |
|---|---|---|
log.retention.hours | 168 (7일) | 이 시간이 지난 이벤트는 삭제 |
log.retention.bytes | -1 (무제한) | partition당 이 용량을 넘으면 오래된 것부터 삭제 |
디스크 사용량은 대략 “초당 유입량 × retention 기간 × replication factor”로 잡히므로, 디스크 계획은 이 설정에서 시작합니다. 그리고 retention은 4편의 lag와 한 쌍입니다. lag가 retention 기간을 넘도록 방치되면, 아직 읽지 못한 이벤트가 삭제되는 조용한 유실이 일어납니다. lag 모니터링이 운영의 첫 번째 지표인 이유입니다.
함정: Advertised Listener
로컬을 벗어나면 거의 반드시 밟는 함정입니다. 증상은 특이합니다 — 처음 접속은 되는데 그다음부터 전부 실패합니다.
원인은 Kafka의 접속 방식에 있습니다. client는 bootstrap 주소로 처음 접속한 뒤(2편), broker가 알려주는 advertised listener 주소로 다시 접속해 실제 통신을 합니다. 이 주소가 client 입장에서 닿을 수 없는 주소면, 첫 접속만 성공하고 이후 통신이 전부 실패합니다.
공식 image의 기본값이 localhost:9092라서 이 시리즈의 로컬 실습은 그대로 됐지만, 구성이 바뀌면 broker가 알려줄 주소를 client가 닿는 주소로 맞춰야 합니다.
- Docker Compose network 안에서 service 이름으로 접속하는 다른 container (Docker 기초 8편)
- 다른 머신에서 접속하는 client
접속이 이상하면 client 설정보다 broker의 advertised.listeners를 먼저 확인합니다.
Cluster를 직접 운영할 것인가
broker 3대 이상, 복제 설정, 디스크 계획, 버전 업그레이드까지 직접 감당하는 비용은 작지 않습니다. 그래서 운영에서는 관리형 서비스가 흔한 선택입니다.
- AWS MSK: broker 프로비저닝과 패치를 AWS가 맡습니다. Kafka Connect까지 관리형(MSK Connect)으로 제공됩니다
- Confluent Cloud: Kafka 개발사의 SaaS. Schema Registry 등 생태계 도구가 통합되어 있습니다
이 시리즈에서 배운 topic, partition, group, offset은 어느 쪽에서든 그대로입니다. 관리형이 대신해 주는 것은 broker 운영이지 설계가 아니므로, partition 수와 key 설계(3편), lag 모니터링(4편), 멱등 소비(5편)는 여전히 사용자의 몫입니다.
생태계 한 발 더
Kafka 주변에는 client 코드 없이 파이프라인을 구성하는 도구들이 있습니다.
- Kafka Connect: producer/consumer 코드를 직접 짜는 대신, 설정 JSON으로 소스와 타깃을 연결하는 실행 프레임워크입니다. DB의 변경 이력을 캡처해 Kafka로 보내는 Debezium이 대표적인 source connector이고, Kafka에서 DB로 적재하는 JDBC sink가 반대편입니다. 이 조합으로 MySQL → Kafka → PostgreSQL CDC 파이프라인을 구축한 기록이 AWS ML CI/CD와 CDC 파이프라인 구축 4편입니다
- Schema Registry: 이벤트의 스키마를 중앙에서 관리하고 호환성 정책을 강제하는 도구입니다. producer와 consumer가 여러 팀으로 갈라질 때 필요해집니다
시리즈를 마치며
여섯 편의 내용을 한 문단으로 압축하면 이렇습니다. Kafka는 생산자와 소비자 사이에 추가 전용 log를 두어 양쪽을 분리하고(1편), log는 partition으로 쪼개져 key가 순서 보장의 단위를 정하며(3편), consumer group이 partition을 나눠 맡고 offset으로 진행을 추적합니다(4편). 애플리케이션은 client 라이브러리로 이 구조 위에서 이벤트를 주고받고(5편), 운영은 replication·retention·lag의 관리입니다(이번 편).
실습 container 정리는 한 줄입니다.
1
docker rm -f kafka
관련 글
- Kafka 해부: 이 시리즈를 한 편으로 압축한 단편
- AWS ML CI/CD와 CDC 파이프라인 구축 4편: Kafka Connect와 Debezium으로 만든 실전 CDC 파이프라인
- Airflow 해부 시리즈: 배치 오케스트레이션과 스트리밍의 경계
- Docker 기초 시리즈: 이 시리즈의 실습 환경