Kafka 입문

실전 카프카 개발부터 운영까지 책을 읽으며 정리한 글입니다.

카프카란?

카프카(Apache Kafka)는 분산 이벤트 스트리밍 플랫폼이다. 쉽게 말하면, 여러 시스템 사이에서 데이터를 빠르고 안전하게 전달해주는 중간 다리 역할을 한다.

탄생 배경

2011년 링크드인(LinkedIn)이 내부 문제를 해결하기 위해 만들었다. 당시 링크드인은 사용자 행동 로그, 서버 메트릭, 데이터베이스 변경 이력 등을 여러 시스템이 제각각 주고받고 있었다. 시스템이 늘어날수록 연결이 복잡해져 마치 스파게티처럼 얽혔고, 하나가 느려지면 연결된 모든 곳이 영향을 받았다.

[개선 전] 시스템끼리 직접 연결

A → B
A → C
B → D
C → D   → 연결이 늘수록 복잡도가 폭발적으로 증가

[개선 후] Kafka를 중심에 두고 연결

A →        → B
B → Kafka  → C
C →        → D   → 각 시스템은 Kafka하고만 연결하면 됨

카프카를 중간에 두면, 데이터를 보내는 쪽(프로듀서)과 받는 쪽(컨슈머)이 서로를 몰라도 된다. 프로듀서는 카프카에 데이터를 던져두기만 하면 되고, 컨슈머는 필요할 때 카프카에서 꺼내 쓰면 된다.

핵심 개념

• 토픽(Topic): 데이터를 구분하는 카테고리. 예를 들어 “주문 이벤트”, “로그인 이벤트”처럼 종류별로 토픽을 나눈다.
• 프로듀서(Producer): 토픽에 메시지를 보내는 주체.
• 컨슈머(Consumer): 토픽에서 메시지를 읽어가는 주체.
• 브로커(Broker): 메시지를 저장하고 전달하는 카프카 서버. 여러 브로커가 모여 클러스터를 이룬다.

카프카의 특징

추후 게시글에 좀 더 자세히 작성해 볼 예정입니다!

높은 처리량과 낮은 지연시간

• 카프카, 펄사, 래빗MQ를 처리량과 응답 속도로 비교하면, 처리량은 카프카가 가장 높고 응답 속도만 보면 래빗MQ가 더 빠르다. 하지만 두 지표를 함께 놓고 보면 카프카가 단연 독보적이다.

• 카프카가 빠른 핵심 이유는 디스크에 순차적으로 쓰는 방식 덕분이다. 일반적으로 디스크는 느리다고 알려져 있지만, 무작위로 읽고 쓰는 게 느린 것이지 순차적으로 이어서 쓰는 속도는 메모리에 버금갈 정도로 빠르다. 카프카는 메시지를 디스크에 순서대로 append하기 때문에 대용량 데이터도 빠르게 처리할 수 있다.

높은 확장성

• 서비스가 성장하면 데이터 파이프라인에도 더 많은 처리 능력이 필요하다.
• 카프카는 브로커(서버)를 클러스터에 추가하는 것만으로 처리 용량을 수평 확장할 수 있다.
• 토픽을 여러 파티션으로 나눠 각 브로커에 분산하기 때문에, 브로커가 늘어날수록 병렬 처리 능력도 함께 늘어난다. 서비스를 중단하지 않고도 증설할 수 있다는 점도 운영 측면에서 큰 장점이다.

고가용성

• 카프카는 각 파티션의 데이터를 여러 브로커에 복제(replication)해 보관한다.
• 브로커 하나가 장애로 죽어도 다른 브로커의 복제본이 즉시 그 역할을 대신하므로 서비스 중단 없이 운영을 이어갈 수 있다.
• 2013년에 이 리플리케이션 기능이 추가되면서 카프카는 단순 메시지 큐에서 엔터프라이즈 수준의 안정성을 갖춘 플랫폼으로 자리잡았다.

내구성

• 전통적인 메시징 시스템은 컨슈머가 메시지를 가져가는 순간 저장소에서 삭제한다.
• 반면 카프카는 메시지를 가져가도 삭제하지 않고, 설정한 기간이나 용량 한도까지 디스크에 계속 보관한다.
• 덕분에 장애가 발생해도 과거 메시지를 다시 불러와 재처리할 수 있고, 새로운 컨슈머가 생겨도 처음부터 데이터를 읽어갈 수 있다.

개발 편의성

• 프로듀서와 컨슈머는 서로를 전혀 몰라도 된다. 프로듀서는 카프카에 메시지를 던져두기만 하면 되고, 컨슈머는 자신의 속도에 맞춰 꺼내 쓰면 된다.

• 한쪽이 느려지거나 죽어도 다른 쪽에 영향을 주지 않는다.

• 두 가지 부가 도구도 제공한다.
  • 카프카 커넥트: Elasticsearch, HDFS, RDB 등 외부 시스템과 카프카를 연결하는 커넥터 모음이다. 직접 프로듀서·컨슈머 코드를 작성하지 않아도 설정만으로 데이터를 주고받을 수 있다.
  • 스키마 레지스트리: 메시지의 데이터 형식(스키마)을 중앙에서 관리한다. 프로듀서와 컨슈머가 서로 다른 형식으로 데이터를 주고받아 발생하는 파싱 오류를 방지한다.

운영 및 관리 편의성

• 브로커를 클러스터에 추가하거나 제거하는 작업이 단순하고, 서비스를 멈추지 않고도 진행할 수 있다.
• 버전 업그레이드 역시 롤링 방식(브로커를 하나씩 순차적으로 교체)으로 무중단 적용이 가능하다. 카프카 클러스터의 상태, 토픽별 처리량, 컨슈머 지연(lag) 등을 모니터링할 수 있는 도구도 풍부하게 제공된다.

카프카의 활용 사례

데이터 파이프라인 - 넷플릭스

넷플릭스는 하루에도 수천억 건의 이벤트를 처리한다.

• 사용자의 넷플릭스 비디오 시청 활동, 유저 인터페이스 사용 빈도, 에러 로그, 성능 이벤트, 문제 해결 및 진단 이벤트 등의 모든 이벤트는 데이터 파이프라인을 통해 흐른다.

초기에는 Chukwa라는 도구로 이 데이터를 수집했는데, Chukwa는 각 서버에서 이벤트를 모아 버퍼에 담아두다가 HDFS에 기록하는 방식이었다.

문제는 버퍼를 들고 있는 노드가 갑자기 죽으면, 그 안에 쌓여 있던 데이터가 그대로 사라진다는 점이었다.

이를 해결하기 위해 Kafka를 도입했다. Kafka는 데이터를 여러 브로커에 복제해두기 때문에 노드 하나가 죽어도 다른 브로커에서 데이터를 그대로 읽을 수 있다.

파이프라인 진화 과정

• V1.5: Chukwa를 완전히 걷어내기 전, 수집한 트래픽 중 약 30%를 Kafka로 분기해 실시간 처리에 활용했다. 라우터가 Kafka에서 데이터를 읽어 Elasticsearch 등 필요한 곳으로 전달했다.
• V2.0 (Keystone 파이프라인): Kafka가 파이프라인의 중심이 됐다. 이제 모든 이벤트가 Kafka를 거쳐 흐르며, Elasticsearch나 S3 같은 하위 시스템에 일시적 장애가 생겨도 Kafka가 메시지를 계속 쌓아두기 때문에 데이터 파이프라인 전체가 멈추지 않는다.

카프카가 해결한 문제들

• 데이터 유실 방지(데이터 내구성): 메시지를 여러 브로커에 복제하므로 노드 장애가 발생해도 데이터가 보존된다.
• 장애 격리: 하위 저장소(Elasticsearch, S3 등)가 일시적으로 죽어도 Kafka가 그 사이 메시지를 버퍼링해, 복구 후 이어서 처리할 수 있다.
• 실시간 + 배치 동시 처리: 같은 Kafka 토픽을 실시간 소비자와 배치 소비자가 각자 독립적으로 읽을 수 있어, 별도 파이프라인 없이 두 방식을 하나로 통합했다.

참고 : https://medium.com/netflix-techblog/evolution-of-the-netflix-data-pipeline-da246ca36905

데이터 통합 - 우버

