Kafka log , Segment
- 카프카의 로그 메시지는 실제로는 segment로 저장이 된다.
- 파티션은 단순히 파일 디렉토리만 되어 있고, 해당 파티션 디렉토리에 메시지 저장 segment를 file로 가지고 있다.
- 파티션은 여러개의 segment로 구성되며 개별 segment는 데이터 용량이 차거나 일정 시간이 경과하면 close되고
새로운 segment를 생성하여 데이터를 연속적으로 저장한다. - segment는 close 되면 더 이상 브로커가 write하지 않으며 read-only가 된다. 브로커는 여러개의 segment중 단 하나의 active segment에만 write와 read를 수행한다. 하나의 파티션은 단 하나의 active segment를 가진다.
log.segment.bytes (broker level)
- 개별 segment의 최대크기이며 기본값은 1gb
- 지정된 크기를 넘기면 해당 segment는 더 이상 active segment가 아니고 close된다 (write는 안되고 read 만됨)
- topci config는 segment.bytes이며 기본값은 log.segment.bytes 설정을 따른다. (broker 설정을 override한다)
log.roll.hours(ms) (broker level)
- 개별 segment가 유지되는 (roll 수행 되기 전) 최대 시간이며 기본값은 7일이다.
- 지정된 시간을 넘기면 해당 segment는 더 이상 active segment가 아니고 close된다. (write는 안되고 read만)
- log.segment.bytes에 지정된 크기만큼 차지 않아도 log.roll.ms만큼의 시간이 지나면 해당 segment를 close한다.
- topic config는 segment.ms이며 기본값은 log.roll.hours 설정에 따른다. (broker 설정을 override한다)
Topic을 생성하면 파티션 디렉토리내에 메시지 내용을 가지는 segment와 offset의 위치 byte 정보를 가지는 index파일, record생성 시간에 따른 위치 byte 정보를 가지는 timeindex 파일로 구성된다.
파일이름은 그전 파일의 마지막 offset 기준으로 생성이 된다. 0000000000000000042.log 그전 로그 파일이 42까지 offset을 commit해서 남김
메시지로그 Segment의 index, timeindex
- index 파일은 offset 별로 byte position 정보를 가지고 있다.
- 메시지 segment는 file기반이므로 특정 offset의 데이터를 파일에서 읽기 위해서는 시작 File Poiner에서 얼마만큼의 byte에 위치해 있는지 알아야함
- index 파일은 모든 offset에 대한 byte position 정보를 가지고 있지 않으며
- log.index.inverval.bytes에 설정된 값만큼의 segment bytes가 만들어질 때마다 해당 offset에 대한 byte position
정보를 기록한다. - Timeindex 파일은 메시지의 생성 Unix 시간을 밀리 세컨드 단위로 가지고 있고 해당 생성 시간에 해당하는
offset정보를 가진다.
Segment 생명주기 + log.cleanup.policy
- Segment 파일은 Active => Closed => Deleted 또는 Compacted 단계로 관리가 된다.
- Segment 파일은 Log Cleanup 정책에 따라 지정된 특정 시간이나 파일 크기에 따라 삭제 되거나
Compact 형태로 저장된다.
Log Cleanup Policy
카프카 브로커는 오래된 메시지를 관리하기 위한 정책을 log.cleanup.policy 로 설정 (Topic 레벨은 cleanup.policy)
- log.cleanup.policy = delete 로 설정하면 segment를 log.retention.hours나 log.retention.bytes 설정값에 따라 삭제
- log.cleanup.policy = compact로 설정하면 segment를 key값 레벨로 가장 최신의 메시지만 유지하도록 segment 재 구성
- log.cleanup.policy = [delete, compact] 로 설정하면 compact와 delete를 함께 적용
log.retention.hours(ms)
- 개별 Segment가 삭제되기전 유지하는 시간. 기본은 1주일(168시간)
- 크게 설정하면 오래된 segment를 그대로 유지하므로 디스크 공간이 더 필요하다.
작게 설정하면 오래된 segment를 조회할 수 없음 - Topic Config는 retention.ms이며 기본값은 log.retention.hours를 따른다.
log.retention.bytes
- Segment 삭제 조건이 되는 파티션 단위의 전체 파일의 크기를 설정한다. 기본값은 -1로 무한대이다.
- 적당한 디스크 공간 사용량을 제약하기 위해 보통 설정하게 된다.
- Topic Config는 retention.bytes이며 기본값은 log.retention.bytes를 따른다.
log.retention.check.interval.ms
- 브로커가 background로 Segment 삭제 대상을 찾기 위한 ms 단위의 주기
Log Compaction
- log.cleanup.policy=compact 로 설정 시 Segment의 key값에 따라 가장 최신의 메시지로만
compact하게 segment 재 구성한다. - key값이 null 인 메시지에는 적용할 수 없음
- 백그라운드 스레드 방식으로 별도의 I/O 작업을 수행하므로 추가적인 I/O 부하가 소모된다.
- Active Segment는 Compact 대상에서 제외된다.
- Compaction은 파티션 레벨에서 수행 결정이 되며, 개별 세그먼트들을 새로운 세그먼트들로 재 생성하게 된다.
compact가 이뤄지면 offset들이 띄엄띄엄 존재하게 된다.
현재 메모리상(Dirty Segments Map) 에 Alex 를 key로 가진 log중에 71이 가장 최신임으로
나머지는 지우고 정리하게 된다.
각 key 값 중에 최신 value를 가진 log들만 살아남아서 clean log segment가 되었다.
- 메시지의 순서는 여전히 유지되고 메시지 자체의 offset은 변하지 않는다.
- Consumer는 (Active Segment를 제외하고) 메시지의 가장 최신 값을 읽는다.
- 단 Compact 기반으로 로그가 재생될 시 키 값은 있지만 밸류가 Null 값을 가지는 메시지는 일정 시간 이후에 삭제가 되기 때문에 읽지 못할 수 도 있다.
Log Compaction 수행 시점
- Dirty 비율이 log.cleaner.min.cleanable.ratio 이상이고 메시지가 생성된 지 log.cleaner.min.compaction.lag.ms 이 지난 Dirty 메시지에 수행된다.
- 메시지가 생성된지 log.cleaner.max.compaction.lag.ms 이 지난 Dirty 메시지에 수행된다.
log.cleaner.min.cleanable.ratio
- Log cleaner가 Compaction을 수행하기 위한 파티션 내의 dirty 데이터 비율 (dirty/total)
- 기본값은 0.5이며 값이 작을 수록 Log cleaner가 더 빈번히 Compactionㅇ르 수행한다.
- Topic Config는 min.cleanable.dirty.ratio 이다.
log.cleaner.min.compaction.lag.ms
- 메시지가 생성된 후 최소한 log.cleaner.min.compaction.lag.ms 가 지나야 Compaction 대상이 될 수 있다.
- 기본값은 0이며 값이 클수록 최근 데이터 보다는 오래된 데이터를 기준으로 수행된다.
- Topic Config는 min.compaction.lag.ms이다.
log.cleaner.max.compaction.lag.ms
- Dirty ratio 이하여도 메시지 생성 후 log.cleaner.max.compaction.lag.ms 시간이 지나면 Compaction 대상이 될 수 있다.
- 기반값은 무한대에 가까운 큰 값이며 Topic Config는 max.compaction.lag.ms 이다.
value가 null인 경우에는 내부적으로 cleaner가 지우게 된다.
'Cloud > kafka-core' 카테고리의 다른 글
Multi Node Kafka Cluster (0) | 2024.07.02 |
---|---|
Kafka File Producer App + File Consumer App (0) | 2024.06.30 |
Kafka Consumer - 03 (0) | 2024.06.18 |
Kafka Consumer - 02 (0) | 2024.06.04 |
Kafka Consumer - 01 (0) | 2024.05.16 |