[Kafka] 브로커, 토픽, 주키퍼

 

브로커 + 토픽

 

카프카 브로커

• 카프카 클러스터는 다수의 브로커(서버)들로 구성되어 있다.
• 각각의 브로커는 정수형ID로 구분된다.
• 각 브로커는 특정한 토픽 파티션만 포함된다.
• 임의의 브로커에 연결된 이후(부트스트랩 브로커라고도 불림) 전체의 클러스터에 연결하게 된다.

 

브로커와 토픽

• 토픽-A 는 3개의 파티션을 가지고 있다고 간주하고, 토픽-B는 2개의 파티션을 가지고 있다고 간주하자
• 토픽 파티션은 모든 브로커에 걸쳐 분산되게 된다. 브로커에 토픽-B 데이터가 존재하지 않아도 가져야 할 데이터만 가지고 있기 때문에 정상이라고 볼 수있다.
• 이는 카프카 스케일을 이루고, 수평적 스케일링이라고 부른다.

 

카프카 브로커의 전개

• 카프카의 각각의 브로커는 "부트스트랩 서버"라고도 불린다.
• 하나의 브로커에만 연결이 된다면, 카프카 클라이언트는 전체의 클러스터와 어떻게 연결할지 알고있다. (스마트 클라이언트)
  1. 연결개시 + 메타데이타 요청
  2. 성공하면 클러스터 안에 있는 모든 브로커의 리스트를 리턴한다.
  3. 프로듀스, 컨슘하기 위한 다른 브로커와의 연결이 가능해진다.

 

토픽복제(Topic Replication factor) 

• 토픽은 복제계수가 1보다 커야함(실제 카프카 클러스터가 있을 때, 2 ~ 3 으로 설정한다.)
• 점검 및 이상현상으로 인해 브로커가 다운되었을때, 다른 브로커가 데이터를 서빙할 수 있다.
• 아래는 토픽-A 가 2개의 파티션을 가지고 복제계수를 2로 설정한 것의 예시이다.

 

• 그렇다면, 만약 브로커102를 잃으면 어떻게 될까?

• 여전히, 101브로커와 103브로커가 살아있기 때문에 데이터를 제공할 수 있다.

 

파티션을 위한 리더설정

• 하나의 브로커에 하나의 파티션만이 리더로서의 설정이 가능하다.
• 프로듀서는 한 브로커의 파티션리더에게만 데이터를 보낼 수 있다.
• 따라서, 각각의 파티션은 하나의 리더를 가지고 여러 ISR을 가질 수 있다. (레플리카를 ISR(in-sync replica)이라고 부른다.)

 

 

리더에 의한 프로듀서와 컨슈머의 기본적인 행동

• 리더의 기본적인 작동방식은 카프카 프로듀서는 리더 파티션 브로커에만 기록하게 된다.
• 프로듀서와 마찬가지로 컨슈머에서도 리더 파티션 브로커에서만 읽게된다.
• 만약 브로커 101이 다운되더라도 102에서 데이터를 읽어올 수 있도록 프로듀서와 컨슈머에게 데이터를 제공할 수 있다.

 

 

카프카의 컨슈머의 레플리카 가져오기(Fetching)(Kafka 2.4+)

• 카프카2.4 이상의 버전으로부터, 컨슈머가 가장 가까운 레플리카에서 읽게 해주는 기능이 생겼다. 
• 레이턴시를 개선하는데 도움이 될뿐만더러, 네트워크 코스트를 낮추기 때문에 클라우드 비용이 적게 드는 이점이 있기 때문이다.

 

프로듀서 확인 + 토픽 내구성

프로듀서 확인(acks)

• 프로듀서는 데이터 쓰기에 대한 확인을 받을 수 있다. 즉, 쓰기가 성공적으로 이루어졌다는 확인을 카프카 브로커로부터 받는다.
  • acks = 0: 프로듀서가 확인을 기다리거나 요청하지 않는것 (브로커가 다운되어도 모르기 때문에, 데이터 손실이 발생할 수 있음)
  • acks = 1: 프로듀서가 리더를 기다리게 된다 (제한적인 데이터 손실이 발생할 수 있음)
  • acks = all: 리더와 레플리카(ISR)가 쓰기를 확인하라고 요구하게 되는것 (데이터 손실이 발생하지 않음)

 

