4 분 소요

[kafka]kafka 프로듀서, 브로커 동작원리

kafka 란?! (broker,producer,consumer)

1. Kafka 아키텍처

1.1 기본 구성 요소

  • Kafka는 분산 스트리밍 플랫폼으로, 실시간 로그 수집, 처리, 저장에 특화됨

image (16)

  • Producer: 데이터를 Kafka에 전송 (push작업)
  • Broker: 메시지를 저장하는 서버
  • Consumer: 메시지를 구독하여 처리 (poll작업)

  • image (17)

  • Zookeeper: (Kafka 3.x 이하) 클러스터 메타데이터와 Broker 상태 관리

    • 일종의 공유 저장소 Zookeeper를 사용하여 데이터를 저장하는 모든 대상은 Zookeeper입장에서 Client이며 Client는 자기 상태 정보등을 저장할 수 있음 (ZookeeperClient=KafkaBroker) 또한 Zookeeper를 사용하는 Client들은 다른 Client노드 Alive여부를 알 수 있고 (watch기능) Client중 Leader를 선출할 수 있는 기능이 있어 클러스터 환경에서 가용성 확보를 위해 주로 사용

    image (18)

    web ui에서도 확인 가능

1.2 토픽과 파티션

image (19)

  • Kafka에서 데이터는 Topic 단위로 저장됨

  • 각 토픽은 1개 이상의 Partition으로 구성됨 → 분산 저장 가능

    • topic 생성

      image (21)

      image (22)

      모든 파티션은 원래 Leader가 되어야 할 브로커가 지정되어 있으며 이를 Preferred Leader라 부름 (=Replias의 첫 번째 브로커 번호)

      image (23)

  • 파티션은 데이터가 실제 저장되는 단위이며, 메시지는 한 파티션에만 저장됨

  • 각 파티션은 Offset 기반으로 메시지를 저장하며, Consumer는 이 Offset으로 메시지를 조회

image (24)

1.3 복제본 (Replication)

image (25)

  • 각 파티션은 복제본(replica) 을 가질 수 있음
  • 복제본에는 Leader와 Follower가 있으며, 실제 메시지 송수신은 Leader가 담당함
  • Follower는 Leader를 polling 하여 데이터를 동기화함
  • Leader 장애 시 Follower 중 하나가 Leader로 승격됨

image (26)

즉 팔로워 파티션은 오로지 리더로부터 메시지 받아와(polling) 동기화만 수행함 (리더가 Down되면 리더로 승격 가능)

그렇다면 적당한 파티션 개수는?

브로커가 3대라면 파티션 3개가 가장 좋을까? → 그건 아님 브로커가 3대라도 파티션은 6개 혹은 12개 등 더 늘릴수록 Producer,Consumer의 성능은 증가할 수 있음 (특히 Consumer의 성능)

  • 토픽 생성 후 파티션 개수 변경시 증가는 가능하나,감소는 불가능

2. Broker 옵션

Kafka의 broker는 설정 파일 (server.properties) 을 통해 다양한 설정 가능

2.1 어떤 옵션들이 있냐

Kafka Topic Configuration Reference
https://docs.confluent.io/platform/current/installation/configuration/topic-configs.html

Kafka의 브로커 설정 항목에 대한 공식 문서입니다.

토픽 생성 및 삭제

  • auto.create.topics.enable: Producer나 Consumer가 없는 토픽에 접근시 자동 생성을 허용할지 여부 (기본값 false)
  • delete.topic.enable: 토픽 삭제를 가능하게 할 것인지 여부.(기본값 true) (false설정 후 삭제시 실제 삭제는 안되나 leaderunavailable상태로 표시되어 사용 불가)

파티션 및 리더 관리

  • num.partitions: 토픽 생성 시 default 파티션 개수 (기본 1)

  • min.insync.replicas: producer가 acks=all 전송시 리턴을 위해 만족되어야 할 동기화된 복제본의 개수 (기본 1)

  • auto.leader.rebalance.enable: 리더가 불균형할 경우 자동 조정 여부 (기본 true)

    image (27)

    • leader.imbalance.check.interval.seconds: 리더 불균형 점검 주기 (기본 300초)
    • leader.imbalance.per.broker.percentage: 리더 불균형 허용 퍼센트 (기본 10%)

세그먼트 관리 (레코드가 실제 저장되는 파일)

  • log.dirs : 로컬 파일시스템에 저장할 로그 세그먼트의 위치 (기본값 /tmp/kafkalogs )

  • log.segment.bytes: 로그 세그먼트 하나의 최대 크기 (기본 1GB)

  • log.retention.[ms/minutes/hours]: log.cleanup.policy=delete일 때 레코드 삭제를 위한 보관 기준 일수 (.hours와 .mintues 와 .ms 모두 적용시 log.retention.ms가 우선 적용됨) (기본값 7일)

  • log.cleanup.policy

    : 로컬 파일시스템에 저장된 메시지 데이터의 삭제 정책 (기본값 delete)

    • delete: retentiontime지난 레코드 삭제 (세그먼트 단위 삭제)
    • compact: key별 가장 마지막 value값만 남기고 삭제

