[INFRA] APACHE KAFKA - Modest Study

Kafka

pub - sub 모델의 메시지 큐입니다.

Pub - sub(Publish - subscribe) 패턴 : 서버리스, 마이크로 서비스 아키텍처에서 주로 사용되는 비동기 메세징 패턴

PUBLISHER

분산 환경에 특화되어 있습니다.
발신자는 특정 채널 (토픽) 로 메시지를 전달한다.
해달 채널(토픽) 구독 중은 수신자만 메시지를 수신한다.
낮은 지연과 높은 처리량을 통해 아주 효과적으로 데이터를 처리한다.

주요 구성 요소

kafka

Event : producer 와 consumer 가 데이터를 주로 받는 단위, 이벤트 혹은 메시지라 불립니다.
Broker : 카프카의 서버입니다. 여러 개의 클러스터로 구성 가능합니다. 스케일 아웃이 가능합니다.
Zookeeper : 브로커의 분산 메시징 처리를 관리하는 도구입니다.
Producer : kafka에 이벤트를 게시하는 클라이언트 어플리케이션을 의미합니다.
Consumer : topic을 구독하고 이로부터 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션을 의미합니다.
Topic : producer는 이 topic에 이벤트를 게시합니다. consumer 는 topic으로 부터 이벤트를 가져와 처리합니다.
- Topic 은 이벤트가 담긴 폴더와 유사합니다.
- Topic은 여러 브로커에 분산되어 저장됩니다.
Partition : topic은 여러 개의 partition으로 나누어 질 수 있습니다. 이벤트가 어떤 partition 에 저장될 지는 이벤트의 key에 의해 정해지고 같은 키를 가지는 이벤트는 항상 같은 partition에 저장됩니다.
- 첫 번쨰 파티션은 0부터 부여되고, 큐처럼 FIFO 구조로 컨슈머가 가져간다.
- 컨슈머가 가져가더라도 데이터는 파티션 내에서 사라지지 않는다.
- 컨슈머 그룹 내 컨슈머는 모두 다른 파티션을 보고 있어야 함, 컨슈머 그룹만 다르면 동일 데이터를 다양한 곳으로 보내 처리 가능
Kafka는 topic 의 Partition에 지정된 consumer가 항상 정확히 동일한 순서로 partition의 이벤트를 읽을 것을 보장합니다.

주요 개념

producer와 consumer의 분리

둘은 서로 완전 별개로 동작합니다, producer는 broker의 topic에 메시지를 게시하기만 하면 되고, consumer는 broker의 특정 topcic 에서 메시지를 가져와 처리하기만 합니다.
이 덕분에 kafka는 높은 확장성을 제공합니다. Producer, consumer 를 필요에 의해 스케일 인, 아웃하기 매우 용이한 구조입니다.
producer는 데이터를 보낼 때 key를 지정할 수 있다.
- key=null, 기본 파티셔너 사용할 경우 라운드 로빈으로 할당한다.
- key가 존재, 기본 파티셔너 사용 시 key에 대한 hash 값을 구하고 hash 값에 맞는 특정 파티션에 할당

Consumer의 Pull 모델

Consumer 는 Pull 모델 기반으로 메시지 처리를 진행하기 때문에 Consumer의 처리 가능한 시점에 메시지를 가져와 다양한 소비자를 다루기 쉽고 효율적입니다.
Pull 모델에서도 소비자가 처리 가능할 때 한번에 가져오기 때문에 Push 모델의 장점인 Buffering에 대한 문제도 해결할 수 있습니다.

소비된 메시지 추적

메시지는 지정된 Topic에 전달되고, Topic은 여러 Partition 으로 나누어집니다. 그리고 각 파티션은 로그들로 이루어져 있고 순차적으로 추가됩니다. 그 메시지의 위치는 offset이라 합니다.(인덱스 같은 역할)
메시징 시스템은 Broker에서 소비된 메세지에 대한 메타데이터를 유지합니다.
Consumer 의 poll()은 이전에 commit한 offset이 존재하면 해당 offset 이후의 메시지를 읽고 마지막 offset을 커밋합니다. 이를 반복합니다.

Consumer group