우버는 Kafka를 시스템 로그, 앱 이벤트(라이더/드라이버 위치, 요청 상태 등), 애플리케이션 로그를 수집해 여러 하위 시스템에 전달하는 메시지 버스로 활용한다. 그런데 서비스가 커지면서 단일 Kafka 클러스터로는 감당이 안 되어 여러 데이터센터에 클러스터를 분산했고, 클러스터 간 데이터를 복제할 필요가 생겼다.

• Kafka 클러스터는 독립적인 단위이기 때문에, 예를 들어, 서울 데이터센터 클러스터에 쓴 데이터는 미국 데이터센터 클러스터에서 자동으로 보이지 않는다.
• 글로벌 분석이나 머신러닝 학습처럼 전 세계 데이터를 한 곳에서 봐야 하는 경우, 혹은 한 데이터센터 전체가 장애났을 때 다른 클러스터로 서비스를 이어가는 재해 복구(DR)를 위해 클러스터 간 데이터 복제가 필요하다.

기존 방식의 문제 - MirrorMaker

Kafka가 공식 제공하는 클러스터 간 복제 도구인 MirrorMaker를 사용했지만 운영하면서 세 가지 문제가 반복됐다.

• 잦은 리밸런싱: 워커 노드가 추가/제거될 때마다 파티션을 재분배하는 리밸런싱이 발생했고, 이 과정에서 5~10분간 복제가 멈췄다. 심한 경우 32회 재시도 끝에 영구 중단되거나, 복구 후 밀린 메시지가 한꺼번에 쏟아져 목적지 클러스터에 트래픽 스파이크를 일으켜 프로덕션 장애로 이어졌다.
• 토픽 추가 시 재시작 필요: 새 토픽을 복제 대상에 추가하려면 MirrorMaker 클러스터 전체를 재시작해야 했다.
• 데이터 유실 위험: 오프셋을 자동으로 커밋하는 방식이어서, 복제 도중 쓰기가 실패하면 해당 메시지가 소실될 수 있었다.

해결책 - uReplicator

우버는 이 문제들을 직접 해결하기 위해 uReplicator를 개발해 오픈소스로 공개했다. 핵심 변경 사항은 두 가지다.

• 리밸런싱 제거: 고수준 컨슈머 대신 SimpleConsumer를 사용하고, Helix라는 분산 관리 프레임워크가 각 워커에게 파티션을 직접 할당한다. 워커가 추가/제거될 때 영향받는 파티션만 이동하므로 전체 리밸런싱이 발생하지 않는다.
• 동적 토픽 관리: REST API로 복제할 토픽을 실시간으로 추가/삭제할 수 있어 재시작이 불필요하다.
• 데이터 유실 제로: 목적지 클러스터에 메시지가 정상 저장된 것을 확인한 후에만 오프셋을 커밋한다.

출시 8개월 후 기준으로 프로덕션 장애가 단 한 건도 보고되지 않았다. 기존에는 주 1회꼴로 장애가 발생했던 것과 비교하면 큰 개선이었다.

참고 : https://www.uber.com/kr/en/blog/ureplicator-apache-kafka-replicator/

머신러닝 - LLM과 실시간 스트리밍

LLM이 등장하면서 Kafka의 활용 범위가 크게 넓어졌다. 기존에는 숫자나 구조화된 데이터만 실시간 처리가 가능했지만, LLM이 텍스트·문서·오디오 같은 비정형 데이터를 이해할 수 있게 되면서 Kafka와 결합한 다양한 패턴이 생겨났다.

• 사일로에 갇힌 비정형 데이터 활용: 사일로(Silo)란 원래 곡식을 저장하는 창고를 뜻하는데, IT에서는 서로 단절된 채 고립된 데이터 저장소를 비유적으로 가리킨다. 예를 들어 영업팀 CRM, 고객지원팀 이메일, 물류팀 ERP가 각자의 저장소에 데이터를 쌓아두고 서로 연결되지 않은 상태가 전형적인 사일로다. 기업 데이터의 80% 이상은 이메일, PDF, 문서처럼 기존 시스템이 처리하지 못하는 비정형 데이터인데, LLM을 Kafka 파이프라인에 연결하면 이 데이터를 실시간으로 읽고 분석해 흩어진 사일로를 하나로 통합할 수 있다.

