Kafka

[Kafka 입문] 다중 브로커, 레플리카

99duuk 2025. 1. 3. 11:43

카프카의 브로커는 마스터-워커 구조가 아니라 병렬적으로 구성됨.

즉, 모든 브로커는 동등한 수준으로 동작하며, 클러스터 내에서 특정 역할(리더/팔로워)을 파티션 단위로 동적으로 분배함

 

SPRING_KAFKA_BOOTSTRAP_SERVERS: kafka:9092,kafka-2:9092처럼 모든 브로커의 주소를 명시함으로써,

클라이언트(프로듀서/컨슈머)가 클러스터 내 모든 브로커에 연결할 수 있도록 설정하는 것임

 

세부 설명

1. 병렬적 브로커 구성

Kafka 클러스터에서:

  • 모든 브로커는 Zookeeper를 통해 상태를 공유함.
  • 각 브로커는 클러스터의 일부이며, 서로 독립적이지만 협력적으로 작동함
  • 파티션을 기준으로 리더-팔로워 구조가 동작함:
    • 특정 파티션은 하나의 브로커가 "리더" 역할.
    • 나머지 브로커는 "팔로워"로 복제본(replication)을 유지.

2. 클라이언트 연결

SPRING_KAFKA_BOOTSTRAP_SERVERS는 클라이언트(예: Spring Boot 애플리케이션)가 Kafka 클러스터에 연결할 브로커의 초기 진입점(bootstrap) 목록임.

예:

SPRING_KAFKA_BOOTSTRAP_SERVERS: kafka:19092,kafka-2:29092
  • 클라이언트는 지정된 브로커 중 하나에 연결한 뒤, 클러스터 내의 다른 브로커 정보도 자동으로 가져옴
  • 따라서 모든 브로커 주소를 반드시 명시할 필요는 없지만, 최소 하나 이상의 브로커를 명시해야 연결이 가능함.
  • 여러 브로커를 명시하면 연결 실패 시 대체 브로커로 연결 시도가 이루어짐.

3. 리더-팔로워 동작

  • 클러스터 내부에서 특정 파티션의 리더는 특정 브로커가 담당.
  • 예를 들어, 파티션 0은 kafka가 리더로, 파티션 1은 kafka-2가 리더로 설정될 수 있음.
  • 클라이언트는 리더 브로커와 통신하여 데이터를 읽거나 쓰며, 팔로워는 데이터를 복제하여 장애 복구를 대비.

4. 장점

  • 병렬적인 브로커 구조를 통해 부하 분산이 가능.
    • 여러 브로커에 파티션을 분산 배치하여 처리 성능이 향상.
  • 브로커가 다운되더라도 복제본(replication)이 유지되므로 고가용성을 보장.
    • 리더 브로커가 다운되면 팔로워 중 하나가 새로운 리더로 승격.

5. 예시

브로커 파티션 역할

kafka 0 리더
kafka 1 팔로워
kafka-2 0 팔로워
kafka-2 1 리더
  • 클라이언트는 kafka 또는 kafka-2 중 어느 브로커에 연결하든, 적절한 파티션 리더와 통신하게 됨.

결론

Kafka 브로커는 병렬적으로 구성되며, 클러스터 내부의 리더/팔로워 역할은 파티션 단위로 동적으로 분배됨.

SPRING_KAFKA_BOOTSTRAP_SERVERS는 초기 연결 진입점만 제공하며,

클라이언트는 이후 브로커 목록을 자동으로 가져와 적절한 브로커와 통신함.

따라서 여러 브로커를 설정할 경우 모든 브로커를 명시하면 더 안정적인 연결을 확보할 수 있음.

 

 

1. 클러스터의 복제본 수란?

KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR와

KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR는

파티션 복제본(replication)의 수를 설정함.

  • Kafka의 기본 단위는 파티션임. 각 파티션은 리더(Leader)와 팔로워(Follower)로 구성됨.
  • 복제본(replica)은 동일한 데이터를 가진 파티션의 복사본임.
  • 복제본 수가 클러스터에 있는 브로커 수보다 크면 안 됨. 예를 들어, 브로커가 2개일 때 복제본 수를 3으로 설정하면 오류가 발생.

