Kafka Connect는 “소스 시스템(DB, 파일, SaaS 등) → Kafka” 또는 “Kafka → 싱크 시스템(검색엔진, 스토리지 등)”으로 데이터를 코드 최소화로 이동시키는 프레임워크입니다. 운영 관점에서는 Distributed 모드(클러스터 구성)로 띄우고, 커넥터는 REST API로 배포/관리하는 패턴이 표준에 가깝습니다. Source
1) Kafka Connect 아키텍처 한 장 요약
Kafka Connect의 핵심 구성요소는 아래 4개로 이해하면 운영이 쉬워집니다.
- Worker: Connect 프로세스(JVM). Standalone/Distributed로 실행 가능
- Connector: “무엇을 어디로 옮길지” 정의(논리 단위)
- Task: 실제 병렬 처리 단위(Connector가 여러 Task로 쪼개질 수 있음)
- Internal Topics: 설정/오프셋/상태를 Kafka 토픽에 저장 (분산 운영의 핵심)
Distributed 모드는 운영에 권장되며, 노드 장애 시 다른 워커로 작업이 재분배되고(리밸런싱), 상태/오프셋/설정이 Kafka 내부 토픽에 저장되어 안전합니다. Source
아키텍처 참고 이미지(블로그에 삽입용):
-
Kafka Connect 개념/구성 다이어그램
출처: https://daniel.arneam.com/blog/distributedarchitecture/2020-10-15-Kafka-Connect-Concepts/ -
REST 기반 관리(Connect/REST API 흐름 참고)
출처: https://developer.hpe.com/blog/kafka-connect-and-kafka-rest-api-on-mapr-streaming-just-became-a-whole-l/
2) 실행 모드 선택: Standalone vs Distributed (운영은 보통 Distributed)
- Standalone: 개발/테스트, 단일 프로세스. 커넥터 설정 파일을 커맨드라인 인자로 넘김. Source
- Distributed: 운영 권장(확장/HA/관리 편의). 커넥터는 REST API로 생성/수정/삭제. Source
결론: “운영환경 셋팅”이 목적이면 Distributed 모드를 기준으로 환경을 잡는 걸 추천합니다.
3) 설치 전략 2가지 (선택지)
A. “Apache Kafka 배포판” 기반
- Kafka 바이너리(브로커/Connect 포함)를 설치하고 Connect 워커를 직접 실행하는 방식
- 장점: 순수/가벼움, 벤더 종속 낮음
- 단점: 플러그인/모니터링/보안 구성은 직접 챙겨야 함
B. “Confluent Platform” 기반(실무에서 많이 씀)
- Connect, Schema Registry, 각종 커넥터/운영 도구 생태계가 잘 갖춰짐
- Connect 실행/플러그인/레퍼런스가 풍부함 Source
4) 운영환경 기본 전제(권장 체크리스트)
Kafka Connect는 JVM 프로세스이며, 메시지 크기/버퍼링/압축/커넥터 종류에 따라 CPU·메모리 요구량이 달라집니다. 컨테이너/Kubernetes 같은 환경에서도 잘 동작하며, Connect 자체가 스케일/재시작을 담당하지 않으므로(=오케스트레이터가 담당) 운영 플랫폼과 궁합이 좋습니다. Source
운영 체크리스트:
- Kafka 브로커 준비(bootstrap 서버)
- 네트워크/대역폭(특히 대용량 싱크/소스)
- JVM 메모리/GC(heap 기본값으로 시작 후 메트릭 기반 튜닝) Source
- 플러그인 경로(plugin.path) 표준화 (모든 워커 동일)
- Internal topics(config/offset/status) 복제/컴팩션 정책
- 로그/메트릭/헬스체크 체계
5) 플러그인(커넥터) 설치: plugin.path로 통일
Kafka Connect 플러그인은 보통 “커넥터 + 의존 JAR” 묶음 디렉터리 형태로 설치합니다. Connect는 플러그인을 plugin.path에 지정한 디렉터리들에서 발견하며, 플러그인 간 라이브러리 충돌을 피하기 위해 클래스로더 격리를 합니다. Source
예시:
# worker 설정에 포함
plugin.path=/usr/local/share/kafka/plugins운영 팁:
- 모든 워커 노드에 동일한 플러그인 디렉터리 구조를 배포(버전도 동일)
- 커넥터 버전 중복 설치(서로 다른 버전 공존)는 장애의 단골 원인 → “노드별 동일 버전” 원칙
6) Distributed Worker 설정 핵심(운영의 80%)
Distributed 모드에서는 워커 설정 파일(예: connect-distributed.properties)이 핵심입니다. 실행 자체는 아래처럼 단순합니다. Source
bin/connect-distributed worker.properties(1) 클러스터 식별: group.id
같은 group.id를 가진 워커들이 한 Connect 클러스터를 이룹니다. Source
(2) 내부 토픽 3종은 “클러스터 단위로 공유”
Distributed 워커는 아래 3개 내부 토픽에 설정/오프셋/상태를 저장합니다. 운영 안정성을 위해 복제 계수, 파티션 수, 컴팩션 정책이 중요합니다. Source
config.storage.topic(설정) — 파티션 1 고정offset.storage.topic(오프셋)status.storage.topic(상태)
또한 같은 Connect 클러스터의 모든 워커는 위 3개 토픽 이름을 완전히 동일하게 가져야 합니다. Source
(3) 내부 토픽 자동 생성 vs 수동 생성
Connect가 시작 시 내부 토픽을 자동 생성할 수 있고(권장), 보안/정책상 막혀 있으면 수동 생성이 필요합니다. 문서에는 수동 생성 예시도 제공됩니다. Source
7) 커넥터 배포/운영: “REST API로 한다” (Distributed 모드)
Standalone은 커넥터 설정 파일을 실행 시 인자로 넣지만, Distributed는 REST 요청으로 커넥터를 생성/관리합니다. Source
이 말은 곧 운영 자동화의 기본 단위가:
- Git에 커넥터 JSON 보관
- CI/CD에서 REST로 배포
- 장애 시 REST로 pause/resume/restart
…로 잡힌다는 뜻입니다.
(블로그 이미지로 REST API 운영 흐름을 위의 REST 다이어그램 이미지로 곁들이면 이해가 빠릅니다.)
8) 운영에서 자주 나오는 설정 포인트
A. 리소스/성능 관점
- 대용량 메시지/버퍼링/압축 사용 시 메모리·CPU 요구가 상승할 수 있어, 기본 heap으로 시작 후 메트릭으로 검증하라고 권장합니다. Source
B. 컨테이너/Kubernetes 운영
- Connect는 “자체적으로 스케일/재시작을 관리하지 않음” → Kubernetes/Swarm 등 오케스트레이터로 운영하는 구조가 자연스럽습니다. Source
C. (선택) Schema Registry 연동
- Avro/Protobuf/JSON Schema를 쓰면 Schema Registry를 함께 두는 구성이 일반적이며, Connect에서도 컨버터로 쉽게 붙일 수 있습니다. Source
9) (부록) 더 참고할 영상 1~2개
-
Standalone vs Distributed 모드 실행 예시(YouTube)
https://www.youtube.com/watch?v=OZ4Yne_rK3M -
Kafka Connect 101(개념 빠른 요약)
https://www.youtube.com/watch?v=MjJABMOywFM
