Zayson
A to Zayson!
Zayson
전체 방문자
오늘
어제
  • 분류 전체보기 (132)
    • Computer Science (20)
      • Network (4)
      • DB (12)
      • OS (4)
    • Algorithm (32)
      • 완전탐색(Brute-Force) (3)
      • 그리디(Greedy) (6)
      • 투포인터(Two-Pointer) (1)
      • 그래프(Graph) (5)
      • BFS & DFS (9)
      • 구현, 시뮬레이션(Implementation) (5)
      • 다이나믹 프로그래밍(DP) (3)
    • Backend (51)
      • Spring Boot (19)
      • JPA (16)
      • Kafka (2)
      • Java (13)
      • Kotlin (1)
    • DevOps (1)
      • Jenkins (5)
      • Oracle Cloud Infrastructure (1)
      • Kubernetes & Docker (1)
    • Trouble Shooting (3)
      • JPA (1)
      • Spring Boot (2)
    • 회고 (5)
      • 엔빵 프로젝트 포스트 로드맵 (1)
      • 2022년 (4)
    • Kafka (7)
      • Kafka (5)
      • Kafka Connect (2)
    • 기술 서적 (6)
      • 데이터 중심 애플리케이션 설계 (3)
      • 개발자가 반드시 정복해야할 객체 지향과 디자인 패턴 (2)
      • 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (1)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

인기 글

태그

  • 엔빵프로젝트
  • SpringBoot
  • 나 혼자 스프링부트!
  • BFS
  • JPA
  • Computer science
  • 그리디
  • CS
  • 관계형 데이터베이스 실전 입문
  • Java
  • spring boot
  • 구현
  • dfs
  • Kafka Connect
  • 백준
  • 라이브스터디
  • 프로그래머스
  • kafka
  • Backend
  • 완전탐색

최근 글

티스토리

hELLO · Designed By 정상우.
Zayson

A to Zayson!

Kafka: Static Membership
Kafka/Kafka

Kafka: Static Membership

2024. 11. 3. 17:35

서론


Kafka Consumer는 여러 가지 이벤트를 통해 리밸런싱이 발생한다.

  • Consumer ↔ GroupCoordinator 간 session.timeout.ms 내에 Heartbeat가 수신되지 않은 경우
  • Consumer가 Consumer Group을 나가거나 들어오는 경우
  • Consumer Group이 구독하는 토픽의 파티션이 추가되는 경우 등

Consumer는 리밸런싱이 시작되면 완료되기 전까지 데이터를 처리하지 못한다. 이로 인해 데이터 처리가 일시 중단되며 지연이 발생한다.

또한, 리밸런싱 과정에서 파티션을 Revoke/Assign 하는 과정에서 네트워크 부하 등으로 인한 클러스터 성능 저하가 발생한다.

 

Kafka 2.3.0부터는 이러한 리밸런싱의 단점을 보완하기 위해 Static Membership이라는 메커니즘이 도입되었다.

Consumer Group Membership Strategy


Kafka의 Consumer Group Membership에는 다음 2가지 방식이 있다.

  1. Dynamic Membership
  2. Static Membership

 

Static Membership은 리밸런싱 횟수를 줄이고자 KIP-345에서 제안되어 Kafka 2.3.0에 도입됐다.

Dynamic Membership

Consumer Group에 속한 각 Consumer는 member.id라는 고유 ID를 부여받는다.

Dynamic Membership 에서는 각 Consumer가 Consumer Group에 참여할 때마다 새로운 member.id가 발급된다.

따라서, GroupCoordinator는 Consumer Group에 새로 참여하는 모든 Consumer를 새로운 Consumer로 인식하게 된다.

 

예를 들어, Consumer Group에 속한 특정 Consumer에게 잠깐의 순단이 발생했다고 가정해보자.

Consumer는 고유한 멤버 ID를 갖고 있으며, con-1, con-2, con-3의 ID를 가진 상태라고 하자.

con-1이 Consumer Group을 탈퇴하면 LeaveGroup에 따른 리밸런싱이 발생한다.

이 때, con-1이 처리하던 토픽 파티션은 revoke되고, 다른 Consumer에게 assign된다.

[그림1] LeaveGroup으로 인한 리밸런싱 발생 / [그림2] Revoke된 토픽 파티션은 새로운 Consumer에게 Assign

 

Consumer가 다시 Consumer Group에 들어오기 위해 요청한다.

GroupCoordinator는 이를 새로운 Consumer로 인식해 con-A라는 새로운 member.id를 발급한다.

 

새로운 member.id 를 발급받아 Consumer Group 재가입

 

con-A는 Consumer Group에 들어오고 새로운 토픽 파티션을 할당받는다.

새로운 토픽 파티션을 Assign

 