복제본의 역할:

  1. 데이터 가용성: 브로커가 하나 다운되더라도 다른 복제본에서 데이터를 사용할 수 있음.
  2. 장애 복구: 리더 브로커가 다운되면 팔로워 중 하나가 리더로 승격.

설정 예시:

KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 2
KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 2

위 설정은 모든 토픽과 트랜잭션 로그가 최소 두 개의 브로커에 복제된다는 것을 의미.

2. 기존 브로커를 복제한다는 의미인가?

ㄴㄴ 브로커 자체를 복제하지 않음. 대신, 파티션의 데이터를 다른 브로커에 복제함.

 

예를 들어:

  1. 하나의 토픽 my-topic이 있고, 이 토픽이 2개의 파티션(partition-0, partition-1)으로 구성되어 있다고 가정해봄.
  2. 클러스터에 브로커 2개(DI-kafka-1, DI-kafka-2)가 있고, 복제본 수가 2로 설정되어 있다면:
    • partition-0: DI-kafka-1에 리더, DI-kafka-2에 팔로워로 복제.
    • partition-1: DI-kafka-2에 리더, DI-kafka-1에 팔로워로 복제.

3. 다중 브로커 구성의 동작 방식

  • 클러스터에 브로커를 추가하면, Kafka는 파티션 리더와 복제본을 자동으로 분배함.
  • 프로듀서와 컨슈머는 클러스터에 연결하며, Kafka 클라이언트는 Zookeeper(또는 Kafka 자체의 메타데이터)를 통해 리더 브로커를 확인하고 통신.

4. 복제본 수의 장단점

장점:

  1. 가용성 증가: 한 브로커가 다운되더라도 데이터가 손실되지 않음.
  2. 장애 복구 지원: 리더 브로커가 다운되면 다른 복제본에서 새로운 리더가 승격됨.
  3. 데이터 안전성: 데이터가 복제되므로 안정성이 증가함.

단점:

  1. 저장 공간 증가: 복제본 수만큼 추가 저장소가 필요.
  2. 네트워크 부하: 복제본 간 동기화로 인해 네트워크 사용량 증가.

5. 클러스터의 동작 확인

구성을 올바르게 했는지 확인하려면:

  1. Docker Compose로 Kafka 클러스터를 실행.
  2. Kafka CLI 도구를 사용하거나 Conduktor Console 같은 UI 도구로 클러스터 상태를 확인.
  3. 아래 명령어를 사용해 토픽 복제본 상태를 확인: 
    kafka-topics --bootstrap-server kafka:19092 --describe --topic <토픽이름>
    출력 예: 
    Topic: my-topic  PartitionCount: 2  ReplicationFactor: 2
Partition: 0  Leader: 1  Replicas: 1,2  Isr: 1,2
Partition: 1  Leader: 2  Replicas: 1,2  Isr: 1,2

 

긍께..

복제본은 브로커를 복제한다는게 아니라 파티션을 복제..

다중 브로커로 구성된 브로커 수만큼 파티션을 복제해서 같은 데이터를 여러 브로커에 동일한 데이터가 모두 저장..

메인은 해당토픽의 리더 브로커고 장애시 알아서 팔로워 브로커가 승격...

 

복제본(replica)은 브로커를 복제하는 것이 아니라 파티션(partition)을 복제하는 것

1. 파티션 복제란?

  • Kafka 토픽(topic)은 파티션(partition) 단위로 나뉘며, 각각의 파티션이 복제됨.
  • 복제본(replica)은 특정 파티션의 데이터를 동일하게 복사한 사본.
  • 파티션 복제본은 클러스터에 있는 여러 브로커에 분산 저장됨.

2. 복제본이 브로커에 저장되는 방식

  • Kafka는 파티션 복제본을 다른 브로커에 분산하여 저장합니다.
  • 클러스터의 브로커 수와 복제본 수에 따라 동일한 데이터가 여러 브로커에 저장됩니다.
    • 복제본 수는 브로커 수보다 작거나 같아야 합니다.

