KRaft의 개념과 Kafka와의 상관관계

 

 

 

주키퍼는 카프카와 보편적으로 함께 사용되는 서비스이다.

주키퍼와 카프카의 개념을 잘 모르겠다면 아래 포스트를 참고하면 된다.

하지만, 주키퍼와 카프카를 같이 사용할 때 문제점들이 발생하면서, 이를 보완하기 위한 새로운 서비스가 등장하게 된다.

 

Zookeeper의 개념과 Kafka와의 상관관계

 

 

---

 

 

 

 

 

KRaft가 생긴 배경

 

Zookeeper 사용 시의 문제점

1. 성능

브로커는 모든 토픽과 파티션에 대 한 메타데이터를 주키퍼에서 읽어야 한다.

하지만, 메타데이터의 업데이터는 주키퍼에서 동기방식으로 일어나고 브로커에서는 비동기방식으로 전달된다.

이 과정에서 메타데이터 불일치가 발생할 수 있다.

 

또한, 컨트롤러 재시작 시 모든 메타데이터를 주키퍼로부터 읽어야하는 것도 성능 면에서 부담이 된다.

특히 토픽과 파티션이 많은 대규모 카프카 클러스터에서는 오랜 시간 걸리는 등 병목현상이 발생할 수 있다.

 

---

 

2. 관리

주키퍼와 카프카는 서로 다른 애플리케이션으로, 서로 다른 구성 파일과 환경, 서비스 데몬 등을 가지고 있습니다.

결국 관리자는 동시에 서로 다른 애플리케이션을 운영해야 하므로 관리 면에서 번거로움을 준다.

예를 들어, 주키퍼의 릴리즈 노트 확인, 버전 업그레이드, 구성 파일 변경과 동시에 카프카의 릴리즈 노트 확인, 버전 업그레이드, 구성 파일 변경이 필요하다.

 

 

---

 

3. 모니터링

주키퍼와 카프카는 서로 다른 애플리케이션이므로, 모니터링을 적용하는 방법과 각 애플리케이션에서 보여주는 주요 메트릭도 다르다.

그 외에도 각 애플리케이션에서 발생하는 이슈 또는 장애상황에 개별적으로 대처해야 하며,

두 애플리케이션 간 통신 이슈가 발생할 수 있는 위험이 있다.

 

 

---

 

 

 

 

 

 

KRaft의 주요 목적은 카프카의 구조를 단순화하고 확장성을 향상시키기 위함이다.

주키퍼를 제거함으로써 설치, 구성, 유지보수가 단순화될 뿐만 아니라 카프카의 성능과 안전성 역시 크게 향상된다.

KRaft를 카프카와 결합하여 운영 복잡성을 줄이고, 유연한 시스템으로 만들어 대규모 데이터 처리 환경에서의 효율성을 높일 수 있다.

 

주키퍼 모드 vs KRaft 모드

 

 

주키퍼 모드는 주키퍼 앙상블(=여러 서버로 구성된 클러스터)과 카프카 클러스터가 존재하며,

카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 하게 된다.

 

분류	역할
카프카 컨트롤러 (1개)	파티션의 리더 선출, 메타데이터 관리, 리더 변경, 파티션 할당, 주키퍼와의 상호작용 1. 주키퍼의 임시노드에 가장 먼저 연결에 성공한 브로커가 컨트롤러가 됨. 2. 해당 임시노드에 컨트롤러가 있다는 사실을 통해 카프카 클러스터 내 이미 컨트롤러가 있다는 것을 인식함
주키퍼	리더 정보를 기록
메타데이터	카프카 컨트롤러가 클러스터의 상태, 토픽, 파티션 정보 등을 주키퍼에 저장

카프카 리더의 역할
1. 특정 파티션에 대한 모든 읽기 및 쓰기 요청을 처리한다. 클라이언트는 리더에게 직접 요청을 보내고, 리더는 해당 요청을 처리하여 결과를 반환한다.
2. 자신의 파티션에 대한 데이터를 다른 팔로워(복제 브로커)에게 복제하는 역할을 한다. 이를 통해 데이터의 일관성을 유지하고, 장애 발생 시 데이터 손실을 방지한다.
3. 각 소비자 그룹의 오프셋을 관리하여, 소비자가 어떤 메시지를 읽었는지 추적한다. 이를 통해 소비자는 중복된 메시지를 읽지 않도록 할 수 있다.

* 오프셋: 메시지가 저장된 위치를 나타내는 고유한 식별자 / 해당 메시지가 저장된 순서

 

 

---

 

 

 

KRaft 모드는 주키퍼와의 의존성을 제거하고, 카프카 단일 애플리케이션 내에서 메타데이터 관리 기능을 수행하는 독립적인 구조이다.

주키퍼 모드와 다르게 컨트롤러가 3개이며, 이들 중 하나의 컨트롤러가 액티브 컨트롤러이면서 리더 역할을 담당한다.

(리더 역할을 하는 컨트롤러가 Write 역할도 수행한다.)

 

액티브 컨트롤러가 장애 또는 종료되는 경우, 내부에서 새로운 합의 알고리즘을 통해 새로운 리더를 선출한다.

분류	역할
카프카 컨트롤러 (3개)	파티션의 리더 선출, 메타데이터 관리, 리더 변경, 파티션 할당, 클라이언트와 상호작용 1. 후보자들이 적합한 리더를 투표하게 됨 2. 후보자 중 충분한 표를 얻으면, 해당 컨트롤러가 새로운 리더가 됨
메타데이터	카프카 내부의 별도 토픽을 이용하여 관리

 

 

 

---

 

 

 

 

 

KRaft의 성능

 

KRaft의 주요 성능 개선 중 하나는 파티션 리더 선출의 최적화이다.

