kafka가 Zookeeper대신 KRaft를 사용하는 이유가 뭘까?

카프카를 왜 사용해야 할까?

이전에 카프카가 어떻게 동작하며 왜 필요한지에 대해 학습한 적이 있습니다. 간단히 복습해 보겠습니다. 카프카는 단순한 MQ 시스템이라고 보기는 어렵습니다. MQ 시스템의 구조와 유사한 점은 있지만, 보다 정확하게 표현하면 중앙 이벤트 로깅 시스템에 가깝습니다. 물론 전체적인 구조는 MQ와 크게 다르지 않습니다. 프로듀서(Producer)가 메시지를 발행하고, 컨슈머(Consumer)가 이를 소비하며, 그 사이에는 메시지를 저장하고 전달하는 브로커(Broker)이 존재합니다. 그래서 처음 접하게 되면 "그냥 여러 번 읽을 수 있는 MQ 시스템 아닌가?"라고 이해할 수도 있습니다. 이러한 이해도 크게 틀린 것은 아니지만, 카프카를 단순히 MQ라고 표현하는 것은 다소 부족한 설명이 될 수 있습니다. 그렇다면 한 가지 의문이 생길 수 있습니다. 왜 프로듀서와 컨슈머만 있으면 되지, 굳이 브로커가 존재해야 할까요? 간단히 설명하면 브로커를 사용하는 이유는 효용성때문으로 이해하시면 됩니다. 자세한 내용은

EDA에도 패턴들이 이렇게나 많이 존재 하다니..

이 글을 참고해주면 감사하겠습니다. 초반에는 브로커와 브로커의 메타 정보를 읽는 Zookeeper가 존재하였습니다. 그렇다면 어째서 kafka내부에서 동작시키지않고 Zookeeper라는 외부 인프라를 이용하게 되었을까요?

Zookeeper는 무엇이고, 왜 사용하게 되었을까?

KRaft를 이해하기 전에 먼저 Zookeeper라는 시스템을 이해할 필요가 있습니다.
Zookeeper는 분산 시스템에서 상태를 관리하고 여러 노드의 동작을 조율하는 분산 코디네이션 시스템입니다.
kafka 초기 버전에서는 여러 브로커가 함께 동작하는 클러스터 구조를 사용합니다.

이때 어떤 브로커가 살아있는지, 누가 리더인지, 토픽과 파티션의 메타데이터는 무엇인지와 같은 클러스터 상태 정보를 관리할 필요가 있습니다. 여기서 브로커가 왜 이렇게까지 많이 필요할 이유가 있을까요? 브로커가 많다는 건 어떤 이점이 있을까요?

kafka는 기본적으로 대량의 데이터를 처리하기 위해 설계된 시스템입니다.
단일 서버로는 처리할 수 없는 수준의 트래픽과 데이터를 안정적으로 처리하기 위해 여러 개의 브로커를 사용하는 클러스터 구조를 채택하고 있습니다. (레디스의 전략과는 사뭇 다른 느낌이 듭니다. _.._)

어째서 위와 같은 클러스터 상태  정보들을 관리하는 이유가 무엇일까요?

kafka 초기 버전에서는 클러스터 상태 정보들을 관리하는 역할을 Zookeeper가 담당하고 있었습니다.
kafka는 여러 개의 브로커로 구성된 클러스터 환경에서 동작합니다.
이러한 구조에서는 단순히 메시지를 저장하는 것뿐만 아니라, 클러스터 전체의 상태를 지속적으로 관리해야 합니다.
이처럼 분산 환경에서는 시스템의 상태가 계속해서 변화할 수 있습니다.
kafka는 단순히 메시지를 전달하는 시스템을 넘어, 여러 서버가 함께 동작하는 분산 시스템이기 때문에 이러한 클러스터 상태 정보들을 관리하는 역할이 반드시 필요합니다.

결국 분산 환경에서 클러스터 상태 정보를 관리하기 위해 Zookeeper라는 분산 코디네이션 시스템을 사용하게 되었습니다.

이쯤에서 3가지 의문이 듭니다.

다른 기술들도 많을텐데 Zookeeper를 사용하는 이유가 무엇일까?

kafka가 처음 개발되던 시점에는 분산 시스템의 상태를 관리하는 표준적인 도구로 Zookeeper가 널리 사용되고 있었습니다.
Zookeeper는 다음과 같은 기능들을 제공하고 있었습니다.

• 분산 환경에서의 리더 선출(Leader Election)
• 분산 락(Distributed Lock)
• 클러스터 메타데이터 관리
• 노드 상태를 감지하는 Watch 기능

이러한 기능들은 kafka와 같은 분산 시스템에서 클러스터 상태를 관리하기 위해 필요한 요소들이었습니다.
따라서 kafka는 이러한 기능을 직접 구현하기보다는 이미 검증된 Zookeeper를 활용하는 방식을 선택하게 되었습니다.
결과적으로 kafka는 초기 설계에서 클러스터 상태 관리 역할을 Zookeeper에 위임하는 구조로 만들어지게 되었습니다.

