Big Data/Kafka

[Kafka] 데이터 모델: topic, partition, replication

ooeunz 2020. 7. 7. 10:18
반응형

토픽, 파티션

카프카가 고성능, 고가용성 메시징 애플리케이션으로 발전하는 데에는 토픽파티션이라 불리는 카프카 데이터 모델의 역할이 컸습니다. 토픽은 메시지를 받을 수 있는 논리적인 모델로 데이터를 구분하기 위한 단위입니다. 예를 들어 A라는 사람에게서 받은 메일과 B라는 사람에게서 받은 메일을 구분하기 위해서 이메일 주소를 사용하는 것과 비슷한 논리입니다.

 

파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위입니다. 즉 토픽을 분할해서 파티셔닝 한 형태입니다. 이와 같이 토픽을 파티셔닝 하는 이유는 프로듀서로부터 도착한 메시지의 순서가 보장되어야 하면서 동시에 성능을 향상하기 위해서입니다.

 

예를 들어 4개의 프로듀서에서 전송되는데 1초가 걸리는 메시지를 하나의 파티션에 전송했다고 가정해보겠습니다. 일반적인 분산 시스템의 경우 메시지의 처리시간이 1초일 확률이 높지만, 메시징 큐 시스템에서는 한 가지 제약 조건이 존재합니다. 바로 메시지의 순서가 보장되어야 한다는 것입니다. 때문에 결과적으로 4개의 프로듀서에서 메시지를 전송하였다고 하더라도 이를 모두 처리하는 데에는 4초가 걸리게 됩니다.

 

이와 같이 순서를 지키며 병렬적으로 메시지를 처리하기 위해서 카프카는 하나의 토픽안에 여러 개의 파티션을 둠으로서 메시지를 병렬적으로 처리하게 됩니다. 즉 프로듀서 4개에 4개의 파티션이 있다면 이를 모두 처리하는 데에 1초의 시간만 있으면 되는 것입니다.

 

그렇다면 무조건 파티션의 수를 늘리는 것만이 능사일까요?

꼭 그렇지는 않습니다. 각 파티션은 카프카 브로커의 디렉토리와 매핑되고 저장되는 데이터마다 2개의 데이터가 저장됩니다.

Index 실제 데이터

카프카는 모든 디렉토리의 파일에 대해 핸들을 열게 되고, 결국 파티션의 수가 많을 수록 파일 핸들 수 역시 많아지게 되므로 리소스가 낭비되게 됩니다.

 

핸들(handle)은 자원(resource)에 대한 추상적인 참조이다. 핸들은 응용 소프트웨어가 데이터베이스나 운영 체제 같은 다른 시스템에서 관리되는 메모리 블록들이나 객체들을 참조하는 데 사용된다. 리소스 핸들은 불투명한 식별자가 될 수도 있고(이 경우에 보통 리소스의 종류를 관리하기 위한 배열 인덱스나 테이블을 나타내는 정수 번호로 사용된다) 또는 더 많은 정보에 접근할 수 있게 해주는 포인터가 될 수도 있다.
https://ko.wikipedia.org/wiki/%ED%95%B8%EB%93%A4_(%EC%BB%B4%ED%93%A8%ED%8C%85)

 

또한 장애 복구 시간이 증가하게 됩니다. 카프카는 고가용성을 위해서 리플리케이션을 지원합니다. 리플리케이션이란 쉽게 말해 원본 데이터를 복제해두는 것인데, 카프카에서는 파티션마다 리플리케이션이 동작하게 되어 한 개의 리더와 나머지 파티션은 팔로워의 역할을 하게 됩니다. 따라서 만약 브로커에 장애가 발생했을 경우 각 파티션에 관한 리더를 선출해야 하므로 파티션의 수가 증가함에 따라 시간이 새로운 리더 선출에 대한 시간이 비례하여 상승하게 됩니다.

 

 

이와 같은 이유로 파티션의 수는 속도를 올릴 수 있는 이점이 될 수 있지만, 도리어 단점이 될 수도 있습니다. 특히 카프카에서 파티션을 증가하는 것은 아무 때나 변경이 가능하지만, 반대로 파티션의 수를 줄이는 것은 토픽을 삭제하는 방법 말고는 존재하지 않습니다. 따라서 파티션의 수를 정할 때 원하는 목표 처리량의 기준을 잡고 조금씩 파티션의 수를 늘려가며 정적 수를 유지하는 것이 좋습니다.

 

※ 카프카에서는 브로커당 약 2천 개 정도의 최대 파티션 수를 권장하고 있습니다.

 


리플리케이션

카프카는 분산 애플리케이션으로 서버의 물리적인 장애가 발생하는 경우에도 높은 고가용성을 보장합니다. 이를 위해 카프카는 리플리케이션(복제) 기능을 제공하게 되는데, 단순히 토픽 자체를 리플리케이션 하는 것이 아니라, 토픽을 이루는 각각의 파티션을 리플리케이션 합니다. (때문에 너무 많은 파티션의 수는 장애 시간을 연장시킬 수 있다고 이전 포스팅에서 설명하였었습니다.)

 

카프카의 브로커는 리더(Leader)와 팔로워(Follower)로 이루어지게 됩니다. 오직 리더에만 쓰기와 읽기 작업을 할 수 있고, 만약 리더 브로커에서 장애가 발생하게 되면, 팔로워 중 하나를 새롭게 리더로 선출하게 됩니다.

 

 

이러한 이유로 카프카에서는 브로커 중 하나라도 살아있다면 데이터가 손실되지 않지만, 간혹 모든 브로커가 다운 되었을 경우에는 가장 먼저 정상화된 브로커의 데이터를 동기화하게 됩니다. 따라서 먼저 가장 먼저 정상화된 브로커가 가진 데이터가 이전의 버전이라면 일부 데이터의 손실이 일어나게 됩니다. 그래서 카프카는 0.11.0.0 버전부터는 가장 마지막에 다운된 리더가 정상화되기를 기다리는 방안을 선택했습니다.

 

해당 옵션은 아래의 루트의 코드로 확인할 수 있는데, false일 경우 가장 마지막에 다운된 리더의 정상화를 기다리고, true는 서비스적 관점에서 메시지의 손실이 발생하더라도 빠른 서비스를 제공을 위해 가장 빨리 정상화된 브로커의 데이터를 동기화하는 설정입니다.

vi /usr/local/kafka/config/server.properties

unclean.leader.election.enable = false

 

 

너무 많은 파티션의 수는 단점으로 작용할 수도 있듯이 너무 많은 리플리케이션의 수 역시 문제점을 야기할 수 있습니다.

 

저장공간

첫 번째로 저장 공간의 문제점이 생깁니다. 예를 들어 파티션의 사이즈가 100GB인 브로커가 있습니다. 그리고 만약 이 브로커의 리플리케이션 팩터는 3이라면 (자신을 포함) 카프카 클러스터 내 필요한 총저장소의 크기는 300GB가 됩니다.

 

브로커 리소스 사용량 증가

두 번째로 브로커의 리소스 사용량 증가입니다. 브로커에서는 완벽한 리플리케이션을 위해서 사용자가 알아차리지 못하는 사이 비활성화된 토픽이 리플리케이션이 잘되고 있는지 계속해서 상태를 체크하는 작업이 이루어집니다. 따라서 리플리케이션 역시 적당한 수를 채택하는 것이 필요합니다.

 

반응형