아키텍처+MSA

[아키텍처/Kafka] Kafka만의 특징: 분산 로그 저장, Queue vs Topic (기존 메세징 시스템과 차이)

깃짱 2025. 9. 17. 10:00
반응형
반응형

🌏 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 기반 분산 저장)
사용 사례 단순 비동기 메시지 전달 이벤트 스트리밍, 로그 수집, 실시간 분석

 

 

 

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!

 

반응형