카프카 토픽 내구성

• 만약 복제 계수가 2이고 브로커가 3개라면 브로커 102를 잃더라도 여전히 토픽 데이터가 제공된다. (아직 다른 브로커에 존재하기 때문)
• 일반적으로 N이라는 숫자의 복제 계수를 선택하면, 최대 N-1개의 손실이 발생해도 카프카의 데이터 사본이 클러스터의 어딘가에 존재하게 된다.

 

주키퍼(Zookeeper)

• 주키퍼는 카프카 브로커를 관리한다. 파티션의 리더 선출에 대해 도움을 준다.
• 변경사항(토픽생성, 브로커가 죽거나 생길경우, 토픽삭제 등..)이 있는 경우 주키퍼가 카프카 브로커들에게 알림을 전송한다.
• 카프카 2.x 버전은 주키퍼 없이는 사용하는것이 불가능하다.
• 카프카 3.x 버전은 주키퍼 없이 사용가능하다 (KIP-500) Kafka Kraft
• 카프카 4.x 는 주키퍼가 없어질 예정이다.
• 주키퍼는 홀수개수(1,3,5,7) 개의 서버와 함께 작동하도록 설계되어 있다.
• 주키퍼는 리더(writes)와 나머지의 팔로워(reads)가 되도록 한다. 1개는 쓰기에 나머지는 읽기에 사용된다.
• 오래된 카프카 버전에서는 컨슈머 오프셋을 주키퍼에 저장하도록 했었는데 최근에는 컨슈머 오프셋이라는 이름의 내부 카프카 토픽에 저장한다.

 

 

주키퍼 클러스터(ensemble)

 

 

계속 주키퍼가 필요할까?

• 카프카 브로커 관리에 있어서는?: Yes!
  • 카프카 4.0이 나오기 전까지는 프로덕션에서 주키퍼 없이 카프카를 사용할 수 없다.
• 카프카 클라이언트에 있어서는?: Hell no
  • 주키퍼를 대신하는 유일한 연결 엔드포인트로서 브로커를 활용하도록 이전해왔다.
  • 모든 카프카 클라이언트와 CLI툴들은 오로지 카프카 브로커를 연결 엔드포인트로 활용하도록 이전되었다. 따라서, 컨슈머도 주키퍼에 연결해야하지 말아야한다.
  • 또한, 주키퍼는 카프카에 비해 안전하지 않다. 만일 주키퍼를 사용하게 된다면 카프카 브로커로부터의 연결만 수락하도록 해서 주키퍼를 보호해야한다.

 

 

Kafka KRaft - 주키퍼 지우기

• 100,000개 이상의 카프카 클러스터가 주키퍼 위에 있을때 문제가 발생하는 경우가 잦았다. 따라서, 주키퍼를 지우기위한 노력을 했다.
• 카프카가 주키퍼에 대한 의존을 없앰으로써 다음과 같은 이점을 얻게 되었다.
  • Apache Kafka는 수백만 개의 파티션으로 확장할 수 있다.
  • 유지보수와 설정도 쉬워지고 안정성도 개선되고 Kafka를 모니터링, 지원, 관리하기가 쉽다.
  • 시스템 전체에 하나의 보안 모델을 사용할 수 있다.(주키퍼 보안은 다루지 않고 Kafka 보안만 다루기 때문)
  • Apache Kafka를 쓰면 시작 프로세스도 하나면 충분하기 때문에 컨트롤러 셧다운 시간과 복구 시간도 단축된다.

 

카프카 Kraft 아키텍쳐

• 합의체의 비교를 해보면, 카프카의 관리를 위한 주키퍼 합의체가 존재하는 반면 카프카 브로커에서의 하나가 리더로써 존재한다.

 

 

Kraft으로 인한 성능 개선