티스토리 뷰
Apache Kafka란?

Apache Kafka는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 수천 개의 회사에서 사용하는 오픈 소스 분산 이벤트 스트리밍 플랫폼이다.
왜 사용할까?
회사 시스템을 들여다보면 한숨부터 나온다. 데이터베이스(DB)에서 데이터를 뽑아 분석 도구로 보내고,
또 다른 데이터를 가공해 이메일 시스템으로도 보내야 한다.
늘어나는 서비스만큼 소스 시스템과 타겟 시스템은 거미줄처럼 얽혀만 간다.단순히 계산해 봐도 그렇다.
소스가 4개, 데이터를 받아야 할 타겟이 6개라고 치자. 점대점으로 연결한다면 최대 24개의 통합 파이프라인이 필요하다.
상상만 해도 머리가 지끈거린다.
이게 다가 아니다. 어떤 놈은 REST로 데이터를 던지고, 다른 놈은 FTP로 파일을 떨군다. 데이터 형식도 JSON이었다가, XML이였다가 제멋대로다. 가끔 스키마라도 바뀌면? 갑자기 사용자가 몰려 부하가 치솟으면? 기존 방식으로는 이미 한계가 보였다. 낡은 데이터 파이프라인은 삐걱거리기 일쑤였다.
이런 아수라장에서 "이벤트 스트리밍"이라는 한 줄기 빛을 발견했다. 그리고 이 이벤트 스트리밍의 세계에서 빼놓을 수 없는 이름이 바로 아파치 카프카(Apache Kafka)다. 이 녀석, 사실 거대한 소셜 네트워크 서비스인 링크드인(LinkedIn)에서 그들의 복잡다단한 데이터 문제를 해결하기 위해 태어났다.

기술적인 용어는 잠시 접어두자. 쉽게 말해, 데이터베이스, 센서, 모바일 기기, 클라우드 서비스, 온갖 소프트웨어 애플리케이션 같은 '이벤트 소스'에서 데이터가 생겨나는 족족, 실시간으로 잡아채는 거다. 이렇게 잡아챈 데이터는 '이벤트 스트림'이라는 형태로 차곡차곡 쌓인다. 마치 끊임없이 흐르는 강물처럼.

위 그림을 보면 감이 올 것이다.
링크드인처럼 수많은 서비스에서 실시간으로 쏟아지는 엄청난 양의 데이터를 카프카가 어떻게 중앙에서 받아내고, 필요한 곳으로 다시 질서정연하게 흘려보내는지 말이다. 그들이 겪었던 데이터 통합의 고통이 고스란히 느껴지는 동시에, 카프카라는 해결책이 얼마나 강력한지 보여준다.
강물(이벤트 스트림)은 그냥 흘러가고 끝나는 게 아니다.
필요하면 언제든 다시 꺼내 볼 수 있고(내구성 있는 저장), 원하는 대로 주무르고(조작), 분석하고(처리) 할 수 있다.
실시간으로 강물의 변화에 반응할 수도, 한참 뒤에 지난 물길을 되짚어볼 수도 있다. 그리고 이 물길을 여러 목적지로 정확하게, 원하는 만큼 흘려보낼 수도 있다.
즉, 이벤트 스트리밍은 데이터가 쉼 없이 흐르고 해석되도록 하여, 딱 맞는 정보가, 딱 맞는 장소에, 딱 맞는 시간에 도착하도록 하는 기술이다.
이 모든 것을 해내는 심장이 바로 아파치 카프카(Apache Kafka)다.
아파치 카프카의 디커플링(Decoupling)
카프카는 '디커플링(Decoupling)' 을 통해 N:M문제를 해결한다.
디커플링은은 우리말로 하면 '분리', '느슨한 연결'이다.
기존에는 데이터를 주는 소스 시스템과 받는 타겟 시스템이 맞물려서 돌아가게 설계되어 있어 소스 하나가 바뀌면 그걸 받았는 타겟들이 줄줄이 영향을 받고, 반대의 경우도 마찬가치였다.
카프카는 이 둘 사이에 끼어들어 중재자 역할을 한다.
소스 시스템: 데이터 생산자(Producer)라고 칭하며, 카프카에게 데이터를 던져준다.
타겟 시스템: 데이터 소비자Consumer)라고 칭하며, 카프카에서 데이터를 받아온다.
결국, 소스와 타겟은 서로 얼굴도 모르는 사이가 된다. 그들은 오직 카프카하고만 이야기한다. 덕분에 한쪽에서 무슨 일이 생기든 다른 쪽은 크게 신경 쓸 필요가 없다. 각자 자기 할 일만 잘하면 되니, 유지보수도 편해지고, 시스템을 확장하기도 훨씬 수월해진다. 이게 바로 카프카가 가져다주는 디커플링의 마법이다.
예시로, 택배 서비스를 생각하면 좋다.