초창기 kafka에서 Zookeeper를 사용하지 않는 다면, 어떻게 될까?

kafka는 여러 브로커로 구성된 클러스터 환경에서 동작합니다.
이 환경에서는 브로커의 상태, 파티션의 리더 정보, 토픽 메타데이터와 같은 클러스터 상태 정보를 지속적으로 관리해야 합니다.
만약 이러한 정보들을 관리하는 시스템이 존재하지 않는다면 다음과 같은 문제가 발생할 수 있습니다.

• 어떤 브로커가 살아있는지 알 수 없음
• 파티션의 리더가 누구인지 결정할 수 없음
• 토픽 및 파티션 메타데이터가 일관되게 유지되지 않음

이러한 상황에서는 클러스터가 일관된 상태를 유지하기 어렵기 때문에 kafka 시스템 자체가 정상적으로 동작하기 어려워집니다.

Zookeeper는 Kafka와는 별개의 시스템입니다. 그렇다면 Zookeeper에서 장애가 발생하면 어떻게 되는 것일까요?

결론부터 말하자면, Zookeeper 역시 단일 서버로 운영되지 않습니다. kafka와 마찬가지로 클러스터 형태로 구성하여 장애에 대응합니다.
Zookeeper는 여러 개의 노드로 구성된 Zookeeper Ensemble이라는 구조를 사용합니다.
일반적으로 3개 ~ 5개로 사용하는 경우가 많습니다. 이러한 구조에서는 과반수(Quorum) 기반으로 시스템이 동작합니다.
즉, 전체 노드 중 절반 이상이 정상적으로 동작하고 있다면 시스템은 계속해서 동작할 수 있습니다.
예를 들어 Zookeeper 노드가 3개라고 가정해보겠습니다.

이 중 한 노드가 장애가 발생하더라도 나머지 두 노드가 살아 있다면 과반수를 유지하기 때문에 시스템은 계속 동작합니다.
하지만 만약 과반수 이상의 노드가 장애가 발생하게 된다면 클러스터의 합의가 깨지게 되고 정상적인 동작이 어려워질 수있습니다.
이러한 이유로 Zookeeper는 단일 노드로 운영하기보다는 여러 노드로 구성된 클러스터 형태로 운영하는 것이 일반적입니다.
결과적으로 kafka는 브로커 클러스터 외에도 Zookeeper 클러스터를 함께 운영해야 하는 구조를 가지고 있었습니다.

합의는 분산락 3대 요소중 하나로 다음 포스트를 참고하시면 됩니다.

분산락은 도대체 무엇일까?

 

분산 환경에서 클러스터의 상태를 관리하기 위해 초창기 kafka는 Zookeeper를 사용했습니다. 하지만 kafka를 운영하기 위해서는 kafka 브로커뿐만 아니라 Zookeeper 서버도 함께 운영해야 하는 상황이 발생했습니다. 또한 Zookeeper에 장애가 발생할 경우, 심각한 상황에서는 kafka 클러스터의 관리 기능이 정상적으로 동작하지 않을 수도 있습니다. 이처럼 별도의 시스템에 의존하는 구조는 운영 복잡도를 높이는 문제가 있었습니다. 이러한 문제를 해결하기 위해 kafka는 Zookeeper 없이 메타데이터를 관리할 수 있는 구조인 KRaft(Kafka Raft Metadata mode) 를 도입하게 되었습니다.

KRaft는 Zookeeper과 무엇이 다른가?

지금까지 Zookeeper가 어떤 역할을 하는지 대략적으로 살펴보았습니다. 그리고 이러한 역할을 이제는 KRaft가 대신 수행하게 되었습니다. 이전의 kafka 구조에서는 브로커만으로 클러스터를 운영할 수 없었기 때문에 클러스터 상태 관리, 리더 선출, 메타데이터 관리와 같은 기능들을 Zookeeper가 담당하고 있었습니다.

즉, kafka가 직접 처리하지 못하는 클러스터 관리 기능을 외부 시스템인 Zookeeper에 의존하는 구조였습니다.

하지만 KRaft가 도입되면서 이러한 구조가 변경되었습니다. 이제 kafka는 Zookeeper 없이도 클러스터 메타데이터를 관리할 수 있게 되었으며, 관련 기능들은 kafka 내부에 포함된 KRaft 모듈이 담당하게 됩니다.
결과적으로 kafka는 더 이상 외부 시스템에 의존하지 않고 kafka 내부에서 클러스터 상태를 관리할 수 있는 구조로 변화하게 되었습니다.
이러한 구조 덕분에 기존처럼 Zookeeper 장애로 인해 kafka 운영이 복잡해지는 상황을 줄일 수 있게 되었습니다.

