Kafka
- pub - sub 모델의 메시지 큐입니다.
- Pub - sub(Publish - subscribe) 패턴 : 서버리스, 마이크로 서비스 아키텍처에서 주로 사용되는 비동기 메세징 패턴
- 분산 환경에 특화되어 있습니다.
- 발신자는 특정 채널 (토픽) 로 메시지를 전달한다.
- 해달 채널(토픽) 구독 중은 수신자만 메시지를 수신한다.
- 낮은 지연과 높은 처리량을 통해 아주 효과적으로 데이터를 처리한다.
주요 구성 요소
- 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)
- replication:1이면 partition : 1/ replication:2이면 partition 원본:1, 복제본 : 1/ replication:3이면 partition 원본:1, 복제본 : 2
- 브로커 갯수가 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: