ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Kafka] Kafka Rebalance Protocol 알아보기 ( JoinGroup, LeaveGroup )
    Kafka 2024. 2. 4. 07:53
    728x90
    반응형

    - 목차

     

    Rebalance 란 무엇일까요?

    먼저 Rabalance 를 어휘적으로 살펴볼려고 합니다.

    Rebalance 는 Unbalance 인 상태를 해결하는 행위입니다.

    Partition 과 Consumer 사이의 관계가 Unbalance 상태가 될 수 있습니다.

    Unbalance 의 원인 제공이 Partition 일 수도 있고, Consumer 일 수도 있겠죠 ?

    Partition 의 갯수가 늘어나거나, 어떤 Consumer 가 먹통이 될 수 있죠.

    이러한 경우에 Partition 과 Consumer 사이의 적절한 매칭 관계에 문제가 발생하고 이러한 상태가 Unbalance 상태입니다.

    그리고 Kafka Broker ( 특히, Group Coordinator ) 는 Unbalance 를 감지하여 Rebalance 를 트리거하게 됩니다.

    Rebalace 라는 행위를 통해서 Partition 과 Consumer 는 새롭게 매칭됩니다.

     

    Rebalance 는 언제 발생할까요 ?

    아래 페이지는 Rebalance 의 조건을 살펴본 여러 실험들이 기록되어 있습니다.

    https://westlife0615.tistory.com/653#27

     

    [Kafka] Rebalance 가 발생하는 경우들 알아보기 ( Rebalance Scenario )

    - 목차 들어가며. 이번 글에서는 Rebalance 가 발생하는 여러가지 경우들에 대해서 자세히 알아보려고 합니다. 사용하게 될 Consumer 예제 코드는 아래와 같습니다. kafka-clients 2.8.1 모듈을 사용하였구

    westlife0615.tistory.com

     

    Rebalance 는 Partition 과 Consumer 사이의 Unbalance 상태를 해결하는 행위입니다.

    그래서 Rebalance 가 발생하는 조건은 Unbalance 상태의 Partition 과 Consumer 입니다.

    Broker 의 관점에서 Partition 의 갯수가 늘어나는 경우에 Rebalance 가 발생하게 됩니다.

    왜냐하면 새로운 Partition 을 Consume 할 Client 가 필요하기 때문이죠.

    그리고 Consumer 의 관점에서는 단순히 Consumer 에 문제가 발생하는 경우, 특히 먹통이 되는 Consumer 에 의해서 발생합니다.

    Consumer 는 내부적으로 Record 를 Polling 하고 Heartbeat 를 전달해야하는 의무가 있습니다.

    정해진 주기 내에서 Polling 또는 Heartbeat 행위를 수행하지 않으면 Group Coordinator 인 Broker 는 Rebalance 를 트리거합니다.

     

     

     

    들어가며.

    Kafka 의 Rebalance 는 Partition 과 Consumer 간의 Unbalaced 상태를 해결하는 방식을 의미합니다.

    데이터 처리 관점에서 바라볼 때에 Topic 의 Partition 은 방대한 양의 데이터입니다.

    그리고 Consumer 는 Partition 에 쌓인 방대한 데이터를 처리해야한 데이터 처리 어플리케이션입니다.

    즉, Consumer 는 Partition 에 쌓인 데이터를 하나씩 하나씩 처리해야하는 입장이죠.

    이러한 데이터 처리를 효율적으로 수행하기 위해서 Partition 과 Consumer 를 1 대 1로 매칭시켜서

    데이터 처리 워크로드 또는 트래픽을 Balanced 한 상태로 만들어야합니다.

    만약 Consumer 가 추가되거나 혹은 일시적으로 종료되거나, Partition 이 추가되거나 삭제되어 Unbalanced 상태가 된다면,

    Rebalance 과정이 필요합니다.

    그리고 이러한 Rebalance 는 자동적으로 발생합니다.

     

    < Consumer 가 추가되거나 삭제될 때 >

     

     

    < Partition 이 추가되거나 삭제될 때 >

     

     

     

    Rebalance Protocol.

     

    FindCoordinator.

    Kafka Consumer 는 bootstrap.servers 설정을 통해서 브로커들의 IP 와 Listening Port 를 알 수 있습니다.

    그리고 자신이 속한 Consumer Group 의 Group Coordinator 를 찾습니다.

     

    잠시 Group Coordinator 에 대해서 설명을 하자면,

    Group Coordinator 는 카프카 브로커 중의 하나입니다.

    Group Coordinator 로 선택된 브로커는 브로커로써 역할 뿐만 아니라 Group Coordinator 의 역할 또한 수행하게 됩니다.

    Group Coordinator 는 Kafka Consumer Group 을 관리하는 특별한 Broker 이구요.

    Consumer Group 마다 Group Coordinator 에 해당하는 Broker 는 달라집니다.

    그래서 Consumer Group 이 많아지면, 하나의 Broker 가 여러 Consumer Group 을 관리하게 됩니다.

     

    다시 돌아와서,

    Consumer Group 과 관련된 처리는 Group Coordinator 가 수행하게 되구요.

    Group Coordinator 는 Consumer Group 생성, Rebalance 등의 처리를 수행합니다.

    그래서 FindCoordinator 단계에서 자신이 속한 Consumer Group 의 Coordinator 를 찾고,

    이 Group Coordinator 와 Consumer 는 소통을 수행합니다.

     

     

    JoinGroup.

    JoinGroup 은 Consumer 가 Group Coordinator 에게 Rebalance 를 위해서 전달하는 첫번째 요청입니다.

    자신이 어떤 Consumer 인지 Group Coordinator 에게 알려주는 과정인데요.

    Consumer Configuration 이 전달됩니다.

     

    "group.id : test-group" => "나는 test-group 이라는 Consumer Group 에 속하는 Consumer 입니다."

    "heartbeat.interval.ms : 50000" => "나는 5초에 한번씩 Heartbeat 를 전송할게요."

    "session.timeout.ms : 150000" => "만약 제가 15초 동안 Heartbeat 를 전송하지 않는다면 저에게 어떤 문제가 생긴겁니다. "

     

    이런 느낌의 메시지를 담아서 Group Coordinator 에게 JoinGroup 요청을 전달하게 됩니다.

    Group Coordinator 는 group.initial.rebalance.delay.ms 로 설정된 시간까지 Consumer 들로부터 JoinGroup 요청을 받습니다.

    일종의 제출 마감 기간입니다.

    group.initial.rebalance.delay.ms 까지 요청된 JoinGroup 데이터를 토대로 Consumer Group 을 구성합니다.

     

    이 과정에서 첫번째로 JoinGroup 요청을 보낸 Consumer 가 Group Leader 가 되구요.

    Group Leader 는 Partition - Consumer 간의 Ownership 을 결정합니다.

    Group Leader 가 Partition - Consumer Ownership 을 결정할 수 있도록

    Group Coordinator 는 Group Leader 에게 Partition 과 Consumer 들에 대한 정보를 제공합니다.

     

    ( 카프카에서는 많은 권한을 Client 에게 이관하는 전략을 취합니다. 그래서 Partition Ownership 의 결정 권한은 Group Leader 에게 있습니다. )

     

     

    SyncGroup.

     

    Consumer 들은 JoinGroup 요청 이후에 SyncGroup 요청을 보냅니다.

    SyncGroup 은 Partition 과 Consumer 의 Ownership 을 Group Coordinator 에게 전달하는 과정입니다.

    Group Leader 는 JoinGroup 의 Response 로써 전달받은 Consumer 와 Partition 정보를 기반으로 Ownership 을 결정합니다.

    즉, A Consumer 는 1번 Partition 을 처리하고 B Consumer 는 2번 Partition 을 처리하도록 Ownership 을 결정합니다.

    그리고 이러한 Ownership 의 정보를 Group Coordinator 에게 전달합니다.

     

    아래 그림처럼 Group Leader 인 Consumer 1 은 Group Coordinator 에게 Partition - Consumer 의 매핑 정보를 전달합니다.

    그리고 Group Leader 가 결정한 Partition - Consumer 매핑 정보를 기반으로 Group Coordinator 는 Consumer 들에게 Fetching 할 Partition 를 제공합니다.

     

     

     

     

    반응형
Designed by Tistory.