[Kafka 개념] Kafka 토픽과 파티션 (2)

 

토픽과 파티션

토픽을 삭제하면 데이터는 삭제되고 파이프라인은 중단된다. 데이터의 생명주기 한가운데에 토픽이 있다.

그만큼 토픽은 카프카에서 중요한 역할을 하므로 잘 이해하고 상세 옵션들에 대해서 자세히 알 필요가 있다.

 

 

 

적정 파티션 개수

토픽의 파티션 개수는 카프카의 성능과 관련이 있다.

그렇기 때문에 토픽을 운영함에 있어 적절한 파티션 개수를 설정하고 운영하는 것이 매우 중요하다.

 

토픽 최초 생성 시, 파티션의 개수를 정하는 데에 고려해야 할 점은 3가지가 있다.

• 데이터 처리량
• 메시지 키 사용 여부
• 브로커, 컨슈머 영향도

 

데이터 처리량

파티션은 카프카의 병렬처리의 핵심이다.

파티션의 개수가 많아지면 많아질수록 1:1 매핑되는 컨슈머 개수가 늘어나기 때문이다.

그렇기 때문에 파티션 개수를 정할 때는 해당 토픽에 필요한 데이터 처리량을 측정하여 정하는 것이 중요하다.

 

데이터 처리 속도를 올리는 방법은 2가지가 존재한다.

1. 컨슈머의 처리량을 늘리기

2. 컨슈머를 추가해서 병렬 처리량을 늘리기

 

첫 번째 방법인 컨슈머의 처리량을 늘리기 위해서는

컨슈머가 실행되는 서버의 사양을 올리는 스케일 업을 하거나GC 튜닝 등을 활용할 수 있다고 한다.

그러나 컨슈머 특성상 다른 시스템들(S3, Hadoop, Oracle 등)과 연동되기 때문에

일정 수준 이상 처리량을 올리는 것은 매우 어렵다.

 

두 번째 방법인 파티션 개수를 늘리고 파티션 개수만큼 컨슈머를 추가하는 방법은

데이터 처리량을 늘리는 가장 확실한 방법이다.

그러므로 프로듀서가 보내는 데이터양과 컨슈머의 데이터 처리량을 계산해서 파티션 개수를 정하면 된다.

만약, 프로듀서가 보내는 데이터가 초당 1000 레코드 이고, 컨슈머가 처리할 수 있는 데이터가 초당 100 레코드라면

최소한으로 필요한 파티션 개수는 10개 정도이다.

 

참고로 컨슈머 전체 데이터 처리량이 프로듀서 데이터 처리량보다 많아야 한다.

그 이유는 전체 컨슈머 데이터 처리량이 프로듀서가 보내는 데이터보다 적다면

컨슈머 렉이 생기고, 데이터 처리 지연이 발생하게 되기 때문이다.

 

또한 파티션 개수를 무조건 늘리는 것이 좋은 것 만은 아니다. 파티션 개수를 늘리게 됨에 따라

컨슈머, 브로커의 부담이 있기 때문이다. 그렇기 때문에 데이터를 처리함에 있어

지연 발생에 따른 서비스 영향도를 같이 고려하여 파티션 개수를 구하는 것이 중요하다.

 

 

메시지 키 사용 여부

메시지 키 사용 여부는 데이터 처리 순서와 밀접한 연관이 있다.

그러므로 메시지 키를 사용함과 동시에 데이터 처리 순서를 지켜야 하는 경우에 대해 고려해야 한다.

 

프로듀서가 기본 파티셔너를 사용하는 경우를 가정해보자.

메시지키를 사용하면 프로듀서가 토픽으로 데이터를 보낼 때,

메시지 키를 해시 변환하여 메시지 키를 파티션에 매칭시킨다.

만약 위 그림과 같이 파티션 개수가 달라지면, 이때 매칭된 파티션과 메시지 키의 매칭이 깨지고

전혀 다른 파티션에 데이터가 할당된다.

 

메시지 키를 사용하고 컨슈머에서 메시지 처리 순서가 보장되어야 한다면

최대한 파티션의 변화가 발생하지 않는 방향으로 운영해야 한다.

 

만약에 파티션 개수가 변해야 하는 경우에는

기존에 사용하던 메시지 키의 매칭을 그대로 가져가기 위해 커스텀 파티셔너를 개발하고 적용해야 한다.

 

이러한 어려움 때문에 메시지 키별로 처리 순서를 보장하기 위해서는 파티션 개수를

프로듀서가 전송하는 데이터양보다 더 넉넉하게 잡고 생성하는 것이 좋다.

 

 

