Kafka의 주요 특징과 장점
1. 높은 처리량 (High Throughput)
처리 성능
- 단일 Broker에서 초당 수백만 개의 메시지 처리 가능
- 수백 MB/s ~ 수 GB/s의 데이터 전송 속도
성능을 높이는 핵심 기술
1.1 순차적 디스크 I/O (Sequential Disk I/O)
랜덤 I/O: 메모리 접근보다 느림
순차 I/O: 메모리 접근과 유사한 속도
Kafka는 로그를 순차적으로 디스크에 기록:
[메시지1][메시지2][메시지3][메시지4]... → 디스크에 순차 기록
장점:
- 디스크 seek time 최소화
- OS의 페이지 캐시 효율적 활용
- 랜덤 I/O 대비 1000배 이상 빠름
1.2 Zero Copy
전통적인 방식:
디스크 → OS 버퍼 → 애플리케이션 버퍼 → 소켓 버퍼 → NIC
Zero Copy:
디스크 → OS 버퍼 → NIC
- CPU 개입 없이 DMA(Direct Memory Access)로 데이터 전송
- 불필요한 복사 제거로 성능 향상
1.3 Batch Processing
// Producer: 메시지를 배치로 전송
props.put("batch.size", 16384); // 16KB 배치
props.put("linger.ms", 10); // 10ms 대기
// Consumer: 메시지를 배치로 조회
props.put("max.poll.records", 500); // 한 번에 500개- 네트워크 왕복 횟수 감소
- 디스크 I/O 최적화
1.4 Compression (압축)
props.put("compression.type", "snappy");
// 옵션: gzip, snappy, lz4, zstd압축률 비교:
| 알고리즘 | 압축률 | 속도 | 사용 사례 |
|---|---|---|---|
| gzip | 높음 | 느림 | 네트워크 대역폭 제한 |
| snappy | 중간 | 매우 빠름 | 균형잡힌 선택 |
| lz4 | 낮음 | 가장 빠름 | CPU가 제한적 |
| zstd | 가장 높음 | 빠름 | 최신 권장 |
2. 확장성 (Scalability)
2.1 수평 확장 (Horizontal Scaling)
초기:
Topic: orders (3 partitions)
└── Broker 1, 2, 3
확장 후:
Topic: orders (6 partitions)
└── Broker 1, 2, 3, 4, 5, 6
- Broker 추가로 처리 능력 증가
- Partition 추가로 병렬 처리 증가
- 다운타임 없이 확장 가능
2.2 Consumer 병렬 처리
Topic: user-events (10 partitions)
Consumer Group:
├── Consumer 1 → Partition 0, 1
├── Consumer 2 → Partition 2, 3
├── Consumer 3 → Partition 4, 5
├── Consumer 4 → Partition 6, 7
└── Consumer 5 → Partition 8, 9
- Partition 수만큼 Consumer 병렬 실행
- 처리량을 선형적으로 증가
3. 내결함성 (Fault Tolerance)
3.1 데이터 복제 (Replication)
Topic: orders (replication factor = 3)
Partition 0:
├── Leader → Broker 1 [읽기/쓰기]
├── Replica → Broker 2 [동기화]
└── Replica → Broker 3 [동기화]
작동 방식:
- Producer는 Leader에 메시지 전송
- Leader는 Replica에 복제
- Replica가 동기화되면 ACK 전송
- Leader 장애 시 Replica가 새로운 Leader 선출
3.2 ISR (In-Sync Replicas)
ISR = Leader와 동기화된 Replica 목록
정상:
ISR = [Broker 1 (Leader), Broker 2, Broker 3]
Broker 3 지연:
ISR = [Broker 1 (Leader), Broker 2]
Broker 1 장애:
ISR = [Broker 2 (새 Leader), Broker 3]
장점:
- 데이터 손실 방지
- 자동 장애 복구 (Failover)
3.3 내구성 보장 설정
// Producer 설정
props.put("acks", "all"); // 모든 ISR이 확인할 때까지 대기
// Topic 설정
min.insync.replicas=2 // 최소 2개의 replica가 동기화되어야 함4. 데이터 영속성 (Durability)
4.1 디스크 기반 저장
메시지 → 메모리 → 디스크 → 복제본
(OS 캐시) (영구 저장)
- 모든 메시지를 디스크에 영구 저장
- Broker 재시작 후에도 데이터 유지
4.2 보관 정책 (Retention Policy)
# 시간 기반 보관
retention.ms=604800000 # 7일
# 크기 기반 보관
retention.bytes=1073741824 # 1GB
# Log Compaction (키 기반 보관)
cleanup.policy=compact사용 예시:
시간 기반: 로그 데이터 (7일 후 삭제)
크기 기반: 제한된 디스크 (1GB 초과 시 삭제)
Compaction: 최신 상태만 유지 (사용자 프로필)
5. 확장된 Pub/Sub 모델
5.1 Consumer Group
Topic: events
Consumer Group A (실시간 처리):
└── Consumer 1, 2, 3 → 메시지 분산 처리
Consumer Group B (배치 처리):
└── Consumer 1 → 모든 메시지 처리
Consumer Group C (분석):
└── Consumer 1, 2 → 메시지 분산 처리
장점:
- 같은 데이터를 여러 용도로 활용
- 각 Consumer Group은 독립적인 Offset 관리
- 큐 모델과 Pub/Sub 모델의 장점 결합
6. 스트림 처리 (Stream Processing)
6.1 Kafka Streams API
StreamsBuilder builder = new StreamsBuilder();
// 실시간 스트림 처리
KStream<String, Purchase> purchases = builder.stream("purchases");
// 변환, 필터링, 집계
KTable<String, Long> salesByRegion = purchases
.filter((key, purchase) -> purchase.getAmount() > 100)
.groupBy((key, purchase) -> purchase.getRegion())
.count();
salesByRegion.toStream().to("sales-by-region");특징:
- Exactly-once semantics 지원
- Stateful 처리 (상태 저장)
- Windowing (시간 기반 집계)
7. 다양한 통합 (Integration)
7.1 Kafka Connect
[데이터 소스] → Source Connector → Kafka → Sink Connector → [데이터 싱크]
지원 시스템:
- 데이터베이스: MySQL, PostgreSQL, MongoDB, Cassandra
- 파일 시스템: HDFS, S3
- 검색: Elasticsearch, Solr
- 캐시: Redis
- 스트리밍: HDFS, S3, BigQuery
장점:
- 코드 없이 데이터 파이프라인 구축
- 확장 가능하고 안정적
- 수백 개의 커넥터 사용 가능
8. 운영 편의성
8.1 모니터링
JMX 메트릭:
├── Broker 메트릭 (처리량, 요청 수)
├── Topic 메트릭 (메시지 수, 크기)
├── Producer 메트릭 (전송 속도, 에러)
└── Consumer 메트릭 (Lag, 처리 속도)
8.2 관리 도구
- Kafka CLI: 기본 명령줄 도구
- Kafka Manager: 웹 기반 관리 UI
- Confluent Control Center: 엔터프라이즈 모니터링
- Burrow: Consumer lag 모니터링
9. 실시간 처리
낮은 지연 시간
Producer → Kafka → Consumer
< 10ms < 10ms
- 평균 지연 시간: 수십 밀리초
- 실시간 데이터 파이프라인 구축 가능
10. 순서 보장 (Ordering Guarantees)
Partition 단위 순서 보장
User A의 이벤트 (key="userA")
└── Partition 0: [이벤트1] → [이벤트2] → [이벤트3]
순서 엄격히 보장
User B의 이벤트 (key="userB")
└── Partition 1: [이벤트1] → [이벤트2] → [이벤트3]
순서 엄격히 보장
활용:
- 금융 거래: 순차적 처리 필요
- 사용자 행동 추적: 시간 순서 중요
- 상태 변경 이벤트: 순서가 의미를 결정
주요 장점 요약
| 특징 | 장점 | 비즈니스 가치 |
|---|---|---|
| 높은 처리량 | 초당 수백만 메시지 | 대용량 데이터 처리 |
| 확장성 | 수평 확장 | 성장에 따른 유연한 대응 |
| 내결함성 | 자동 복구 | 높은 가용성 |
| 영속성 | 데이터 재처리 | 분석 및 감사 |
| 낮은 지연 | 실시간 처리 | 즉각적인 대응 |
| 순서 보장 | 정확한 이벤트 순서 | 데이터 일관성 |
| 통합성 | 다양한 시스템 연결 | 빠른 구축 |
실제 벤치마크
LinkedIn (Kafka 개발사)
- 7조 개 이상의 메시지/일
- 4.5PB 데이터/일
- 1400+ Kafka 클러스터
Netflix
- 8조 개 이벤트/일
- 수 페타바이트 데이터
- 실시간 추천 시스템 구동
Uber
- 1조 개 메시지/일
- 실시간 위치 추적
- 동적 가격 책정
다음 단계
- Kafka 사용 사례 - 실제 활용 예시
- Topic과 Partition - 아키텍처 깊이 이해
- Producer 기본 개념 - 메시지 전송 방법
댓글 (0)