kafka KRaft

이번 포스팅에서는 저번 카프카를 다룰 때 주키퍼가 제거된다는 것을 말했었고 현재는 3.7이지만 지금 버전이 주키퍼를 사용할 수 있는 마지막 버전이다. 그러므로 크래프트에 대해 알아보고 마이그레이션도 알아보자.

 

KRaft가 생긴 이유

아파치 카프카의 분산 시스템을 관리하기 위해 도입된 메커니즘이다.

아파치 주키퍼를 사용해서 클러스터 메타 데이터의 관리와 조정을 했지만 주키퍼의 의존성은 카프카 확장성과 유지보수에 제약을 갖게 했다. 해결하기 위해서 카프카 자체로 내부에서 분산 시스템의 상태를 관리하는 방식을 도입하고자 만들어졌다.

 

1. 브로커는 모든 토픽과 파티션에 대한 메타데이터를 주키퍼에서 읽어야 하며, 메타데이터의 업데이트는 주키퍼에서 동기방식으로 일어나고 브로커에는 비동기 방식으로 전달됐다. 이 과정에서 메타데이터의 불일치 발생과 재시작 시 모든 메타데이터를 주키퍼로부터 읽어야 하는 부담으로 인함과 토픽과 파티션이 많은 대규모 클러스터에서 오랜 시간이 걸리는 병목 현상이 발생할 수 있다.

 

2. 주키퍼와 카프카는 완전히 서로 다른 애플리케이션이기 때문에 서로 다른 구성 파일과 환경 서비스 데몬을 가지고 있다. 그러므로 관리자는 동시에 서로 다른 애플리케이션을 운영해야 한다. 동시에 두 가지 애플리케이션을 운영한다는 것으로 부담이 된다. 

 

3. 모니터링에 있어 주키퍼와 카프카를 모두 모니터링해야 하는 부분에서 이 둘은 각 메트릭을 이해하고 모니터링하는 방법도 다르기에 각각 서비스를 이해해야 하지만 크래프트는 하나로 관리하게 된다.

 

1, 2, 3 으로 인해 KRaft에 생성 이유를 알아볼 수 있다.

 

KRaft의 주요 목적

카프카의 구조를 단순화하고 확장성을 향상시키기 위함으로 주키퍼를 제거함으로 설치, 구성, 유지보수가 단순화될 것이고 카프카의 성능과 안정성도 향상될 것이다. 

 

 

주키퍼와 카프카 구성 차이

 

주키퍼는 주키퍼 앙상블과 카프카 클러스터가 존재하고 카프카 클러스터 중 하나의 브로커가 컨트롤러의 역할을 하게 된다.

컨트롤러는 파티션의 리더를 선출하는 역할을 하고 리더 선출 정보를 브로커에게 전파하고 주키퍼에 리더 정보를 기록하는 역할을 한다.

컨트롤러의 선출 작업은 주키퍼를 통해 실행되는데 주키퍼의 임시노드로 이루어진다.

이를 통해 한번에 하나의 컨트롤러만 클러스터에 존재하게 보장한다.

 

크래프트에서는 주키퍼 의존성을 제거하고 카프카 단일 애플리케이션 안에서 메타데이터 관리 기능을 수행하는 독립적인 구조가 되는 것이다.

컨트롤러도 늘어나고 이들 중 하나의 컨트롤러가 컨트롤러이며 리더의 역할을 담당하게 된다.

리더 역할의 컨트롤러가 write하는 역할도 하게 된다.

이로써 내부의 별도 토픽을 이용해 메타데이터를 관리하고 리더 역할을 한느 컨트롤러가 장애 또는 종료될 경우 내부에서는 새로운 합의 알고리즘을 통해 새로운 리더를 선출하게 된다.

 

KRaft 성능

주요 성능 개선중 하나는 파티션 리더 선출의 최적화로 크래프트에서 더 많은 파티션 생성이 가능하게 됐다.

 

KRaft의 구성

크래프트로 인해 브로커와 크래프트를 분리된 서버에 배치해야 하는지 궁금할 수 있지만 분리된 서버에 배치하는 것을 권고한다.

그러므로 주키퍼 서버의 리소스 절약을 목적으로 크래프트로 전환하는 것을 고려하는 것은 추천하지 않으며 한정된 자원 내에서 실행해야 한다면 동일한 서버에서 배치하는 것도 고려할 수 있다. 하지만 크래프트 사용으로 인해 주키퍼에 대한 의존성이 제거되어서 관리도 단순화되고 물리적 서버의 리소스도 절감이 가능하며 주키퍼는 추후 제거될 예정이니 크래프트에 대한 사용법을 익혀두는 것이 좋을 것 같다.

 

 

공식 문서에 따라 크래프트 구성은 권장 방식은 브로커와 별개로 크래프트 서버를 할당해 운영하는 것이다.

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

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

 

서버의 리소스가 한정적인 경우 위처럼 크래프트와 브로커를 동시에 운영할 수 있다. 이경우 브로커와 컨트롤러가 동일한 서버에서 실행되므로 해당 서버에 장애가 발생 시 컨트롤러 역시 종료될 수 있다. 

추천하지 않는 방식이지만 작은 규모의 카프카 클러스터 구성 운영에는 적합하다.

 

주키퍼에서 크래프트 마이그레이션

마이그레이션 방법에 대해 알아보자.

전반적인 마이크레이션 방법과 공식 페이지의 마이그레이션 방법을 통해 마이그레이션을 진행해 보도록 하겠다.

 

현재 주키퍼 버전 모드 -> 1차 카프카 버전 업그레이드(브리지 모드) -> 2차 크래프트 모드 마이그레이션

전환으로 단순한 업그레이드는 아니며, 내부적으로 사용하는 API와 근본적인 변환으로 인해 주키퍼 모드에서 크래프트 모드로 다이렉트 마이그레이션은 불가능하다.

이로 인해 카프카는 브리지 모드를 도입했고 브리지 모드는 주키퍼 모드와 크래프트 모드를 동시에 지원하며 두 모드 사이 다리역할을 하게 된다.

단계별로 살펴보자.

1단계: 카프카 3.0 버전 + 주키퍼 -> 카프카 3.6 버전 + 주키퍼

마이 그레이션 GA가 지원되는 카프카 버전은 3.6으로 먼저 업그레이드를 해야 한다.

2단계: 카프카 3.6 버전 + 주키퍼 -> 카프카 3.6 버전 + 크래프트

이렇게 적용할 시 사전준비는 끝이고 이제 실제 마이그레이션을 해보자.

필자는 카프카 3.7 버전을 사용 중이고 이전 예제는 카프카 3.7과 주키퍼를 사용했어서 바로 크래프트로 마이그레이션 해보고자 한다.

https://docs.confluent.io/platform/current/installation/migrate-zk-kraft.html

해당 페이지에서 마이그레이션에 대한 설명을 확인할 수 있다.

 

카프카 마이그레이션을 해보는 도중 데이터를 데이터를 가져오는 도중 데이터를 포맷해버려서 추후에 주키퍼 사용하다 크래프트로 마이그레이션 하는 포스팅으로 돌아오도록 하겠다... 레퍼런스가 많지 않아서 공식 문서 보고 따라 하다 잘못된 동작을 해버렸다. 나중에 하면 그래도 할 수 있을 것 같기에 추후에 올리도록 하겠다.

 

여기까지 카프카에 크래프트에 대해 알아보았다.

다음 포스팅은 멀티 모듈에 대해 자세하게 알아보는 포스팅으로 찾아오도록 하겠다.

멀티 모듈을 사용해 보았지만 지금의 내 기준으로 모듈을 나누면 모듈을 나누는 것보다 오히려 의존성도 더 꼬이게 되고 성능도 안 좋아지고 객체지향이 지향하는 특성에 위배될 것이 명명백백하기 때문에 다음 포스팅으로 멀티 모듈에 대해 더 자세히 알아보고 필자 프로젝트를 가져와서 구조를 설명하고 구조를 어떤 식으로 나눌지 고민하는 포스팅으로 오겠다. 멀티 모듈을 하면서 지금은 AWS에 필요 없는 금액이 부여돼서 배포를 삭제했지만 도커를 사용해서 배포를 진행할 수 있게끔 구성하도록 하기도 하겠다.