Go, Vantage point
가까운 곳을 걷지 않고 서는 먼 곳을 갈 수 없다.
Github | https://github.com/overnew/
Blog | https://everenew.tistory.com/
티스토리 뷰
윈도우에서 kafka를 실행하려면, ZooKeeper를 먼저 동작해야 한다.
왜 그런 작업이 필요한지 알아보자.
Zookper란?
kafka는 분산 시스템으로 동작하기 때문에 관리를 해줄 코디네이션 서비스가 필요하다.
분산 시스템은 서버 간의 정보 공유, 서버 상태 체크, 데이터 락 등의 기능이 필수적으로 필요하다.
Zookeeper는 분산 코디네이션 서비스로 Kafka와 같은 분산 솔루션에 사용된다.
이전 글을 참조해보면 알 수 있지만, 분산 시스템은 가용성을 챙긴 만큼 단점이 존재한다.
https://everenew.tistory.com/483
(알림 시스템으로 알아보는) 분산 시스템의 trade-off (두 장군 문제)
알림 서비스가 분산 시스템을 사용하는 이유 애플리케이션으로 알림을 보내는 대표적인 서비스는 FCM(andriod)과 ARNs(IOS)이 있다.애플리케이션뿐만 아니라 이메일이나 slack 메시지 등 알림 서비스
everenew.tistory.com
단점은 정확히 한번 메시지 전달을 보장하는 것은 불가능하다는 것이다.
이는 상대 노드가 메시지를 수신한 것조차 확인할 수 있는 방법이 없기 때문에 부분 실패(partial Failure)를 발생시킬 수 있다.
따라서 분산 시스템의 코디네이션이 이를 안전하게 처리하는 기능을 제공해야 한다.
Zookeeper 구조
리더로 선출된 서버의 Request Processor가 다른 Follower 서버들이 받는 Client의 write 요청까지 처리하게 된다.
Zab(Zookeeper Atomic Broadcast)는 Request Processor에서 처리된 작업을 모든 Follower 서버에도 전파한다.
각 클라이언트의 상태 정보들은 Zookeeper의 znode라는 in-memory Key-Value 형태로 저장한다.
클라이언트에는 znode의 변화를 감지하는 watcher를 설정하여 변경 내용을 전달 받을 수 있다.
Kafka와의 동작 원리
Kafka는 크게 3가지 구성요소를 가진다.
Producer: 메시지 생산
Consumer: 메시지 소비
Broker: 메시지 전달 및 저장
각각의 Producer와 Consumer는 카프카 외부에서 동작하는 서비스들이므로,
카프카 Brocker가 카프카 시스템의 핵심이다.
이 브로커가 카프카 클러스에서는 여러 개로 존재한다.
여러 개의 브로커 중 하나가 컨트롤러의 역할을 수행한다.
컨트롤러는 각 브로커에게 담당 파트션을 할당하고 다른 브로커들의 정상 동작을 모니터링 기능을 맡는다.
이때 컨트롤러 브로커가 ZooKeeper의 watch 기능을 통해서 다른 브로커를 모니터링한다.
이외의 브로커들도 watch 기능으로 컨트롤 노드의 변경 사항을 확인 가능하다.
Kafka는 왜 Zookeeper 쓰는가?
이번 주제를 찾아보기 시작한 가장 큰 궁금증은 분산 시스템을 구현해야 하는 Kafka는 왜 직접 코디네이터 시스템을 구현하지 않고 zookeeper에게 의존하는지에 대해서이었다.
위에서 살펴보았듯이 zookeeper는 일종의 카프카의 메타데이터 저장소로서 기능했다.
카프카 브로커들의 주요 정보를 주키퍼에 저장해야 했고 이로 인해 주키퍼 클러스터까지 관리하고 운영해야 한다.
이런 의존성은 결국 복잡성을 늘리기 때문에, Kafka 2.8.0 부터는 직접 카프카 내부에 메타데이터를 저장하는 방식으로 변경되었다.
참조
https://cornswrold.tistory.com/523
https://velog.io/@moon_happy/%EC%A3%BC%ED%82%A4%ED%8D%BC%EB%8A%94-%EB%AD%98%EA%B9%8C
https://always-kimkim.tistory.com/entry/kafka101-broker
https://junuuu.tistory.com/812
'CS > 기타' 카테고리의 다른 글
빌드 도구 비교 (Maven VS Gradle) (0) | 2025.02.24 |
---|---|
Git과 GitLab 그리 Harbor의 이해 (2) | 2025.02.21 |
(알림 시스템으로 알아보는) 분산 시스템의 trade-off (두 장군 문제) (2) | 2024.12.08 |
리눅스 쉘 커스텀 명령어 & 명령어 이름 변경 (0) | 2024.10.29 |
URL 링크 단축 사용 이유와 링크 단축기 구현 방식 (0) | 2024.09.10 |