multi node kafka cluster?
- 여러대의 서버(node)로 구성될 kafka cluster를 의미
- 신뢰성 , 확장성 , 고가용성을 위해서 multi node 구조로 배포
- 신뢰성: 데이터의 복제를 통해서, 하나의 broker가 장애가 나더라도 다른 broker에서 data 사용 가능
- 확장성: 노드를 추가하여 cluster 처리 용량을 유연하게 늘리는 것이 가능
- 고가용성: leader-follower구조로, 특정 broker장애 발생해도 다른 broker가 자동으로 leader역할 수행
- kafka cluster 구조
- kafka cluster는 broker , zookeeper , producer , consumer 등으로 구성됨
- cluster에는 여러개의 broker가 있으며, 각 broker는 특정 partition에 속하는 data를 저장 및 관리
- multi node에는 이러한 broker들이 각기 다른 server에 위치해서 장애 발생시에도 정상 동작 가능
- broker
- cluster내 각 server에서 실행되며, data partition을 저장하고 client요청도 처리
- cluster 내에서 server를 실행하는 각 개별 노드 ( 프레미스에서는 pc 1대가 노드 1개 )
- topic => 논리적으로 데이터를 분류하는 단위이며, 이를 여러조각으로 나눈게 partition이다.
- 같은 topic내의 partition들의 내용은 중복된거는 없다.
- partition이 3개의 복제본을 가지도록 설정했다면, 각 partition의 data가 3개의 broker(PC)에 중복 저장
- partition
- topic의 논리적 구분 단위이며, multi node에서는 partition을 여러 broker에 분산해 저장
- 복제
- 각 partition의 data를 복제본 형태로 여러 노드에 저장해서 신뢰성 보장
- 카프카에서 가용성에 대한 핵심 기능이다.
- kafka에서 각 partition들은 여러개의 복제본으로 구성됨. ( 크게 리더와 팔로워로 나뉨)
- leader replica => partition의 모든 읽기,쓰기 요청을 처리하는 주요 복제본
- follower replica => leader를 따라서 데이터를 복제. leader가 장애시 대신하기 위한 준비를 함.(지속적으로 동기화)
- 복제는 leader에서 follower로만 이루어진다. ( follower가 leader의 partition을 읽어감 )
- 복제본 간의 동기화 상태를 나타내는 2가지 개념 ISR , AR 존재
- ISR( in sync replica)
- leader와 동기화가 완료된 복제본으로 구성된 집함. 이는 leader와 동일한 data를 가지니, leader가 장애 발생시 ISR의 팔로워가 leader로 승격 될 수 있다.
- ISR의 동기화 상태를 유지하는 것이 kafka의 데이터 안전성에 중요.
- 복제본이 많아질수록 안전성이 높아지지만, 네트워크 비용이나 시스템 부하가 증가 될 수 있음
- AR ( assigned replica )
- 해당 파티션에 할당된 모든 복제본. 여기에는 leader와 follower의 복제본이 포함됨.
- replication.factor 파티션의 복제본 개수를 지정
- replication.factor가 3이면, 원본 partition , 복제 partition을 포함해서 모두 3개의 파티션을 가짐을 의미
- replication.factor는 broker의 개수보다 클 수 없다.
- acks옵션
- acks=0 => client가 broker의 응답을 기다리지 않음. 데이터 손실 가능성이 크다.
- acks=1 => leader 복제본 쓰기 성공시 응답이며, leader에만 기록이 남음.
- acks=2 => 모든 ISR복제본에 쓰기가 완료될 때만 응답을 하며, 가장 안전하다.
- 데이터 동기화 과정
- follower replica는 leader의 log를 실시간으로 복제해서 data를 동기화 함.
- 1. 로그복사 => follower는 leader의 data 변경사항을 받아와서 자신에게 기록.
- 2. ISR유지 => leader는 follower가 data를 빠르게 동기화 못하면 해당 follower를 제거.
- 3. 최소 ISR 요구사항 => min.insync.replicas로 최소 ISR수를 유지한다. 일정 갯수 이하면, 더이상 쓰기 허용x
- 만약 leader가 장애가 나는 상황...
- 1. kafka controller는 주기적으로 zookeeper로 leader의 상태를 확인한다.
- 2. 만약 장애 감지시, ISR에 포함된 팔로워중 하나가 새 leader로 승격.( 주로 가장 빠르게 동기화 된 follower선택)
- 3. data 요청 재전송 =>client는 새 leader replica에게 data를 소비 or 생산 한다.
- zookeeper
- cluster metadata를 관리하고, 리더 선출 등의 역할을 한다.
- 즉, 중앙화된 metaData 관리 시스템이다. ( 분산 코디네이션 서비스 )
- cluer 내의 node들이 일관된 상태를 유지하게 도우며, 장애 발생시 신속하게 복구 할 수 있게 함.
- 주키퍼 서버
- 분산 코디네이션을 위하여 여러 서버로 구성됨. 홀수 개로 구성해서 다수결 투표로 장애에 대응
- ZNode
- 주키퍼에 저장되는 데이터 단위
- 노트 형태의 경로를 가지며, 트리 구조로 관리
- 각 Znode는 data와 metaData를 포함한다
- 주요기능
- broker관리
- metaData 저장
- leader 선출
- 설정관리 및 동기화
- cluster 상태 모니터링
- kafka와 zookeeper 간의 상호작용
- broker등록 및 연결 정보 관리
- partition leader 선출
- 특정 partition의 leader가 다운되면, zookeeper가 ISR내의 follower중 하나를 새로운 leader로 선출
- kafka broker들의 변경 사항을 실시간으로 감지함.
- zookeeper의 한계
- 복잡성 증가
- 확장성 제약
- 고가용성 관리의 부담
- kafka controller broker
- kafka cluster가 시작되면, 여러 broker중 하나가 controller 역할을 맡게 됨. 이는 zookeeper와 상호작용해서 선출.
- cluster의 관리와 metaData 변경 사항을 담당하는 특별한 broker로, cluster 내 중앙 조정 역할을 수행
- controller broker는 주로 zookeeper와 상화작용하며 broker,partition,leader 등 cluster의 전반적인 상태를 관리
- controller broker는 모든 metadata변경 사항을 cluster내의 broker들에게 전파
- 역할
- partition leader 선출 및 관리
- broker 상태 관리
- partition 재배치와 replica 관리
- metaData 변경 반영
- 선출 과정
- 1. cluster의 각 broker는 zookeeper에 controller로 선출되기 시도함
- 2. 가장 먼저 요청한 broker가 controller로 선출 및 zookeeper는 이를 기록함.
- 3. 선출된 broker는 zookeeper의 controller node에 정보를 기록하며, 역할을 수행
- 만약 controller가 장애가 나면?
- zookeeper가 이를 감지하고 다시 뽑는다.
kafka-topics --bootstrap-server localhost:9092 --create --topic multi-broker-02 --partitions 3 --replication-factor 3