3. 리더와 팔로워 역할

  • 리더(Leader): 특정 파티션의 모든 읽기/쓰기 요청을 처리.
  • 팔로워(Follower): 리더의 데이터를 복제하여 저장하며, 리더 장애 시 승격될 준비함.

장애 시 동작:

  • 리더 브로커가 다운되면, Kafka는 Zookeeper 또는 Kafka 자체 메타데이터를 통해 팔로워 중 하나를 리더로 승격시킴.
  • 승격된 리더는 계속해서 클라이언트의 요청을 처리함.

4. 동일한 데이터 저장

  • 파티션 복제본은 복제본 수(replication factor)에 따라 여러 브로커에 동일한 데이터를 저장.
  • 복제본 수가 많을수록 데이터 안전성과 가용성이 증가.

리더 브로커가 복제본 데이터를 관리하고, 팔로워 브로커에 데이터를 복제.

1. 기본 데이터 흐름

Kafka 클러스터 구성:

  • 클러스터에는 여러 브로커 (예: DI-kafka-1, DI-kafka-2)
  • 토픽은 하나 이상의 파티션으로 나뉘며, 각 파티션은 하나의 리더와 여러 팔로워 복제본을 가짐.

데이터 쓰기(Producer → Kafka):

  1. 프로듀서(Producer)가 토픽에 데이터를 전송.
  2. 리더(Leader) 파티션이 데이터를 수신.
  3. 리더는 데이터를 저장하고, 동시에 각 팔로워(Follower) 복제본에 데이터를 비동기적으로 복제.
  4. 복제가 완료되면, Kafka는 데이터를 클라이언트에게 정상 저장 완료(ACK)를 반환.

2. 데이터 쓰기 흐름

예를 들어, my-topic의 partition-0 데이터 흐름은 다음과 같음

  • 리더: DI-kafka-1
  • 팔로워: DI-kafka-2
  1. 프로듀서가 my-topic의 partition-0에 데이터를 보냄.
  2. DI-kafka-1(리더)가 데이터를 저장.
  3. 리더가 데이터를 DI-kafka-2(팔로워)에 복제합니다. (비동기적 복제)
  4. DI-kafka-2가 리더의 데이터를 동기화한 후, Kafka는 프로듀서에게 쓰기 완료 알림.

3. 데이터 읽기 흐름

컨슈머(Consumer → Kafka):

  1. 컨슈머는 Kafka에서 특정 토픽의 데이터를 읽음
  2. 컨슈머는 파티션의 리더에서 데이터를 읽음
    • 팔로워는 데이터 읽기 요청을 처리하지 않고, 오직 리더가 처리!
  3. 리더가 데이터를 컨슈머에게 전송

4. 장애 발생 시

리더 장애:

  1. partition-0의 리더인 DI-kafka-1이 다운되었다고 가정.
  2. Zookeeper는 클러스터를 감시하며, 리더가 더 이상 응답하지 않는 것을 감지.
  3. DI-kafka-2(팔로워)가 새로운 리더로 승격.
  4. 이후 컨슈머와 프로듀서는 DI-kafka-2와 통신하며 데이터를 읽고 씀.

5. 요약된 데이터 흐름

  1. 쓰기 요청(Producer → Kafka):
    • 프로듀서 → 리더 → 팔로워(복제).
  2. 읽기 요청(Consumer → Kafka):
    • 컨슈머 → 리더.
  3. 복제(Replication):
    • 리더가 팔로워로 데이터를 복사.

 

쓰기:

      Producer → [Leader: DI-kafka-1] → [Follower: DI-kafka-2]

 

읽기:

      Consumer → [Leader: DI-kafka-1]

 

장애 발생 후:

      Consumer → [New Leader: DI-kafka-2]

 

 

'Kafka' 카테고리의 다른 글

[카프카 입문] 사용 전후 example  (0) 2025.01.07
[Kafka 입문] 토픽, 파티션, 스트림  (1) 2025.01.02
[Kafka 입문] 구성 요소와 역할  (0) 2025.01.02

'Kafka'의 다른글

  • 현재글[Kafka 입문] 다중 브로커, 레플리카

관련글

티스토리툴바