브로커와 컨슈머의 영향도

카프카에서 파티션은 각 브로커의 파일 시스템을 사용하기 때문에

파티션이 늘어나는 만큼 브로커에서 접근하는 파일 개수가 많아진다.

 

그런데 운영체제에서는 프로세스당 열 수 있는 파일 최대 개수를 제한하고 있다.

그러므로 카프카 브로커가 접근하는 파일 개수를 안정적으로 유지하기 위해서는 

각 브로커당 파티션 개수를 모니터링해야 한다.

 

데이터양이 많아져서 파티션 개수를 늘려야 하는 상황이라면,

브로커당 파티션 개수를 확인하고 진행한다. 만약 브로커가 관리하는 파티션 개수가

너무 많다면 파티션 개수를 분산하기 위해서 카프카 브로커 개수를 늘리는 방안도 같이 고려해야 한다.

 

 

 

토픽 정리 정책 (cleanup.policy)

토픽의 데이터는 시간 또는 용량에 따라 삭제 규칙을 적용할 수 있다.

또는 삭제를 원치 않는다면 카프카 클러스터가 살아있는 한 토픽의 데이터를 삭제하지 않도록 설정 할수도 있다.

 

토픽의 데이터를 삭제할 때는 세그먼트 단위로 삭제를 진행한다.

세그먼트는 토픽의 데이터를 저장하는 명시적인 파일 시스템 단위이다.

세그먼트는 파티션마다 별개로 생성되며, 세그먼트의 파일 이름은 오프셋 중 가장 작은 값이 된다.

또한 세그먼트는 여러 조각으로 나뉘는데, segment.bytes 옵션으로 1개의 세그먼트 크기를 설정할 수 있다.

segment.bytes 크기보다 커질 경우에는 기존에 적재하던 세그먼트 파일을 닫고

새로운 세그먼트를 열어서 데이터를 저장한다.

데이터를 저장하기 위해 사용 중인 세그먼트를 액티브 세그먼트라고 한다. 

 

데이터를 더이상 사용하지 않을 경우에는 cleanup.policy 옵션을 사용하여 데이터를 삭제할 수있는데, 

cleanup.policy 옵션은 2가지 삭제 정책을 제공한다.

 

1. 데이터 완전 삭제 (delete policy)
2. 동일 메시지 키의 가장 오래된 데이터 삭제 (compact policy)

토픽 삭제 정책 (delete policy)

토픽을 운영하면 일반적으로 대부분의 토픽의 cleanup.policy를 delete로 설정한다.

이 옵션은 명시적으로 토픽의 데이터를 삭제하는 것을 뜻한다.

 

삭제 정책이 실행되는 시점은 시간 또는 용량이 기준이 된다.

retention.ms는 토픽의 데이터를 유지하는 기간을 밀리초로 설정할 수 있다.

카프카는 일정 주기마다 세그먼트 파일의 마지막 수정 시간과 retention.ms를 비교하는데,

세그먼트 파일의 마지막 수정 시간이 retention.ms를 넘어가면 세그먼트는 삭제된다.

 

retention.bytes는 토픽의 최대 데이터 크기를 제어한다.

retention.bytes를 넘어간 세그먼트 파일들은 삭제되며, 삭제된 데이터는 복구할 수 없다.

 

토픽 압축 정책 (compact policy)

토픽의 압축 정책은 일반적으로 생각하는 zip이나 tar 압축과는 다른 개념이다.

여기서 압축이란, 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책을 뜻한다.

 

압축 정책은 액티브 세그먼트를 제외한 나머지 세그먼트들에 한해서만 데이터를 처리한다.

 

데이터의 압축 시작 시점은 min.cleanable.dirty.ratio 옵션값을 따른다.

이는 액티브 세그먼트를 제외한 세그먼트에 남아 있는 데이터의 테일(tail) 영역의

레코드 개수와 헤드(head) 영억의 레코드 개수의 비율을 뜻한다.

참고로 테일 영역의 레코드들은 클린(clean) 로그라고 부르며,

헤드 영역의 레코드들은 더티(dirty) 로그라고 부른다.

 

더티 비율(dirty ratio)는 더티 영역의 메시지 개수를 압축 대상 세그먼트에 남아있는

데이터의 총 레코드 수(더티 영역 메시지 개수 + 클린 영역 메시지 개수)로 나눈 비율을 뜻한다.

 

 

 

 

 

 

 

본 내용은 아래 교재를 바탕으로 정리한 글입니다.

 

아파치 카프카 애플리케이션 프로그래밍 with 자바 | 최원영 - 교보문고