소수의 파티션에 대한 리더 선출 작업은 카프카 또는 카프카를 사용하는 클라이언트들에게 별다른 영향이 없지만,

대량의 파티션에 대한 리더 선출 작업은 다소 시간이 소요되어 대량의 데이터 파이프라인 역할을 하는 카프카와 클라이언트들에게 매우 크리티컬한 요소일 수 있다.

 

따라서 이러한 지연 시간을 방지하고자 주키퍼 모드의 경우 카프카 클러스터 전체의 파티션 리미티는 약 200,000개 정도였으나,

리더 선출 과정을 개선한 KRaft 모드에서는 훨씬 더 많은 파티션 생성이 가능하다.

 

 

KRaft모드 컨트롤러는 메모리 내에 메타데이터 캐시를 유지하고 있어, 메타데이터 복제하는 시간이 줄어들어 보다 효율적인 컨트롤러 리더 선출 작업이 일어난다.

더불어 주키퍼와의 의존성도 제거해 내부적으로 메타데이터의 동기화와 관리과정을 효율적으로 개선했기 때문에 주키퍼와 큰 차이가 날 수 밖에 없다.

 

---

 

 

 

 

 

KRaft의 구성

 

주키퍼 서버의 리소스 절약을 주된 목적으로 KRaft로 전환하는 것은 추천하지 않는다.

KRaft 모드에서도 브로커와 KRaft를 분리된 서버에 배치하는 것을 강력 추천하고 있기 때문이다.

 

위 구성은 브로커와 컨트롤러를 분리하여 높은 가용성과 안정성을 확보하는데 중점을 둔다.

이렇게 분리된 구성은 시스템의 장애 포인트를 최소화하고, 하나의 구성 요소에서 문제가 발생했을 시 전체 시스템에 미치는 영향을 줄일 수 있다.

특히 대규모 카프카 클러스터를 운영하거나, 엄격한 SLA를 충족해야 하는 비즈니스 환경에서는 반드시 브로커와 별개로 구축하기를 추천한다.

 

 

---

 

 

서버의 리소스가 한정적인 경우에는 브로커와 KRaft를 동시에 운영할 수 있다.

이 경우 해당 서버에서 장애가 발생하면 컨트롤러 역시 불필요하게 종료될 위험이 있다.

작은 규모의 카프카 클러스터를 운영하거나, 개발 용도의 경우 적합하다.

 

---

 

 

 

KRaft 서버 권장 사항

 

KRaft가 카프카와 같이 많은 데이터를 처리하지 않으므로 권장 사양은 높지 않다.

CPU	CPU를 공유하는 경우 Dedicated CPU
MEM	최소 4GB
DISK	최소 SSD 64GB
JVM	최소 1GB

 

---

 

 

 

 

 

주키퍼 모드 👉 KRaft 모드 마이그레이션

 

예전 자료들을 보면 기본적으로 카프카 구축 시 주키퍼를 사용하도록 설명되어 있다.

위와 같은 문제로 KRaft로 마이그레이션 하려고할 때의 방법을 살펴보자.

 

서비스 중단 없이 마이그레이션 하는 방법은 아래와 같다.

 

주키퍼 모드 -> 카프카 버전 업그레이드(브릿지 모드) -> KRaft 모드 마이그레이션

 

내부적으로 사용하는 API와 구성의 근본적인 변화로 인해 KRaft로 바로 마이그레이션은 불가능하다.

브릿지 모드는 주키퍼 모드와 KRaft 모드를 동시에 지원하며 두 모드 사이의 다리 역할을 한다.

주키퍼 마이그레이션 GA가 지원되는 브릿지 모드 버전으로는 카프카 3.6버전을 추천한다.

(카프카 4.0 이상부터는 KRaft 모드로만 사용이 가능하다.)

GA(General Availability)
소프트웨어나 제품이 일반 사용자에게 안정적으로 제공될 준비가 완료되었음을 의미한다.
즉, 베타 버전의 테스트를 통해 안정성이 확보되었고, 실제 운영 환경에서 사용하기에 적합하다는 의미이다.

 

 

---

 

 

단계	카프카 버전	with	설명
1	3.0	주키퍼 모드	- 현재 카프카 버전에서 주키퍼 마이그레이션 GA가 지원되는 카프카 3.6 버전으로 업그레이드. - 롤링 업그레이드 방식으로 진행할 수 있으며, 클라이언트의 타임아웃이 일부 발생하기는 하지만 무중단으로 업그레이드가 가능함.
2	3.0 -> 3.6	주키퍼 모드	- 마이그레이션 방법은 공식 문서를 참고. - 마이그레이션 역시 롤링 업그레이드 방식으로 진행됨.
3	3.6	KRaft 모드	- KRaft 모드를 사용 시 클러스터의 메타 데이터관리를 자체적으로 수행할 수 있으며, 이에 따라 새로운 도구들이 필요함. (kafka-metadata-quorum 도구는 클러스터 ID, 현재 리더, 팔로워 LAG 등 중요한 정보를 조회하는 데 사용되며, 현재 상태와 리더, 팔로워 LAG 등을 파악하는데 필수적인 도구이다.)

롤링 업그레이드(rolling upgrade)
시스템이나 애플리케이션의 업그레이드를 단계별로 진행하는 방법이다.
이 방식은 시스템을 한 번에 중단하지 않고, 일부 노드나 서버를 순차적으로 업그레이드하여 서비스의 가용성을 유지하는 데 도움을 준다.

 

 

 

 

 

 

 

---

참고사이트

Apache Kafka의 새로운 협의 프로토콜인 KRaft에 대해(1)

Apache Kafka의 새로운 협의 프로토콜인 KRaft에 대해(2)