[Kafka 이해] 카프카 심화 개념3

donghyeok·2022년 8월 11일
0

Kafka

목록 보기
6/6

1. Partition Assignment Strategy

Partition Assignment Strategy

  • Consumer의 설정 파라미터 중에서 partition.assignment.strategy로 할당 방식 조정
    1. org.apache.kafka.clients.consumer.RangeAssigner
      • Topic별로 작동하는 Default Assignor
    2. org.apahce.kafka.clients.consumer.RoundRobinAssignor
      • Round Robin 방식으로 Consumer에게 Partition 할당
    3. org.apache.kafka.clients.consumer.StickyAssignor
      • 최대한 많은 기존 Partition 할당을 유지하면서 최대 균형을 이루는 할당을 보장
    4. org.apache.kafka.clients.consumer.CoorperativeStickyAssignor
      • 동일한 StickyAssignor 논리를 따르지만 협력적인 Rebalance를 허용
    5. org.apache.kafka.clients.consumer.ConsumerPartitionAssignor
      - 해당 인터페이스를 구현하면 사용자 지정 할당 전략을 사용할 수 있음.

      Range Assignor

  • Default Assignor
  • 동일한 Key를 가지고 있는 메시지들에 대한 Topic들 간에 co-partitioning하기 유리
    - ex) Delivery ID를 Key로 가지고 있는 delivery_status 메시지와 delivety_location 메시지

    Round Robin Assignor

  • Range 방식보다 효율적으로 분해하여 할당
  • 재할당 후 Consumer가 동일한 Partition을 유지한다고 보장하지 않음 (재할당시 바뀔 수 있음)
  • COnsumer간 Subscribe 해오는 Topic이 다른 경우, 할당 불균형이 발생할 가능성 있음
    - 3개의 Consumer C0, C1, C2와 3개의 Topic T0, T1, T2 가정
    • T0는 partition 1개, T1은 Partition 2개, T2는 Partition 3개 가정
    • C0는 T0만, C1은 T0/T1, C2는 T0/T1/T2 Subscribe한다고 가정

    Sticky Assignor

  • Range방식보다 Rebalancing 오버 헤드를 줄임
  • 가능한한 균형적으로 할당을 보장
    - Consumer 들에게 할당된 Topic Partition의 수는 최대 1만큼 다룸
    - 특정 Consumer A가 다른 Consumer B들에 비해 2개 이상 더 적은 Topic Partition이 할당된 경우, A에 할당된 Topic의 나머지 Partition들은 B에 할당될 수 없음.
  • 재할당이 발생했을 떄, 기존 할당을 최대한 많이 보존하여 유지
    - Topic Partition이 하나의 Consumer에서 다른 Consumer로 이동할 때의 오버헤드를 줄임.

  • Round Robin 방식과 비슷하지만 다른 방식으로 동작
    - 재할당 시, Round Robin은 전체 재할당, Sticky Assignor는 기존 할당 유지하면서 나머지 부분만 재할당
    - 3개의 Consumer C0, C1, C2와 3개의 Topic T0, T1, T2 가정
    - T0은 Partition 1개, T1은 Partition 2개, T2는 Partition 3개 가정
    - C0 는 T0만, C1은 T0/T1, C2는 T0/T1/T2 Subscribe 가정

2. Cooperative Sticky Assignor

Consumer Rebalancing Process

  1. Consumer들이 JoinGroup 요청을 Group Coordinator에 보내면서 리밸런싱 시작
  2. JoinGroup의 응답이 Consumer들에 전송된다 (Group Leader는 Consumer들 정보를 수신)
  3. 모든 구성원은 Broker에 SyncGroup 요청을 보내야한다 (Group Leader는 각 Consumer의 Partition 할당을 계산해서 Group Coordinator에게 전송)
  4. Broker는 SyncGroup 응답에서 각 Consumer별 Partition 할당을 보냄

Eager Rebalancing 프로토콜

  • Eager Rebalancing 프로토콜은 최대한 단순하게 유지하기 위해 만들어짐
  • 각 구성원은 JoinGroup 요청을 보내고 재조정에 참여하기 전에 소유한 모든 Partition을 취소해야함
  • 안전면에서는 좋이만 "Stop-The-World"프로토콜은 그룹 재조정 기간 동안 작업을 수행할 수 없음.

Incremental Cooperative Rebalancing Protocol

  • Revoke할 Partition만 Revoke해줌
  • 이상적인 Consumer Rebalancing 프로토콜
  • Consumer A, B가 Consume하고 있는 상태에서 처리량을 늘이기 위해 Consumer C를 추가한다고 가정
    - Consumer A에 할당된 Partition중 하나만 Consumer C로 이동하는 것이 가장 이상적임
    - 전체 재조정동안 모두 정지해 있는 대신 Consumer A만 하나의 Partition을 취소하는 동안만 가동 중지
    - BUT!! Consumer는 자신의 Partition 중 어느 것이 다른 곳으로 이동해야 하는지 알 수 없음.

Cooperative Sticky Assignor

  • Rebalancing을 두번 수행! (위의 문제 해결)
  • 첫번째 Rebalancing에서 Consumer는 자신의 Partition 중 어느 것이 다른 곳으로 재할당 되어야하는지 인지
  • JoinGroup 요청을 보내면서 시작하지만, 소유한 모든 Partition을 보유하고, 그 정보를 Group Coordinator에게 보냄
  • Group Leader는 원하는 대로 Consumer에 Partition을 할당하지만, 소유권을 이전하는 Partition들만 취소
  • Partition을 취소한 구성원은 그룹에 Rejoin하여 취소된 Partition을 할당할 수 있도록 두번째 재조정을 트리거

0개의 댓글

관련 채용 정보