택배 서비스를 이용하지 않고 물건을 보내려면, 수신자에게 연락해서 약속을 잡고, 주소를 말하고, 직접 물건을 갖다 주거나, 받으러 가야 한다.
택배 서비스를 이용하면 택배 회사에 물건을 맡기기만 하면 택배 기사가 가져가서 알아서 배송지로 보내주고 받는다.
택배 서비스와 같이 카프카를 이용하게 되면 송신자(소스 시스템)가 물건(데이터)을 카프카(택배회사)에 보내면 알아서 배송지(타겟 시스템)로 가는 형식이다.
디커플링 뭐가 좋을까?
카프카를 통한 디커플링 아키텍처는 시스템 운영 및 개발 환경에 다각적인 이점을 제공한다.
첫 번째로는 시스템 간 의존성이 최소화 된다.
기존의 강결합(Tightly Coupled) 구조에서는 특정 시스템의 변경이 연관된 다른 시스템에 연쇄적인 수정 작업이 필연적으로 발생했지만, 카프카를 이용할 경우 다른 시스템의 상태나 구현 방식에 대해 알 필요가 없어 시스템의 유연성이 크게 향상된다.
두 번째로는 유지보수 용이 및 확장성이 좋아진다.시스템 간의 결합도가 낮아짐에 따라 특정 시스템의 유지보수 작업이 다른 시스템에 미치는 파급 효과가 줄어 문제 발생 시 원인 파악 및 해결이 용이해진다. 업그레이드나 교체 또한 상대적으로 단순해진다.
또한, 새로운 생산자나 소비자를 추가할 경우, 카프카에 연결하는 것 만으로 시스템 확장이 가능해진다.
세 번째로는 장애 격리 및 시스템 안정성이 향상된다.
특정 소비자 시스템에 장애가 발생하더라도, 카프카는 생산자로부터 오는 데이터를 지속적으로 수신하여 안전하게 보관합니다. 장애가 발생한 소비자는 복구 후 카프카에 저장된 데이터를 다시 처리할 수 있으므로, 일시적인 장애가 전체 데이터 흐름의 중단이나 데이터 유실로 이어지는 것을 방지한다.
(이걸 이용해서 일부 상용 서비스에서는 레디스 대신에 캐시로도 쓴다고 한다.)
네 번째로는 MSA 구현의 핵심 요소라는 점이다.
각 마이크로서비스는 카프카를 통해 이벤트를 발행(Publish)하거나 구독(Subscribe)함으로써 상호작용하며, 이는 서비스 간의 결합도를 낮추고 각 서비스의 독립적인 개발과 배포를 가능하게 한다.
디커플링을 뒷받침하는 카프카의 기술적 기반
디커플링과 그로 인한 이점들은 단순히 개념적인 우수성에서 비롯된 것만은 아니다.
아파치 카프카는 그 이면에 견고한 기술적 토대를 갖추고 있기 때문에 이 모든 것이 가능하다.
첫째, 분산 시스템(Distributed System) 설계가 되어있다.
카프카는 다수의 서버로 구성된 클러스터 환경에서 동작하도록 설계되어, 단일 장애 지점(SPOF, Single Point Of Failure)의 위험 없이 시스템 전체의 안정적인 운영을 보장한다. 이는 일부 서버에 문제가 발생하더라도 전체 서비스의 연속성을 유지하는 데 기여한다.
둘째, 데이터의 내구성 있는 저장(Durable Storage)이 가능하다.
카프카는 수신한 메시지를 디스크에 안전하게 기록하고, 설정에 따라 여러 복제본을 유지함으로써 데이터 유실의 위험을 최소화한다. 이를 통해 메시지 전달의 신뢰성을 확보하고, 시스템 장애 발생 시에도 데이터 복구가 가능하도록 지원한다.
셋째, 수평적 확장성(Horizontal Scalability)이다.
데이터 처리량이나 저장 용량이 증가할 경우, 카프카 클러스터에 브로커(서버)를 추가하는 방식으로 시스템 전체의 성능과 용량을 유연하게 확장할 수 있다. 이는 예측 불가능한 데이터량 증가에도 효과적으로 대응할 수 있는 기반을 제공하며, 비용 효율적인 시스템 운영을 가능하게 한다.
넷째, 고성능 메시지 처리 능력이다.
카프카는 페이지 캐시 활용, 제로 카피(Zero-Copy) 기술 등 운영체제 수준의 최적화와 효율적인 데이터 구조를 통해 대량의 메시지를 낮은 지연 시간으로 신속하게 처리할 수 있다. 이는 실시간 데이터 스트리밍 및 분석 요구사항을 충족시키는 핵심적인 역량이다.
이러한 기술적 특성들이 유기적으로 결합되어, 아파치 카프카가 제공하는 디커플링의 가치를 극대화하고 안정적이면서도 유연한 데이터 파이프라인 구축을 가능하게 한다.
맺음말
지금까지 살펴본 것처럼, 아파치 카프카는 단순히 데이터를 주고받는 통로를 넘어선다.
복잡하게 얽힌 현대 기업의 데이터 환경에서 발생하는 고질적인 문제들, 즉 시스템 간의 과도한 의존성, 데이터 형식 및 프로토콜의 다양성, 스키마 변경의 어려움, 그리고 예측 불가능한 부하 증가 등에 대한 명쾌한 해답을 제시한다.
다음 글에서는 이러한 카프카의 내부 아키텍처와 동작 원리를 이해하는 데 있어 가장 기본적이면서도
핵심적인 구성 요소인 토픽(Topic), 파티션(Partition), 그리고 오프셋(Offset)에 대해 작성하겠다.
참고 및 출처
이미지: ChatGPT (DALL·E) 생성
참고 문서:
Apache Kafka Quickstart
Confluent Blog - What is an Event Streaming Platform?
'기술노트 > Apach Kafka' 카테고리의 다른 글
| Kafka 기초5 - 브로커(Broker) (0) | 2025.05.19 |
|---|---|
| Kafka 기초4 - 컨슈머 그룹 (0) | 2025.05.16 |
| Kafka 기초3 - 컨슈머 (0) | 2025.05.02 |
| Kafka 기초2 - 프로듀서 & 메세지 (0) | 2025.05.02 |
| Kafka 기초1 - 토픽, 파티션, 오프셋 (0) | 2025.05.02 |
- Total
- Today
- Yesterday
- apach kafka
- 컨슈머그룹
- sticky partitioner
- broker
- Producer
- 라운드로빈
- Cluster
- 클러스터
- 메세지
- 파티션
- 토픽
- kafak
- 분산서비스
- 파티셔닝
- Consumer
- 역직렬화
- 오프셋
- 컨슈머
- Apache kafka
- Serializer
- 백프레셔
- 카프카
- 디커플링
- 아파치카프카
- Kafka
- 브로커
- 키 기반 파티셔닝
- 프로듀서
- 직렬화
- 소비자
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |