이번 포스팅을 통해서 컨슈머 그룹에 관해서 알아보겠습니다. 일반적으로 컨슈머는 카프카 토픽에서 메시지를 읽어오는 역할을 합니다. 컨슈머 그룹은 하나의 토픽에서 여러 컨슈머 그룹이 동시에 접속해 메시지를 가져올 수 있습니다. 이것은 기존의 다른 메시징 큐 솔루션에서 컨슈머가 메시지를 가져가면 큐에서 삭제되어 다른 컨슈머가 가져갈 수 없는 것과는 다른 방식인데 이 방식이 좋은 이유는 하나의 데이터를 다양한 용도로 사용하는 요구가 많아졌기 때문입니다.
또한 만약 프로듀서가 토픽에 보내는 메시지 속도가 갑자기 증가해 컨슈머가 메시지를 가져가는 속도보다 빨리지게 되면 처리하지 못한 메시지들이 많아지게 되어 프로듀서가 생성하는 시간과 컨슈머가 이 메시지를 처리하는 시간의 간격이 점점 벌어지게 됩니다. 이 시간차를 줄이기 위해 단순하게 컨슈머를 늘릴 수 있지만, 이럴 경우 오프셋 정보와 새로 추가된 컨슈머의 오프셋 정보가 뒤섞여 메시지가 뒤죽박죽 될 것입니다. 그래서 카프카에서는 여러 컨슈머가 메시지를 가져갈 수 있도록 컨슈머 그룹이라는 기능을 제공합니다.
컨슈머 그룹에 대한 예
컨슈머 그룹에 대한 예를 들어보며 한번 살펴보도록 합시다.
해댕 그림은 토픽에 대한 파티션이 3개이며 컨슈머 그룹에는 컨슈머 한 개가 있다고 가정한 것입니다.
프로듀서가 토픽에 많은 메시지를 보내고 각 파티션별로 나눠 처리하는데 컨슈머 그룹에 컨슈머가 1개 있어 메시지를 처리하는데 지연이 걸린다고 가정해봅시다. 그러면 앞서 설명드린 것과 같이 프로듀서가 보낸 시간과 컨슈머가 이를 처리하는 시간의 간격이 점점 벌어질 것입니다. 이를 해결하기 위해서는 컨슈머를 충분히 확장해야 합니다.
컨슈머 그룹 안에서 컨슈머들은 메시지를 가져오고 있는 토픽의 파티션에 대해 소유권을 공유합니다. 위 사진은 동일한 컨슈머 그룹 아이디내에서 2개의 컨슈머를 추가한 경우입니다. 이 경우 컨슈머 그룹 내에서 리벨런스(Rebalance)라는 파티션과 컨슈머의 소유권을 이동시키도록 합니다. 전에는 컨슈머 01이 파티션 0, 1, 2 소유권을 가졌지만 리벨런스를 통해서 컨슈머 02가 파티션 1, 컨슈머 03이 파티션 2를 가지도록 했습니다. 이 처럼 리벨런스는 컨슈머를 쉽고 안전하게 추가할 수 있고 재거할 수도 있어 높은 가용성과 확장성을 확보할 수 있습니다. 하지만 이 리벨런스는 단점이 존재합니다. 리벨런스가 발생하면 컨슈머 그룹 전체가 메시지를 가져올 수 없어 일시적으로 사용할 수 없는 단점이 있습니다.
메시지 생산속도와 소비속도의 간격을 줄이기 위해서는 컨슈머 그룹 내에 컨슈머를 늘리면 된다고 했는데, 만약 컨슈머 04번을 추가했다면 어떻게 동작하고 있을까요? 정답은 "컨슈머 04이 파티션을 할당받지 못해 아무런 일도 하지 않고 대기만 하게 된다"입니다. 왜 이런 상황이 발생하는 걸까요? 이유는 토픽의 파티션에는 하나의 컨슈머만 연결할 수 있기 때문입니다 (토픽의 파티션 수 = 최대 컨슈머 수). 왜 하나의 파티션에는 하나의 컨슈머만 연결할 수 있을까요? 그 이유는 메시지의 순서를 보장할 수 없기 때문입니다. 그렇다면 프로듀서와 컨슈머의 시간 차이를 줄이기 위해서는 어떻게 해야 할까요? 바로 파티션과 컨슈머를 같이 늘리는 것입니다.
컨슈머 그룹내에 다운되는 경우
이번에는 컨슈머 그룹 내에 컨슈머 하나가 다운되는 경우에 대해 살펴보겠습니다.
컨슈머가 컨슈머 그룹 안에서 멤버로 유지하고 할당된 파티션의 소유권을 유지하는 방법은 하트비트를 보내는 것입니다. 하트비트는 컨슈머가 poll 할 때와 가져간 메시지의 오프셋을 커밋할 때 보내게 됩니다. 만약 컨슈머가 오랫동안 하트비트를 보내지 않으면 세션은 타임 아웃되고 해당 컨슈머가 다운되었다고 판단하여 리벨런스가 시작됩니다.
위 그림은 컨슈머 02이 다운되어 리벨런스한 것입니다. 컨슈머 02번이 파티션 1, 2를 할당받아 메시지를 가져오는 상황입니다. 하나의 파티션에 하나의 컨슈머만 연결되었기 때문에 카프카의 룰을 위반한 것은 아닙니다. 하지만 하나의 컨슈머가 여러 파티션에 대한 메시지를 가져와 처리하다 보니 많은 메시지를 처리해야 합니다. 이렇게 약간은 불균형한 상황이 발생할 수 있지만 전체적인 컨슈머 그룹은 안정적으로 동작함으로써 안정성을 확보할 수 있습니다. 하지만 이런 상황이 지속되면 모니터링을 통해 컨슈머의 장애 상황을 인지하고, 새로운 컨슈머를 추가해 정상적인 운영 상태를 만드는 것이 좋습니다.
[REFERENCE]
GitHub - dpkp/kafka-python: Python client for Apache Kafka
Python client for Apache Kafka. Contribute to dpkp/kafka-python development by creating an account on GitHub.
github.com
해당 글의 모든 레퍼런스는 "카프카, 데이터 플랫폼의 최강자" (고승범, 공용준 지음)을 알립니다.
카프카 데이터 플랫폼의 최강자:실시간 비동기 스트리밍 솔루션 Kafka의 기본부터 확장 응용까지
COUPANG
www.coupang.com
"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."
'BigData' 카테고리의 다른 글
| 아파치 카프카(Apache Kafka)의 성능 최적화 [1] (0) | 2021.09.09 |
|---|---|
| [Apache Kafka] 카프카 컨슈머의 커밋(commit)과 오프셋(offset)을 알아보자 [4] (0) | 2021.09.05 |
| [Apache Kafka] 카프카 컨슈머(Consumer)의 파티션과 메시지 순서를 알아보자 [2] (0) | 2021.09.03 |
| [Apache Kafka] 카프카 컨슈머(Consumer)를 알아보자 [1] (0) | 2021.09.03 |
| [Apache Kafka] 카프카 프로듀서(Producer)를 알아보자 [2] (0) | 2021.09.01 |
