Bong's Log

Apache Kafka는 대용량 데이터를 빠르고 안정적으로 처리하기 위한 분산 스트리밍 플랫폼이다. 실시간 로그 수집, 메시지 브로커, 이벤트 소싱, 데이터 파이프라인 등 다양한 용도에 사용되며, 현대적인 데이터 아키텍처의 핵심 구성요소로 자리 잡고 있다.

Kafka의 기본 개념

Kafka는 다음과 같은 구성요소를 가진다:

• Producer: 데이터를 Kafka로 전송하는 주체
• Consumer: Kafka로부터 데이터를 구독하는 주체
• Broker: Kafka 서버. 메시지를 저장하고 분배하는 역할
• Topic: 메시지를 분류하는 논리적 단위
• Partition: Topic을 수평으로 분산 처리하기 위한 단위
• Offset: 메시지의 위치를 나타내는 인덱스

Kafka는 메시지를 디스크에 영속적으로 저장하고, Consumer가 직접 Offset을 관리할 수 있도록 함으로써

높은 내구성과 유연한 처리 방식을 제공한다.

Kafka는 단독으로 사용되는가?

결론부터 말하자면, Kafka는 단독으로는 단순한 메시지 브로커 이상으로 활용되기 어렵다. 일반적으로는 다른 시스템과 조합하여 다음과 같은 아키텍처를 구성한다:

• Kafka + Zookeeper: (구버전 기준) 클러스터 메타데이터 및 브로커 상태 관리
• Kafka + Schema Registry: Avro/Protobuf 기반 메시지 구조 관리
• Kafka + Kafka Connect: 다양한 외부 시스템과 연결 (예: DB, Elasticsearch, S3)
• Kafka + Flink / Spark Streaming: 실시간 스트리밍 분석
• Kafka + ksqlDB: SQL 기반 스트리밍 쿼리 처리
• Kafka + Debezium: CDC (Change Data Capture) 구현

Kafka의 주요 활용 분야 (Use Case)

1. 실시간 로그 수집

• 웹서버, 애플리케이션, 보안 시스템 등에서 발생하는 로그를 중앙으로 수집
• Kafka → Logstash or Fluentd → Elasticsearch

2. 마이크로서비스 간 비동기 통신

• 서비스 간 REST API 호출 대신 이벤트 기반 메시지 전달
• 예: 주문 서비스 → Kafka Topic → 결제/알림/배송 서비스 소비

3. 실시간 데이터 파이프라인 구축

• 다양한 소스 (DB, 파일, API 등)로부터 수집한 데이터를 정제 후 다른 시스템으로 전달
• Kafka Connect + Sink Connector 사용

4. DB 변경사항 수집 (CDC)

• Debezium으로 MySQL/PostgreSQL 등의 변경 로그를 Kafka로 보내고, 이를 기반으로 캐시 DB, 분석 시스템, 백업 저장소 등으로 반영

5. 이벤트 소싱

• 모든 상태 변경을 이벤트로 저장하고, 재생 가능한 시스템 구성
• 예: 계좌 입출금 이력, 쇼핑몰 주문 상태 흐름 등을 완전한 이벤트 로그로 구성

6. 실시간 모니터링 및 경보 시스템

• Kafka Topic에 수집된 이벤트를 분석하여 이상 탐지 또는 알림 시스템과 연동
• 예: 센서 이상치 탐지, 보안 이벤트 분석 등

결론

Kafka는 단순한 메시지 큐 그 이상으로, 데이터 흐름 중심의 아키텍처를 설계할 수 있는 강력한 플랫폼이다. 단독보다는 다른 시스템과의 조합을 통해 실시간 데이터 처리, 로그 분석, 마이크로서비스 통신 등 다양한 용도로 활용되며, 특히 대용량 환경에서의 안정성과 확장성을 중요하게 여기는 조직에서 점점 더 많은 채택을 받고 있다.

Kafka를 단순히 배워보는 것에서 끝내지 않고, 위의 Use Case를 직접 구성해보는 실습을 통해 그 진가를 체감해보는 것을 추천한다.

CDC(Change Data Capture)를 실무에 적용할 때, 단순히 binlog를 켜고 모든 테이블을 추적하는 것은 비효율적이고 위험할 수 있다. 이 글에서는 CDC 구성 시 테이블 단위로 필터링 설정이 왜 중요한지, 그리고 실제 설정 예시와 함께 설명한다.

1. 전체 테이블 추적의 문제점

CDC를 설정하면 기본적으로 데이터베이스 내 모든 변경 사항이 수집 대상이 된다. 하지만 아래와 같은 이유로 전체 테이블을 추적하는 것은 실무에서 권장되지 않는다.

1-1. 성능 저하

• 변경이 거의 없는 테이블도 Kafka에 메시지를 전송하게 되면 리소스 낭비가 발생한다.
• CDC 커넥터, Kafka, Consumer 모두 부하 증가

1-2. 보안 및 개인정보 이슈

• 고객정보, 카드번호, 비밀번호 해시 등이 CDC를 통해 외부 시스템으로 유출될 수 있다

1-3. 장애 영향 범위 확대

• Kafka 적체 또는 Consumer 오류 발생 시 전체 시스템 장애로 확산될 위험

1-4. 유지보수 복잡도 증가

• 불필요한 데이터도 모니터링 및 재처리 대상으로 포함됨

1-5. 실질적 오류 상황 발생 가능

