[ADVANCED #9] 카프카의 데이터 저장 메커니즘: 파티션, 세그먼트, 인덱스 그리고 로그 정리 정책

1. 개요

 카프카의 로그 메시지는 실제로는 Segment라는 단위로 저장된다. 파티션은 단순히 파일 디렉토리 형태일 뿐이며, 해당 디렉토리 안에는 메시지를 담고 있는 여러 개의 Segment 파일이 존재한다.

 

 파티션은 여러 Segment로 구성되고, 개별 Segment는 데이터 용량이 가득 차거나 일정 시간이 지나면 close되며 새로운 Segment가 생성되어 메시지를 이어서 저장한다. 이를 롤링(rolling)이라고 하며, 예를 들어 Segment #1이 close되면 Segment #2가 새로 만들어지는 식이다.

 

 Segment가 close되면 브로커는 더 이상 해당 Segment에 write하지 않고, read-only 상태로 유지한다. 브로커는 여러 Segment 중 단 하나의 Active Segment에만 쓰기(write)와 읽기(read)를 수행한다. 따라서 하나의 파티션은 항상 단 하나의 Active Segment를 가진다.

---

2. Segment의 저장 크기와 roll 관련 설정

Config	설명
log.segment.bytes	- 개별 segment의 최대 크기이며 기본값은 1GB (근데 보통 데이터 크기 처리는 Topic을 기준으로 설정해줌) - 지정된 크기를 넘기면 해당 segment는 더 이상 active segment가 아니고 close됨(즉, write는 안 되고 read만 됨) - Topic config는 segment.bytes이며, 기본값은 log.segment.bytes 설정을 따름
log.roll.hours(ms)	- 개별 segment가 유지되는(roll 수행되기 전) 최대 시간이며 기본값은 7일 - 지정된 시간을 넘기면 해당 segment는 더 이상 active segment가 아니고 close됨(write는 안 되고 read만 됨) - log.segment.bytes에 지정된 크기만큼 차지하지 않아도 log.roll.ms만큼의 시간이 지나면 해당 segment를 close함 - Topic config는 segment.ms이며, 기본값은 log.roll.hours 설정을 따름

---

3. 파티션 디렉토리내의 Segment와 Index 파일 구성

Topic을 생성하면, 파티션 디렉토리에는 다음과 같은 파일들이 생성된다.

• Segment 파일: 실제 메시지를 저장
• Index 파일: offset과 byte 위치를 매핑
• TimeIndex 파일: 메시지 생성 시간과 offset을 매핑

kafka-topics --bootstrap-server localhost:9092 --create --topic pizza-topic-segtest --partitions 3

~/data/kafka-logs/pizza-topic-segtest-0 디렉토리내 파일

---

4. 메시지 로그 Segment와 Index, TimeIndex

• Index 파일: offset마다 byte position 정보를 기록한다. Segment는 파일 기반이므로 특정 offset을 조회하기 위해서는 시작 포인터에서 몇 바이트 떨어져 있는지 알아야 한다.
• Index 파일은 모든 offset을 기록하지 않고, log.index.interval.bytes에 설정된 간격에 따라 주기적으로 기록된다.
• TimeIndex 파일: 메시지 생성 시간을 밀리초 단위의 Unix Time으로 기록하고, 해당 시간에 매핑되는 offset을 관리한다.

---

5. Segment 파일의 rolling

• Segment는 Active → Closed 상태로 전환된다.
• Segment 파일명은 각 Segment의 시작 offset을 기준으로 작성된다.
• 하나의 파티션에는 오직 하나의 Active Segment만 존재한다.

---

6. Segment 파일의 생명 주기

 

• Segment는 Active → Closed → Deleted 또는 Compacted 단계로 관리된다.
• 삭제 또는 Compact 여부는 Log Cleanup 정책에 따라 결정된다.

---

7. Log Cleanup Policy

카프카는 오래된 메시지를 관리하기 위해 log.cleanup.policy를 사용한다. (토픽 레벨에서는 cleanup.policy)

• delete : log.retention.hours나 log.retention.bytes 기준에 따라 Segment 삭제
• compact : Key 단위로 최신 메시지만 유지하도록 Segment 재구성
• [delete, compact] : 두 정책을 혼합 적용

---

8. Log.cleanup.policy=delete시 삭제를 위한 설정 파라미터

Config	설명
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 단위의 주기

---

9. Log Compaction

[1] Log Compaction이란?

 

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

[2] Log Compaction 수행 개요

1)

 

2) 

• Active Segment는 Compact 대상에서 제외
• Compaction은 파티션 레벨에서 수행 결정이 되며, 개별 세그먼트들을 새로운 세그먼트들로 재생성함

[3] Log Compaction 수행

 

 

 

[4] Log Compaction 수행 후 특징

• 메시지 순서(Ordering)는 유지된다.
• 메시지 offset은 변하지 않는다.
• Consumer는 Active Segment를 제외하고 Key별 최신 메시지만 읽을 수 있다.
• 다만, Key는 존재하지만 Value가 null인 메시지는 일정 시간이 지나면 삭제되어 조회되지 않을 수 있다.

[5] 언제 Log Compaction이 수행되는가?

• Dirty 비율이 log.cleaner.min.cleanable.ratio 이상이고 메시지가 생성된 지 log.cleaner.min.compaction.lag.ms이 지난 Dirty 메시지에 수행
• 메시지가 생성된지 log.cleaner.max.compaction.lag.ms 이 지난 Dirty 메시지에 수행

Config	설명
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임

[6] Compaction 수행 시 메시지의 삭제

 

• Key가 null인 메시지나 오래된 Value는 Compaction 과정에서 제거될 수 있다.
• 이로 인해 Consumer는 최신 상태만 조회할 수 있고, 불필요한 데이터는 정리된다.