[Kafka 개념] Kafka 브로커, 클러스터, 주키퍼

 

카프카 브로커, 클러스터, 주키퍼

주키퍼와 연동하여 동작하는 카프카 클러스터

 

카프카 브로커는

카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자,

데이터를 분산 저장하여 장애가 발생하더라도

안전하게 사용할 수 있도록 도와주는 애플리케이션이다.

 

 

기본적으로 하나의 서버에는 한 개의 카프카 브로커 프로세스가 실행되나,

데이터를 안전하게 보관하고 처리하기 위해서는

3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영하는 것이 좋다.

 

 

카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게

분산 저장하고 복제하는 역할을 수행한다.

 

 

 

브로커

데이터 저장, 전송

프로듀서로부터 데이터를 전달받으면 카프카 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 저장하고

컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를 전달한다.

 

프로듀서로부터 전달된 데이터는 파일 시스템에 저장된다.

카프카는 메모리나 데이터베이스에 저장하지 않으며, 따로 캐시 메모리를 구현하여 사용하지도 않는다.

 

그렇다면 파일 시스템에 저장하기 때문에 파일 입출력으로 인해 속도 이슈가 발생하지 않을까?

일반적으로 파일 시스템은 다루기 편하지만 지속적으로 입출력할 경우

메모리에 올려서 사용하는 것보다 처리 속도가 현저히 느리기 때문이다.

 

그러나 카프카는 페이지 캐시(page cache)를 사용하여 디스크 입출력 속도를 높여서 이 문제를 해결했다고 한다.

페이지 캐시란 OS에서 파일 입출력의 성능 향상을 위해 만들어 놓은 메모리 영역을 뜻한다.

읽은 파일의 내용은 메모리의 페이지 캐시 영역에 저장시킨다.

추후 동일한 파일의 접근이 일어나면 디스크에서 읽지 않고 메모리에서 읽는 방식이다.

 

 

데이터 복제, 싱크

데이터 복제(replication)는 카프카를 장애 허용 시스템으로 동작하도록 하는 원동력이다.

복제의 이유는 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도

데이터를 유실하지 않고 안정하게 사용하기 위함이다.

 

카프카의 데이터 복제는 파티션 단위로 이루어진다.

토픽을 생성할 때 파티션의 복제 개수(replication factor)도 같이 설정되는데,

직접 옵션을 선택하지 않으면 브로커에 설정된 옵션값을 따라간다.

복제 개수의 최솟값은 1(복제 없음)이고, 최댓값은 브로커 개수만큼 설정하여 사용할 수 있다.

 

아래와 같이 토픽을 생성할 때, 파티션 복제 개수도 설정하는 것을 확인할 수 있다.

$ kafka-topics.sh --create --zookeeper test-broker01:2181,test-broker02:2181,test-broker03:2181/test \
  --replication-factor 3 --partitions 1 --topic test

 

토픽의 파티션의 복제 개수가 3인 경우

 

복제된 파티션은 리더(Leader)와 팔로워(Follower)로 구성된다.

프로듀서 또는 컨슈머와 직접 통신하는 파티션을 리더, 나머지 복제 데이터를 가지고 있는 파티션을 팔로워라고 부른다.

 

팔로워 파티션들은 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고 있는 오프셋과 차이가 나는 경우 

리더 파티션으로부터 데이터를 가져와서 자신의 파티션에 저장하는데, 이 과정을 '복제(replication)' 라고 부른다.

 

파티션 복제로 인해 나머지 브로커에도 파티션의 데이터가 복제되므로 복제 개수만큼의 저장 용량이 증가한다는 단점이 있다. 그러나 복제를 통해 데이터를 안전하게 사용할 수 있다는 강력한 장점 때문에 카프카를 운영할 때 2 이상의 복제 개수를 정하는 것이 중요하다.

 

 

브로커 0에 장애가 발생한 경우

 

위 그림처럼 브로커 0에 장애가 발생한 경우, 해당 브로커에 있던 기존의 리더 파티션은 사용할 수 없기 때문에

팔로워 파티션 중 하나가 리더 파티션 지위를 넘겨받는다.

이를 통해 데이터가 유실되지 않고 컨슈머나 프로듀서와 데이터를 주고 받도록 동작할 수 있다.

 

운영 시에는 데이터 종류마다 다른 복제 개수를 설정하고 상황에 따라서는 토픽마다 복제 개수를

