728x90
반응형
목적
Kraft 도입에 대한 니즈를 소개하기 위함
등장 배경
기존 아파치 주키퍼의 경우 아래의 문제점이 있었음
- 성능적인 부분
- 브로커는 모든 토픽과 파티션에 대한 메타데이터를 주키퍼에서 읽어야 하며, 메타데이터의 업데이터는 주키퍼에서 동기방식으로 일어나고, 브로커에는 비동기방식으로 전달됨. 이 때문에 토픽과 파티션이 많은 대규모 카프카 클러스터에서는 지연이 등의 병목현상이 발생하게 됨
- 관리적인 부분
- 주키퍼와 카프카는 완전히 다른 애플리케이션으로 서로 다른 구성 파일, 환경, 서비스 데몬을 가지고 있음. 결국 관리자는 동시에 서로 다른 애플리케이셩늘 운영해야 함
- 모니터링 등
- 서로 다른 애플리케이션인 만큼 모니터링을 적용하는 방법과 주요 메트릭도 다름
Kraft의 주요 목적
카프카의 구조를 단순화하고 확장성을 향상시키기 위함
주키퍼 vs Kraft
- 주키퍼 앙상블과 카프카 클러스터가 존재하며 카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 하게 됨
- 컨트롤러는 파티션의 리더를 선출, 리더 선출 정보를 브로커에게 전파하고 주키퍼에 리더 정보를 기록하는 역할을 함
- 컨트롤러의 선출 작업은 주키퍼를 통해 이루어지는데, 주키퍼의 임시노드를 통해 이루어짐
- 즉, 컨트롤러가 할 일이 너무 많아짐
- 카프카 단일 애플리케이션 내에서 메타데이터 관리 기능을 수행하는 독립적인 구조가 됨
- 주키퍼에서는 1개였던 컨트롤러가 3개로 늘어나고, 이들 중 하나의 컨트롤러가 액티브(그림에서는 노란색 컨트롤러) 컨트롤러이면서 리더 역할을 담당함
- 리더 역할을 하는 컨트롤러가 write 하는 역할도 하게 됨
- 주키퍼에서는 메타 데이터 관리를 주키퍼가 했다면, Kraft에서는 카프카 내부의 별도 토픽을 이용하여 메타 데이터를 관리함
Kraft의 성능
Kraft의 주요 성능 개선 중 하나는 파티션 리더 선출의 최적화임. 파티션이 적을 때에는 이 리더 선출 작업이 다른 클라이언트에게 영향이 없겠으나, 대량의 파티션에 대한 리더 선출 작업은 시간이 다소 소요되어 크리티컬한 요소가 될 수 있음
따라서 주키퍼에서는 카프카 클러스터 전체의 파티션 제한을 20만개까지로 하였으나, Kraft에서는 더 많은 파티션 생성이 가능함
- 복구 소요시간에서 속도 차이가 나는 이유는 Kraft에서의 컨트롤러는 메모리 내에 메타데이터 캐시를 유지하고 있기 때문에 동기화와 관리과정이 간소화 되었음
- 또한 액티브 컨트롤러 장애 시 최신 메타데이터가 메모리에 유지되고 있으므로 메타데이터 복제 시간도 줄어듦
참고
728x90
반응형