토픽의 파티션 수가 증가함에 따라 빠른 전송이 가능하다. 그렇다면 토픽의 파티션 수를 많이 늘리는 것이 무조건 좋은 것은 아니다. 파티션 수가 늘어나면 오히려 카프카에 좋지 않은 영향을 미칠 수도 있다.
(1) 파일 핸들러의 낭비
각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터마다 2개의 파일(인덱스와 실제 데이터)이 있다. 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 된다. 결국 파티션의 수가 많을수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비하게 된다.
(2) 장애 복구 시간 증가
카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 브로커에는 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어 있으므로, 브로커에는 여러 개의 파티션이 존재하게 된다. 또한, 각 파티션마다 리플리케이션이 동작하게 되며, 하나는 파티션의 리더이고 나머지는 파티션의 팔로워가 된다.
만약 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 되므로, 카프카는 리더를 팔로워 중 하나로 이동시켜 클라이언트 요청을 처리할 수 있게 한다. 이와 같은 장애 처리는 컨트롤러로 지정된 브로커가 수행한다. 컨트롤러는 카프카 클러스터 내 하나만 존재하고, 만약 컨틀롤러 역할을 수행하는 브로커가 다운되면 살아 있는 브로커 중 하나가 자동으로 컨트롤러 역할을 대신 수행한다.
만약 브로커에 총 1,000개의 파티션이 있고 2개의 리플리케이션이 있는 브로커가 갑자기 종료되면, 일시적으로 이 브로커에 있는 1,000개의 파티션은 사용할 수 없게 된다. 파티션의 리더를 다른 브로커가 있는 곳으로 이동시켜야 사용할 수 있는데, 만약 컨트롤러가 각 파티션별로 새로운 리더를 선출하는데 5밀리초의 시간이 소요된다고 가정하면 1,000개의 모든 파티션에 대해 새롱누 리더를 선출하는데는 총 5초가 소요되며, 일부 파티션의 경우 장애 시간은 5초 이상이어질 수도 있다.
최악의 상황으로 다운된 브로커가 컨트롤러인 경우라면, 컨트롤러가 살아있는 브로커에게 완전히 넘어가기 전까지 새로운 리더를 선출할 수 없다. 컨트롤러의 failover는 자동으로 동작하지만 새 컨트롤러가 초기화하는 동안 주키퍼에서 모든 파티션의 데이터를 읽어야 한다. 카프카 클러스터에 10,000개의 파티션이 있고 주키퍼에서 데이터를 읽는 파티션당 2밀리초가 걸린다면 20초가 넘는 시간 동안 장애가 발생하게 될 수도 있다.
이렇게 파티션 수를 무작정 늘리다보면 미처 생각하지 못한 문제가 발생할 수 있다. 따라서 무작정 파티션 수를 늘리기보다는 적절한 값으로 설정해 운영하는 편이 좋다.
토픽의 적절한 파티션 수는?
먼저 토픽의 파티션 수를 정할때 원하는 목표 처리량의 기준을 잡아야 한다. 프로듀서 입장에서 4개의 프로듀서를 통해 각각 초당 10개의 메시지를 카프카의 토픽으로 보낸다고 하면, 카프카의 토픽에서 초당 40개의 메시지를 받아줘야 한다. 만약 해당 토픽에서 파티션을 1로 했을때 초당 10개의 메시지만 받아준다면 파티션을 4로 늘려서 목표 처리량을 처리할 수 있도록 변경한다. 토픽의 파티션 수를 4개로 정해 프로듀서의 목표치를 달성할 수 있게 된다.
하지만 카프카에서는 컨슈머도 있기때문에 컨슈머의 입장도 고려해야 한다. 컨슈머 입장에서 8개의 컨슈머를 통해 각각 초당 5개의 메시지를 카프카 토픽에서 가져올수 있다고 한다면, 해당 토픽의 파티션 수는 컨슈머 수와 동일하게 8개로 맞추어 컨슈머마다 각각의 파티션에 접근할 수 있게 해야 한다.
이렇게 예상 목표치를 가지고 파티션 수를 할당하는 것이 가장 이상적인 방법이다. 카프카에서 파티션 수의 증가는 필요한 경우 아무때나 변경이 가능하지만, 반대로 파티션의 수를 줄이는 방법은 제공하지 않는다. 너무 과도하게 파티션 수를 늘려놓고 난 후에 파티션 수를 줄이고 싶은 상황이 생기면, 토픽을 삭제하는 방법 말고는 다른 해결책이 없다.
적절한 파티션 수를 측정하기 어려운 경우에는 일단 적은 수의 파티션으로 운영해보고, 프로듀서 또는 컨슈머에서 병목현상이 발생하게 될때 조금씩 파티션 수와 프로듀서 또는 컨슈머를 늘려가는 방법으로 적정 파티션 수를 할당할 수 있다.
카프카에서는 브로커당 약 2,000개 정도의 최대 파티션 수를 권장하고 있기 때문에 과도한 파티션 수를 적용하기 보다는 목표 처리량에 맞게 적절한 파티션 수로 유지/운영하는 것이 권장된다.
'데이터베이스(DA, AA, TA) > 데이터처리' 카테고리의 다른 글
[Kafka] 아파치 카프카 알아보기(2) - 운영 가이드 (0) | 2019.12.15 |
---|---|
[Kafka] 아파치 카프카 알아보기(1) - 프로듀서/컨슈머 (1) | 2019.12.15 |
[ELK] 키바나 사용법 정리 (0) | 2019.06.30 |
[데이터처리] 로그데이터 다루기(2) - 수집 미들웨어 Fluentd란? (0) | 2019.05.19 |
[데이터처리] 로그 데이터 다루기 (1) - 수집 미들웨어 Fluentd 중심 (0) | 2019.05.18 |