• Overview

• Apache Kafka vs Redis Stream

🎫 Apache Kafka

• 용어

  • Cluster: 같이 일하는 카프카 노드들의 집합

  • Node: 카프카 프로세스 1개

    → Node는 Broker 또는 Controller 중 1개만, 또는 2개 모두 담당할 수 있음!

  • Broker: 데이터 처리 역할 (외부 통신)

  • Controller: 클러스터 관리 역할 (내부 통신)

    → 클러스터 전체의 메타데이터 관리

• 정리

                          <논리적 구조>
  

  

                          <물리적 구조>
  

  

  • 왜 하나의 토픽 내에 여러 개의 Partition 사용?

    • 병렬 처리: 여러 Consumer가 데이터 동시에 읽기 가능
    • 확장성: Topic을 Partition 단위로 쪼개어, Broker에 분산시켜 저장 가능
    • 내구성: Broker 하나에 장애가 나도, 다른 Broker의 Replica에 복제된 Partition 데이터로 복구 가능

  • Broker는 토픽별로 파티션을 관리하는 것이 아닌, 다른 토픽의 파티션을 묶어서 관리함

  • 파티션 하나는 여러 브로커에 Replica로 존재

    • 한 브로커당 같은 파티션은 딱 1개
    • 복제본 수만큼 타 브로커가 사본 들고있음
    • so, 레플리카 수 ≤ 브로커 수

    → Replica는 복구용, Leader만 메시지 처리 가능!

• 흐름

  1. 프로듀서가 파티션 A로 메시지 발송 희망

     • 아무 브로커에게 파티션 A의 Leader를 물어봄
     • 메타 데이터로 파티션 A의 Leader는 브로커 B인 것을 확인

     → Bootstrap 과정!

  2. 브로커 B와 TCP 연결

     • 브로커 B가 자신의 디스크 디렉토리에 기록
     • Follower들은 브로커 B의 로그를 가져가서 자신의 디스크 디렉토리에 복제

  3. ISR (리더 선정 명단) 정리되면 커밋 완료

     → 이제 컨슈머가 읽을 수 있음

• Partition과 Consumer의 관계

  • 대응 관계

    • Topic - Consumer Group (서비스 단위 그룹)
    • Partition - Consumer

  • Consumer Group에는 여러 Consumer를 둘 수 있음

    • 컨슈머 수가 더 적으면, 알아서 Partition들을 나눠서 담당

    • 파티션 수 ≥ 컨슈머 수

      → 컨슈머가 더 많으면, 몇 컨슈머는 할 일이 X

  • Partition들 사이에서 메시지의 순서 보장 방법

    • Producer

      • Partition을 직접 or Round-Robin 방식으로 지정 가능
      • 같은 키를 같는 메시지는 같은 파티션에 저장되어 순서 유지됨

    • Consumer Group

      • 하나의 Partition은 여러 Consumer Group이 소비 가능

      • 하나의 Partition은 같은 Consumer Group 내에서 하나의 Consumer만 연결

        → 메시지가 파티션별로 순서대로 읽히도록 보장하기 위함

    • Best case: Partition과 Consumer를 1:1로 연결 시

• 추가 세부 내용