| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 | 31 |
Tags
- OverTheWire
- 하둡
- Urn
- LimitRange
- 네트워크 가상화
- Web
- 해커톤
- namespace
- ResourceQuota
- 해시
- 도커
- 웹 스토리지
- 리소스 풀링
- daemonset
- Replicaset
- 혼잡제어
- 고가용성
- 다중화
- k8s
- 클라우드
- 클라우드 네이티브 5회차
- goorm
- docker
- 온프레미스
- cronjob
- configmap
- dns
- 네트워크
- 빅데이터
- 핸드셰이크
Archives
- Today
- Total
NakedFlower 님의 블로그
Apache Kafka 본문
카프카는 아파치 소프트웨어 재단에서 개발한 오픈소스 데이터 스트리밍 플랫폼
대량의 데이터 스트림을 실시간으로 처리하고 저장하기 위해 설계되었으며, 높은 처리량과 낮은 지연 시간을 제공하는 것이 핵심
대규모 데이터 파이프라인, 실시간 분석, 로그 수집, 모니터링 시스템 등 다양한 분야에서 활용

카프카의 핵심 구조
- 프로듀서 : 이벤트를 생성하여 카프카로 전송하는 주체
- 카프카 클러스터 : 데이터를 받아 저장하고 관리하는 분산 데이터 저장소
- 컨슈머 : 카프카 클러스터에서 데이터를 가져와 처리하는 주체
데이터 흐름은 Producer → Kafka Cluster → Consumer 형태로 이루어진다.
핵심 개념: 토픽과 파티션
Topic
- 이벤트를 주제별로 분류하는 단위
- 프로듀서와 컨슈머는 토픽 단위로 데이터를 송수신
Partition
- 토픽을 구성하는 실제 데이터 저장 단위
- 각 이벤트는 파티션에 append 방식으로 저장
- 파티션 내 데이터는 offset으로 식별
- 파티션 단위로 병렬처리 가능
카프카가 대용량 트래픽을 처리할 수 있는 핵심 비결이 바로 이 파티션
하나의 토픽을 여러 개의 파티션으로 나누면, 프로듀서가 보낸 이벤트는 여러 파티션에 나뉘어 저장할 수 있음. 또한, 컨슈머 역시 각 파티션에 개별적으로 붙어 데이터를 읽어올 수 있다. 즉, 파티션의 개수만큼 병렬 분산처리가 가능해지는 것!!

프로듀서 (Producer)
프로듀서는 데이터를 생성하고 카프카 클러스터의 특정 토픽으로 전송하는 역할을 한다.
- 프로듀서는 데이터를 단일 토픽 또는 여러 토픽으로 보낼 수 있다.
- 데이터를 보낼 때, 토픽 내의 여러 파티션 중 어느 파티션으로 보낼지 결정한다. 이를 통해 데이터의 병렬 처리와 분산 저장이 가능해짐.
- 만약 토픽의 파티션이 여러 개라면, 여러 프로듀서가 동시에 각기 다른 파티션에 데이터를 쓰기 때문에 병목 현상 없이 빠른 속도로 데이터를 처리할 수 있다.

컨슈머 (Consumer)
컨슈머는 토픽에서 데이터를 읽어와 소비하는 역할을 합니다.
- 컨슈머는 특정 토픽을 '구독'하여 하나 이상의 파티션에서 데이터를 읽어온다.
- 읽어온 데이터는 애플리케이션의 비즈니스 로직에 따라 처리되거나 다른 시스템으로 전달
- 컨슈머는 자체적으로 읽은 데이터의 위치(오프셋)를 기록하고 추적하고 이를 통해 컨슈머에 장애가 발생하여 중단되더라도, 마지막으로 처리했던 오프셋부터 다시 데이터를 읽어올 수 있다.

지금까지 '카프카 클러스터'라고 통칭했던 시스템은 사실 두 가지 주요 컴포넌트로 나뉨.
Broker
- Kafka 클러스터의 핵심 서버
- 토픽의 파티션 데이터를 저장 및 전송
- 데이터 복제(Replication) 및 장애 조치(Failover) 관리
- 다수의 브로커로 클러스터 구성
ZooKeeper
- 클러스터 메타데이터 및 상태 관리
- 브로커 등록, 리더 선출, 클러스터 구성 변경 등 조정
카프카를 사용하는 이유
- 높은 안정성 (Disk 기반 저장): 일반적인 메시지 큐(MQ) 시스템은 데이터를 메모리에 보관하여 시스템 다운 시 메시지가 유실될 수 있으나, 카프카는 이벤트를 디스크에 저장한다. 따라서 시스템에 문제가 생겨 다운되더라도 데이터가 남아있어 안정적인 복구가 가능하다.
- 대규모 병렬 처리 (Partition): 토픽을 여러 개의 파티션으로 나누어, 대규모 트래픽을 여러 서버(브로커)와 여러 컨슈머에 분산시켜 병렬로 처리할 수 있다.
- 수평적 확장성 (Scale-out): 서비스가 성장하여 트래픽이 증가할 경우, 파티션의 수를 늘리고 브로커와 컨슈머를 추가하는 방식으로 손쉽게 시스템을 확장(Scale-out)할 수 있다. (단, 파티션을 줄이는 것은 어렵다.)
- 고가용성 및 장애 극복: 클러스터 내에서 데이터 복제(Replication)를 지원하며, 주키퍼(또는 KRaft)가 클러스터의 상태를 관리하여 특정 브로커에 장애가 발생해도 서비스 중단 없이 안정적으로 운영할 수 있다.
'Data Engineering' 카테고리의 다른 글
| 하둡 파일 시스템 (0) | 2025.10.31 |
|---|---|
| 빅데이터 개론 (0) | 2025.10.31 |