티스토리 뷰

IT/Message Broker

🔁 Apache Kafka 기반 메시지 처리 구조 완전 정복

Stv 2025. 5. 18. 10:36

목차


    🧠 Kafka란?

    Kafka는 LinkedIn에서 개발하고 지금은 Apache 재단에서 관리하는 분산 메시징 시스템이다.
    기존의 MQ와 비교했을 때, 높은 처리량과 내구성, 확장성 때문에 대규모 시스템에서 널리 사용된다.
    단순히 "메시지를 주고받는 도구"가 아니라, 데이터 스트림을 처리하고 저장하는 플랫폼에 가깝다.

     

    📌 Kafka의 핵심 구성 요소

    1. Producer
      • 메시지를 발행(publish)하는 주체
      • 예 : 주문 서비스가 "주문 생성됨" 이벤트를 Kafka로 발행
    2. Topic
      • 메시지를 분류해서 전달하는 단위 (이벤트의 카테고리 같은 개념)
      • 예 : order-created, payment-completed
    3. Broker
      • Kafka 서버 하나를 의미
      • 여러 개의 브로커가 모여 Kafka 클러스터를 구성하고, 메시지를 저장하고 전달함
    4. Partition
      • 하나의 Topic을 물리적으로 분산시킨 단위
      • 메시지를 병렬 처리할 수 있게 해줌 -> Kafka의 고성능 핵심
    5. Consumer
      • 특정 Topic의 메시지를 구독하고 소비(consume)하는 애플리케이션
      • 예 : 배송 서비스가 order-created Topic을 구독해서 배송 준비 시작
    6. Consumer Group
      • 여러 Consumer가 하나의 그룹으로 묶여서 분산 소비를 가능하게 하는 구조
      • Kafka는 하나의 메시지를 같은 Consumer Group 내에서는 한 번만 전달함

    🔁 Kafka 메시지 처리 흐름

    • Kafka의 메시지 처리 과정을 순서대로 정리해보면 다음과 같다.

    📌 전체 흐름

    1. Producer가 특정 Topic에 메시지를 발행한다.
    2. Kafka Broker가 해당 메시지를 Topic의 Partition에 저장한다.
    3. Conumer가 Topic을 구독하고, 메시지를 읽어서 처리한다.
    4. 메시지를 처리한 이후에는 Offset을 커밋하여 다음 메시지를 추적할 수 있게 한다.

    🔍 메세지 소비 방식 (Consumer 동작 방식)

    • Kafka에서 메시지를 소비하는 방식은 Pull 기반이다.
    • 즉, Kafka는 소비자가 요청할 때만 메시지를 보낸다.

    📌 Offset 기반 처리

    Kafka는 "이 메시지 읽었어!"라는 걸 기억하는 Offset을 사용한다.
    • Offset은 각 Partition 안에서의 메시지 번호 같은 개념
    • Consumer는 마지막으로 읽은 Offset을 기준으로 다음 메시지를 읽는다
    • Auto commit vs Manual commit 방식 존재
      • Auto : 주기적으로 자동 저장 (편하지만 유실 위험)
      • Manual : 직접 처리 성공 시점에만 commit (정밀 제어 가능)

     

    🧩 Partition과 Consumer Group 구조 이해

    이 구조를 제대로 이해하면 Kafka의 고성능과 확장성을 납득할 수 있다.

    예를 들어보자 :

    • order-created Topic이 3개의 Partition으로 구성됨
    • Consumer Group delivery-service가 존재하고, 그 안에 Consumer가 3개 있다.
    이 경우, Kafka는 Partition 3개를 각각 1개의 Consumer에 할당해서 병렬 처리 가능

    💡주의 : Consumer 수가 Partition 수보다 많아도 일부는 쉬게 된다 (할당이 안 되기 때문)

    🚨 메시지 처리 시 고려할 사항

    1. Idempotency
      • 메시지를 여러 번 받더라도 한 번만 처리되어야 함
      • DB insert 전에 중복 체크 or 이벤트 기반 ID deduplication 필요
    2. Exactly-once 보장
      • Kafka는 기본적으로 at-least-once (중복 가능성 존재)
      • idempotent producer, transactional messaging을 이용하면 exactly-once 구현 가능
    3. DLQ (Dead Letter Queue)
      • Consumer에서 예외 발생 시 해당 메시지를 별도 Queue로 보내서 나중에 수동 처리
    4. Back-pressure 처리
      • 소비 속도가 느릴 경우 처리 지연 발생 -> 버퍼링, 스케일 아웃 고려 필요

    ✨ 실무에서 Kafka를 왜 쓰는가?

    용도 설명
    시스템 간 비동기 통신 MSA 환경에서 서비스 간 decoupling
    대용량 로그 수집 실시간 로그/이벤트 분석용
    실시간 스트리밍 처리 Spark, Flink 같은 실시간 처리 시스템과 연계
    장애 복원력 향상 이벤트 중심 처리로 서비스 간 장애 전파 최소화

     

    Kafka vs MQ

    항목 Kafka 기존 MQ (RabbitMQ 등)
    처리량 매우 높음 (백만 단위 메시지 처리) 상대적으로 낮음
    저장 구조 디스크 기반 로그 저장 메모리 중심 큐
    메시지 소비 Pull 기반 (Offset 관리) Push 기반
    메시지 보존 기본 설정으로도 오래 저장 가능 처리 후 즉시 삭제됨