리벨런싱이란?
카프카에는 파티션이라는 개념이 존재한다.
프로듀서가 토픽으로 메시지를 발행하면 카프카 클러스터에 저장되고, 이후 컨슈머들이 해당 토픽의 메시지를 폴링하여 읽고 처리한다
카프카는 로그처럼 메시지를 쌓는 구조를 가지며, 1 대 1 대응으로 처리가된다면 문제가 없겠지만, 1 대 N으로 접근한다면 어떻게될까?
큐에 쌓인 메시지를 처리하다 실패했을때 처리가 불가능 할 것이다. 예를들어 1번 컨슈머가 처리하다 오류가나서 에러처리하고 종료됐을때, 다른 2번 컨슈머가 다른 메시지들을 처리하여 1번이 처리하던 메시지는 넘어가야하기 때문이다.
그러므로 카프카에서는 병렬적으로 처리하기 위해서 하나의 토픽에 대해 파티션으로 나눠서 저장하는 방법을 사용한다. 1번 인스턴스 - 1번 파티션, 2번 인스턴스 - 2번 파티션이 사용할 수 있도록 말이다.
이를 위해 카프카는 컨슈머 그룹을 통해 하나의 토픽을 여러 파티션으로 나누어 각 컨슈머 인스턴스에 할당하여 병렬로 처리할 수 있게 한다.
컨슈머 그룹에서 한 인스턴스가 문제가 생기면, 다른 인스턴스가 대신 처리할 수 있도록 파티션을 재할당 한다. 이 과정을 리밸런싱이라고 한다.
리밸런싱이란?
카프카에서 리밸런싱(Rebalancing)이란 컨슈머 그룹 내에서 파티션 할당을 다시 계산하고 재분배하는 과정을 말한다.
컨슈머 그룹은 토픽의 파티션을 나누어 각 컨슈머 인스턴스가 병렬로 처리할 수 있게 설계되어 있다. 그러나 컨슈머가 새로 추가되거나, 장애가 발생해 세션이 끊기거나, 구독 중인 토픽의 파티션 수가 변경되면 기존 할당 정보가 무효화된다.
이때 그룹 코디네이터는 리밸런싱을 통해 파티션을 남은 컨슈머에게 재할당하거나 새로 참여한 컨슈머에게 분배한다. 이를 통해 장애가 발생해도 메시지 처리를 중단하지 않고 다른 인스턴스가 이어서 처리할 수 있게 보장한다.
하지만 리밸런싱 과정에서는 잠시 모든 컨슈머가 할당을 반납하고 새로운 할당을 받는 단계가 필요하다. 이로 인해 메시지 소비가 일시적으로 멈추거나 지연될 수 있으며, 너무 자주 리밸런싱이 일어나면 서비스 지연이 심해질 수 있다. 이를 완화하기 위해 Kafka에서는 incremental rebalance와 같은 최적화 기법을 지원한다.
리벨런싱 조건
리벨런싱의 조건은 여러가지가 있다.
- 컨슈머 인스턴스가 새로 추가될 때
- 컨슈머 인스턴스가 종료되거나 장애로 빠질 때 (세션 타임아웃/하트비트 실패)
- 컨슈머 그룹이 구독 중인 토픽의 파티션 수가 변경될 때
- 그룹 코디네이터 브로커가 변경되거나 장애가 발생할 때
- 컨슈머가 구독하는 토픽 목록을 변경할 때 (subscribe 변경)
- 컨슈머 그룹 설정(파티셔너, 할당 전략 등)이 변경될 때
내가 주목할 점은,
카프카 메시지로 비동기 처리를 하다보니 로직을 오랫동안 처리할 수 있다고 착각할 수 있는데, max.poll.interval.ms(기본값 5분)에 따라 최대로 동작할 수 있는 시간을 지정할 수 있다. 물론 최대 제한시간이 존재한다.(약 24일 정도라고 한다)
24일동안 동작할 수 있게 선택지를 줘도, 이정도까지 사용하는것은 안좋은 선택일 수 있다. 너무 크게 잡으면 장애감지를 24일 뒤에 할 수 있다라고 볼 수 있기 때문이다. 너무 작게 잡으면 리벨런싱이 자주 일어날 것 이다.
그런데 max.poll.interval.ms을 넘어서면 왜 리벨런싱이 일어날까? 서버의 성능은 동일해서 다시해도 똑같이 오래걸릴텐데, 그 이유는 해당 인스턴스가 죽었다고 판단하고 다른 인스턴스에게 재할당 해주려는 목표이다.
리벨런싱 유의할점
좋다. 이제 리벨런싱이 일어나는 이유와 하면 좋다는것까지 알았다. 그렇다면 단점은 뭘까?
kafka는 오프셋 커밋(offset commit) 을 기준으로 "어디까지 처리했는지"를 기억한다. 리밸런싱은 모든 컨슈머가 파티션 할당을 반납하고 새로 할당 받는 과정인데, 이때 아직 커밋되지 않은 메시지가 있을 수 있다. 그렇다면 처리를 하고 커밋만 안돼서 메시지를 다시 처리할 수 있는 가능성이 생긴다. 이를 위해 중복 처리를 방지해야한다. 예를 들어 처리한 내용에 대한 내용이 db에 있다면 update를 한다던지 무시하는 처리를 해주면 된다.
또한 리밸런싱이 일어나는 동안에는 모든 동작이 멈춰 병목이 생길 수 있다. 이는 파티션 갯수에 따라 어느정도 걸리는지 달라지니, 성능을 위해서 파티션을 무분별하게 늘리는것은 좋지 못하다.
'Web' 카테고리의 다른 글
| Rag를 사용해서 자신의 전문 비서를 만들어 보자 - Lang Chain (2) | 2025.07.08 |
|---|---|
| Rag를 사용해서 자신의 전문 비서를 만들어 보자 (5) | 2025.07.08 |
| MSA에 꼭 필요한 Terraform 사용해보기 (2) | 2025.07.05 |
| ElasticSearch 인덱스 갱신을 위한 Debezium 사용해보기 (1) | 2025.06.22 |
| ElasticSearch를 이용한 검색 기능 만들어보기 - 1 (1) | 2025.06.20 |