• 공급망 위험 자동 대응: 외부 공급업체로부터 “제품 오염 발생” 이메일이 오면, LLM이 즉시 내용을 분석해 제품 ID와 배치 번호를 추출한다. 이를 Kafka의 실시간 재고 스트림과 결합하면 해당 제품이 있는 매장에 자동으로 판매 중단 경고를 보낼 수 있다. 사람이 이메일을 읽고 수동으로 대응하던 과정을 자동화한 것이다.

• 자연어로 실시간 데이터 조회: “오늘 카테고리별 시간당 매출이 얼마야?”라고 질문하면, LLM이 이를 Kafka Streams나 Flink SQL 같은 스트림 처리 쿼리로 변환해 실행한다. 별도 데이터 저장소를 거치지 않고 스트림을 직접 조회하기 때문에 항상 최신 데이터로 답변받을 수 있다.

• 실시간 고객 360 뷰: 정적인 제품 매뉴얼(PDF)과 실시간 고객 행동 이벤트를 Kafka로 통합한다. 고객이 문의하면 LLM이 벡터 DB에서 관련 문서를 찾고 실시간 컨텍스트를 더해 답변을 제안한다. 상담원이 답변을 선택·수정하는 과정이 다시 스트림으로 흘러 모델 학습(RLHF)에 활용된다.

• 로컬 LLM으로 개인정보 보호: 금융·보험처럼 데이터 보안이 중요한 분야에서는 외부 API(OpenAI 등)로 데이터를 보내는 대신, Kafka 인프라 옆에 Llama 같은 오픈소스 LLM을 직접 띄운다. GDPR(개인정보보호법) 등 법적 요건을 지키면서도 실시간 임베딩 생성과 질의응답을 안전하게 처리할 수 있다.

참고 : https://www.youtube.com/watch?v=sgWxkFV7U0g&t=731s

스마트 시티 - MQTT + Kafka

스마트 시티에는 교통 신호, 가로등, 주차 센서, 대기질 측정기, 차량 등 수십만 개의 IoT 기기가 쉴 새 없이 데이터를 내보낸다. 이 기기들은 대부분 배터리로 동작하거나 네트워크가 불안정한 환경에 놓여 있어, 데이터 전송에 무거운 프로토콜을 쓸 수 없다. 그래서 등장한 것이 MQTT다.

MQTT와 Kafka의 역할 분담

MQTT는 저전력·저대역폭 환경에 최적화된 경량 메시지 프로토콜로, IoT 기기가 데이터를 브로커에 전달하는 역할을 한다. 하지만 MQTT 브로커는 수신한 데이터를 장기간 보관하거나 대규모로 분산 처리하는 데 한계가 있다. 여기서 Kafka가 그 뒤를 이어받는다.

[IoT 센서/차량/공장 장비]
        ↓ MQTT (경량 전송)
  [MQTT 브로커]
        ↓ 
  [Kafka 클러스터] → 교통 분석 시스템
                   → 차량 모니터링 시스템
                   → 도시 운영 대시보드

활용 사례

• 커넥티드 차량: 차량은 속도, 위치, 엔진 상태, 급제동 여부 등을 실시간으로 송출한다. Kafka가 이 스트림을 받아 교통 흐름 최적화(신호 제어), 사고 감지, 차량 예방 정비 알림 등에 활용한다.

• 스마트 교통 인프라: 도로 곳곳의 센서가 차량 밀도와 신호 대기 시간을 Kafka로 흘려보내면, 실시간으로 신호 주기를 조정하거나 우회 경로를 안내할 수 있다.

• 제조·산업 시설: 공장 내 기계 진동, 온도, 압력 데이터를 Kafka로 통합해 이상 징후를 실시간으로 감지한다. 장비가 고장나기 전에 유지보수 알림을 보내는 예지 정비(Predictive Maintenance)가 대표적인 사례다.

참고 : https://www.kai-waehner.de/blog/pdfviewer/mqtt-and-kafka-architectures-use-cases-for-manufacturing-connected-vehicles-and-smart-city/?auto_viewer=true#page=&zoom=page-fit&pagemode=none