kafka - 3

유현민·2022년 8월 10일
0

kafka

목록 보기
3/12
post-thumbnail

토픽 - 한 개 이상의 파티션 소유

파티션 - 데이터 저장(레코드), 큐와 비슷한 구조, FIFO, 삭제X

파티션 배치

  • 라운드 로빈 방식
  • 장점 : 한개 브로커에 지속적으로 처리되는게 아니라 분산되어 데이터 처리
    통신집중 막고, 선형 확장하여 데이터 증가 대응 가능

데이터 쏠림 방지
kafka-reassign-partitions.sh -> 파티션 재분배

컨슈머 개수를 늘림과 동시에 파티션 개수도 늘리면 처리량이 증가하는 효과를 볼 수 있다.

파티션1 - 컨슈머2 -> 불가능
파티션2 - 컨슈머2 -> 가능
파티션2 - 컨슈머1 -> 가능

파티션 늘리면서 컨슈머도 같이 늘리기
만약 장애가 발생하면 컨슈머 한개로도 가능

파티션 개수 줄이기는 불가능

레코드

timestamp - 시간 저장, 스트림 프로세싱, 기본(생성시간)

offset - 브로커에 적재 -> 생성

header - (key-value), 스키마 버전, 포맷과 같이 데이터 프로세싱에 참고할만한 정보 담아서 사용 가능

key - 값 분류 위해 사용(파티셔닝), null이면 라운드 로빈 방식으로 데이터를 파티션에 저장, 어느 파티션에 들어갈지 정하는게 파티셔너 이다.

if 메시지 key == null -> RR방식으로 특정 토픽 파티셔너에 전달
!= null -> 해쉬값에 의해서 특정 파티션에 매칭되어 전달

value -> 문서들, 처리할 데이터 담는 공간(csv, JSON...)

브로커에 저장된 레코드의 메시지 값은 어떤 포맷인지 알 수 없기 때문에 미리 역직렬화 포맷 알아야한다.

토픽 이름 제약 조건

빈 문자열 X
영어, 숫자, 마침표, 언더바, 하이픈
마침표, 언더바 두개 동시 X

토픽이 데이터의 얼굴이다...
토픽이름 변경 불가

  1. 환경.팀명.APP명.메시지타입
  2. 프젝명.서비스명.환경.이벤트명
  3. 환경.서비스명.JIRA-번호.메시지타입
  4. 카프카클러슽명.환경.서비스명.메시지타입

클라이언트 메타데이터

카프카 클라이언트 ----(메타데이터 요청)---> 카프카 클러스터
카프카 클라이언트 <---(메타데이터 응답)---- 카프카 클러스터

카프카 클라이언트는 통신하고자 하는 리더 파티션의 위치를 알기 위해 메타데이터를 브로커로부터 전달 받는다.

카프카 프로두셔 메타데이터 옵션

metadata.max.age.ms -> 강제 리프래시 간격, 기본 5분
metadata.max.idle.ms -> 메타데이터를 캐시에 유지하는 기간, 시간이 지나면 강제로 meta RF

클라이언트는 무조건 리더와 통신, 리프래쉬 간격 확인

만약 LEADER_NOT_AVAILABLE 익셉션이 자주 발생하면 메타데이터 리프래시 간격을 확인하자!

카프카 데이터 복제 단위는 파티션

프로듀서와 컨슈머는 리더와 통신

profile
smilegate megaport infra

0개의 댓글