잠깐의 순단으로 인해서 2번의 리밸런싱이 발생했다.

그림으로는 간단해보이지만, Consumer A → B로 토픽 파티션을 리밸런싱하는 작업은 많은 양의 데이터 전송이 필요하다.

Static Membership

Static Membership에서는 GroupCoordinator가 특정 Consumer가 기존에 Consumer Group에 속해 있었던 Consumer임을 인식하도록 설계된다.

 

이를 위해 각 Consumer는 고유한 group.instance.id를 설정해줘야 하며, 이 설정을 통해 Static Membership을 사용할 수 있다.

# Consumer 1
props.put("group.instance.id", "con-1");

 

Dynamic Membership에서 사용한 예시로 Static Membership을 적용했을 땐 어떻게 동작하는지 확인해보자.

 

con-1이 Consumer Group을 탈퇴한다.

이 때, con-1은 GroupCoordinator에게 Consumer Group 탈퇴를 알리지 않으므로 리밸런싱이 발생하지 않는다.

con-1은 Consumer Group을 떠나지만 GroupCoordinator에게 알리지 않아 리밸런싱이 트리거 되지 않음

 

리밸런싱이 발생하지 않기 때문에 con-1이 처리하고 있던 토픽 파티션은 어떠한 Consumer에게도 할당되지 않은 상태로 남는다.

토픽 파티션은 session.timeout.ms 동안 대기

 

con-1이 다시 Consumer Group으로 돌아온다.

GroupCoordinator는 con-1이 이미 Consumer Group에 속했던 Consumer임을 인지하므로 리밸런싱이 발생하지 않는다.

con-1은 그대로 다시 자신이 처리하던 토픽 파티션을 할당받아 처리한다.

 

session.timeout.ms 내에 Consumer Group에 돌아와 리밸런싱이 발생하지 않음

 

Static Membership을 사용하면 Dynamic Membership을 사용할 때와 달리 리밸런싱이 발생하지 않은 것을 확인할 수 있다.

Static Membership을 적용하고 리밸런싱을 피함으로써 리밸런싱 시 발생할 수 있는 단점들을 피할 수 있다.

 

위에 내용을 설명할 때 고려하지 않은 부분이 있다. Consumer가 Consumer Group으로 돌아오지 않을 수도 있다.

할당받지 않은 토픽 파티션은 결국 다른 Consumer가 할당받아 처리해야 한다. 토픽 파티션을 무한히 처리하지 않도록 방치할 수 없기 때문이다.

 

Static Membership은 기존 Consumer가 다시 Consumer Group으로 돌아와서 토픽 파티션을 처리하기 까지 대기하는 유예 기간으로 session.timeout.ms를 사용한다.

 

session.timeout.ms 내에 기존 Consumer가 돌아오지 않으면 GroupCoordinator는 리밸런싱을 트리거한다.

그리고 처리되지 않던 토픽 파티션을 새로운 Consumer에게 Assign되어 처리된다.

session.timeout.ms 내에 Consumer Group이 돌아오지 않아 리밸런싱 발생

 

따라서, Static Membership을 사용시에는 Consumer가 재시작되는 시간을 고려해 적절한 값으로 session.timeout.ms를 지정해야 한다.

예를 들어, Consumer가 Consumer Group에 다시 들어오기 까지 약 1분이 걸린다면 session.timeout.ms를 1분보다 큰 값으로 지정해야 불필요한 리밸런싱을 줄일 수 있다.

Reference.


Conduktor: https://learn.conduktor.io/kafka/consumer-incremental-rebalance-and-static-group-membership/


Confluent: https://www.confluent.io/blog/dynamic-vs-static-kafka-consumer-rebalancing/


Medium: https://medium.com/apache-kafka-from-zero-to-hero/apache-kafka-guide-16-partition-rebalance-static-group-membership-1a5af31269b8


KIP-345: https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances


실전 카프카 개발부터 운영까지

반응형
저작자표시 비영리 변경금지 (새창열림)

'Kafka > Kafka' 카테고리의 다른 글

Kafka: Exactly-Once Semantic (w/ Transaction_)  (0) 2025.01.27
Kafka Connect: Incremental Cooperative Rebalancing  (0) 2024.12.09
Kafka Issue: InvalidRecordException (related Timestamp)  (0) 2024.06.01
Kafka: Kafka Broker 내부 구조  (0) 2024.04.28
    'Kafka/Kafka' 카테고리의 다른 글
    • Kafka: Exactly-Once Semantic (w/ Transaction_)
    • Kafka Connect: Incremental Cooperative Rebalancing
    • Kafka Issue: InvalidRecordException (related Timestamp)
    • Kafka: Kafka Broker 내부 구조
    Zayson
    Zayson
    공부한 내용을 정리하는 공간

    티스토리툴바