search

Kafka 구성요소

0. Kafka란?

Kafka는 대규모 실시간 데이터 스트림을 처리하고 저장하는 분산 스트리밍 플랫폼으로, 메시지 브로커 이상의 기능을 제공한다.

  • 주요 특징:

    • Publisher-Subscriber 모델 : 데이터를 생성(Producer)하고 소비(Consumer)하는 구조

    • 분산 처리 : 여러 Partition으로 데이터 분산 → 병렬 처리 및 성능 향상

    • 내구성 : 디스크에 로그를 저장하여 데이터 유실 방지

    • 확장성 : 클러스터 구성으로 유연하게 서버 추가 가능

    • 실시간 스트리밍 : 실시간으로 데이터 흐름을 처리하고 분석할 수 있는 기능

    • 높은 처리량 : 대규모 데이터 트래픽을 처리할 수 있도록 최적화됨

hashtag
1. Kafka의 기본 구성요소

hashtag
Kafka

  • Broker : 카프카 서버. 카프카를 브로커라고 하기도 한다.

    • Controller : 클러스터 내 특정 브로커가 장애 등으로 인해 사용할 수 없는 경우, 해당 브로커가 갖고 있는 토픽을 정상동작하는 브로커에게 재분배해주는 역할을 한다. ⇒ 즉, 카프카 중에 이상한게 있으면 찾아서 분담해주는 역할

    • Coordinator : 브로커의 메시지를 읽어가는 Consumer를 체크하여 문제가 있다면(매칭된 파티션의 데이터를 컨슘 할 수 없는 경우), 정상동작하는 Consumer로 재배정하는 역할을 한다.

    • Controller와 Coordinator는 특별히 어떤 조건으로 결정되는 것이 아니라 생성된 브로커 중 하나가 담당하게된다.

hashtag
Producer

  • 메시지 생산(produce)해서 브로커의 토픽으로 메시지를 보내는 역할을 하는 어플리케이션, 서버 등

  • 메시지를 전송할 때 특정 Key를 사용하여 Partition을 결정한다.

  • 작동 방식

    • Record 생성 : 메시지를 Key-Value 형식으로 생성

    • Partition 선택 : Key 해싱(Hashing)을 통해 적절한 Partition을 선택

    • 전송 및 확인 : 지정된 Partition으로 메시지를 전송 후 결과 확인

hashtag
Consumer

  • 토픽의 파티션에 저장되어 있는 메시지를 소비(consume)하는 역할을 하는 어플리케이션, 서버 등

  • Consumer(Group) 단위로 Partition을 할당받아 메시지 처리한다.

    • Offset 관리 :

      • Consumer는 자신이 어디까지 메시지를 읽었는지를 Offset을 통해 관리

hashtag
Consumer Group

  • 하나의 이벤트를 여러 애플리케이션에서 소비할 수 있는 구조

  • 사용 예시

    • "예약 완료" 이벤트 → 콘서트 서비스, 데이터 플랫폼, 결제 서비스가 모두 소비해야 할 때

    • "예약 완료" 이벤트를 콘서트 서비스와 결제 서비스에서 각각 소비 한다고 할 때의 구성 예제

      • 콘서트 Consumer Group: 병렬 처리를 위해 Consumer 4개 배정

      • 결제 Consumer Group: 안정성을 위해 Consumer 2개 배정

  • 동작 원리

    • Consumer Group은 동일한 Group ID를 공유하며, 서로 다른 Partition을 나눠서 처리한다.

    • 메시지는 하나의 Consumer Group 내에서는 중복 소비 불가

    • 다른 Consumer Group은 동일한 메시지를 독립적으로 소비 가능

  • (⚖️참고) 토픽의 파티션 수와 컨슈머 수에 따른 소비

    • Consumer 개수 > Partition 개수 : Consumer가 여러개의 partition을 담당

    • Consumer 개수 = Partition 개수 : 최적의 병렬 처리

    • Consumer 개수 < Partition 개수 : 병렬 처리 가능하긴 하나, 일부 Consumer 대기 상태 발생 ❗이 때, 여러개의 컨슈머가 하나의 파티션을 바라봐서 동시성 이슈가 생기지 않도록 해야한다.

hashtag
2. Topic & Partition⭐

topic은 partition으로 이루어져 있다

hashtag
⭐Topic

  • 카프카 클러스터의 브로커에서 데이터를 관리할 때 기준이 되는 개념

  • 어떤 주제의 데이터를 보관할지 정하는 주제라고 봐도 된다

    • 예약완료 이벤트를 저장하는 곳이 topic