스레드 관리

  • num.io.threads : KafkaBroker가 DiskI/O에 사용할 쓰레드 개수 (Disk개수 *8을 권장), (기본값 8)
  • num.network.threads: Broker 서버가 요청받거나 리턴할 때 쓰이는 쓰레드 개수 (기본값 3)
  • background.threads: 로그 삭제 등 내부 job처리를 위해 사용되는 백그라운드 쓰레드 수. (특별한 이유가 없으면 default(10)설정 권고)

레코드 관리

  • message.max.bytes : Producer/Consumer가 전송/수신할 수 있는 단일 Record의 최대 크기
  • fetch.max.bytes : Consumer의 Fetch요청에 한번에 return할 수 있는 크기
  • replica.fetch.max.bytes : 브로커간 메시지 복제를 위해 허용할 수 있는 fetch요청 최대 크기

3. Topic 옵션

Kafka Topic Configuration Reference
https://docs.confluent.io/platform/current/installation/configuration/topic-configs.html

Kafka의 토픽 설정 항목에 대한 공식 문서입니다.

3.1 메시지 저장 정책

  • cleanup.policy: 메시지 삭제 정책
    • delete: 일정 기간이 지나면 세그먼트 단위 삭제
    • compact: 같은 key에 대해 마지막 value만 남기고 나머지 삭제
  • retention.ms: cleanup.policy=delete일 때 레코드 삭제를 위한 보관 일 수 기준 (기본값 7일)
  • retention.bytes: cleanup.policy=delete일 때 레코드 삭제를 위한 파티션 크기 기준. 이 파라미터 값의 크기를 초과할 때 삭제
  • segment.bytes: 로컬 파일시스템에 저장되는 로그 세그먼트당 최대 크기 (기본 1GB)
  • segment.ms : 현재 active로그 세그먼트가 segment.bytes에 도달하지 않아도 새 세그먼트로 분리될 수 있는 시간 기준
  • max.message.bytes: 하나의 메시지 최대 크기 (기본 1MB)
  • image (28)

3.2 압축 설정

  • compression.type

    : 메시지 압축 유형 설정 (gzip, snappy, lz4, zstd, none)

    • Producer 설정이 우선되며, Broker나 Topic 수준에서 설정 가능
    • 컨플루언트 카프카에서는 lz4 로 압축하기를 적극 추천

4. Producer 메커니즘과 성능

Producer의 동기 전송 vs비동기 전송

  • producer 메시지 전송시 동기전송 방식과 비동기 전송 방식을 선택할 수 있음
  • 일반적으로 Producer의 성능 향상을 위해 비동기 전송 방식을 채택

image (29)

4.1 기본 흐름

image (30)

파이썬에서는 Accumulator가 큐라고 생각하면 됩니두

  1. 메시지 생성 (send 호출)
  2. 직렬화 (Serializer)
  3. 파티셔너 결정
  4. 파티션별 Accumulator에 저장 (메모리 버퍼)
  5. 배치 전송 조건 만족 시 브로커로 전송

4.2 파티셔너 동작 방식

  • Key 존재 시: murmur2 해시 알고리즘 기반으로 파티션 결정

    image (31)

  • Key 없음:

    • Kafka 2.3 이하: 라운드 로빈 방식

      image (32)

      • Kafka는 성능 향상을 위해 Accumulator에 레코드를 모았다가 전송하는 배치 전송이 기본 전송 방식 임. 따라서 Accumulator에 레코드가 들어왔다고 해서 즉시 전송되는 것이 아니라 어느 정도 차거나 시간이 어느 정도 지날때 까지 잠시 대기함. • 그런데 라운드 로빈 방식은 파티션을 골고루 채우다보니 개별 파티션이 꽉 찰 때까지 시간이 소요되는 단점 존재(지연 증가) • 이를 개선하기 위해 ApacheKafka2.4에 UniformSticky방식이 도입됨.

    • Kafka 2.4 이상: Uniform Sticky 방식 (스티키 방식은 랜덤하게 파티션을 하나 선택하여 먼저 채워나가는 방식)

    image (33)

4.3 배치 전송 기준

  • batch.size: Accumulator에 쌓이는 최대 바이트 (버스의 크기느낌)

  • linger.ms

    : 시간이 지나면 쌓인 만큼만 전송 (배치 전송 지연시간) (버스의 최대 대기시간 느낌)

    • (0으로 설정하더라도 어느정도 배치가 모인 후 전송함)
  • buffer.memory: 전체 Accumulator 메모리 크기 (기본 32MB)

image (34)

4.4 전송 보장

image (35)

  • acks=0: 브로커 응답 안 받음 (가장 빠르지만 안전성 없음)
  • acks=1: Leader에 쓰기만 되면 OK
  • acks=all: 모든 ISR에 복제되면 OK (가장 안전함)

5. Producer 유용한 옵션

5.1 압축 옵션

  • compression.type

    : none, gzip, snappy, lz4, zstd

    • lz4 권장 (압축비율 높고 속도 빠름)

5.2 재시도 및 오류 옵션

  • retries: 재시도 횟수 (기본 무한)
  • retry.backoff.ms: 재시도 대기 시간 (100ms)
  • max.block.ms: Accumulator가 다 찼을 때 대기 시간

5.3 전송 지연 및 배치

  • batch.size, linger.ms, buffer.memory
  • max.in.flight.requests.per.connection: 병렬 요청 수 제한
  • delivery.timeout.ms: 전체 전송 타임아웃

댓글남기기

참고