(Kafka) 토픽과 파티션의 이해

카프카는 고성능, 고가용성 메시징 애플리케이션으로 발전하는데 토픽과 파티션이라는 데이터 모델을 이용한다.

토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이고, 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위이다.


1. 토픽의 이해


카프카 클러스터는 토픽이라 불리는 곳에 데이터를 저장한다.
토픽은 메일주소 시스템이라고 생각하면 쉽다.
토픽이름은 249자 미만으로 영문, 숫자, ' . ' , ' _ ', ' - ' 를 조합하여 자유롭게 만들 수 있다.

1개의 메시지를 보내는데 1초가 걸린다면, 4개의 메시지를 각각 보내게 되면 4초가 걸리게 된다.
큐시스템에서 한 가지 제약조건은, 메시지의 순서가 보장되어야 한다. 그렇게 때문에 이전메시지 처리가 완료된 후 다음 메시지를 처리하게 된다.
그래서 토픽안에 4개의 파티션을 만들어서 보낸다면 1초가 걸리게 된다.

무조건 파티션수를 늘려야 할까?

다음과 같은 단점이 있다.
  • 파일 핸들러의 낭비
-> 각 파티션은 브로커의 디렉토리와 매핑 되고, 저장되는 데이터마다 2개의 파일(인덱스와 실제 데이터)이 있습니다. 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 됩니다.
결국 파티션의 수가 많을 수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비하게 됩니다.


  • 장애 복구 시간 증가
- >   카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 브로커에는 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어지므로 브로커에는 여러 개의 파티션이 존재한다.
또한 각 파티션마다 리플리케이션이 동작하게 되며, 하나는 파티션의 리더이고 나머지는 파티션의 팔로워가 된다.

만약 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 되므로, 카프카는 리더를 팔로워 중 하나로 이동시켜 클라이언트 요청을 처리할 수 있게된다.
이와같은 장애 처리는 컨트롤러로 지정된 브로커가 처리하게 된다.
컨트롤러는 카프카 클러스터 내 하나만 존재하고, 만약 컨트롤러 브로커가 다운되면 살아있는 브로커 중 하나가 컨트롤러 역할을  대신 수행한다.

만약 브로커 내에 총 1000개의 파티션이 있고 2개의 리플리케이션이 있는 브로커가 갑자기 종료되면, 일시적으로 이 브로커에 있는 1000개의 파티션은 사용할 수 없게 된다. 파티션은 리더를 다른 브로커가 있는 곳으로 이동시켜야 사용할 수 있다. 만약 컨트롤러가 각 파티션별로 새로운 리더를 선출하는데 5밀리초가 걸린다면 1000개의 모든 파티션에 대해 새로운 리더를 선출하는데 총 5초가 소요된다.

최악의 상황으로 다운된 브로커가 컨트롤러인 경우라면, 컨트롤러가 살아있는 브로커에게 완전히 넘어가기 전까지 새로운 리더를 선출할 수 없습니다. 컨트롤러의 페일오버는 자동으로 동작하지만 새 컨트롤러가 초기화하는 동안 주키퍼에서 모든 파티션의 데이터를 읽어야 합니다.
카프카 클러스터내에 10000개의 파티션이 있고 주키퍼에서 데이터를 읽는데 2밀리초가 걸린다면 20초가 넘는 시간이 걸린다.






댓글

이 블로그의 인기 게시물

(네트워크)폴링방식 vs 롱 폴링방식

(ElasticSearch) 결과에서 순서 정렬

(18장) WebSocekt과 STOMP를 사용하여 메시징하기