그렇다면 이러한 구조적인 차이 외에도 KRaft는 Zookeeper와 어떤 차이점이 있을까요?

가장 큰 차이점은 메타데이터를 관리하는 방식입니다.
기존 kafka 구조에서는 브로커의 상태, 토픽 정보, 파티션 정보와 같은 클러스터 메타데이터를 Zookeeper에 저장하고 관리했습니다.
kafka 브로커들은 필요할 때마다 Zookeeper와 통신하여 해당 정보를 조회하거나 변경했습니다.
하지만 KRaft 구조에서는 이러한 메타데이터를 kafka 내부의 로그(Log) 형태로 저장하고 관리합니다.

즉, kafka가 메시지를 로그 형태로 저장하는 것처럼 클러스터 메타데이터 역시 로그 기반으로 기록하고 복제하는 방식을 사용합니다.
이 과정에서 Raft 합의 알고리즘이 사용됩니다. Raft 합의 알고리즘을 통해 여러 kafka 노드가 메타데이터에 대해 합의를 이루고, 이를 통해 일관된 상태를 유지할 수 있습니다.

Raft 합의 알고리즘이란 무엇일까?

Raft는 분산 시스템에서 여러 노드가 동일한 상태를 유지하기 위해 사용하는 합의(Consensus) 알고리즘입니다.
분산 시스템에서는 여러 서버가 동시에 동작하기 때문에 다음과 같은 문제가 발생할 수 있습니다.

• 어떤 노드의 정보가 최신 상태인지 알기 어려움
• 동시에 여러 노드에서 상태 변경이 발생할 수 있음
• 네트워크 장애로 인해 노드 간 상태가 달라질 수 있음

이러한 상황에서 시스템이 정상적으로 동작하기 위해서는 모든 노드(브로커)가 동일한 상태에 대해 합의하는 과정이 필요합니다.
Raft 알고리즘은 바로 이러한 문제를 해결하기 위해 만들어진 합의 알고리즘입니다.

1. 여러 노드(브로커) 중 하나를 Leader로 선출하고, 나머지 노드(브로커)들은 Follower로 동작합니다.
2. Leader는 시스템의 상태 변경을 관리하는 역할을 하며, 상태 변경이 발생하면 이를 로그(Log) 형태로 기록한 뒤 다른 노드들에게 전파합니다.
3. 과반수 이상의 노드(브로커)가 해당 로그를 받아들이면 그 상태 변경은 합의된 상태(Committed) 로 인정됩니다.

이러한 과정을 통해 여러 서버가 존재하더라도 모든 노드(브로커)가 동일한 상태를 유지할 수 있게 됩니다.
kafka의 KRaft 구조에서도 이 Raft 알고리즘을 사용하여 클러스터 메타데이터를 관리하고 노드(브로커) 간 상태를 일관되게 유지합니다.

그렇담, Zookeeper는 어떤 합의 알고리즘을 무엇을 사용할까?

Zookeeper 클러스터에서는 다음과 같은 구조가 만들어집니다.

• Leader
• Follower

Leader가 상태 변경을 관리하고, Follower들은 Leader의 로그를 받아 복제합니다.
동작 과정은 대략 다음과 같습니다.

1. 클라이언트 요청이 Leader에게 전달됩니다.
2. Leader는 상태 변경을 트랜잭션 로그로 기록합니다.
3. 해당 로그를 Follower들에게 전파합니다.
4. 과반수 노드가 승인하면 commit 됩니다.

이 방식 덕분에 여러 노드가 존재하더라도 데이터의 순서와 일관성을 유지할 수 있습니다.

결론

kafka가 Zookeeper를 더 이상 사용하지 않고 KRaft를 사용하는 이유에 대해 살펴보았습니다. 기존 kafka 구조에서는 kafka 브로커와 함께 Zookeeper 서버를 별도로 운영해야 하는 구조였습니다. 이러한 구조는 시스템을 운영하는 과정에서 운영 복잡도를 증가시키는 요소가 되었습니다. 또한 Zookeeper에 심각한 장애가 발생할 경우, kafka 클러스터의 메타데이터 관리 기능에도 영향을 줄 수 있는 상황이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Kafka는 Zookeeper에 의존하지 않고 내부적으로 메타데이터를 관리하는 구조인 KRaft(Kafka Raft Metadata mode) 를 도입하게 되었습니다. KRaft는 Raft 합의 알고리즘을 기반으로 메타데이터를 관리하며, 이를 통해 분산 환경에서도 여러 노드가 동일한 상태를 유지하면서 안정적으로 시스템을 운영할 수 있도록 합니다. 결과적으로 kafka는 KRaft를 통해 시스템 구조를 단순화하고 운영 복잡도를 줄이는 방향으로 발전하게 되었습니다.