티스토리 뷰
Kafka-Broker & Apache Zookeeper
우선 Broker와 Zookeeper는 Kafka Cluser의 기본적인 요소라고 할 수 있다.
간단하게 설명하면 Broker는 직접 분산처리를 하는 일꾼이고 Zookeeper는 그것을 관리하는 관제탑이라고 비유할 수 있다.
설명을 들어가기전 전체적인 그림을 먼저 봐보자.
위 그림에서 처럼 Broker는 Producer와 Consumer를 통해서 메시지를 읽고 처리하는 kafka의 messageQ의 메인 로직을 실행하지만 Zookeeper는 그 로직이 잘 수행될 수 있도록 관리를 해주는 소프트웨어이다.
Broker
Kafka에서 broker는 Partition에 대한 read/write를 관리하는 소프트웨어이다.
producer에서 데이터를 각 partition에 넣게되면, consumer는 그 partition에 저장된 데이터를 가져가는 방식에서, broker는 그 데이터들을 저장 / 분산 / 관리하는 역할을 하고 있다.
이러한 점에서 producer에서 데이터를 넣을 당시에 어느 parition으로 넣을 건지에 대한 생각은 하지 않아도 된다.
(어느 partition으로 넣을 지는 broker에서 계산한 hash값을 통해서 정해지게 된다.)
Key Cardinality
partition에서 유니크 한 값의 갯수를 cardinality라고 한다.
key cardinality가 중요한 이유는 consumer group의 개별 consumer가 수행하는 작업의 양에 영향을 미치기 때문이다.
key 선택이 잘 못되면 작업부하가 고르지 않을 수 있기 때문이다.
각각 broker 서버들은 Kafka에서 bootstrap-server라고 부른다. CLI에서 변수로 들어가는 경우에 broker를 지칭한다.
또한, 각각의 broker들은 ID로 식별하게 된다.
Broker는 최소 3대 이상 Cluster를 구성해야하고 운영 상황에서는 4대 이상을 권장한다.(안정성을 위해서)
4대를 권장하는 이유로는 만약 3대 구성에서 1대가 Down되는 장애가 발생할 경우 Kafka 서비스 전체에 영향이 가기 때문이다.
그리고 Broker의 특이하면서도 편리한 것은 특정 Broker에 연결하면 전체 클러스터에 연결되어 접근할 수 있다는 점이다.
예를 들어서 A라는 topic에서 4개의 partiton이 각각의 broker에 있지만 그것과 상관없이 하나의 broker에만 연결되면 모든 메시지를 읽어 올 수 있다는 점이다.
각각의 Broker는 모든 Broker, topic, partition에 대한 metadata를 가지고 있다.
하지만, 되도록이면 모든 서버의 이름을 설정 변수로 넣어주는 것을 추천한다.
왜냐하면, 변수로 넣어놓은 broker가 장애가 날 경우 Cluster에 전혀 접근을 하지 못하기 때문이다.
Controller Broker
Controller Broker의 경우에는 Broker들의 health check를 하는 대표 Broker의 개념인데, 모르는 내용들이 나오니 우선 건너뛰고 다음 개념들을 알고 와서 읽는 것을 추천한다.
- Cluster에서 하나의 Broker가 Controller가 된다.
- Zookeeper를 통해 Broker Liveness 모니터링
- Partition Leader와 *Replica 정보를 Cluster내의 다른 Broker들에게 전달
- Zookeeper에 Replica 정보의 복사본을 유지한 다음 더 빠른 액세스를 위해 클러스터의 모든 Broker들에게 동일한 정보 캐시
- Partition Leader 장애시 Leader election 수행
- Controller 장애시 Zookeeper가 재선출
Coordinator Broker
여러 대의 broker중에서 한대는 코디네이터 역할을 맡는다.
그 역할로는 *consumer gruop의 상태를 체크하고 partition을 consumer와 매칭되도록 하는 역할을 한다.
Zookeeper
Zookeeper는 Kafka의 요소긴 하지만 독립적인 서비스라고도 할수있다.(현재는 zookeeper를 없애고 Kafka 단독적으로 사용할 수 있는 것을 개발중이라고..)
기본적으로 Zookeeper의 역할은 Broker를 관리하는 소프트웨어이다. Kafka에서 변경사항이 생길 경우에 그것에 대해 알려주는 역할을 한다. 대표적으로는 Topic의 생성/제거, Broker의 추가/제거 등이 있겠다.
Kafka는 Broker가 최소 3대로 구성되고 데이터의 양에 따라 계속 늘어나게 된다. 여기서 Zookeeper는 이 여러대의 서버들이 정보 공유 및 동기화를 할 수 있게 해주는 말 그대로 관제탑이라고 할 수 있다.
Zookeeper에도 기본적으로 Leader, Follower가 있고, 홀수개로 구성되어야 한다.그 이유는 Quorum 기반의 알고리즘을 사용하기 때문이다.
Quroum 기반 알고리즘
합의체가 의사를 진행하거나 의결하는데 필요한 최소한도의 인원수
분산 환경에서 예상치 못한 장애 발생시 일관성 유지
한마디로 Zookeeper는 분산형 Config 정보 유지, 분산 동기화 서비스를 제공하고 대용량 분산 시스템을 위한 네이밍 레지스트리 제공 소프트웨어라고 할 수 있다.
# Zookeeper 쉘 실행
$ ./zookeeper-shell.sh localhost:2181
'Infra > Kafka' 카테고리의 다른 글
5_Replication (0) | 2022.08.16 |
---|---|
4_Consumer (0) | 2022.08.15 |
3_Producer (0) | 2022.08.11 |
1. Kafka - Topic (0) | 2022.07.04 |
0. Apache Kafka (0) | 2022.07.04 |
- Total
- Today
- Yesterday
- apache
- Java
- frontend
- 프론트엔드
- feign client
- NextJS
- Producer
- logback
- K8S
- apache kafka
- Front
- Linux
- broker
- consumer
- KAFKA
- API
- React
- spring
- docker
- rhel
- JPA
- Firebase
- Container
- OS
- 리액트
- centos
- spring boot
- zookeeper
- Data Engineering
- cs
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |