반응형
반응형
🌏 Kafka의 분산 로그 저장 시스템(Distributed Commit Log)
이것이 카프카의 가장 뚜렷한 차별점입니다
✅ 로그(Log)
- Kafka는 메시지를 단순히 "큐에 넣었다가 소비되면 삭제"하는 게 아니라,
- 디스크에 순차적으로 로그 형태로 저장(Commit Log) 합니다.
Partition 0
├─ Offset 0 : 주문1
├─ Offset 1 : 주문2
├─ Offset 2 : 주문3
각 메시지는 Offset이라는 번호와 함께 디스크에 기록되어, 메시지를 읽어도 바로 사라지지 않고, Retention 설정(예: 7일, 30일) 동안 보존됩니다.
이 때문에 나중에 새로 온 Consumer도 과거 데이터를 다시 읽을 수 있습니다. (Replaying 가능)
또한 디스크에 순차 쓰기(append only log)라서 초당 수백만 건 처리 가능하여 대규모 처리에도 유리합니다.
✅ 분산(Distributed)
파티션별 다른 서버 저장 (= 샤딩)
하나의 브로커에 모든 데이터를 저장하면 위험하니, Partition 단위로 쪼개 여러 Broker에 분산 저장합니다. (물론 파티션의 개수가 서버 개수보다 많게 되면 같은 서버에 저장하게 될 수도 있겠지만 최대한 나누려고 합니다)
예를 들어, order-topic을 생성했다면 들어오는 메시지들은 라운드 로빈(round-robin) 방식이나 Key 해싱을 통해 Partition에 분산 저장됩니다.
Leader/Follower 구조 (= DB 다중화)
Partition은 Leader/Follower 구조로 Replication 되어 장애에도 안전합니다. 데이터를 복제해서 저장해 장애 복구와 안전성을 확보할 수 있습니다.
🌏 기존 메시징 시스템 vs Kafka (= Queue vs Topic)
Kafka와 기존 메세징 시스템은 서비스 간 데이터를 중개하기 위해 Producer/Consumer 구조를 사용한다는 점에서는 비슷하지만 아래와 같은 차이가 있습니당
✅ 기존 메시징 시스템 (RabbitMQ, ActiveMQ, IBM MQ 등)
- 본질: 메시지 큐(Message Queue)
- 특징
- 메시지를 소비(consume)하면 큐에서 제거됨
- Queue 모델 중심으로, 생산자(Producer)가 넣고, 소비자(Consumer)가 꺼내는 구조
- 보통 Point-to-Point (1개의 메시지는 1번만 소비됨)
- 장점: 단순하고 이해하기 쉬움, 전통적으로 많이 사용됨
- 단점: 대규모 데이터 스트리밍이나 장기 보관에는 적합하지 않음
✅ Kafka
- 본질: 메시지 브로커 + 분산 로그 저장 시스템
- 특징
- 메시지를 디스크에 Commit Log 형식으로 저장
- 메시지를 소비해도 바로 삭제되지 않고 설정한 기간 동안 보관
- 하나의 메시지를 여러 Consumer Group이 독립적으로 여러 번 소비 가능
- Pub/Sub 모델과 Queue 모델을 모두 지원하는 유연성
- 장점: 대규모 실시간 데이터 처리, 확장성, 내구성
- 단점: 초기 진입장벽이 높음, 운영 복잡성 존재
| 구분 | 전통 MQ (RabbitMQ 등) | Kafka |
|---|---|---|
| 저장 방식 | Queue (읽으면 삭제) | Commit Log (읽어도 일정 기간 보관) |
| 데이터 모델 | 큐 중심 | 로그(Partition + Offset) 중심 |
| 재처리 가능 여부 | 어려움 (Replyaing은 안됨) | 가능 (Replaying 가능) |
| 확장성 | 제한적 | 매우 뛰어남 (Partition 기반 분산 저장) |
| 사용 사례 | 단순 비동기 메시지 전달 | 이벤트 스트리밍, 로그 수집, 실시간 분석 |

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!
반응형
'아키텍처+MSA' 카테고리의 다른 글
| [아키텍처/Kafka] acks(Acknowledgement) 설정: acks=0,1,all (0) | 2025.09.17 |
|---|---|
| [아키텍처/Kafka] 메세지 복제(Replication)와 브로커의 Leader-Follower 구조 (0) | 2025.09.17 |
| [아키텍처/Kafka] 비동기 메시징 시스템: 개념 + Consumer Group을 통한 병렬 처리의 원리를 간단히 알아보자! (0) | 2025.09.16 |
| [아키텍처] 아키텍처 개선과 SPOF 해결: SPOF 문제는 꼬리에 꼬리를 이어.. (3) | 2025.08.18 |
| [아키텍처] 재배포 및 배포 롤백: 서비스 장애 발생 시 피해를 최소화하기 위한 롤백의 중요성 (2) | 2023.08.26 |