[카프카 클러스터]

프로듀서, 컨슈머는 리더 파티션과 직접 통신해서 데이터를 처리하게 됩니다.

팔로워 파티션은 리더 파티션에 있는 데이터를 확인해서 자신에게 없는 데이터를 복제해갑니다.

파티션 = 3, 복제개수 = 3인 토픽 생성 시

리더 파티션의 위치가 Round-Robin 방식으로 적절히 분배되기 때문에 프로듀서, 컨슈머가 클러스터와 통신을 할 때 네트워크 비용이 각 서버(브로커)에 분산된다는 장점이 있습니다. 앞단에 로드 밸런서를 놓는 방식이 아니라 컨슈머, 프로듀서가 직접 분산해서 통신하는 것입니다. 

 

복제 개수가 늘어나면 데이터를 안전하게 저장할 수 있지만, 팔로워 파티션이 지속적으로 리더 파티션에 있는 데이터를 복제해야하기 때문에 브로커들 간의 네트워크 통신이 많아진다는 단점이 있습니다. 때문에 일반적인 경우에는 복제 개수를 2로 운영하는 것이 브로커의 리소스 관리에 좋습니다.

 

리더 파티션이 특정 브로커에 몰려있는 경우, 파티션 밸런싱을 맞추는 명령어 (kafka-reassign-partisions.sh)를 적용할 수 있습니다. 때문에 카프카 클러스터를 운영하다가 서버 관련 리소스 사용 비율이 특정 브로커에 몰려있다고 판단되면, 리더 파티션이 밀집되어 있지 않은지 확인하는 것이 중요합니다.


[1주키퍼 + 다중 카프카 클러스터]

 

카프카 클러스터를 상황에 따라 분리해서 데이터를 격리할 수 있습니다. 한 개의 주키퍼에 주문 로그, 데이터 분석, 웹 로그 등과 같이 목적에 따라 나누는 것도 좋은 방법일 수 있습니다. 하지만 주키퍼가 데이터를 많이 저장하고 통신량이 많아지면 병목 지점이 될 수 있다는 부분을 유의해야 합니다.

+ Recent posts