- 카프카의 토픽으로 들어오는 메세지는
세그먼트
라는 파일에 저장된다- 메세지는 정해진 형식에 맞추어 순차적으로 로그 세그먼트 파일에 저장된다
로그 세그먼트
는 메세지 내용뿐만 아니라 메세지의 키, 벨류, 오프셋, 메세지 크기 같은 정보도 함께 저장된다- 로그 세그먼트 파일들은 브로커의 로컬 디스크에 보관된다
- 로그 세그먼트의 최대 크기는
1GB
가 기본값으로 설정되어있다- 로그 세그먼트가 1GB보다 커지게 되는 경우에는 기본적으로
롤링
전략을 적용한다- 하나의 로그 세그먼트에 메세지를 덧붙이다가, 로그 세그먼트의 크키가 1GB에 도달하면 해당 세그먼트 파일을 클로즈 하고, 새로운 로그 세그먼트를 생성하는 방식으로 진행된다
- 롤링 전략이 있지만, 카프카 관리자는 1GB 크기의 로그 세그먼트 파일이 무한히 늘어날 경우를 대비해 로그 세그먼트에 대한
관리 계획을 수립
해둬야 한다- 로그 세그먼트를 관리하는 방법은 크게
로그 세그먼트 삭제
와컴팩션
으로 구분할 수 있다
토픽생성
kafka-topics --bootstrap-server kafka1:9091 --create --topic chaptor4-topic04 --partitions 1 --replication-factor 3
chator4-topic04 토픽에 메세지 log1 전송
컨슈머를 이용해 chaptor4-topic04 토픽의 메세지를 가져온다. --from-beginning 옵션을 추가해서 강제로 peter-test03 토픽의 처음부터 메세지를 가져올 수 있게 한다
kafka-console-consumer --bootstrap-server kafka1:9091 --topic chaptor4-topic04 --from-beginning
chaptor4-topic04 토픽에 retention.ms
옵션을 조정해서 메세지를 삭제해 보도록 한다
kafka-config
명령어를 이용
콘솔 프로듀서와 콘솔 컨슈머가 실행되어 있다면, ctrl + X 또는 ctrl + C 버튼을 입력해 종료한다
kafka-configs --bootstrap-server kafka1:9091 --topic chaptor4-topic04 --add-config retention.ms=0 --alter
describe
로 확인삭제 주기의 기본값은 5분
이므로, 최대 5분후 삭제 작업이 일어난다chaptor4-topic04 토픽에 추가했던 retention.ms 옵션 삭제
kafka-configs --bootstrap-server kafka1:9091 --topic chaptor4-topic04 --delete-config retention.ms --alter
별도의 reteontion.ms
옵션을 설정하지 않으면, server.properties
의 옵션 값이 적용된다.
기본값은 7
일이므로, 모든 세그먼트 파일은 7일이 지남과 동시에 전부 삭제된다retention.bytes
옵션을 이용해서 지정된 크기
기준으로도 로그 세그먼트를 삭제할 수 있다
- 컴팩션은 로그를 삭제하지 않고 컴팩션하여 보관할 수 있다
- 로그 컴팩션은 기본적으로 로컬 디스크에 저장되어 있는 세그먼트를 대상으로 실행한다
- 현재 활성화된 세그먼트는 제외하고 나머지 세그먼트들을 대상으로 컴팩션이 실행된다
컴팩션 할지라도 카프카의 로컬 디스크에 로그를 무기한 보관한다면, 로그의 용량은 감당할 수 없이 커져서 디스크가 저장할 수 있는 용량의 한계에 도달하게 된다. 카프카에서는 단순하게 메세지를 컴팩션하게 보관하기보다는 좀 더 효율적인 방법으로 컴팩션 한다. 카프카에서 로그세그먼틀를 컴팩션하면 메세지의 키 값을 기준으로 마지막의 데이터만 보관하게 된다
로그 컴팩션
기능을 이용하는 대표적인 사례로는 카프카의 _consumer_offset
토픽이 있다_consumer_offset
토픽은 카프카의 내부 토픽으로, 컨슈머 그룹의 정보를 저장하는 토픽이다키(컨슈머 그룹명, 토픽명)
와 밸류(오프셋 커밋 정보)
형태로 메세지가 저장된다
- 예를들어 CG01 컨슈머 그룹이 T01 토픽을 컨슘하고, 첫 번째 메세지를 읽고 커밋했다고 가정
- 이 정보는
키
의밸류
형태 메세지로 _consumer_offset 토픽에 저장되어야 한다- 따라서 키는 CG01(컨슈머 그룹), T01(토픽명) 이고 밸류는 1(오프셋)인 메세지가 _consumer_offset 토픽에 저장된다
- 약 한 시간 후 CG01 컨슈머 그룹이 T01 토픽을 컨슘하고 나서 두 번째 메세지를 읽고 커밋한다
- 그러면 키가 (CG01, T01) 이고 밸류는 2인 메세지가 _consumer_offset 토픽에 저장된다
- 또 한 시간이 지나 세 번째 메세지를 읽고 커밋하면, 키가 (CG01, T01)이고 밸류는 3인 메세지가 _consumer_offset 토픽에 저장된다
- 현재
_consumer_offset
토픽에 저장된 메세지는 총 3개이고,키 (CG01, T01)
을 기준으로밸류가 1, 2, 3
인 메세지입니다- 이후
로그 컴팩션 동작
이 일어나면키값이 (CG01, T01)
인메세지의 마지막 데이터인 3
만남게 된다- 컨슈머 그룹은 항상 마지막으로 커밋된 오프셋 정보가 중요하므로, 과거에 커밋된 정보들은 삭제돼도 무방하다
로그 컴팩션
은 메시지의 키값을 기준으로 과거 정보는 중요하지 않고 가장 마지막 값이 필요한 경우에 사용한다프로듀서가 카프카로 메세지를 전송할 때, 메세지에는 메세지의 키와 밸류를 같이 전송하게 된다. 밸류는 필숫값이지만 키는 필숫값이 아니다. 따라서 로그 컴팩션
기능을 사용하고자 한다면, 카프카로 메세지를 전송할 때 키도 필숫값으로 전송
해야 한다.
- 키
K1
의 밸류 V1,V3,V4
- 컴팩션 후 밸류 V4- 키
K2
의 밸류 V2,V6,V10
- 컴팩션 후 밸류 V10- 키
K3
의 밸류 V5
- 컴팩션 후 밸류 V5- 키
K4
의 밸류 V7
- 컴팩션 후 밸류 V7- 키
K5
의 밸류 V8,V9
- 컴팩션 후 밸류 V9- 키
K6
의 밸류 V11
- 컴팩션 후 밸류 V11
빠른 장애 복구
최신의 상태만 복구
한다빠른 재처리
라는 장점이 있다고 해서 모든 토픽에 로그 컴팩션을 적용하는 것은 좋지 않다로그 컴팩션 작업
이 실행되는 동안 브로커의 과도한 입출력 부하가 발생할 수 있으니 유의해야 한다브로커의 리소스 모니터링
도 병행하여 로그 컴팩션
을 사용해야 한다옵션 | 옵션 값 | 적용 범위 | 설명 |
---|---|---|---|
cleanup.policy | compact | 토픽의 옵션으로 적용 | 토픽 레벨에서 로그 컴팩션을 설정할 때 적용하는 옵션 |
log.cleanup.policy | compact | 브로커의 설정 파일에 적용 | 브로커 레벨에서 로그 컴팩션을 설정할 때 적용하는 옵션 |
log.cleaner.min.compaction.lag.ms | 0 | 브로커의 설정 파일에 적용 | 메세지가 기록된 후 컴팩션하기 전 경과되어야 할 최소 시간을 지정한다. 만약 이 옵션을 설정하지 않으면, 마지막 세그먼트를 제외하고 모든 세그먼트를 컴팩션할 수 있습니다 |
log.cleaner.max.compaction.lag.ms | 9223372036854775807 | 브로커의 설정 파일에 적용 | 메세지가 기록된 후 컴팩션하기 전 경과되어야 할 최대 시간을 지정한다 |
log.cleaner.min.cleanable.ratio | 0.5 | 브로커의 설정 파일에 적용 | 로그에서 압축이 되지 않은 부분을 더티라고 표현한다. 저체 로그 대비 더티의 비율이 50%가 넘으면 로그 컴팩션이 실행된다 |