[번역] shared message queues와 publish-subscribe 방식에 Custom Group 방식을 더한 Kafka 소개

전통적으로 메시지 모델은 Shared Message Queue, Publish-subscribe로 구분된다. 두 가지 모델 모두 그들만에 pros and cons를 보유하고 있다. 하지만 이 두개의 모두 최초 디자인 제한 때문에 큰 데이터를 다루기에는 부족했다. Apache Kafka는 두 모델 중 publish-subscribe 메시징 모델을 구현한 모델로 부족했던 부분을 수정하고 실시간 분석을 위한 스트리밍 데이터를 처리할 수 있도록 가능해졌다. kafka는 LinkedIn에서 2010년에 방대한 데이터 처리를 위해서 개발되었다. Apache Kafka는 전통적인 메시징 모델이 달성하지 못한 격차를 해소했다. Kafka는 두 모델의 개념을 구현하여 단점을 극복하고 동시에 두 가지 방법론을 모두 통합 할 수있는 유연성을 제공한다.


Shared Message Queues
Shared Message Queues 메시지 큐는 producer에서 single consumer에게 스트리밍 데이터를 전송할 수 있다. 큐에 저장된 메시지는 한번만 읽기가 가능하고 하나의 consumer만 읽을 수 있다. subscribers는 메시지를 큐의 끝에서 메시지를 읽어서 가지고 온다. Queueing 시스템은 성공적으로 읽혀진 메시지를 큐에서 제거한다.

약점
한번 읽고 지워지는 SharedMessage Queue는 같은 도메인에 속해 있고 event-driving programming을 하는 명령어와 같은 메시지에서 적합하다. 만약 많은 consumer들이 shared queue에 접근을 하게 된다면 해당 컨슈머들은 logical domain이 같아야 하고 같은 기능을 수행해야 한다. 그렇기 때무에 shared queue는 single domain 소비로 제한된다.

Publish-Subscribe System
publish-subscribe모델은 여러 publisher가 발행이 가능하고 여러 subscriber가 구독이 가능하게 설계되어 있다. 그래서 모든 메시지는 토픽을 구독하는 모든 subscriber들에게 전송이 가능하도록 되어있다.

약점
subscriber로부터 publisher의 logical 결합이 loosely-coupled 되어 있지만 scale은 한정적이다. 각각의 subscriber는 모든 파티션으로 부터 메시지를 접근하기 위해서는 모든 파티션을 접근해야한다. 그러므로 전통적인 pub-sub 모델은 작은 네트워크에서 동작하도록 되어있다.

또한 subscriber와 publisher에 디커플링이 메시지의 신뢰도를 낮추는 영향을 준다. 모든 메시지가 모든 subscriber들에게 전송되기 때문에 메시지가 다른 subscirber에게 전송되는 경우 subscriber들 사이에 sync를 맞추는게 실질적으로 어렵다.


그럼 어떻게 Kafka는 두 모델을 결합했을까?
kafka는 shared message queue 시스템과 pub-sub 모델의 장점을 가지고 만들어졌다. 그 성공은 두개의 컨셉을 기준으로 만들어졌다.

• consumer group 사용
• broker들로 부터 메시지 리텐션

consumer가 그룹에 소속되고 topic을 구독할 때 오직 하나의 consumer만 그룹내에서 토픽의 메시지를 읽는다. 그리고 메시지는 broker 내부 토픽에서 사라지지 않고 보유되는데 이는 shared message queue 시스템과 다른점이다.

여러 consumer group은 같은 토픽에서 값을 읽을 수 있으며, 또한 서로 다른 logical application domain에서 다른 시간데에서도 읽을 수 있다. 그러므로 kafka는 같은 consumer group에 속한 consumer들의 높은 확정성을 제공하고 동시에 독립적인 애플리케이션들이 동작할 수 있는 이점이 있다.

Consumer Group
consumer group은 kafka가 message queue와 pub-sub 모델들의 이점을을 가질 수 있도록하는 유연성을 제공한다. 같은 그룹에 속한 consumer들은 group id를 공유한다. 이 consumer들은 토픽의 파티션을 공장하게 나눈다. 이 각각의 파티션들은 오직 그룹내에 하나의 consumer에서만 소비된다.

