005 Broker Log Segment

강의 메모 #

로그와 세그먼트 #

img.png

  • log.segment.bytes : 바이트 단위의 최대 세그먼트 크기 지정 (기본 값은 1GB)

  • log.roll.ms(hours) : 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기 (기본값은 7일)

  • 프로듀서가 데이터를 전송하면 active 되어있는 .log 파일에 offset 22번으로 들어간다. (FIFO)

  • 가장 최초의 offset 번호가 파일 이름이 된다

  • 가장 마지막 세그먼트 파일을 active segment라고 한다.

    • 브로커의 삭제 대상에서 포함되지 않는다.
    • retention 옵션에 ㄸ라 삭제 대상으로 지정된다.

세그먼트와 삭제 주기 (cleanup.policy=delete) #

img_1.png

  • retention.ms(minutes, hours) : 세그먼트를 보유할 최대 기간 (기본값 7일)
  • retention.bytes : 파티션 당 로그 적재 바이트 값 (기본값 -1; 지정하지않음)
    • 기간과 바이트 중 운영하면서 디스크, 들어오는 데이터 용량에 맞게 수정해야한다
  • log.retention.check.interval.ms : 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격 (기본값 5분)
  • 파일 단위로 삭제되기 때문에, 로그 단위로 개별 삭제는 불가능하다
  • 이미 적재된 데이터에 대해서 수정 불가능 -> 데이터 적재(프로듀서)/사용(컨슈머)할때 데이터를 검증하는 것이 좋다
    • validation 별도 지원은 없으므로 send() 보내기 전에 로직에서 처리를 하던지, 컨슈머 입장에서 받아올때 로직에서 처리하던지 해야할듯

cleanup.policy=compact #

img_2.png

  • 압축(compression)과는 다른 개념
  • 토픽 압축 정책 : 메시지 키 별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책
  • compact 로직에 의해서 어떤 세그먼트 단위로 삭제가 전체 통으로 일어나는게 아니라 message key 단위로 가장 최근에 남아져있는 것만 메시지 키만 남기고 삭제한다.
  • 일부 레코드만 삭제가 될 수 있다.
    • 압축은 active segment를 제외한 데이터가 대상이다.
  • 13(K3)이 16(K3)보다 오래된 데이터이므로 삭제되고, 10(K1), 12(K1), 15(K1) 중에는 15번이 남겨지겠다. 나머지는 삭제(10, 12)

테일/헤드 영역, 클린/더티 로그 #

img_4.png

  • 테일 영역
    • 압축 정책에 의해 압축이 완료된 레코드들
    • 클린(clean) 로그 라고도 부른다
    • 중복 메시지 키가 없다
  • 헤드 영역
    • 압축 정책이 되기 전 레코드들
    • 더티(dirty) 로그 라고도 부른다.
    • 중복된 메시지 키가 있다.

min.cleanable.dirty.ratio #

img_3.png

액티브 세그먼트를 제외한 세그먼트에 남아있는 테일 영역의 레코드 개수와 헤드 영역의 레코드의 비율을 뜻한다 ex) 0.5로 설정 : 테일 영역의 레코드 개수가 헤드 영역의 레코드 개수와 동일할 경우 압축 실행 0.9 : 크게 설정하면, 한번 압축을 할때 많은 데이터가 줄어들므로 압축 효과가 좋지만, 이 비율이 될때까지 용량을 차지하므로 용량 효율이 좋지 않다. 0.1 : 작게 설정하면, 압축이 자주 일어나서 가장 최신 데이터만 유지할 수 있지만 압축이 자주 발생하기 때문에 브로커에 부담을 줄 수 있다.