[아파치 카프카 어플리케이션 프로그래밍] 13. 토픽과 파티션

들어가기전

토픽과 파티션의 기본개념 포스팅 바로가기

https://devfunny.tistory.com/380

카프카의 토픽과 파티션, 오프셋

 

 

 

토픽

카프카의 시작과 끝이다.

카프카를 사용하는 것은 토픽을 만들면서 시작하고, 토픽을 삭제하면 데이터는 삭제되고 파이프라인은 중단된다.

데이터의 생명주기 한가운데에 토픽이 있다.

 

 

적정 파티션 개수

토픽 생성시 파티션 개수 고려사항

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

 

파티션의 개수가 많아질수록 1:1 매핑되는 컨슈머 개수가 늘어난다. 그러므로 파티션 개수를 정할때는 해당 토픽에 필요한 데이터 처리량을 측정하여 정하는 것이 중요하다.

 

 

데이터 처리 속도를 올리는 방법

1) 컨슈머의 처리량을 늘린다.

컨슈머의 처리량을 늘리기 위해 컨슈머가 실행되는 서버의 사양을 올리는 scale-up을 하거나, GC 튜닝 등을 활용할 수 있다.

컨슈머 특성상 다른 시스템들(하둡, 오라클 등)과 연동되기 때문에 일정 수준 잇아 처리량을 올리는 것은 매우 어렵다.

 

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

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

만약 프로듀서가 보내는 데이터가 초당 1,000레코드 이고 컨슈머가 처리할 수 있는 데이터가 초당100 레코드라면, 최소한으로 필요한 파티션의 개수는 10개다.

프로듀서 전송 데이터량 < 컨슈머 데이터 처리량 x 파티션 개수

 

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

컨슈머 랙이 발생하고, 데이터 처리 지연이 발생한다.

그렇기 때문에 컨슈머 전체 데이터 처리량이 프로듀서 데이터 처리량보다 많아야한다.

 

 

 

컨슈머 데이터 처리량을 구하는 방법

1) 상용에서 운영중인 카프카에서 더미 데이터로 테스트를 해보는 것이다. 

컨슈머 데이터 처리량을 구하고 난 뒤, 프로듀서가 보내는 데이터양을 하루, 시간, 분 단위로 쪼개서 예측한다.

 

데이터의 지연이 절대 발생하면 안되는 경우

프로듀서가 보내는 데이터의 최대치를 데이터 생산량으로 잡고 계산하면 된다.

 

데이터의 지연이 일부 발생해도 괜찮은 경우

프로듀서가 보내는 데이터의 최대치를 잡지 않아도 된다. 프로듀서가 보내는 데이터양이 컨슈머의 데이터 처리량보다 작을때 컨슈머 랙이 줄어들기 때문이다.

 

파티션 개수를 무조건 늘리는 것이 좋은 방법은 아니다. 파티션 개수를 늘리게 됨에따라 컨슈머, 브로커의 부담이 커진다.

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

 

2) 메시지 키 사용 여부를 정한다.

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

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

 

프로듀서가 기본 파티셔너를 사용하는 경우를 가정하자.
메시지 키를 사용하면 프로듀서가 토픽으로 데이터를 보낼 때 메시지 키를 해시 변환하여 메시지 키를 파티션에 매칭시킨다.
만약 파티션의 개수가 달라지면 이미 매칭된 파티션과 메시지 키의 매칭이 깨지고 전혀 다른 파티션에 데이터가 할당된다.
그러므로 파티션 개수가 달라지는 순간에는 메시지 키를 사용하는 컨슈머는 특정 메시지 키의 순서를 더는 보장받지 못한다.
파티션을 변환하기 이전과 이후 메시지 키의 파티션 위치가 달라지기 때문이다.

 

메시지 키를 사용하고 컨슈머에게 메시지 처리 순서가 보장되어야 하는 경우

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

만약, 파티션 개수가 변해야하는 경우에는 기존에 사용하던 메시지 키의 매칭을 그대로 가져가기 위해 커스텀 파티셔널르 개발하고 적용해야한다. 

이러한 어려움 때문에 메시지 키별로 처리 순서를 보장하기 위해서는 파티션 개수를 프로두서가 전송하는 데이터양보다 더 넉넉하게 잡고 생성하는 것이 좋다.

 

메시지 키를 사용하지만 데이터 처리 순서를 지키지 않아도 되는 경우

파티션 개수를 처음부터 넉넉하게 잡지 않아도 된다. 데이터의 양에 따라 파티션을 늘리면 되기 때문이다.

 

 

브로커와 컨슈머의 영향도

카프카에서 파티션은 각 브로커의 파일 시스템을 사용한다.

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

그런데 운영체제에서는 프로세스당 열 수 있는 파일 최대 개수를 제한하고 있다. 그러므로 카프카 브로커가 접근하는 파일 개수를 안정적으로 유지하기 위해서는 각 브로커당 파티션 개수를 모니터링해야 한다. 

데이터양이 많아져서 파티션 개수를 늘려야 하는 상황이라면, 브로커당 파티션 개수를 확인하고 진행하면 된다.

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