Topic이란?
- 카프카 내에서 데이터를 구분하기 위한 단위를 토픽이라 한다.
- 원하는 데이터끼리 함께 모아두기 위해 사용한다.
Partition이란?
- Topic을 분할(파티셔닝)한 것을 Partition이라고 한다.
- 여러 프로듀서 혹은 여러 컨슈머가 토픽에 접근할 때, 파티셔닝이 되어있지 않다면(즉, 파티션이 1개라면) 빠른 메시지 전달이 되기 어려울 것이다. 메시징큐는 순서를 보장해야되기 때문이다. 이를 병렬처리 하기 위해서 토픽을 파티셔닝하여 메시지의 빠른 전달을 빠르게 할 수 있다.
- Offset 이라는 개념이 있어서, 파티션 내에서 메시지의 순서는 보장된다.
- 컨슈머 그룹 에서 컨슈머가 추가 또는 제거되면 파티션의 리밸런싱이 일어난다.
-
메시지는 key에 따라 각자 다른 partition으로 assign되게 할 수 있으므로 토픽 내 메시지의 순서가 중요하다면 key를 이용하면 좋다.
- key를 지정하지 않으면 round-robin 방식으로 할당된다.
[참고] Brokers Skew
- Kafka Manager를 사용하다보면
Brokers Skew라는 걸 보게 되곤 한다. - 토픽의 파티션들이 각 브로커 서버에 균등하게 나눠지는 것이 아니라 한쪽으로 치우치는 현상
- 이게 높아지면 파티션 리어사인을 해주는 게 좋다. 물론 안해줘도 당장 별 문제는 안생기지만 리소스를 효율적으로 쓰고 있는 게 아니기 때문이다.
Partition을 얼마까지 늘려야할지
-
파티션수를 늘리는 게 무조건 좋은 건 아니다.
- 파일 핸들러 낭비: 각 파티션은 브로커의 디렉토리와 맵핑되고, 저장되는 데이터마다 2개 파일(인덱스와 실제 데이터)이 있다고 하는데 카프카는 이 모든 파일들에 대해 파일 핸들을 열게 되므로 리소스를 낭비하게 될 수 있다.
- 장애 복구 시간 증가
- 파티션마다 리플리케이션 되어 있기 때문에, 특정 브로커가 다운되면 거기 포함되어 있던 리더 파티션들은 더이상 리더로서 유지될 수 없어 새로운 리더를 선출해야한다. 파티션수가 많다면 그에 비례하게 시간이 소요된다.
- 만일 그 다운된 브로커가 컨트롤러였다면, 컨트롤러의 failover도 되어야 하고 그 과정에서 새 컨트롤러가 초기화하는 동안 주키퍼에서 모든 파티션의 데이터를 읽어야 한다. 따라서 이또한 파티션수에 비례하게 시간이 소요된다. 새로운 컨트롤러가 실행되어야 각 파티션의 리더를 재선출 가능하다.
- 파티션수는 프로듀서의 개수나 컨슈머 개수에 맞추면 적당하겠고, 컨슈머 개수보다 파티션수가 더 적게 되면 잉여 컨슈머가 생긴다.
- 참고로, 파티션수를 한번 늘리면 절대 줄일 수 없으므로 신중하게 늘려야 한다. 토픽을 삭제하는 방법밖에 없다.