Kafka + Flink + ClickHouse 파이프라인

1. 실시간 데이터 파이프라인이란?

간단히 말해, 데이터가 만들어지는 순간 바로 분석하고 결과를 보여주는 것입니다.

예를 들어, 쇼핑몰에서 사용자가 상품을 클릭하는 순간:

• 어떤 상품을 봤는지 기록하고
• 실시간으로 인기 상품 순위를 계산하고
• 대시보드에서 바로 확인할 수 있어야 합니다

이 흐름을 구현하는 데 가장 널리 쓰이는 조합이 Kafka + Flink + ClickHouse입니다.

2. 각 컴포넌트의 역할 (비유로 이해하기)

Kafka — 우체국 역할

"여기서 받은 편지를 모아서, 지정된 곳으로 안전하게 배달해 드리겠습니다."

• 수많은 데이터 소스에서 동시에 들어오는 이벤트를 한 곳에 안전하게 수집
• 데이터가 많아져도 파티션(배달 경로)을 나눠서 병렬 처리
• 데이터가 유실되지 않도록 디스크에 기록하여 언제든 재전송 가능

Flink — 공장 조립 라인 역할

"원자재(원본 데이터)를 받아서, 원하는 제품(분석 결과)으로 가공해 드리겠습니다."

• Kafka에서 들어온 원본 데이터를 실시간으로 변환·집계
• 예: "최근 5분간 사용자 수" 같은 윈도우 기반 계산
• 장애가 나도 이전 상태로 되돌릴 수 있는 체크포인트 기능 내장

ClickHouse — 도서관 서가 역할

"방대한 문서를 카테고리별로 정리해 두었으니, 원하는 정보를 즉시 찾아드리겠습니다."

• 데이터를 컬럼 단위로 압축 저장하므로 저장 공간 절감
• 수억 건 데이터에서 수백 밀리초만에 집계 쿼리 수행
• 표준 SQL로 자유롭게 분석 쿼리 작성 가능

3. 왜 이 조합을 추천하나?

3.1 역할 분리로 단순함

하나의 도구가 모든 것을 처리하려 하면 복잡해집니다. 각 도구가 잘하는 일을 맡는 구조라 설계도 유지보수도 쉽습니다.

3.2 각 컴포넌트가 독립적

• Kafka를 교체하거나 확장해도 Flink, ClickHouse에 영향 없음
• Flink Job을 재시작해도 Kafka 데이터는 그대로 보존
• ClickHouse 노드 추가 시 기존 데이터 자동 복제

이 독립성은 점진적 도입이 가능하다는 뜻입니다. 처음엔 Kafka + ClickHouse만 쓰다가, 처리 복잡도가 높아지면 Flink를 중간에 끼우면 됩니다.

3.3 오픈소스 생태계

세 가지 모두 Apache 재단이나 검증된 오픈소스 프로젝트입니다:

• 커뮤니티가 활발하여 문제 해결 자료가 풍부
• 클라우드 매니지드 서비스를 통해 운영 부담 경감 가능
• 라이선스 비용이 없음 (단, 매니지드 서비스는 별도 비용)

4. 운영 측면: 장점과 단점

4.1 장점

모니터링과 observability가 잘 되어 있음

• Kafka: Prometheus 메트릭 내장 (브로커, 컨슈머 렉 등)
• Flink: Web UI에서 Job 실행 상태, 체크포인트, 처리량 실시간 확인
• ClickHouse: system 테이블에서 쿼리, 병합, 디스크 상태 조회

장애 복구 메커니즘 내장

• Kafka: 복제 팩터(Replication Factor) 설정으로 브로커 장애 시 자동 복구
• Flink: 체크포인트 기반 자동 복원, Savepoint로 계획적 재시작
• ClickHouse: ReplicatedMergeTree로 노드 장애 시 자동 페일오버

확장이 직관적

• Kafka: 브로커/파티션 추가만으로 처리량 확장
• Flink: TaskManager 추가로 병렬도 확대
• ClickHouse: 샤드/레플리카 추가로 저장·쿼리 성능 향상

4.2 단점

운영 복잡도가 3개를 합친 수준

초기 학습 곡선이 가파름

