Kafka
데이터 파이프라인을 구축할 때 가장 많이 고려되는 시스템
링크드인에서 개발된 분산 메시징 플랫폼 & 오픈소스
끊임없이 들어오는 데이터를 일괄적으로 묶어서 데이터를 처리하고 실시간으로 데이터를 처리하거나 가공 → 또 다른 서비스에 데이터를 전달
ex. IoT 데이터 처리, 금융거래 사기 방지
Kafka 개발 배경
기존 링크드인의 데이터 처리 시스템
각 파이프라인이 파편화됨
시스템 복잡도가 높음 → 새로운 시스템 확장하기 어려운 살ㅇ황
개발 목표
프로듀서와 컨슈머 분리
메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
높은 처리량을 위한 메시지 최적화
데이터가 증가함에 따라 스케일 아웃이 가능한 시스템 구축
1. 메시징 시스템(Pub/Sub 모델)
Publisher & Subscriber로 이루어진 비동기 메시징 전송 방식
데이터 단위를 보내는 측(Publisher/Producer)에서 메시지 시스템에 메시지를 저장하면 가져가는 측(Subscriber/Consumer)는 데이터를 수신
Publish 발신자의 메시지에는 수신자가 정해져 있지 않은 상태로 발행
Subscribe 구독을 신청한 수신자만이 정해진 메시지를 받음
수신자는 발신자 정보가 없어도 메시지 수신이 가능
기업에서는 Pub/Sub 모델의 카프카를 어떻게 사용하고 있을까?
넷플릭스
스트리밍 서비스 중 발생하는 수십억 건의 사용자 이벤트(예. 재생, 정지, 좋아요 클릭 등)를 실시간으로 수집하고 분석
🤔 Why?
사용자의 모든 행동(예. 영화 재생, 정지 …)을 분석해서 개인화 추천을 실시간으로 최적화
장애 감지
품질 모니터링
🌊 구체적인 흐름
사용자 앱 → 카프카 → 실시간 처리 시스템(예. Flink, Spark Streaming) → 추천 시스템, 알림 시스템 등
우버
운행 데이터, 위치 정보, 결제 이벤트 같은 걸 수집, 분석
🤔 Why?
수백만 건의 라이드를 동시에 관리해야 해서, 빠르고 신뢰성 있는 데이터 파이프라인이 필요
🌊 구체적인 흐름
드라이버/라이더 앱 → 카프카 → 실시간 매칭 엔진 → 수요-공급 예측, 경로 최적화, 실시간 알림
링크드인
사용자 활동 기록(피드 조회, 메시지 전송 등), 서비스 로그를 수집하기 위함
🤔 Why?
하루에 수십억 건의 이벤트 처리
🌊 구체적인 흐름
사용자 이벤트 → 카프카 → 추천 알고리즘 학습, 인기 게시물 선정, 광고 최적화
쿠팡
주문, 결제, 배송 등 모든 프로세스 이벤트를 실시간 수집, 이상 징후(예. 결제 오류, 배송 지연)를 빠르게 감지
🤔 Why?
대규모 트래픽을 빠르게 수집하고 분석 → 고객 경험 개선
🌊 구체적인 흐름
주문 발생 → 카프카 → 실시간 모니터링 시스템 → 오류 탐지 및 자동 대응
신한은행
디지털 전환 프로젝트에서 이벤트 기반 아키텍처를 도입하면서 카프카 사용
카드 사용 내역 알림, 계좌 입출금 알림 같은 이벤트 실시간 처리
🤔 Why?
기존: 일괄 배치 시스템 多 - 속도 느림
실시간 알림, 자동화된 서비스 제공이 필요했음
🌊 구체적인 흐름
고객 거래 발생 → 카프카 → 알림 서비스, 사기 탐지 시스템
2. 카프카의 아키텍처
프로듀서(Producer)
메시지를 생산하여 브로커의 토픽으로 전달
브로커(Broker)
카프카가 설치된 서버 또는 노드를 지칭
컨슈머(Consumer)
브로커의 토픽으로부터 저장된 메시지를 전달받는 역할
주키퍼(Zookeeper)
분산 애플리케이션 관리를 위한 코디네이션 시스템
분산된 노드의 정보를 중앙에 집중하고 구성관리, 그룹 네이밍, 동기화 등의 서비스 수행
작동 방식
프로듀서는 새 메시지를 카프카에 전달
→ 전달된 메시지는 브로커의 토픽이라는 메시지 구분자에 저장
→ 컨슈머: 구독한 토픽에 접근하여 메시지를 가져옴(pull 방식)
기존의 메시징 시스템과 다른점
파일시스템(디스크)에 메시지 저장
기존 메시징 시스템
프로듀서가 전송한 메시지를 브로커의 메모리 상태에 존재하는 큐에 유지
컨슈머가 메시지를 소비하면 큐에서 바로 메시지를 삭제
카프카
컨슈머가 메시지를 소비하더라도 디스크에 메시지를 일정기간 보관하기 때문에 메시지 손실이 없음(영속성)
멀티 프로듀서, 멀티 컨슈머
디스크에 메시지를 저장 → 프로듀서와 컨슈머 모두 하나 이상의 메시지를 주고 받을 수 있음
분산형 스트리밍 플랫폼
단일 시스템 대비 성능이 우수
수평적 시스템 확장 용이
시스템 트래픽이 높아지면 브로커를 추가해서 클러스터 확장 가능
고가용성 : 일부 노드가 죽더라도 다른 노드가 일을 지속
페이지 캐시
파일 시스템에 세그먼트 파일을 쓰는 동작에서 별도의 버퍼 캐시를 구현하는 대신 운영체제의 페이지 캐시 사용
운영체제
사용하지 않는 메모리를 파일 시스템의 페이지 캐시로 사용
사용자가 요청하지 않아도 미리 읽기 동작을 통해 앞으로 읽을 가능성이 있는 뒤쪽 내용 메모리를 미리 읽어들이는 최적화 진행
내부에서 버퍼캐시 운영 X
JVM에 의해 발생할 수 있는 GC(Garbage Collection) 오버헤드도 줄임
브로커 재시작하는 경우: 페이지 캐시는 커널 영역에 남아있음 → 웜업되어 있는 상태로 서비스 시작 가능
Kafka 기본 구성 요소
cluster
여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
producer
데이터를 만들고 전달하는 전달자의 역할
consumer
프로듀서에서 전달한 데이터를 브로커에 요청하여 메시지(데이터)를 소비하는 역할
broker
생산자와 소비자의 중재자 역할
topic
보내는 메시지를 구분하기 위한 카테고리화
메시지를 논리적으로 묶은 개념 = 데이터베이스의 테이블, 파일시스템의 폴더
프로듀서가 메시지를 보낼 경우 토픽에 메시지가 저장됨
partition
토픽을 구성하는 데이터 저장소 - 수평확장이 가능한 형태
토픽을 구성하는 데이터 저장소이며 메시지가 저장되는 위치
한 파티션 당 한 컨슈머가 메시지를 소비
컨슈머의 처리 속도와 목표 처리량에 따라 파티션의 수가 달라짐
클러스터 구성 내 kafka의 개수와 같게 하거나 배수로 증가시키는 게 좋음
Kafka의 특징
동시성 - 여러 producer이 동시에 메시지를 전송할 수 있고, 여러 consumer에서 동시에 메시지를 읽을 수 있음
파일 형태로 저장 - 노드가 메시지를 전송하면 producer와 consumer를 중재하는 브로커에서 전달자가 전달한 메시지를 브로커의 동작에 영향을 주지 않고 처리 속도 및 장애 복구를 유지할 수 있게 하기 위해 일정 기간 동안 파일 형태로 저장
클러스터 확장 - 시스템 트래픽이 높아지면 브로커 추가해서 클러스터 확장할 수 있음
처리량 늘릴 수 있음 - 처리 속도가 저하되면 consumer이나 producer 추가하여 처리량 늘릴 수 있음
속도의 균형 - consumer가 producer의 메시지 생성 속도를 따라가지 못할 때 consumer를 그룹으로 묶어 프로듀서에서 보내는 속도와 읽는 속도의 균형을 맞출 수 있음