Kafka Connect — source/sink 커넥터 구분과 3개 내부 토픽(offset/config/status)
Kafka Connect 내부 토픽 및 브로커 디스크 장애 대응 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka 공식 문서(documentation#connect_running) + AWS MSK 개발자 가이드 + Apache Kafka JIRA(KAFKA-8046) Apache Kafka 공식 문서 Kafka Connect 및 AWS MSK Kafka Connect 내부 토픽 가이드
이 모듈을 다 읽으면
- source 커넥터와 sink 커넥터가 오프셋을 서로 다른 메커니즘으로 관리한다는 것을 설명할 수 있다
- config.storage.topic이 왜 반드시 단일 파티션이어야 하는지 설명할 수 있다
kafka-learn-35에서 다룬 컨슈머 그룹 오프셋 커밋을 전제로, Kafka Connect가 source/sink 두 방향의 데이터 이동을 각각 어떻게 추적하는지, 그리고 분산 모드에서 클러스터 상태를 공유하는 3개 내부 토픽의 역할을 정리한다.
source 커넥터와 sink 커넥터 — 오프셋의 '기준'이 다르다
source 커넥터는 외부 시스템(DB, 파일, 로그 등)에서 데이터를 읽어 Kafka 토픽으로 내보내는 역할을 한다. 이때 '어디까지 읽었는지'는 Kafka의 개념이 아니라 외부 시스템 고유의 위치 표현(예: DB의 마지막 읽은 PK/타임스탬프, 파일의 바이트 오프셋, DB의 binlog 위치)이므로, Connect 프레임워크가 이를 별도로 추적해 offset.storage.topic에 저장한다. 반대로 sink 커넥터는 Kafka 토픽에서 데이터를 읽어 외부 시스템에 쓰는 역할이며, 내부적으로 일반 컨슈머 그룹처럼 동작하기 때문에 '어디까지 읽었는지'는 kafka-learn-35에서 다룬 일반적인 컨슈머 그룹 오프셋 커밋 메커니즘(__consumer_offsets 토픽, group.id=커넥터명)을 그대로 사용한다 — offset.storage.topic을 쓰지 않는다.
핵심 포인트
- source 커넥터: 외부 시스템의 위치(파일 오프셋, DB PK/타임스탬프, binlog 위치 등)를 offset.storage.topic에 저장
- sink 커넥터: 일반 컨슈머 그룹처럼 __consumer_offsets 토픽에 커밋 — offset.storage.topic을 쓰지 않는다는 게 자주 혼동되는 지점
config.storage.topic — 왜 파티션이 반드시 1개여야 하는가
config.storage.topic은 클러스터에 등록된 모든 커넥터/태스크의 설정을 저장하며, 설정이 변경될 때마다 새 레코드가 기록되고 compaction으로 커넥터별 최신 설정만 유지된다. 이 토픽은 파티션 수가 설정 불가능하게 1개로 고정돼 있는데, 이는 여러 워커가 동시에 설정을 변경해도 클러스터 전체가 '설정 변경이 일어난 순서'에 대해 완전히 하나의 합의된 순서(total order)를 갖도록 보장하기 위함이다 — 파티션이 여러 개면 파티션마다 순서가 따로 매겨져, 워커마다 설정 변경을 다른 순서로 관찰할 수 있는 위험이 생긴다.
핵심 포인트
- config.storage.topic은 파티션 수가 1로 고정(설정 불가) — 모든 워커가 설정 변경 순서를 동일하게 관찰하도록 보장하는 total order가 목적
- compaction으로 커넥터별 최신 설정만 유지, 변경 시마다 신규 레코드 추가
status.storage.topic과 3개 토픽의 공통 요구사항
status.storage.topic은 커넥터/태스크의 실행 상태(RUNNING/PAUSED/FAILED 등)를 저장하며, 여러 파티션을 가질 수 있다 — 이를 통해 REST API를 통한 상태 조회 요청을 클러스터의 어느 워커가 받든 최신 상태를 답할 수 있다. 세 토픽(offset/config/status) 모두 compaction이 설정돼야 하며, 같은 group.id로 클러스터를 구성하는 모든 워커는 반드시 동일한 세 토픽 이름을 설정으로 가져야 한다 — 이름이 다르면 서로 다른 Connect 클러스터로 분리돼버린다. 운영 시에는 Connect를 처음 기동하기 전에 이 3개 토픽을 원하는 파티션 수·복제 팩터로 미리 수동 생성해두는 것이 권장되는데, 자동 생성에 맡기면 브로커의 기본 파티션/복제 설정을 따라가 버려 운영 의도와 어긋날 수 있기 때문이다.
핵심 포인트
- status.storage.topic: 커넥터/태스크 상태 저장, 다중 파티션 가능 — 어느 워커든 최신 상태를 답할 수 있게 함
- 3개 토픽 모두 compaction 필수, 클러스터 내 전 워커가 동일한 토픽 이름을 설정해야 함 — 다르면 별개 클러스터로 분리
- 운영 권장: Connect 최초 기동 전 3개 토픽을 원하는 파티션/복제 팩터로 수동 생성