다르게 설정하여 운영하기도 한다고 한다.

 

 

데이터 삭제

카프카는 다른 메시징 플랫폼과 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않는다.

또한, 컨슈머나 프로듀서가 데이터 삭제를 요청할 수도 없다.

오직 브로커만이 데이터를 삭제할 수 있다.

 

데이터 삭제는 파일 단위로 이루어지는데, 이 단위를 'log segment'라고 부른다.

이 세그먼트에는 다수의 데이터가 들어 있기 때문에 일반적인 데이터베이스처럼 특정 데이터를 선별해서 삭제할 수 없다.

 

세그먼트는 데이터가 쌓이는 동안 파일 시스템으로 열려 있으며,

카프카 브로커에 log.segment.bytes 또는 log.segment.ms 옵션에 값이 설정되면 세그먼트 파일이 닫힌다.

 

세그먼트 파일이 닫히게 되는 기본값은 1GB 용량에 도달했을 때 인데, 간격을 더 줄이고 싶다면 작은 용량으로 설정하면 된다.

그러나 너무 작은 용량으로 설정하면 데이터들을 저장하는 동안 세그먼트 파일을 자주 여닫음으로써

부하가 발생할 수 있으므로 주의해야 한다.

 

닫힌 세그먼트 파일은 log.retention.bytes 또는 log.retention.ms 옵션에 설정값이 넘으면 삭제된다.

또한 닫힌 세그먼트 파일을 체크하는 간격은

카프카 브로커의 옵션에 설정된 log.retention.check.interval.ms에 따른다.

 

 

컨트롤러 (controller)

클러스터의 다수 브로커 중 한 대가 컨트롤러의 역할을 한다.

컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우, 

해당 브로커에 존재하는 리더 파티션을 재분배한다.

 

카프카는 지속적으로 데이터를 처리해야 하므로,

브로커의 상태가 비정상이라면 빠르게 클러스터에서 빼내는 것이 중요하다.

 

만약 컨트롤러 역할을 하는 브로커에 장애가 생긴다면, 다른 브로커가 컨트롤러 역할을 한다.

 

 

코디네이터 (coordinator)

클러스터의 다수 브로커 중 한 대는 코디네이터의 역할을 수행한다.

코디네이터는 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배하는 역할을 한다.

 

컨슈머가 컨슈머 그룹에서 빠지면 매칭되지 않은 파티션을 정상 동작하는 컨슈머로 할당하여 

끊임없이 데이터가 처리되도록 도와준다. 

이렇게 파티션을 컨슈머로 재할당하는 과정을 'rebalance' 라고 부른다.

 

 

 

주키퍼

💁‍♂️카프카 클러스터를 운영할 때 주키퍼가 하는 역할은 무엇일까? 💁‍♂️

 

처음 무작정 실습을 따라할 때 카프카와 같이 붙어오는 주키퍼의 정체에 대해서 궁금했다.

이제 주키퍼가 하는 역할에 대해서 알아보자.

 

Apache Kafka는 Apache Zookeeper를 사용하여 클러스터를 관리한다.

Zookeeper는 브로커, 토픽, 파티션 등 Kafka의 메타 데이터를 관리하여

Kafka 클러스터의 상태를 일관되게 유지하고, 브로커의 실패 및 복구를 감지하는 등의 역할을 수행한다.

 

따라서 Kafka를 띄우기 위해서는 Zookeeper가 반드시 실행되어야 한다.

 

하지만 파티션이 100,000개가 넘었을 때 Kafka 클러스터에 스케일링 문제가 발생했고,

유지보수와 설정 그리고 안정성 개선을 위해

Kafka는 Zookeeper의 의존성을 줄이기 위한 노력을 하고 있다고 한다.

 

실제로 Kafka 3.x부터는 Zookeeper 없이 카프카를 구동할 수 있는 Kraft(Kafka Raft Metadata mode) 모드가 추가되었으며, Kafka 4.0부터는 Zookeeper의 의존성을 완전히 지운 오직 KRaft만 지원되는 버전으로 출시될 예정이라고 한다.

 

Kafka Without ZooKeeper: A Sneak Peek At the Simplest Kafka Yet

 

 

 

 

 

 

본 내용은 아래 교재를 바탕으로 정리한 글입니다.

아파치 카프카 애플리케이션 프로그래밍 with 자바 | 최원영 - 교보문고