[Kafka] 2. 토픽과 파티션

목적

아파치 카프카 애플리케이션 프로그래밍, 카프카 핵심 가이드, 카프카 데이터 플랫폼의 최강자,

그리고 카프카 관련 포스팅을 보고 정리했던 노트를 공유하기 위해 기록한다.

이전 포스팅 참조

2024.03.31 - [Message Queue] - [kafka] 1. kafka의 역사, 장점

[kafka] 1. kafka의 역사, 장점

•  토픽
  • 카프카에서 데이터를 구분하기 위해 사용하는 논리적인 단위
  • 1개 이상의 파티션을 소유함.
• 파티션
  • 프로듀서가 보낸 데이터(레코드)들이 저장되는 물리적인 곳
  • FIFO로써 큐와 비슷한 구조

토픽 생성시 파티션이 배치되는 방법

파티션이 5개인 토픽을 생성했을 경우, 그림과 같이 0번 브로커부터 시작하여 round-robin 방식으로 리더 파티션들이 생성됨.(파티션 0, 파티션 1, 파티션 2…5)

카프카 클라이언트는 리더 파티션이 있는 브로커와 통신하여 데이터를 주고 받으므로 여러 브로커에 골고루 네트워크 통신을 하게 된다.(linear scale out)

부하를 균등하게 배치할 수 있음.

리더 파티션이 균등하게 배치되면, 리더 파티션이 배치된 거 외의 브로커에 팔로워 파티션이 배치된다.

특정 브로커에 파티션이 쏠린 현상

특정 브로커에 파티션이 몰리는 경우에는 특정브로커와 카프카 클라이언트 애플리케이션 만이 통신을 하게 되어, CPU 나 RAM 사용량 초과 현상이 발생할 수 있다.

kafka-reassign-partitions.sh 명령으로 파티션을 재분배할 수 있다.

파티션 개수와 컨슈머 개수의 처리량

파티션과 컨슈머는 1:1 로 매핑되며, 즉 한개의 파티션은 다수의 컨슈머와 매핑될 수 없다.

데이터 처리에 있어 지연이 발생하게 되면, 그것은 컨슈머 랙이라고 부른다.

컨슈머 개수를 늘리면, 그에 맞게 파티션 개수도 늘려 처리량을 증가시킬 수 있다.

많은 레코드를 병렬로 처리하는 가장 좋은 방법은 컨슈머 개수를 늘려 스케일 아웃하는 것이다.

컨슈머 처리량이 초당 1개이고, 프로듀서에서 데이터를 전송하는 처리량이 초당 10개라면, 최소 파티션 10개 컨슈머 10개로 설정해야 함.

파티션과 동일 컨슈머 그룹 내 컨슈머 간에 1:n 으로 매핑되지 않는 이유?

• 컨슈머 리밸런싱이 일어날 경우, 파티션의 소유권을 갖고 있는 컨슈머가 재할당 되는데, 기존 offset과 하트비트를 공유해서 소팅하고 균등하게 분배될 수 있도록 체크해야 하는데, O(n2LogN)으로 오버헤드가 커져서 속도가 느림.
• 또한 컨슈머에서 오프셋을 통해 데이터를 중복 없이 가져오고자 하는데, 오프셋 커밋 전에 가져와서 데이터를 중복으로 처리할 수 있음.
• 따라서 1:1로 매핑되는 것으로 추정됨.

파티션 개수를 줄이는 것은 불가능

카프카에서는 파티션의 데이터를 세그먼트로 저장하고 있다.

• 여러 브로커에 저장된 데이터를 취합하고 timeIndex를 다른 파티션과 합쳐서 정렬해야하는 오버헤드와 만일 timeIndex가 같은 경우, 데이터가 중복되는 등 클러스터에 큰 영향이 가게 된다.

파티션을 신중하게 설정해야하는 이유

파티션에 저장된 데이터 파일은 2개로 원본 데이터와 인덱스 데이터인데,

1. 파티션내에 모든 파일 핸들러를 열어야하므로 리소스 낭비의 문제가 있을 수 있습니다.
2. 파티션이 많을 수록 복구 시간이 증가합니다.

첫번째로 카프카 브로커가 죽었을 때, 이 브로커가 1000개의 파티션에 대한 리더라고 가정합니다. 그렇다면 리더를 새로 선출할 때까지 데이터를 읽을 수도 쓸수도 없기에 새로운 리더를 선출해야합니다.만약 파티션 하나에 대해 리더를 선출하는 시간이 5밀리초라고 가정했다면, 장애 복구 시간은 5초가 걸립니다.

파티션 개수를 선택할 때 유의할 점

• 토픽의 목표 처리량을 컨슈머 예상 처리량으로 나누는 방법으로 파티션 수를 계산할 수 있습니다. 예를 들어 초당 1GB로 토픽을 읽고 쓰길 원하는데 한 컨슈머가 초당 50MB만 처리할 수 있다면 최소한 20개의 파티션이 필요하다는 것을 알 수 있습니다.