[Kafka] Kafka Theory (기본 개념)

'Stéphane Maarek - Learn Apache Kafka for Beginners v2'를 보고 작성한 글입니다. 😀

Topic, Partition and Offset

Topic : 특정 데이터 스트림

• 데이터베이스의 테이블과 유사 (제약이 없음)
• 원하는만큼 토픽을 가질 수 있다
• 토픽은 토픽의 이름으로 식별된다 (중복 x)

토픽은 여러 partiton 으로 나누어진다

• 파티션 내의 각 데이터는 offset 이라는 incremental id를 가진다
• 오프셋은 해당 파티션 내에서만 유효하다
  • E.g 파티션 1과 파티션 2의 오프셋은 서로 다르며 같다 하더라도 다른 데이터를 나타낸다
• 토픽의 순서는 파티션 내에서만 보장된다 (파티션 간의 순서는 보장 x)
• 데이터가 파티션에 기록되면 변경할 수 없다 (immutability)

Broker

카프카 클러스터는 여러 브로커(서버)로 구성된다

각 브로커는 ID(integer)로 식별된다

각 브로커는 특정 토픽 파티션을 포함한다

브로커(bootstrap)에 연결하면 전체 클러스터에 연결된다

브로커의 개수는 작으면 3개부터 많으면 100개 이상도 사용한다

예시) Broker = 3, Topic-A = 3 partitions, Topic-B = 2 partitions

Topic - Replication factor

토픽의 replication factor 는 최소 1 이상이다. (보통 2~3)

리플리케이션을 통해 브로커가 다운되더라도 다른 브로커가 데이터를 저장할 수 있다

예시) Broker=3, replication factor=2

Broker 102 가 다운되면 Broker 101, 102 로 운영이 가능

Concept of Leader for a Partition

항상 하나의 파티션만 리더가 될 수 있다

리더 파티션만 데이터를 수신하고 제공한다

다른 파티션들은 리더 파티션과 데이터를 동기화한다

따라서 각 파티션에는 하나의 리더와 여러 ISR (in-sync replica)이 있다

Zookeeper 가 리더와 ISR을 결정한다

브로커 101이 다운되면 브로커 102는 이전에 ISR 이었기 때문에 리더가되고, 브로커 101이 복구되면 브로커 101은 데이터를 복제 한 후 다시 리더가 되려한다

Producer

프로듀서는 토픽에 데이터를 작성한다

프로듀서는 기록할 브로커와 파티션을 자동으로 안다

브로커에 문제가 생기면 프로듀서는 자동으로 복구한다

프로듀서는 토픽에 데이터를 전달할 때 부하를 분산한다 (load balancing)

• key = null 이면 데이터가 라운드 로빈으로 전송된다 (브로커 101, 102, 103 ...)

프로듀서는 데이터에 대한 acknowledgement 를 지정할 수 있다

• acks=0 : 프로듀서는 ack 를 받지 않는다 (데이터 손실 가능성 큼)
• acks=1 : 리더 브로커의 ack 를 기다린다 (데이터 손실 가능성 낮음)
• acks=all : 리더와 레플리케이션의 ack 를 기다린다 (데이터 손실 없음)

Producer - Message Key

프로듀서는 메시지와 함께 key 를 보낼 수 있다

key = null 이면 데이터가 라운드 로빈으로 전송된다 (브로커 101, 102, 103 ...)

key 가 전송되면 해당 key 에 대한 모든 메시지는 항상 동일한 파티션으로 이동합니다.

특정 필드 (예 : truck_id)에 대한 메시지 순서가 필요한 경우 기본적으로 키가 전송됩니다.

Consumer

컨슈머는 topic 으로부터 데이터를 읽는다

컨슈머는 읽을 브로커를 알고 있다

브로커 장애 발생 시, 컨슈머는 복구 방법을 알고 있다

컨슈머는 각 파티션 내에서 데이터를 순서대로 읽는다

컨슈머는 여러 파티션을 읽을 수 있다

Consumer Group

컨슈머는 컨슈머 그룹의 데이터를 읽는다

그룹 내의 각 컨슈머는 자신의 파티션을 통해서만 데이터를 읽는다

GroupCoordinator 및 ConsumerCoordinator 를 통해 컨슈머를 파티션에 할당한다

파티션 보다 컨슈머가 많으면 일부 컨슈머는 비활성화된다

Consumer Offset

카프카에서는 컨슈머 그룹이 읽고 있는 오프셋을 저장한다

커밋(commit)된 오프셋은 __conumer__offsets 이라는 토픽에 저장된다

그룹의 컨슈머가 데이터를 읽을 경우 오프셋을 커밋해야한다

컨슈머가 죽어도 커밋된 오프셋을 통해 중단된 부분부터 다시 데이터를 읽을 수 있다

Delivery semantics for Consumer

컨슈머의 오프셋 커밋 종류

• At most once :
  • 데이터가 수신되는 즉시 오프셋 커밋
  • 처리(프로세싱)가 잘못되면 데이터를 손실 (다시 읽지 않음)
• At least once (usually preferred) :
  • 데이터가 처리된 후 오프셋 커밋
  • 처리(프로세싱)가 잘못되면 데이터를 다시 읽음
  • 데이터를 다시 읽기 때문에 데이터 중복 가능
  • 데이터 중복 방지를 위해 프로세스의 멱등성(idempotent)을 확인 (메시지를 다시 처리해도 영향을 주지 않음)
• Exactly once :
  • Kafka Stream API를 이용하거나 idempotent consumer를 이용해야 한다

Kafka Broker Discovery

모든 Kafka 브로커는 "bootstrap server"라고도 한다.

즉, 하나의 브로커에만 연결하면 전체 클러스터에 연결된다.

각 브로커는 모든 브로커, 토픽 및 파티션 (metadata)에 대해 알고 있다

Zookeeper

Zookeeper는 브로커를 관리한다

Zookeeper는 파티션의 리더 선택을 돕는다

Zookeeper는 변경사항에 대해 Kafka에 알림을 보낸다 (예 : 새로운 토픽, 브로커 다운, 새로운 브로커, 토픽 삭제 등)

Kafka는 Zookeeper 없이는 작동하지 않는다

Zookeeper는 홀수 수의 서버 (3,5,7)로 작동하도록 설계되었다

Zookeeper는 하나의 리더(쓰기 담당) 서버와 , 나머지 팔로워 (읽기 담당)서버가 있다

컨슈머의 오프셋은 Zookeeper가 아닌 Kafka 토픽에 저장된다

Kafka Guarantees

데이터는 전송 된 순서대로 토픽 파티션에 추가된다

컨슈머는 토픽의 파티션에 저장된 순서대로 데이터를 읽는다

replication factor 를 N개로 하면 프로듀서와 컨슈머는 최대 N-1개의 브로커가 다운되는 것을 허용 할 수 있다

replication factor 3의 장점

• 유지 보수를 위해 하나의 브로커를 중단 할 수 있다
• 다른 브로커가 예기치 않게 중단되도 문제가 되지 않는다
• 한 토픽에 대해 파티션 수가 일정하게 유지되는 한 (파티션 추가 없을 때) 동일한 키에 대한 데이터는 동일한 파티션에 저장된다

요약

---

References

• Stéphane Maarek - Learn Apache Kafka for Beginners v2

---

🏋🏻 개인적으로 공부한 내용을 기록하고 있습니다.
잘못된 부분이 있다면 과감하게 지적해주세요!! 🏋