4장. 카프카 상세 개념 - 토픽과 파티션

4장. 카프카 상세 개념 - 토픽과 파티션

⭐ 토픽과 파티션

---

토픽은 카프카의 시작과 끝이다.

• 토픽을 만들면서 카프카를 사용하기 시작한다.

토픽에 대해 잘 이해하고 설정을 잘하는 것이 카프카를 통한 데이터 활용도를 높이는 것이다!!

 

📌 적정 파티션 개수

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

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

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

 

데이터 처리량

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

• 파티션의 개수가 많아질 수록 매핑되는 컨슈머 개수가 증가하기 때문
• 따라서, 파티션 개수를 정할 때 토픽에 필요한 데이터 처리량을 측정해 정하는 것이 중요

 

파티션 개수만큼 컨슈머 스레드를 운영하면 토픽의 병렬처리를 극대화 할 수 있다.

 

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

• 적다면 컨슈머 렉 발생 + 데이터 처리 지연 발생

 

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

❗상용에서 운영중인 카프카에서 더미 데이터로 테스트해보기

 

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

• 데이터 지연이 발생해도 되는지 아닌지에 따라서 데이터 생성량의 최대치를 어떤 것으로 잡을 지 정하면 된다.

 

❓ 그럼 파티션 개수를 계속 늘리면 좋아지는 것이 아닌가

❗파티션 개수를 늘리면 컨슈머, 브로커의 부담이 있어 그런 것은 아니다

⇒ 데이터를 처리하는데 지연 발생에 따른 서비스 영향도를 같이 고려해야 한다.

 

메시지 키 사용 여부

💡 메시지 키를 사용함과 동시에 데이터 처리 순서를 지켜야 하는 경우에 대해 고려해야 한다.
    - 메시지 키 사용 여부는 데이터 처리 순서와 밀접한 연관이 있다

 

❔ 만약 메시지 키를 사용할 경우

• 프로듀서가 토픽으로 데이터를 보낼 때 메시지 키를 해시 변환하여 파티션에 매칭한다.
• 이때, 파티션의 개수가 달라지면 이미 매칭된 파티션과 메시지 키의 매칭이 깨진다.
• 전혀 다른 파티션에 데이터가 할당
• 따라서, 파티션 개수가 달라지면 컨슈머는 특정 메시지 키의 순서를 더는 보장받지 못한다.

1.  

 

1. 메시지 키를 사용하고 컨슈머에서 메시지 처리 순서가 보장되어야 할 때
   • 최대한 피타션 변화가 없어야 한다.

⇒ 파티션 개수를 프로듀서가 전송하는 데이터양보다 더 크게 잡고 생성하는 것이 좋다.

1. 메시지키를 사용하지만 데이터 처리 순서를 지키지 않을 경우
   • 파티션 개수를 처음부터 크게 잡지 않고 데이터의 양에 따라 파티션을 늘리면 된다.

 

브로커와 컨슈머 영향

카프카에서 파티션은 각 브로커의 파일 시스템을 사용하기 때문에 파티션이 늘어나는 만큼 브로커에서 접근하는 파일 개수가 많아진다.

 

카프카 브로커가 접근하는 파일 개수를 안정적으로 유지하기 위해서는 각 브로커당 파티션 개수를 모니터링 해야 한다.

 

만약 브로커가 관리하는 파티션이 너무 많다면 파티션의 개수를 분산하기 위해 카프카 브로커 개수를 늘리는 방안도 생각해야 한다.

 

📌 토픽 정리 정책(cleanup.policy)

---

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

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

데이터가 삭제되지 않고 남아 있다면 오프셋을 지정해 이전 데이터를 가져올 수 있다.

 

⚠️ 하지만 데이터를 오랫동안 삭제하지 않으면 저장소 사용량이 지속적으로 늘어나게 된다.

 

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

• delete (완전 삭제)
• compact (압축 - 동일 메시지 키의 가장 오래된 데이터 삭제)

 

토픽 삭제 정책(delete)

일반적으로 cleanup.policy는 delete로 설정한다.

명시적으로 토픽의 데이터를 삭제하는 것을 뜻하며, 삭제 시 세그먼트 단위로 삭제를 진행한다.

 

📖 세그먼트

• 토픽의 데이터를 저장하는 명시적인 파일 시스템 단위
• 파티션마다 별개로 생성된다
• 세그먼트 파일의 이름은 오프셋 중 가장 작은 값이 된다.
  
  
• 여러 조각으로 나뉘며, 1개의 세그먼트 크기를 설정할 수 있다.
• 설정한 크기보다 커질 경우 새로운 세그먼트를 열어 데이터를 저장한다,.
• 현재 사용중인 세그먼트를 엑티브 세그먼트라고 한다.

 

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

 

retention.ms

• 토픽의 데이터를 유지하는 기간 (밀리초)
• 세그먼트 파일의 마지막 수정 시간이 retention.ms을 넘어가면 삭제
• retention.byte : 토픽의 최대 데이터 크기 제어
  • 크기가 넘어가면 삭제

 

토픽 압축 정책(compact)

📖 압축

• 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책
  
  

📖 더티 비율(dirty ratio)

• 더티 영역 메시지 개수 / (더티 영역 메시지 개수 + 클린 영역 메시지 개수)

 

⚠️ 메시지 키를 기준으로 오래된 데이터를 삭제하기 때문에 삭제 정책과 달리 파티션에서 오프셋의 증가가 일정하지 않을 수 있다.

 

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

 

min.cleanable.dirty.ratio

• 이 값에 따라 토픽의 압축이 수행된다.
• 더티 비율이 이 값을 넘어가면 압축이 수행된다.
• 설정한 값이 클 수록 한 번 압축할 때 많은 데이터가 줄어 효과가 좋다.
• 하지만 비율이 될 때까지 용량을 차지하므로 용량 효율이 좋지 않다.

 

📌 ISR(In-Sync-Replicas)

---

💡 ISR
  - 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 말한다. 

 

“동기화가 완료” 의 의미

• 리더 파티션의 모든 데이터가 팔로워 파티션에 복제된 상태
• 데이터를 안전하게 사용할 수 있다.

 

ISR 이라는 용어의 등장 이유

• 팔로워 파티션이 리더 파티션으로부터 데이터를 복제하는 데 시간이 걸리기 때문

리더 파티션에 새로운 레코드가 추가되어 오프셋이 증가하면 팔로워 파티션이 위치한 브로커는 리더 파티션의 데이터를 복제한다.

 

replica.lag.time.max.ms

• replica.lag.time.max.ms 값 만큼의 주기를 가지고 팔로워 파티션이 데이터를 복제하는지 확인한다.
• 이 값보다 더 긴 시간동안 데이터를 가져가지 않으면 해당 팔로워 파티션에 문제가 생긴 것으로 판단 후 ISR 그룹에서 제외

 

보통 ISR로 묶인 팔로워 파티션은 리더 파티션으로 선출될 자격을 얻지만 일부 데이터 유실이 발생하더라도 서비스를 중단하지 않고 지속적으로 토픽을 사용하고 싶다면 ISR이 아닌 팔로워 파티션을 리더로 선출할 수 있다.

• unclean.leader.election.enable 옵션

 

참고 자료

http://www.yes24.com/Product/Goods/99122569