Gidhub BE Developer

Kafka Consumer Groups

2019-12-22
goodGid

이 글의 코드 및 정보들은 을 바탕으로 작성하였습니다.

컨슈머 그룹

  • 하나의 토픽에

  • 여러 컨슈머 그룹이 동시에 접속해

  • 메시지를 가져올 수 있다.


  • 기존의 다른 MQ(Message Queue) 솔루션에서는

  • 컨슈머가 메시지를 가져가면

  • 큐에서 삭제되어 다른 컨슈머가 가져갈 수 없게 되는데

  • 카프카에서는 가능해졌다.


  • 컨슈머 그룹은

  • 컨슈머를 확장시킬 수도 있다.


  • 만약 프로듀서가 토픽에 보내는 메시지 속도가

  • 컨슈머가 메시지를 가져가는 속도보다 빨라지면

  • (= 프로듀서 속도 > 컨슈머 속도)

  • 컨슈머가 처리하지 못한 메시지들이 점점 많아지게 되어

  • 카프카로 메시지가 들어오는 시간과

  • 그 메시지가 컨슈머에 의해 카프카에서 나가는 시간의 차이는 점점 벌어지게 된다.


  • 이럴 경우 정해진 시간 내

  • 모든 메시지를 처리할 수 없기 때문에

  • 컨슈머를 확장해야 한다.


  • 단순하게 컨슈머만 확장한다면

  • 기존의 컨슈머의 오프셋 정보와

  • 새로 추가된 컨슈머의 오프셋 정보가 뒤섞여

  • 메시지들의 순서 보장이 깨진다.


  • 그래서 카프카에서는

  • 동일한 토픽에 대해 여러 컨슈머가 메시지를 가져갈 수 있도록

  • 컨슈머 그룹이라는 기능을 제공한다.


  • 이러한 기능을 통해

  • 컨슈머는 확장이 용이해지고

  • 컨슈머의 장애에도 빠른 대처가 가능해진다.

Example

  • 컨슈머 그룹 아이디 : 컨슈머 그룹01

  • 컨슈머 : 컨슈머01 하나만 존재

  • peter-01 토픽의 파티션 수 : 3

  • 토픽(=peter-01)으로 들어오는 메시지를 컨슈머01이 담당하는 상황


  • 위 같은 상황에서

  • 토픽에 너무 많은 메시지가 들어오게 되면

  • 컨슈머가 아직 읽지 못한 메시지가 쌓이게 된다.


  • 이 문제를 해결하기 위해서는

  • 컨슈머를 확장해야한다.

  • 컨슈머를 추가해보자.

  • 추가 컨슈머인 컨슈머02, 03을

  • 동일한 컨슈머 그룹 아이디로 설정하면

  • 위 그림과 같아진다.


  • 동일한 컨슈머 그룹 내 컨슈머가 추가되면

  • 리밸런스가 일어나며

  • 컨슈머02, 03은

  • 기존 컨슈머01이 가져가고 있던

  • 파티션 1과 2에서 메시지를 가져가게 된다.


Case. 만약 컨슈머를 추가했는데도 프로듀서의 속도가 더 빠르다면 ?

  • 컨슈머 수를 늘리면 된다고 학습했기 때문에

  • 컨슈머의 수를 늘려보자.


  • 그런데 컨슈머04는

  • 아무일도 하지 않고 대기만 한다.


  • 그 이유는 다음과 같다.

  • 토픽의 파티션에는

  • 하나의 컨슈머만 연결할 수 있기 때문이다.


  • 즉 컨슈머03, 04가 동시에

  • 파티션 2에서 메시지를 가져올 수 없는 상황이다.

  • 그렇기 때문에 컨슈머04는

  • 아무일도 하지 않고 대기를 하게 된다.


  • 결국 토픽의 파티션 수만큼만

  • 컨슈머가 동작할 수 있게 된다.


  • 그렇다면 이 문제를 어떻게 해결할 수 있을까?

  • 토픽의 파티션 수와 동일하게

  • 컨슈머 수를 늘렸는데도

  • 프로듀서가 보내는 메시지의 속도를 따라가지 못한다면

  • 토픽의 파티션 수를 늘려주고

  • 컨슈머 수도 같이 늘려줘야한다.


Case. 컨슈머가 다운된다면?

  • 컨슈머가 컨슈머 그룹 안에서 멤버로 유지되고

  • 할당된 파티션의 소유권을 유지하기 위해서는

  • 지속적으로 하트비트를 보내야 한다.


  • 즉 컨슈머가 일정한 주기로

  • 하트비트를 보낸다는 사실은

  • 해당 파티션의 메시지를 잘 처리하고 있다고 볼 수 있기 때문이다.


  • 하트비트는 컨슈머가

  • poll할 때가져간 메시지의 오프셋을 커밋할 때 보내게 된다.


  • 만약 컨슈머가 오랫동안 하트비트를 보내지 않으면

  • 세션은 타임아웃되고

  • 해당 컨슈머가 다운되었다고 판단하여 리밸런스가 시작된다.


  • 컨슈머04가 다운되었다고 가정해보자.

  • 컨슈머04는 컨슈머 그룹으로 구성되어 있기 때문에

  • 그룹 내에서 리밸런스가 일어나고

  • 내부적으로 균형을 맞추게 된다.


  • 컨슈머04가 담당하던 파티션 3을

  • 컨슈머03이 이어받아

  • 2개의 파티션으로부터 메시지를 가져오게 된다.


  • 여기서 중요한점은

  • 하나의 파티션에 하나의 컨슈머만 연결되었다.

  • 즉 카프카의 룰을 위반하지 않았기 때문에

  • 이와 같은 변경이 가능하다.


  • 컨슈머03이 파티션 3을 처리하였기 때문에

  • 전체적인 컨슈머 그룹은 안정적으로 동작함으로써

  • 안정성을 확보할 수 있게 된다.


  • 하지만 이런 상황을 지속적으로 내버려두면

  • 컨슈머03에 부하가 생길 수 있기 때문에

  • 모니터링을 통해

  • 컨슈머의 장애 상황을 인지하고

  • 새로운 컨슈머를 추가해

  • 정상적인 운영 상태를 만들어줘야한다.


Reference


Comments

Index