hashtag
⭐Partition

  • 기본 개념

    • Partition은 메시지를 나누어 병렬 처리할 수 있는 단위

    • 하나의 Partition은 하나의 Consumer만 접근 가능

  • 구성 요소

    • Leader Partition : 반드시 1개 존재 (쓰기/읽기 담당)

    • Follower Partition : 복제본(Replica)으로 존재할 수 있으며, Leader 장애 시 승격됨 (없을 수도 있다)

  • Partitioner란?

    • Producer가 메시지를 저장할 Partition을 결정하는 역할을 수행. 덕분에 일관성 유지와 병렬 처리가 가능하다.

    • 즉, Producer가 "이 메시지를 어디에 넣어야 하지?"를 고민할 필요 없게, 어떤 Partition에 저장할지를 알아서 결정해주는 컴포넌트

circle-info

hashtag
Kafka로 동시성 제어하는 방법

  • Key 기반 동시성 제어:

    • 동시성 제어를 위해 Key를 기준으로 메시지를 전송

    • 동시 처리하지 않아야 하는 데이터는 동일한 Key로 묶어서 동일한 Partition으로 전달

  • 사용 예

    • userPoint 차감을 위해 userId를 Key로 설정 → 같은 사용자에 대한 차감은 순차 처리 보장

    • 사용자 별로 Partition을 생성하면 각각 요청이 다르더라도 병렬처리가 가능하지만, 일반적으로 티션 수를 제한하고 Key 해싱 전략을 통해 분산 처리하는 방식을 사용

    • 사용자가 많을 경우에는 홀수/짝수 분할 전략 등과 같은 규칙 적용

      • 홀수 ID → Partition A

      • 짝수 ID → Partition B

⚠️ 참고 동작하는 Consumer가 여러개라고 하더라도 의 Partition은 하나의 Consumer만 할당 가능하다 다만, 하나의 Consumer는 여러 Partition을 할당받을 수 있음.

즉, 1번 메시지를 Consumer A가 가져가면 2번 메시지도 Consumer A가 가져가야 한다. (1번 메시지 ⇒ Consumer A / 2번 메시지 ⇒ Consumer B 가 가져 갈 경우 동시성 이슈 발생)

이렇게 순서성과 동시성 관리는 Kafka의 Consumer Group 관리 메커니즘이 담당한다.

hashtag
3. Rebalancing

  • Consumer Group 내에서 Partition의 소유권을 재조정하는 과정

  • 발생 케이스

    • 새로운 Consumer 추가/제거

    • Topic 내Partition 추가

    • 특정 Consumer 장애 발생

  • 동작 원리

    1. Coordinator가 Partition 소유권 확인 : 현재 Partition과 Consumer 상태를 분석

    2. Partition 소유권 회수 : 기존 Consumer에게 소유권 해제 명령

    3. Partition 재할당 : 새로운 Consumer에게 Partition을 할당

    4. 재시작: 변경 사항 적용 후 메시지 소비 재개

  • 주의 사항

    • Rebalancing 중에는 메시지 소비 중단 → 지연 발생 가능

      • 이유 : Partition 소유권 변경 중 동시성 이슈 방지

      • ex) 메시지 1번을 처리 중인데, Rebalancing으로 Partition이 다른 Consumer에게 넘어가면 메시지가 중복 소비되거나 유실될 수 있음있다.

    • Rebalancing 빈도 증가 시 성능 저하 ⇒ Partition 변경이 잦으면 성능 저하 및 지연 시간이 증가

    • Static Membership 적용 ⇒ Consumer가 자주 등록/해제되지 않도록 설정하여 Rebalancing 최소화

    • Long Polling 실패 ⇒ 메시지를 읽는 동안 Rebalancing이 발생하면 Long Polling이 실패할 수 있음

hashtag
4. Cluster & Replication

  • 고가용성과 장애 복구를 위한 클러스터 구성

  • 구성

    • 하나의 클러스터는 여러 Broker로 구성

    • 데이터는 Replication Factor에 따라 복제

    • Leader Partition : 읽기/쓰기 담당

    • Follower Partition : Leader 복제본 유지

  • 동작 원리

    • Kafka는 고가용성을 위해 여러 Broker로 클러스터를 구성하고, 동일한 데이터를 복제하여 Replication을 유지

    • 리더-팔로워 구조:

      • Leader Partition: 클라이언트의 읽기/쓰기 요청을 처리

      • Follower Partition: Leader Partition을 복제하여 데이터 일관성을 유지

  • 장애 발생 시 시나리오

    • 특정 Broker에 장애 발생 시 Controller가 이를 감지

    • 장애 Broker에 할당된 Leader Partition을 Follower 중 하나로 승격

  • 장애 복구 후, 기존 Follower Partition을 Leader로 교체 가능

🛠️ 참고:

Kafka는 이러한 과정에서 "네가 갖고 있던 리더와 파티션들 뭐야? 니네 팔로워로 바꾸고 이제 올바른 애한테 리더 권한 줄게?"라는 방식으로 클러스터 안정성을 보장한다

NextKafka 메시지 처리 흐름

Last updated