kafka Consumer Groups
만약 같은 그룹에 모든 consumer가 들어있으면 kafka 모델은 전통적인 message queue처럼 동작한다. 왜냐면 각각의 메시지가 하나의 consumer에게만 발행되는 부분이 같기 때문이다. 각각의 파티션은 거의 그룹내에 하나의 consumer와 연결된다.

여러 consumer group가 존재할 때 데이터 소비 모델은 전형적인 pub-sub 모델을 따른다. 메시지는 모든 consumer group에게 전송된다.

만약 하나의 consumer만 들어있는 그룹이 있으면 그 consumer가 모든 파티션을 담당한다.

이상적으로 topic의 파티션 수와 consumer group에 consumer 수가 맞으면 최적으로 효율을 가진다. 만약 consumer가 파티션보다 많으면 consumer들이 idle상태에 빠지게 되므로 자원 낭비가 발생된다. 만약 partition이 consumer보다 많은 경우 consumer들은 여러 파티션에서 값을 있는데 이는 각 파티션에서 읽는 값이 서로 순서가 맞지 않게 읽게 되기 때문에 문제의 소지가 있다. kafka는 파티션 사이에서 메시지의 순서를 보장하지 않는다. 그러므로 kafka는 오직 하나의 consumer가 하나의 파티션의 내용을 구독할 때만 순서가 보장된다. 메시지는 또한 processing중에 그룹화된 키를 통해서 정렬될 수 있다.

kafka는 offset commit과 form을 사용하여 브로커에서 구독 그룹으로 메시지가 전송되었느지 보증한다. 파티션은 consumer그룹내에 오직 하나 또는 하나 이상의 관계를 consumer와 맺을 수 있기 때문에 메시지 중복을 피하기 위해서 한번에 그룹내에서 한번에 하나의 그룹에게만 메시지를 전송한다.

Reblancing
consumer그룹이 scales up & down을 하기 때문에 동작중인 consumer들은 파티선을 그 들 사이에서 쪼갠다. Reblancing은 consumer와 broker의 충돌 또는 topic이나 partition 추가로 인해 파티션과 consumer의 소유권이 변경되면서 진행된다. 이 매커니즘을 이용하여 안전하게 시스템으로 부터 consumer의 추가와 제거가 가능하다.
-> 요약하면 consumer에 문제가 발생하면 다른 consumer가 파티션의 메시지를 받는다 이런 것 같다.

kafka가 시작되면서 브로커는 consumer의 RegisterConsumer 요청을 수신한 consumer group의 하위 집합에 대한 코디네이터로 표시되고 소유해야할 파티션 목록이 포함된 RegisterConsumer Response를 반환한다. 또한 코디네이터는 컨슈머가 살아있거나 죽었는지 체크하고 결함을 찾기위해 동작을 시작한다. 또한 세션이 끊어지기 전에 consumer가 코디네이터 브로커에게 heartbeat 신호 전송에 실패하면 코디네이터는 해당 consumer를 dead로 표시하고 rebalance를 실행한다. 세션 타임아웃 시간은 session.timeout.ms 속성에서 설정할 수 있다. 예를들어 그룹 A의 C2가 실패 했으면 C1그리고 C3가 짧게 자기들의 파티션에서의 메시지 소비를 정지하고 파티션들은 C1과 C2에 대해서 reassian된다. C2 consumer는 잃게 되지만 rebalancing 프로세스가 실행되고 파티션이 그룹내에 다른 consumer들에게 재 할당된다. GroupB는 Group A의 이런 현상이 전혀 영향을 주지 않는다.

결론
shared message queue는 메시지 프로세스내에서 scale을 허용한다 하지만 싱글 도메인에서만 사용이 가능하다. pub-sub 모델은 consumer들에게 브로드캐스팅을 지원하지만 scale이 제한된다. kafka는 shared message queue에서 scale을 가져왔고 pub-sub 아키텍쳐를 consumer gorup를 구현함으로써 단점을 보안하여 재 구현하여 가져왔다. consumer group를 구현함으로써 scale과 멀티 도메인을 사용할 수 있게 되었다. 그리고 kafka에 rebalacing을 통해서 그룹내에서 문제 발생시 문제를 해결할 수 있다.

원문
https://blog.cloudera.com/blog/2018/05/scalability-of-kafka-messaging-using-consumer-groups/