• • Debezium connector가 schema history를 과도하게 로드하다 장애 발생
  • Kafka partition overflow 또는 consumer lag 심화로 처리 누락 발생
  • Custom Sink에서 메시지 과부하로 인해 중복 반영 또는 역순 반영 발생

이러한 상황은 기능적으로는 에러가 아니지만, 결과적으로 서비스 오류로 이어질 수 있는 논리적 장애다.

2. 실무에서는 테이블 단위 설정이 기본

CDC 도구들은 기본적으로 table filtering 옵션을 제공하며, 실무에서는 반드시 필요한 테이블만 지정해서 추적한다.

Debezium 예시 (JSON 설정)

"table.include.list": "erp.orders,erp.order_items,erp.delivery"

Maxwell 예시 (config.properties)

include_tables=orders,order_items,delivery
exclude_tables=log_temp,debug_*

테이블 필터링 시에는 database.table 형식 또는 정규식 패턴을 사용할 수 있다.

3. 어떤 테이블을 추적 대상으로 삼아야 할까?

4. 운영 팁

• 변경 빈도가 높고, 후속 처리가 필요한 테이블만 선정한다
• CDC 대상 테이블은 별도 목록으로 관리하고 Git이나 Wiki에 기록한다
• 실수로 민감 테이블이 포함되지 않도록 팀 내 리뷰 절차를 둔다

5. 결론

CDC는 데이터 변경을 실시간으로 추적할 수 있는 매우 강력한 도구이지만, 추적 범위를 관리하지 않으면 오히려 장애와 혼란의 원인이 된다.

따라서 CDC 구성 시 테이블 단위 필터링은 선택이 아닌 필수이며, 목적에 맞는 테이블만 신중히 설정하는 것이 안전하고 효율적인 운영의 핵심이다.

이번 글에서는 CDC(Change Data Capture) 구성을 위한 대표적인 기술 스택인 Kafka, Debezium, Custom Sink에 대해 역할과 장단점을 중심으로 소개한다.

1. 구성 목적 및 개요

CDC는 실시간 데이터 변경을 추적해 복제, 감사, 백업, 비동기 처리 등에 사용된다. 대표적으로 Kafka 기반의 CDC 구성이 사용되며, 이 구조는 다음과 같은 구성 요소로 이루어진다.

• MySQL (source): binlog 활성화 필요(RAW)
• Debezium (connector): binlog 읽기 및 이벤트 변환
• Kafka (broker): 이벤트 메시지 큐 역할
• Custom Sink (consumer): 실제 타겟 DB 또는 저장소로 데이터 반영

2. 각 구성요소의 역할

Kafka

• 고속 메시지 전달과 분산 저장을 위한 중앙 브로커 역할
• Debezium이 생산한 메시지를 저장하며, 여러 Sink가 이를 소비 가능

Debezium

• Kafka Connect 기반의 CDC 커넥터
• MySQL의 binlog를 읽어 Kafka 메시지로 변환
• INSERT / UPDATE / DELETE 이벤트를 JSON으로 가공

Custom Sink

• Kafka에서 이벤트 메시지를 소비하고, 실제 데이터베이스나 파일 등에 반영
• MariaDB, Elasticsearch, 파일 저장, 알림 트리거 등 다양한 방식 가능

3. 장점

• 실시간 CDC 기반 이력 수집 가능
• 시스템 간 비동기 처리 가능 (예: 이벤트 기반 마이크로서비스 연계)
• Kafka를 통한 메시지 재처리 및 내구성 보장
• 스키마 변경 추적 기능 제공 (Debezium의 schema history 기능 활용 시)

4. 단점 및 고려사항

• Kafka, Zookeeper 구성 자체가 복잡하고 리소스를 많이 사용
• Debezium의 설정 및 안정성 확보에는 일정 수준의 Kafka 경험 필요
• Custom Sink 개발 시 이벤트 형식(JSON) 처리 로직 필요
• 장애 발생 시 메시지 유실, 중복 반영 등의 리스크를 고려한 아키텍처 설계 필요
• 트리거, 내부 쿼리, 스토어드 프로시저 등은 CDC 대상에서 누락될 수 있음

5. 대표 도구 비교 (Debezium vs Maxwell)

Maxwell은 대체제로 적합한가?

Maxwell은 Kafka 없이도 단독으로 실행 가능하며, 복잡한 Kafka Connect 설정 없이 MySQL의 binlog를 읽어 JSON 메시지를 전달한다. 소규모 프로젝트나 빠른 CDC 테스트에 적합하며, 다음과 같은 특징이 있다.

• Debezium 대비 설치가 간단하고 리소스 요구가 낮다
• Kafka, Kinesis, stdout, HTTP 등 다양한 출력 지원
• Schema history, DDL 추적 기능은 제한적
• 실시간 처리보다는 간단한 로그 수집용에 가까움

Maxwell은 "가볍고 빠른 CDC 구성"이 필요한 경우 좋은 대안이 될 수 있으나, 복잡한 데이터 처리나 확장성 있는 아키텍처를 원할 경우 Debezium이 더 적합하다.

6. 마무리

Kafka + Debezium + Custom Sink 구조는 강력한 CDC 솔루션을 구성할 수 있는 방법이지만, 진입 장벽이 높고 운영 복잡도가 크다. Maxwell은 그에 비해 진입이 쉬우며 단순한 변경 로그 추적 용도로는 훌륭한 선택지다.

조직의 필요에 따라 Debezium 또는 Maxwell을 선택하면 되며, 단순 롤백이나 변경 이력 조회만 필요한 경우에는 binlog 기반의 간단한 로그 추출 방식이 가장 효율적일 수 있다.