로그 컴팩션

💡 이번 포스팅에서는 로그 컴팩션에 대해 정리해 보도록 하겠습니다.

컴팩션은 로그 세그먼트 관리 정책 중 하나로, 로그를 삭제하지 않고 컴팩션하여 보관할 수 있습니다.

로그 컴팩션은 기본적으로는 로컬 디스크에 저장되어 있는 세그먼트를 대상으로 실행되는데, 현재 활성화(active)된 세그먼트는 제외하고 나머지 세그먼트들을 대상으로 컴팩션이 실행됩니다.

카프카에서는 단순하게 메시지를 컴팩션하여 보관하기보다는 메시지의 키값을 기준으로 마지막의 데이터만 보관하는 좀 더 효율적인 방법으로 컴팩션합니다.

이런 컴팩션을 사용하는 대표적인 컨슈머가 바로 __consumer_offsets입니다.

위 이미지와 같이 k1에 대해 k1, v1, v3, v4 가 저장되었다고 했을 경우 마지막 k1에 대한 값은 v4입니다. 따라서 컴팩션 후에는 k1에 대한 값으로 v4 만 저장하게 됩니다.

💡 로그 컴팩션을 구현하려면 컴팩션 된 토픽에 키가 있는 레코드가 있어야 합니다.

Log Cleaner

로그 컴팩션은 Log Cleaner라는 객체가 로그 컴팩션 작업을 수행합니다.

로그 컴팩션이 적용된 영역을 clean area, 아직 적용되지 않은 영역을 dirty area라고 부릅니다.

로그 컴팩션 파라미터

config	설명
log.cleaner.min.cleanable.auto	Log Cleaner가 컴팩션을 수행하기 위한 파티션 내의 dirty 데이터 비율 기본값은 0.5이며 값이 작을수록 Log Cleaner가 더 빈번히 컴팩션을 수행합니다. 토픽 구성은 min.cleanable.dirty.ratio 입니다.
log.cleaner.min.compaction.lag.ms	메시지가 생성 된 후 최소한 log.cleaner.min.compaction.lag.ms가 지나야 컴팩션 대상이 될 수 있습니다. 기본값은 0이며 값이 클수록 최근 데이터보다는 오래된 데이터를 기준으로 수행합니다. 토픽 구성은 min.compaction.lag.ms입니다.
log.cleaner.max.compaction.lga.ms	Dirty ratio 이하여도 메시지 생성 후 log.cleaner.max.compaction.ms 시간이 지나면 컴팩션 대상이 될 수 있습니다. 기본값은 무한대에 가까운 큰 값이며 토픽 구성은 max.compaction.lag.ms입니다.

로그 컴팩션 장점

이러한 로그 컴팩션의 장점으로는 빠른 장애 복구가 있습니다.

장애 복구 시 전체 로그를 복구하지 않고, 메시지의 키를 기준으로 최신의 상태만 복구합니다. 따라서 전체 로그를 복구할 때보다 복구 시간을 줄일 수 있다는 장점이 있습니다.

로그 컴팩션 단점

빠른 재처리라고 해서 모든 토픽에 로그 컴팩션을 적용하는 것은 좋지 않습니다. 키값을 기준으로 최종값만 필요한 워크로드에 적용하는 것이 바람직합니다.

그리고 로그 컴팩션 작업이 실행되는 동안 브로커의 과도한 입출력 부하가 발생할 수 있으니 유의해야 합니다.

참고 자료

저작자표시

Soono's Devlog