[Kafka] Kafka의 기본 요소 및 개념

토픽(topic)

정의 및 특징

• 데이터를 분류하고 저장하기 위한 기본 단위
  • 메시지를 pub/sub 할 수 있는 논리적 채널
• kafka 클러스터 안에 있는 데이터 스트림
  • db의 테이블과 개념 유사
• topic은 Producer가 데이터를 전송하고, Conusumer가 데이터를 읽는 단위
• 하나의 Kafka 클러스터에서 다수의 topic 을 생성할 수 있음.
• 각 topic 은 partition 으로 분리되어 데이터를 분산 저장함

---

파티션(partition)

정의 및 특징

• Kafka 토픽을 물리적으로 나눈 단위
• 병렬 처리 및 분산 처리 하기 위해 사용됨
• 각 파티션은 하나의 순서를 가지고 데이터가 특정 순서대로 기록됨

---

오프셋(offset)

정의 및 특징

• Kafka 파티션 내에서 메시지가 저장된 위치를 나타내는 고유한정수 값
  • 각 파티션마다 오프셋은 독립적이다
• 순차적인 번호이며, 컨슈머는 오프셋을 기반으로 메시지를 읽은 위치를 추정함.

---

프로듀서 (Producer)

정의 및 특징

• 메시지를 생성하여 Kafka 브로커로 전송하는 클라이언트
• 애플리케이션에서 생성된 데이터를 Kafka의 특정 토픽에 게시함
• 메시지를 partition 및 offset 기반으로 관리하여, 메시지 전송 시 신뢰성, 속도, 순서 등 고려
• TOPIC 뿐만 아니라 partition도 지정가능
  • 파티션 선택 방식
  1. Key 해싱 라우팅
     • 메시지의 고정된 순서를 보장하기 위해 사용
       • 고정된 순서를 위해서 동기 전송, acks=all 로 설정하여 메시지가 리더와 팔로워 브로커에 모두 복제 될 때까지 대기
  2. 라운드로빈 : Key가 없을 경우 균등하게 분배
  3. 사용자 정의

---

acks

Producer 가 메시지를 전송할 때, Kafka 브로커로부터의 응답 방식

 

1. acks=0

• 설명: Producer는 메시지를 브로커로 전송한 후, 브로커로부터 응답을 기다리지 않습니다. 즉, 브로커가 메시지를 정상적으로 수신했는지 확인하지 않고, 바로 다음 작업을 수행.
•  
• 장점:
  • 가장 빠른 전송 방식입니다. 응답을 기다리지 않으므로, 저지연(low latency)을 요구하는 환경에서 성능이 매우 중요할 때 유리.
• 단점:
  • 메시지가 브로커에 제대로 저장되지 않았더라도 Producer는 성공적으로 전송했다고 판단하고, 이로 인해 데이터 손실이 발생할 수 있습니다. 예를 들어, 브로커가 장애를 겪고 있을 때 메시지가 유실될 가능성이 있음.

 

2. acks=1

• 설명: Producer는 메시지를 브로커로 전송한 후, 리더 브로커로부터 응답을 기다림.
• 리더는 메시지를 수신한 후 바로 ACK를 보내므로, 브로커가 메시지를 저장한 후 응답을 보내며, 리더가 데이터를 디스크에 기록하고 난 후 응답을 보낼 수 있지만, 팔로워 브로커에게는 아직 복제되지 않았을 수 있다.
• 장점:
  • 빠른 성능을 유지하면서 어느 정도의 데이터 내구성도 보장. 리더 브로커가 메시지를 받으면 응답을 보내므로, 일정 부분 내구성이 보장.
  • 상대적으로 낮은 지연 시간과 높은 처리량을 유지 가능.
• 단점:
  • 리더가 메시지를 받았더라도, 팔로워에게 복제되지 않은 상태에서 장애가 발생할 경우 데이터 손실이 발생할 수 있음.
  • 리더 브로커의 장애가 발생하면 데이터 손실이 발생할 위험이 있음.

 

3. acks=all (또는 acks=-1)

• 설명: Producer는 메시지를 전송한 후, 모든 ISR(In-Sync Replica) 브로커가 데이터를 복제한 후 응답을 보낼 때까지 기다림.
• 즉, 리더뿐만 아니라 모든 팔로워 브로커가 데이터를 복제하고 난 후에만 ACK를 받고, 이는 메시지가 완전히 복제되어 클러스터의 모든 정상적인 브로커에 데이터가 저장되었음을 보장.
• 장점:
  • 최고의 내구성을 제공합니다. 메시지가 클러스터 내 모든 브로커에 복제되므로, 리더 브로커에 장애가 발생해도 팔로워 브로커에서 데이터를 복구 가능.
  • 데이터 손실을 완전히 방지하고, 높은 신뢰성을 보장.
• 단점:
  • 지연 시간이 길어질 수 있고. 메시지가 모든 ISR에 복제될 때까지 기다려야 하므로 성능이 떨어질 수 있음.
    • 이로 인해 고성능을 요구하는 시스템에서는 부하가 있음.
  • 클러스터에 복제 지연이 있을 경우, 응답 시간이 느려질 수 있음.

 

ack 비교 요약