• Flink의 상태 관리, 윈도우 개념, Watermark 등은 초보자에게 난이도 높음
• ClickHouse의 MergeTree 패밀리 엔진 선택, 파티셔닝 전략 수립에 시간 소요
• Kafka의 파티셔닝, 컨슈머 그룹 개념 이해 필수

장비 구성이 최소 3개 이상

로컬 개발 환경에서 테스트하려면 최소한 Kafka Brocker 1개, Flink JobManager/TaskManager, ClickHouse 서버가 필요합니다. Docker Compose로 구성하더라도 리소스 사용량이 상당합니다.

5. 비용 측면: 장점과 단점

5.1 장점

소프트웨어 라이선스 비용 = 0

세 컴포넌트 모두 오픈소스로 무료 사용 가능합니다. 라이선스 비용 걱정 없이 프로덕션에 바로 적용할 수 있습니다.

스토리지 비용 효율적 (ClickHouse)

ClickHouse는 컬럼형 압축으로 스토리지 비용을 크게 절감할 수 있습니다.

클라우드 매니지드 서비스 다양

매니지드 서비스를 쓰면 운영 인력을 줄이고, 사용한 만큼만 비용을 지불하면 됩니다.

5.2 단점

인프라 비용이 생각보다 큼

프로덕션 수준의 고가용성을 위해 최소 구성:

초기 단계에서는 비용이 부담될 수 있으므로, 소규모라면 Managed Service를 활용하는 것이 합리적입니다.

데이터 레이크와 중복 저장 이슈

Kafka에 보존 기간을 설정하면 데이터가 이중 저장될 수 있습니다:

• Kafka에 7일 보존 + ClickHouse에 무제한 저장 = 동일 데이터 2곳에 존재
• 보존 정책을 잘 설계하지 않으면 스토리지 비용이 불필요하게 증가

Flink 상태 저장 비용

대용량 상태 기반 처리 시 RocksDB State Backend를 사용하는데, 이 상태를 S3/HDFS에 체크포인트로 저장하면 별도 스토리지 비용이 발생합니다.

6. 언제 이 조합을 쓰고, 언제 다른 조합을 고려하나?

이 조합을 추천하는 경우

• 초실시간(이벤트 발생 ~ 결과 확인까지 1초 이내)이 필수적인 경우
• 이벤트 데이터가 하루 수백만 건 이상인 경우
• 상태 기반 처리(세션 분석, 누적 집계 등)가 필요한 경우
• 장기 데이터 보관과 실시간 분석을 동시에 해야 하는 경우

다른 조합을 고려하는 경우

7. 소규모로 시작하는 방법

처음에는 전체를 한꺼번에 도입할 필요 없습니다. 단계적으로 확장하는 것이 핵심입니다.

Phase 1: Kafka + ClickHouse
├── Kafka로 이벤트 수집
├── 간단한 Consumer로 데이터를 ClickHouse에 적재
└── SQL로 대시보드 구성

Phase 2: Flink 추가
├── 처리 로직이 복잡해지면 Flink Job 도입
├── 윈도우 기반 집계, 상태 관리 필요 시
└── Exactly-Once 보장이 필요해질 때

Phase 3: 운영 고도화
├── 모니터링 대시보드 통합 (Grafana)
├── 장애 대응 자동화
└── 비용 최적화 (스토리지 정책, 리소스 스케일링)

8. 요약

Kafka + Flink + ClickHouse 조합은 실시간 데이터 처리의 표준으로 자리잡고 있습니다. 처음부터 완벽하게 구성하려 하기보다, 작은 규모로 시작하여 단계적으로 확장하는 접근을 추천합니다.

참고 자료

1. Apache Kafka 공식 문서 - https://kafka.apache.org/documentation/
2. Apache Flink 공식 문서 - https://nightlies.apache.org/flink/flink-docs-stable/
3. ClickHouse 공식 문서 - https://clickhouse.com/docs
4. AWS Managed Streaming for Apache Kafka - https://aws.amazon.com/msk/
5. ClickHouse Cloud 가격 - https://clickhouse.com/pricing
6. Flink vs Spark Streaming 비교 (Confluent Blog) - https://www.confluent.io/blog/
7. ClickHouse vs Elasticsearch 성능 비교 - https://clickhouse.com/benchmark/external