파티션과 성능
토픽은 파티션으로 나누어지고, 파티션은 어플리케이션의 컨슈머와 연결되고, 컨슈머는 레코드를 읽어들여 데이터를 처리합니다.
파티션의 개수는 데이터 처리량과 깊은 관련이 있습니다.
위에서 적었듯이 파티션은 컨슈머와 연결되는데, 파티션의 개수가 많아지면 많아질수록 1:1로 매핑되는 컨슈머의 개수가 늘어나 병렬처리가 가능해져 데이터 처리량이 늘어납니다.
고려사항
- 데이터 처리량
- 메시지 키 사용 여부
- 브로커 영향도
데이터 처리량
데이터 처리 속도를 늘리는 방법은 다음의 두 가지 방법이 있습니다.
1. 컨슈머 개선
2. 컨슈머 추가
컨슈머를 개선하는 방법은 컨슈머가 실행되는 서버를 스케일업(사양 개선) 하거나 튜닝을 하는 등의 방법이 있습니다. 그러나 컨슈머는 특성상 외부 어플리케이션과 연동되는 일이 많기 때문에 성능을 개선하기 까다롭습니다.
컨슈머를 추가하는 방법은 단순히 파티션을 늘리고 파티션 개수만큼 컨슈머를 추가하면 되어서 간단합니다.
평소에 프로듀서가 보내는 메시지 양을 확인하고, 컨슈머의 데이터 처리량을 예상해서 프로듀서가 보내는 메시지 양보다 더 많이 처리할 수 있게 파티션을 늘리면 랙이 쌓이지 않으면서 안정적으로 운영할 수 있습니다.
간단하게 https://eventsizer.io/partitions 이곳에서 계산해볼 수 있습니다.
파티션은 한 번 늘리면 줄일 수 없고, 컨슈머가 늘어날수록 브로커에 부담이 커지므로 처음에 조금 적게 운영해보고 차차 늘리는 형식으로 운영해 보는 것이 좋습니다.
메시지 키 사용 여부
파티션이 새롭게 추가되거나 제외되면 리밸런싱이 일어납니다.
리밸런싱이 일어나면 라운드 로빈 할당 전략일경우 기존의 연결을 유지하지 않고 리밸런싱되고, 스티키 파티셔닝 전략을 사용할경우 최대한 기존의 연결을 유지하면서 리밸런싱됩니다.
두 전략 모두 파티션과 컨슈머가 리밸런싱 되었을 때 기존의 연결과 완전히 일치하는지는 보장해주지 않습니다.
만약 토픽이 특정한 컨슈머와 키를 통해 매칭되어야하고, 데이터 처리 순서도 동일해야 할 경우 처음에 컨슈머의 개수를 정한 후 추후에 추가하는 것은 최대한 지양해야 합니다.
커스텀 컨슈머를 개발해 매칭할 수도 있지만, 개발도 어렵고 적용하기도 쉽지 않으므로 처음에 파티션 개수를 프로듀서가 전송하는 데이터 양보다 넉넉히 잡고 생성해둬야 합니다.
브로커 영향도
파티션은 세그먼트를 저장할 때 브로커의 파일 시스템을 이용하여서 파티션이 늘어날수록 브로커가 접근하는 파일 개수도 많아집니다.
열려있는 파일이 너무 많으면 운영체제에서 새롭게 파일에 접근하는 작업이 거부될 수 있어서 브로커 당 파티션 개수를 확인해보고 파티션의 개수를 결정해야 합니다.
만약 파티션이 많이 필요하다면 브로커의 개수를 늘리는 상황도 고려해봐야 합니다.
아파치 카프카 어플리케이션 프로그래밍 with 자바 4장