Consumer group은 하나의 Topic을 구독하는 여러 Consumer들의 모음입니다.
각 Consumer들은 하나의 Topic의 각기 다른 Partition의 내용만 처리할 수 있습니다.(메시지 처리 순서를 보장한다는 말과 같습니다.)
반드시 Consumer group 내의 Consumer 들은 모두 각기 다른 Partition에 연결되어야 합니다.
- 따라서 Consumer를 확장시킬 때는 Partition도 같이 늘려주어야 노는 Consumer를 없게 효율적으로 운용할 수 있습니다.
- 하지만 파티션을 한 번 늘리면 다시 줄일 수 없으니 상황을 많이 고려해야 합니다.

Replication

kafka 아키텍처의 핵심, 클러스터 내 장애 발생 시 가용성을 보장하는 가장 좋은 방법
보통 3개 이상의 broker로 구성될 것을 권장
replication은 partition의 복제를 의미한다.
- replication:1이면 partition : 1/ replication:2이면 partition 원본:1, 복제본 : 1/ replication:3이면 partition 원본:1, 복제본 : 2
  - leader partition: 원본 파티션, follower partition: 복제 파티션 > 합쳐서 ISR(In Sync Replica)
브로커 갯수가 2이면 replication도 최대 2개까지 가능
브로커 장애시 replication이 2 이상이면 나머지 1개 남은 follower partition이 leader partition으로 역할을 승계
그렇다고 replication이 많아지면 broker 리소스 사용량도 그만큼 증가한다.

Partitioner

producer가 데이터를 보내면 무조건 Partitioner을 거쳐서 브로커로 데이터 전송
Partitioner는 데이터를 토픽에 어떤 파티션에 넣을지 결정
메세지 키가 존재 : 특정 해쉬 값이 생성되어 해쉬값을 기준으로 어느 partition에 들어갈지 정해짐
- 동일한 해시값을 생성하므로 순서가 보장된다는 것을 확인 가능, 큐처럼 동작
메시지 키가 존재하지 않음 : 라운드 로빈 방식으로 partition에 들어감, 즉 적절히 분배
- 라운드 로빈 방식 : 우선순위를 두지 않고, 순서대로 시간단위(Time Quantum)로 CPU를 할당하는 방식, 시간이 지나면 큐 끝으로 밀려남, 전통적인 방식과는 조금 다름

Rebalance

Partition을 담당하던 Consumer가 처리불가 상태가 되면 Partition과 Consumer을 재조정하여 Consumer들이 적절하게 나누어 Partition을 처리하게 됩니다. 이는 같은 Consumer group 내 Consumer 들이 Offset 정보를 공유하고 있기 때문에 가능합니다.
이렇게 처리 불가 상태가 된 Consumer 를 제외한 나머지 Consumer들이 Partition을 처리하는 것을 Rebalance라 합니다. 이를 위해 Consumer group이 필요합니다.

메세지(이벤트) 전달 컨셉

At most once : 메시지가 손실될 수 있지만 재전달은 하지 않습니다.
At least once : 메시지가 손실하진 않지만 재전달이 일어납니다.
Exactly once : 메시지는 정확히 한 번 전달됩니다.

Consumer Lag

kafka를 운영함에 있어 가장 중요한 모니터링 지표
producer가 넣은 데이터가 consumer가 가져가는 것보다 많을 때 producer가 넣은 데이터의 offset과 consumer가 가져간 데이터의 offset 차이가 발생하며 이 것이 consumer lag
consumer group이 1개고 partition이 2개인 topic에서 데이터를 가져가면 lag 2개 측정가능
한 개의 토픽과 컨슈머 그룹에 대해 lag이 여러개 존재할 수 있고 그 중 가장 높은 숫자의 lag을 records-lag-max라고 부름

카프카 모니터링 툴

Burrow

카프카의 consuemr lag을 모니터링할 때 사용

Kafka Manager (CMAK)

kafka 클러스터를 모니터링하는 툴
클러스터 관리
컨슈머 lag 관리
파티션 리밸런싱(파티션 추가)
topic 관리: 리스트 조회, 생성, 삭제

Reference:

← Previous Post Next Post →