• 카프카 로그의 파티션과 세그먼트

    Untitled

    • 카프카의 로그 메세지는 실제로 segment로 저장

    • 파티션은 단순히 파일 디렉토리로만 되어 있고, 해당 파티션 디렉토리에 메세지 저장 segment를 file로 가지는 형태

    • 파티션은 여러개의 segment로 구성되며, 개별 segment는 데이터 용량이 차거나 일정 시간이 경과하면 close되고 새로운 segment를 생성 → 새로운 데이터 저장

    • segment는 close되면 더 이상 브로커가 write하지 않고 read-only상태로 변경

    • 브로커는 여러 개의 segment중에 단 하나의 active segment에만 write/read 수행

    • 즉, 하나의 파티션은 하나의 active segment를 가짐

    • segment의 저장 크기와 roll 관련 config

      브로커 레벨 config

      브로커 레벨 config

  • 파티션 디렉토리내의 segment와 index 파일 구성

    • topic을 생성하면 파티션 디렉토리내에 메세지 내용을 가지는 segment와 offset위치 byte정보를 가지는 index 파일, record 생성 시간에 따른 위치 byte 정보를 가지는 timeindex 파일로 구성

    • 예시(pizza-topic-stest)

      Untitled

      • 파일이름은 offset 번호를 알려주며 파일이름의 offset부터 저장됨을 알려줌
      • 예제는 offset 0부터 저장된 파일들
  • 메세지 로그 segment와 Index, TimeIndex

    .index 파일 예시는 18 offset의 byte position을 가지고 있으며 offset 0 → offset 18 까지는 4334 byte 떨어져 있음을 의미
.timeIndex 에서는 시간 단위로 offset을 기록하고 해당 offset을 .index파일에서 위치를 참조하는 방식

    .index 파일 예시는 18 offset의 byte position을 가지고 있으며 offset 0 → offset 18 까지는 4334 byte 떨어져 있음을 의미 .timeIndex 에서는 시간 단위로 offset을 기록하고 해당 offset을 .index파일에서 위치를 참조하는 방식

    • Index 파일은 offset 별로 byte position 정보를 가지고 있음
    • 메세지 segment는 file기반이므로 특정 offset의 데이터를 파일에서 읽기 위해서는 시작 FIle Pointer에서 얼마만큼 byte에 위치해 있는지 알아야함
    • Index파일은 모든 offset에 대한 byte position 정보를 가지고 있지 않으며, log.index.interval.bytes에 설정된 값만큼의 segment bytes가 만들어질 때마다 해당 offset에 대한 byte position 정보를 기록
  • Segment 파일의 생명 주기

    • segment 파일은 Active → Closed → Deleted OR Compacted 단계로 관리
    • segment 파일은 Log Cleanup 정책에 따라 지정된 특정 시간이나 파일 크기에 따라 삭제 되거나 Compact 형태로 저장(default = delete)
    • Log Cleanup Policy
      • 카프카 브로커가 오래된 메세지를 관리하기 위한 정책

      • log.cleanup.policy로 설정(Topic 레벨에서 설정하기 위해서는 cleanup.policy로 설정)

      • log.cleanup.policy = delete → segment를 log.retention.hours, log.retention.bytes 설정 값에 따라 삭제

        • log.cleanup.policy = delete config

          Untitled

      • log.cleanup.policy = compact → segment를 key 값 레벨로 가장 최신의 메세지만 유지하도록 segment 재구성

      • log.cleanup.policy = [delete, compact] → compact, delete 동시 적용

  • Log Compaction이란

    Untitled

    • log.cleanup.policy = compact 설정 시 segment의 key값에 따라 가장 최신의 메세지로만 compact하게 segment 재구성
    • key가 null인 메세지에는 적용 불가능
    • 백그라운드 스레드 방식으 별도의 I/O작업을 수행하므로 추가적인 I/O 부하 소모
  • Log Compaction 수행

    Untitled

    Untitled

    • Log Compaction 관련 더 깊이 알려면 참고: https://www.youtube.com/watch?v=VAKHYxu1qll
  • Log Compaction 수행 이후

    • 메세지의 순서(Ordering)은 유지
    • 메세지의 offset은 변하지 않음
    • Consumer는 (Active Segment 제외) 메세지의 최신 값을 읽음 단, Compact 기반으로 로그가 재생될 시 키값은 있지만 값이 null을 가지는 메세지는 일정 시간 이후 삭제되기 때문에 읽지 못할 수 있음)
  • Log Compaction 수행 시점

    Untitled

    • dirty 비율이 log.cleaner.min.cleanable.ratio 이상이고 메세지가 생성된 지 log.cleaner.min.compaction.lag.ms이 지잔 dirty 메세지에 대해 수행
    • 메세지가 생선된 지 log.cleaner.max.compaction.lag.ms 이 지난 dirty 메세지에 대해 수행
  • Compaction 수행 시 메세지의 삭제

    Untitled