List
지난 글에서는 Apache Flink의 내부 아키텍처를 구성하는 핵심 요소들에 대해 자세히 살펴보았습니다.
이번 글에서는 실시간 데이터 처리 영역에서 자주 비교되는 Kafka Streams와 ksqlDB를 내부 구조적 관점에서 Apache Flink와 비교해 보겠습니다.
Apache Flink와 Kafka 기반 기술(Kafka Streams, ksqlDB)의 구조적 차이 이해하기
세 가지 기술은 모두 실시간 데이터 처리를 목표로 하지만, 내부적으로는 동작 방식과 아키텍처가 매우 다릅니다. 먼저, 각각의 기술이 어떻게 구성되어 있는지 내부 구조를 하나씩 뜯어보겠습니다.
1. Apache Flink의 내부 구조
지난 글에서 자세히 설명했지만, Flink 구조를 다시 한번 요약하면 다음과 같습니다.
•
JobManager가 작업의 전체 실행 계획과 리소스 관리를 담당
•
TaskManager는 실제 작업을 수행하는 노드로, 상태(state)를 관리하고 체크포인트를 통해 장애를 복구
•
State Backend가 상태 데이터를 관리하며 대규모 상태 저장 및 빠른 복구를 지원
•
Checkpointing 메커니즘으로 장애 시에도 정확한 상태 복원이 가능
여기서 핵심은 Flink는 독립적인 분산 처리 플랫폼이라는 것입니다. Flink는 Kafka 같은 메시지 큐뿐만 아니라 다양한 데이터 소스를 지원하며, 데이터 처리와 저장을 자체 클러스터에서 독립적으로 수행합니다.
2. Kafka Streams의 내부 구조
Kafka Streams는 Apache Kafka를 기반으로 스트리밍 데이터를 처리하는 라이브러리입니다. Kafka Streams는 Kafka와 매우 밀접하게 연관되어 있으며, Kafka가 제공하는 파티션(partition)과 오프셋(offset) 개념을 기반으로 데이터를 처리합니다.
Kafka Streams 구조적 특징
•
라이브러리 방식의 사용
◦
별도의 분산 클러스터를 운영하지 않고, 애플리케이션 내부에서 라이브러리 형태로 동작
◦
따라서 별도의 운영 환경 없이 기존 Kafka 클러스터만 있다면 쉽게 사용할 수 있음
•
Kafka의 오프셋 기반 처리
◦
데이터를 Kafka 토픽(topic)의 파티션으로부터 가져와 처리하며, 처리 상태는 Kafka 자체에 내장된 컴팩션(compaction) 토픽이나 RocksDB(로컬 상태 저장소)에 저장
•
RocksDB를 통한 로컬 상태 저장
◦
상태는 각 Kafka Streams 애플리케이션 인스턴스의 로컬 RocksDB에 저장
◦
장애 발생 시 Kafka의 로그 기반 오프셋을 활용해 복구
Kafka Streams의 장점과 단점
•
장점
◦
Kafka와의 완벽한 통합
◦
클러스터 운영이 불필요해 간단한 환경 구성 가능
◦
낮은 지연시간(latency) 제공
•
단점
◦
대규모 분산 처리 시 복잡성 증가
◦
Kafka 외 데이터 소스 통합 제한적
◦
장애 복구 시간이 길어질 수 있음
3. ksqlDB의 내부 구조
ksqlDB는 Kafka Streams 위에서 동작하는 SQL 인터페이스를 제공하는 플랫폼입니다. 쉽게 말하면, Kafka Streams를 좀 더 편리하게 SQL로 쓸 수 있도록 만든 래퍼(wrapper)에 가깝습니다.
ksqlDB 구조적 특징
•
ksqlDB 서버 노드
◦
Kafka Streams 라이브러리를 내장한 서버 노드를 운영
◦
사용자가 SQL 형태로 명령을 내리면 내부에서 Kafka Streams API로 변환하여 실행
•
쿼리 실행과 상태 관리
◦
ksqlDB는 Kafka Streams와 마찬가지로 로컬 RocksDB 상태 저장소를 활용해 상태를 관리
◦
쿼리 결과는 Kafka 토픽에 실시간으로 저장되며, 다른 서비스에서 쉽게 접근 가능
•
인터랙티브 쿼리(Interactive Query)
◦
상태 데이터에 실시간으로 접근할 수 있도록 HTTP REST 인터페이스를 제공하여 애플리케이션과의 연동이 편리함
ksqlDB의 장점과 단점
•
장점
◦
사용이 쉬운 SQL 기반 인터페이스
◦
Kafka Streams의 장점을 모두 포함
◦
간단한 스트리밍 애플리케이션 구축에 적합
•
단점
◦
복잡한 스트리밍 처리 작업 시 표현의 한계
◦
대규모 복잡한 연산 시 운영상 복잡성 증가
세 가지 기술 구조적 차이의 핵심 정리
항목 | Apache Flink | Kafka Streams | ksqlDB |
기반 환경 | 독립적인 분산 처리 플랫폼 | Kafka 기반 라이브러리 | Kafka Streams 기반 서버 |
상태 관리 | 분산 State Backend (메모리 또는 RocksDB) | 로컬 RocksDB, Kafka 내부 토픽 | 로컬 RocksDB, Kafka 내부 토픽 |
장애 복구 메커니즘 | 체크포인트 기반 분산 복구 | Kafka 오프셋 기반 복구 | Kafka 오프셋 기반 복구 |
운영 환경의 복잡성 | 독립적 클러스터 운영 필요 | 별도 운영 필요 없음 | 별도 서버 운영 필요 |
데이터 소스 연동성 | 다양한 데이터 소스 지원 | Kafka만 완벽 지원 | Kafka만 완벽 지원 |
기술별 대표 활용 사례
내부 구조의 차이는 결국 어떤 상황에서 어떤 기술이 적합한가? 에 직접적인 영향을 줍니다. 단순히 기능 비교를 넘어서, 실무에서 기술을 선택할 때 고려해야 할 현실적인 기준을 구조적·실용적 관점에서 함께 살펴보겠습니다.
1. Apache Flink – 복잡한 실시간 분석 / 대규모 처리 환경에 적합
예시: 대규모 금융거래 시스템, 실시간 추천 시스템, IoT 센서의 복잡한 패턴 분석
•
구조적 관점
◦
Flink는 자체 클러스터에서 실행되는 독립적인 분산 처리 엔진으로, 수십~수백 개 노드에서 병렬 처리를 고도화할 수 있음
◦
State Backend를 통해 수백 GB 이상의 상태 데이터를 안정적으로 저장하고, Checkpointing으로 장애 발생 시에도 거의 중단 없이 복구 가능
◦
데이터 처리 흐름이 DAG(Directed Acyclic Graph) 형태로 구성되어 있어 복잡한 데이터 파이프라인을 유연하게 설계 가능
•
실용적 관점
◦
집계, 필터링, 윈도우 연산, 세션 분석 등 다양한 연산을 한 번에 수행해야 하는 환경에서 Flink는 연산자 조합과 세밀한 튜닝이 가능
◦
Kafka뿐만 아니라 S3, HDFS, JDBC 등 다양한 데이터 소스 및 싱크와의 연동이 자유롭고, 실행 중에도 Savepoint를 활용해 무중단 작업 업그레이드가 가능하여 운영 안정성도 좋음
2. Kafka Streams – 경량 스트리밍 애플리케이션, 마이크로서비스 환경에 적합
예시: Kafka 기반 마이크로서비스에서 주문 이벤트 실시간 처리, 사용자 로그 필터링, 간단한 통계 처리
•
구조적 관점
◦
Kafka Streams는 Kafka 위에서 작동하는 라이브러리 형태로, 별도의 클러스터 없이 애플리케이션 내부에서 직접 실행
◦
Kafka의 파티션 구조를 그대로 활용하며, 상태는 로컬 RocksDB에 저장되므로 별도 분산 파일 시스템이 필요하지 않음
◦
장애 복구 역시 Kafka의 오프셋 정보를 그대로 활용하기 때문에 Kafka 환경에서는 구성이 매우 단순
•
실용적 관점
◦
클러스터 관리가 필요 없어 개발과 배포가 간단하고, Spring Boot 등 애플리케이션에 바로 통합할 수 있음
◦
Kafka에 익숙한 개발팀이라면 빠른 개발과 낮은 운영 부담으로 쉽게 적용할 수 있으며, 낮은 지연 시간 덕분에 실시간 API나 사용자 이벤트 기반 처리에도 적합
3. ksqlDB – SQL 기반 실시간 집계, 대시보드, 데이터 분석에 적합
예시: 주문 현황 대시보드, 실시간 방문자 수 집계, 알림 조건 트리거 처리
•
구조적 관점
◦
Kafka Streams를 기반으로 하지만, 서버 형태로 독립 실행되며 REST API나 CLI를 통해 SQL 쿼리를 전송 가능
◦
실행된 쿼리 결과는 Kafka 토픽에 지속적으로 적재되고, 외부 시스템에서 쉽게 구독이 가능
◦
상태는 로컬 RocksDB에 저장되며, 쿼리 상태도 함께 관리
•
실용적 관점
◦
SQL 기반으로 작동하므로 개발자가 아닌 사용자(데이터 분석가, PO 등) 도 실시간 쿼리를 작성할 수 있어 접근성이 높음
◦
Kafka로 직접 쿼리 결과를 출력할 수 있어 BI 도구, 대시보드, 경고 시스템과 연동하기에 적합하고, 빠르게 프로토타입을 구성하여 실시간 처리를 실험하는 PoC 환경에 유리
마무리
이번 글에서는 Apache Flink와 Kafka Streams, ksqlDB의 내부 구조를 자세히 비교해 보았습니다. 내부 구조와 동작 방식을 이해하면, 실제로 어떤 기술을 선택할 때 더욱 명확한 기준을 세울 수 있습니다.
다음 글에서는 최근 워크샵에서 다뤘던 실습 내용을 기반으로, Apache Flink를 실제로 어떻게 활용할 수 있는지 구체적인 사례와 함께 살펴보겠습니다.