kafka topic and partition

[yeomko22]

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

• 데이터 처리량

• 메세지 키 사용 여부

• 브로커, 컨슈머 영향도

• 파티션 개수가 많아지면 1:1 매칭되는 컨슈머 개수가 늘어난다. 따라서 데이터 처리량 측정이 중요하다.

데이터 처리량

• 컨슈머의 처리량을 늘리는 것 (컨슈머 서버의 스케일 업)
• 컨슈머를 추가하여 병렬처리량을 늘리는 것 (가장 확실)
• 파티션 개수만큼 컨슈머를 추가하는 방법이 데이터 처리량을 늘리는 가장 확실한 방법
• 그러므로 프로듀서가 보내는 데이터 양과 컨슈머의 처리량을 계산하면 파티션 개수가 나온다.

producer 데이터 전송량 < 컨슈머 처리량 x 파티션 개수

• 컨슈머 데이터 처리량을 구하기 위해서는 더미 데이터로 테스트를 진행해볼 것

[yeomko22]

메세지 키 사용 여부

• 메세지 키 를 사용함과 동시에 데이터 처리 순서를 지켜야하는 지를 살펴봐야함
• 메세지 키를 사용할 경우, 파티션 개수가 변경되면 매칭이 깨져버린다. (해시 함수를 사용하기 때문)
• 떄문에 파티션 개수가 달라지는 순간 메시지 키를 사용하는 컨슈머는 특정 메시지 키의 순서를 더는 보장받지 못한다.
• 만일 컨슈머에서 메시지 처리 순서가 보장되어야 한다면 파티션 변화가 발생하지 않는 방향으로 운영해야 한다.
• 파티션 개수가 변하는 경우에는 기존 메시지 키의 매칭을 그대로 가져가기 위해 커스텀 파티셔너 개발이 필요하다.
• 이러한 문제때문에 파티션 개수를 넉넉하게 잡는 편이 좋다.

[yeomko22]

브로커와 컨슈머의 영향도

• 파티션이 늘어나는 만큼 브로커에서 접근하는 파일 개수가 많아진다.
• 운영체제에서는 프로세스가 열 수 있는 파일 최대 개수를 제한한다.
• 따라서 각 브로커 당 파티션 개수를 모니터링 해야 한다.
• 만일 브로커 수에 비해 파티션이 너무 많을 경우 브로커를 늘려주는 방안도 고려해야 한다.

[yeomko22]

토픽 관리 정책

• 시간 또는 용량에 따라 삭제 규칙 적용이 가능
• cleanup policy에는 delete와 compact가 있다.

topic delete policy

• 세크먼트 단위로 삭제를 진행함
• 삭제의 기준은 시간 혹은 용량
• 각파티션은 다시 세그먼트 단위로 파일에 저장이 된다. 이 때 파일의 크기는 segment.bytes 옵션에 따른다.

topic compact policy

• 일반적ㅇ니 압축과는 달리 각 메세지 키 별로 오래된 레코드는 삭제하는 정책을 말함
• KTable 처럼 메세지 키를 기반으로 데이터를 처리할 경우 유용하다.

[yeomko22]

ISR (In Sync Replicas)

• 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태, 즉, 모든 데이터가 팔로워 파티션에 복제된 상태를 말한다.
• 프로듀서는 리더 파티션에 데이터를 전쏭하고, 리더 파티션은 다시 팔로워 파티션에 데이터를 복제한다.
• ISR로 묶인 리더와 팔로워는 데이터가 모두 동일, 그러므로 팔로워도 리더로 선출될 자격 있음
• unclean.leader.election.enalbe=true로 설정하면 ISR이 아니더라도 리더 파티션이 장애가 났을 떄 팔로워 파티션이 리더로 선출된다. 이 떄 데이터 유실이 발생한다.
• 반대의 경우엔 리더 파티션이 존재하는 브로커가 다시 시작될 때까지 기다린다. 이 때는 서비스가 중단된다. 그러나 데이터 유실은 발생하지 않는다.