acks 값	응답을 기다리는 브로커	내구성	성능
acks=0	없음	낮음	매우 높음
acks=1	리더 브로커	중간	높음
acks=all	리더 + 모든 ISR	매우 높음	낮음

 

---

Kafka 메시지 기본 구조

1. Key
   • 메시지의 파티션을 결정하는 데 사용
   • 데이터 카테고리와 같이 특정 파티션으로 데이터를 라우팅할 떄 유용
2. Value
   • 메시지의 실제 데이터
   • Json, 문자열 등 기타 직렬화된 데이터
   • Value는 nullable 함
3. Compression Type
   • 메시지를 압축하여 효율성을 높일 수 있음
   • gzip, zstd 등을 지원
4. Headers (Optional)
   • KEY-VALUE 형태로 메타데이터 추가 가능
5. Partition + Offset
   • 메시지가 저장될 파티션과 파티션 내 고유 위치 지정
6. Timestamp
   • 메시지 생성 시점의 타임스탬프

---

컨슈머 (Consumer)

정의 및 특징

• Kafka 브로커로부터 토픽의 데이터를 읽고 처리하는 역할을 담당하는 애플리케이션 또는 클라이언트

---

Consumer 그룹

• 컨슈머의 논리적인 묶음으로, 동일한 컨슈머 그룹에 속한 컨슈머들이 하나의 토픽에서 병렬로 데이터를 소비함.
• 서로 다른 컨슈머 그룹은 동일한 토픽에서 독립적으로 데이터 처리가 가능함
  • 주문 이벤트" 토픽에서, 한 컨슈머 그룹은 실시간 알림 처리에 사용되고, 다른 그룹은 데이터 분석에 사용
• 하나의 컨슈머는 하나 이상의 파티션을 할당받아 데이터를 읽고, 하나의 파티션은 동시에 하나의 컨슈머에게만 할당됨

---

Consumer 오프셋

• 컨슈머가 특정 파티션에서 데이터를 읽은 마지막 위치

오프셋 관리

• 컨슈머는 읽은 오프셋 정보를 kafka 의 내부 토픽 ( __consumer_offsets ) 에 저장함.

1. 자동커밋
2. 수동커밋

위의 두 가지 방식이 있고, 장애 복구 시에 활용된다.

---

redhat의 kafka cluster 이미지

 

파티션 개수와 컨슈머 개수의 관계

기본 원칙

1. 파티션 ≥ 컨슈머:
   • 한 컨슈머는 하나 이상의 파티션을 할당받아 처리 가능.
   • 파티션이 컨슈머보다 많으면, 일부 컨슈머가 여러 파티션을 처리.
2. 파티션 < 컨슈머:
   • 컨슈머 그룹 내 일부 컨슈머는 파티션을 할당받지 못하고 대기 상태가 됨
   • 효율적이지 않으므로, 컨슈머 그룹의 컨슈머 수는 파티션 수를 초과하지 않는 것이 좋음.

 

파티션-컨슈머 할당 예시:

• 토픽 A: 4개의 파티션
  • 컨슈머 그룹 1 (2명의 컨슈머):
    • 컨슈머 1: 파티션 0, 1
    • 컨슈머 2: 파티션 2, 3
  • 컨슈머 그룹 2 (4명의 컨슈머):
    • 각 컨슈머가 한 파티션씩 처리 (0, 1, 2, 3).
  • 컨슈머 그룹 3 (5명의 컨슈머):
    • 1명은 파티션을 할당받지 못하고 대기.

 

컨슈머와 파티션의 관계 공식:

• 최대 병렬 처리 단위 = 파티션 수
  컨슈머를 늘리더라도 파티션 수가 병렬 처리의 한계를 결정함.

---

Broker

정의 및 특징

• 데이터를 저장하고, 클라이언트로부터 오는 요청을 처리하는 서버
• Kafka 클러스터는 여러 개의 Broker로 구성될 수 있음
• 각 Broker는 서로 다른 데이터를 관리하며, 데이터를 특정 방식으로 분배 및 복제함

---

클러스터에서의 Broker의 관계

• Broker 들은 상호 협력하여 데이터를 분산 처리하고, 장애 발생 시 데이터를 복제하여 데이터의 가용성을 유지

리더와 팔로워

• 각 파티션은 리더를 가지고 있고, 그 외의 다른 Broker들은 팔로워로 존재함.
  • 팔로워를 ISR(In-Sync-Replica) 로 부름.
• 리더는 해당 파티션에 대한 읽기/쓰기 작업을 처리하며, 팔로워들은 리더의 데이터를 복제하여 장애가 발생했을 때 데이터를 잃지 않도록 함.
• 만약 리더 Broker에 장애가 발생하면, Kafka는 자동으로 다른 팔로워를 리더로 승격시키며 서비스 연속성 보장
• Broker는 하나의 파티션에 대해 리더이면서, 동시에 다른 파티션에 대해 팔로워 역할도 될 수 있음.
• Producer 는 리더인 Broker 에게만 데이터를 전송가능
• CQRS 패턴식으로 쓰기는 리더에게 읽기는 팔로워에게 가능하며 이때는 복제 지연을 고려해야함