일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 파이썬 소스
- auto configure
- 자바 프로젝트
- spring
- 문법 정리
- K6
- 파이썬
- gradle
- 유사코드
- MongoDB
- SQL
- oracle
- smart cast
- c#
- jsp
- 프로젝트
- 학점
- 티스토리
- 오라클 디비
- 오라클
- hyperledger
- 알고리즘
- 백준 알고리즘
- dynamic query
- 자바
- 리눅스
- resilience4j
- JVM
- 운영체제
- 초대장
- Today
- Total
모종닷컴
KRaft 합의 알고리즘 본문
zookeeper를 이용한 카프카 메타데이터 관리
- 카프카 2.8 버전 이전에는 아래와 같은 메타데이터들을 관리하기 위해 zookeeper를 사용했었음.
- 클러스터 토폴로지 정보, 토픽 메타데이터, 컨트롤러 정보, 컨슈머 그룹 정보, ACLs 정보, 브로커 정보 등..
Zookeeper를 통해 메타데이터를 관리했을 떄 발생하는 문제들
Zookeeper 자체에 이슈가 있다기보다는 주키퍼를 활용하여 메타데이터를 관리하는 카프카의 방식에 여러 가지 문제가 있었음.
주키퍼라서 생기는 문제들.
- 주키퍼는 카프카와 별개의 분산 시스템
- 관리자는 카프카를 배포하기 위해 두 개의 개별 분산 시스템을 관리하고 배포하는 방법을 배워야 한다.
- SASL과 같은 설정이 카프카, 주키퍼 두 시스템에 모두 적용되어야 한다.
- 로컬에서 간단한 테스트를 해보고 싶더라도 주키퍼, 카프카 두 가지의 애플리케이션 모두 운영해야 한다.
- 주키퍼 Watch의 한계점
메타데이터 복제 프로세스 문제
- 컨트롤러는 메타데이터 변경 사항이 생기면 클러스터 내의 브로커들에게 변경된 내용을 전파(LeaderAndISr, UpdateMetadata 등) 하도록 되어있는데, 이 전송이 성공적으로 전달되지 않으면 브로커 간의 메타데이터 상태가 불일치하게 된다.
- 업데이트되지 않은 노드에게 클라이언트는 메타데이터를 요구할 수 있다. 이로 인해 클라이언트는 잘못된 정보를 받을 수 있다
Quorum 기반의 메타데이터 관리
카프카의 KIP문서를 보면 이를 "post zookeeper"라고 하면서 처음 소개를 하고 있음. 카프카의 메타데이터 관리를 할 때 주키퍼를 활용하지 않고 카프카 자체적으로 메타데이터를 관리하도록 변경되었으며, 각 클러스터 간의 Quorum을 만들고 참여하는 노드 사이에 합의 알고리즘을 이용하여 메타데이터를 관리함. 이 합의 알고리즘으로 Raft 알고리즘을 사용하는데 Kafka 시스템에 좀 더 적합한 형태로 변화를 살짝 주었는데 이를 KRaft(Kafka Raft) 알고리즘이라 한다.
Raft 합의 알고리즘
분산 시스템 환경에서 모든 노드가 동일한 상태를 유지하도록 하고, 일부 노드의 결함이 전체 시스템에 영향이 없도록 동작하기 위한 합의 알고리즘
TMI로 Raft 알고리즘 이름의 유래가 재밌었는데 검색하다 보면 "Raft"라는 이름이 'reliable', 'replicated', 'redundant', 'fault-tolerant' 등의 단어의 조합된 것이 아닐까 하는 추측들이 있는데, 실제 이름을 짓는 과정에서 Raft 알고리즘의 특징인 log(통나무)라는 것을 이용하여 Paxos(Raft 이전에 자주 사용하던 합의 알고리즘, 그리스에 있는 섬이름임) 섬을 탈출한다에 집중하였고 Raft라는 이름이 등장하게 되었다고 한다.
Raft에서 등장하는 용어들을 먼저 살펴보면 아래와 같다.
- Leader: 클러스터를 대표하는 노드. 모든 팔로워에게 명령을 전파한다.
- Follwer: 리더를 제외한 노드. 리더로부터 전파된 명령을 로컬에서 수행
- Candidate: 선거 기간 동안 리더가 될 자격을 얻은 노드. 선거에서 패하면 팔로워로 추락
- Term: "제1대 대통령", "제2대 대통령"처럼 해당 선거가 몇 번째 선거인지를 나타내는 번호
Raft 합의 알고리즘의 동작 과정은 아래의 사이트를 통해 확인해 볼 수 있다.
https://thesecretlivesofdata.com/raft/
KRaft 알고리즘
KRaft 알고리즘은 Raft 알고리즘에 약간의 변형을 주어 만들었다고 했는데, Raft 알고리즘에서 리더 선출과정을 통해 선정된 Leader 노드 는 Follwer 리더에게 로그를 전달(push)하도록 되어있다. 하지만 KRaft 알고리즘에서는 반대로 Follower가 Leader노드에게 변경된 로그를 요청(pull)하도록 되어있다.
이런 변형을 준 이유로 카프카에서는 기존 시스템의 로그 레이어를 재사용하기 편하고, 리더의 과한 역할을 제거하고, 팔로워가 많아질수록 pull 방식이 적합하다고 판단하여서 팔로워가 리더에게 로그를 직접 요청하도록 수정했다고 한다.
'Programming > Apache Kafka' 카테고리의 다른 글
Quorum based Controller (0) | 2024.01.07 |
---|---|
카프카 모니터링 - 메트릭 (0) | 2023.12.02 |
Kafka Transaction (0) | 2023.11.18 |
Exactly Once Semantics (0) | 2023.11.05 |