Kafka partition : consumer group instance

요즘은 업무에서 kafka를 다루지 못하고 있어서 너무 슬프다. 그래서 기본 개념들을 다음과 같이 복습하는 겸 정리해봤다.

 

Event Sourcing

어떤 이벤트를 발행하고, 그것을 구독하는 패턴

Kafka 는 이러한 부분을 실시간으로 확장가능하게 처리하는데 최적화되어 있다.

 

Cluster & Broker

Kafka Server 는 기본적으로 Cluster 에 여러 Broker 들이 존재한다. (MongoDB cluster 처럼)

기본적으로 한 Cluster 에 최소 한 개의 Broker(=실제 Kafka Process)를 갖는다.

이때 Cluster 내 Broker 들 간의 동기화는 RAFT 를 사용한다. -> 가능하면 홀수로 맞추는게 좋음

 

Topic

이벤트의 기본 구분 단위

Topic 을 기준으로 Message 를 Produce 하고 Consume 한다.

이때 Topic 은 Message를 실제로 저장하는 Partition 이라는 개념이 존재한다.

 

Partition

Topic 에 대해 발생한 Message 를 저장하는 단위

파티션은 기본적으로 하나씩 존재하며, 필요 시 늘릴 수 있다. (필요한 상황은 후술)

파티션마다 message 를 의 순서를 기록하는 offset 이라는게 존재.

파티션 내부에서는 메시지의 순서가 보장된다.

• Consumer는 이러한 Partition 의 OFFSET 을 기준으로 읽어옴(앞)
• Producer 는 이러한 Partition의 OFFSET 을 기준으로 생성(뒤)

Offset

파티션에 기록된 Message 의 순서를 의미 (배열의 index 와 비슷)

Consumer는 이러한 Offset 을 기준으로 자신이 마지막으로 읽은 위치를 파악함

이러한 offset 은 partition 당, consumer group 당 계산됨

 

Message

특정 topic 에 대해 실제로 발생시킨 메시지 값

key, value, headers 로 구성되어 있다.

• key -> partition 구분자로 사용
• value -> json data
• headers -> 메타 정보 전달에 사용

메시지를 Consumer가 읽고, 그걸 기반으로 다음 행동을 처리함

참고로 key 는 메시지가 partition 어디 partition 이 저장될지 구분하는 용도로 쓰이는데 따로 지정하지 않을 경우 round-robin으로 저장된다

 

Producer

Topic 에 대해 Message 를 발생시킨 대상

Producer 는 Kafka 의 Topic 에 Message 를 포함하여 생성함

Kafka 에서는 실제 Producer 가 누구인지에 대해 따로 관리하지 않음(보통은 필요시 따로 명시함)

 

Consumer

Consumer 는 Topic을 Consume 한다. (=subscribe)

consume이 발생하면 last offset (마지막으로 읽은 offset)이 증가 -> 다음 읽을 위치 갱신

이러한 last offset 은 consumer group 단위로 보관된다

 

Consumer Group

topic 의 partition의 offset 은 consumer group 단위로 관리된다.

이러한 consumer group 은 말 그대로 consumer 들의 집합이다.

이때 consumer group 안에 있는 consumer 를 consumer instance 라고 부름

 

consumer group 이 생성되고 offset 이 처리되는 로직은 다음과 같다

1. Consumer 가 자신의 Consmer Group 을 명시해서 Consume 요청
2. 해당하는 토픽의 파티션에 대해 컨슈머 그룹으로 가능한지 확인함 (빈 자리 확인)
3. 있으면 컨슘 시작, 없으면 대기

따라서 컨슈머 그룹은 어떤 이벤트에 대해 처리할 서비스의 단위로 취급하는 것이 일반적이다.

 

참고로 consumer group 을 명시하지 않고 consume 시작 시, 자동으로 해당 토픽의 offset 가장 끝에 보낸다. (앞의 메시지 못읽음)

 

Partition & Consumer Group 상세 설명

앞선 내용들을 좀 더 살펴보자

• offset 은 {partition, consumer group} 단위로 저장된다
• 한 partition 에 대해 같은 consumer group 의 instance 가 여러 개 있어도 하나만 consume 가능
• 한 partition 에 대해 서로 다른 consumer group 의 instance 들이 존재한다면 따로 consume 가능
• 한 partition 내에서 메시지의 순서는 보장된다

Partition 확장

어떤 topic 에 대해 같은 consumer group 을 갖는 여러 consumer 들이 필요한 상황을 가정해보자

e.g)  topic 을 병렬로 처리하고 싶은 상황

이 경우에는 partition을 늘려줘야 한다.

• consumer 는 partition을 기준으로  consume 함
• 하나의 partition 에는 consumer group 당 하나의 instance 만 존재할 수 있음
• 따라서 partition 이 1이라면 instance 가 여러 개 존재해도 partition 을 할당 받지 못해 처리를 시작하지 못함

Partition 을 늘려주면 Consumer group instance 가 추가로 파티션을 할당받아 처리 가능

이때 Partition 마다 따로 OFFSET 을 관리하게 되며, 생성된 message은 각 partition에 round robin으로 추가됨

단, Partition 은 늘리는 것은 가능한데 줄이는 게 안됨(kafka 정책)

 

 

그럼 예제들을 살펴보자

 

Case] Partition > Consumer Group Instance

다음의 상황을 가정

• topic 에 대해 partition 을 4로 설정
• 같은 consumer group instance 가 3개 존재

이 경우, 한 consumer group instance 가 추가로 파티션을 할당받게 된다

따라서 다음과 같이 처리된다

• partition 1 - >A
• partition 2- > B
• partition 3 -> C
• partition 4-> {A,B,C} 중 아무거나

 

이때 같은 Consumer Group Instance D 가 새로 consume 을 시도하는 경우 다음과 partition 4 는 D에 할당된다

왜냐하면 kafka 에서는 한 partition에 한 consumer group instance 가 붙게 되도록 기본적으로 리밸런싱을 해주므로

 

참고로 여기서 리밸런싱이란 Consumer Instance 수나 partition 수가 변경되면 Kafka 는 자동적으로 리밸런싱을 수행, 각 partition 을 가능한 균등하게 consumer 들에게 재할당시켜주는 것을 의미

 

Case] Partition < Consumer Group Instance 

다음의 상황을 가정

• topic 에 대해 Partition 을 1로 설정
• 같은 consumer group instance 는 3개가 존재(A,B,C)

이 경우 제일 먼저 Consume 을 시도한 Consumer Group Instance 만이 파티션 할당받고 나머지는 IDLE

이때 Partitoin 을 할당 받은 Consumer 가 다운된 경우, idle 하던 consumer 가 즉시 이어서 할당받는다.

 

결론

Partition : Consumer Group Instance = 1:1 로

병렬 처리는 Partition 갯수만큼만 보장됨에 주의

Partition > Consumer Group Instacne => group instance 간 공평한 consume 안됨

Partition < Consumer Group Instance => idle 한 instance 발생