비용 최적화를 위한 Loki Retention 설정하기

이언철·2026년 2월 3일

Grafana Loki S3 SRE aws cost cost optimization devops finOps monitoring observability

Grafana Champions

목록 보기

9/10

https://community.grafana.com/t/setting-up-loki-retention-for-cost-optimization/158772

해당 Topic을 한글로 작성한 내용입니다.

로그는 눈에 띄지 않게 비용을 증가시킵니다.
특히 프로덕션이 아닌 개발 또는 테스트 클러스터에서도 제한 없이 로그를 수집하고 보관한다면,
1~2년이 지나면서 스토리지 비용이 눈에 띄게 증가하게 됩니다.

S3와 같은 객체 스토리지를 사용하는 경우, 저장되는 데이터 양에 비례해 비용이 선형적으로 증가합니다.
따라서 환경과 워크로드에 맞는 Retention 정책을 설계하여
전체 스토리지 비용과 쿼리 성능을 함께 관리하는 것이 중요합니다.

Loki에서 Retention이 동작하는 방식

Loki에서 로그 Retention은 Compactor 컴포넌트가 담당합니다.
기본 설정에서는 로그를 무기한 보관하며,
retention_enabled를 활성화해야만 Retention 정책이 적용됩니다.

객체 스토리지에 자체적인 Lifecycle 정책이 설정되어 있다면,
해당 기간은 Loki Retention 기간보다 길게 설정해야 충돌을 피할 수 있습니다.

Compactor의 Retention 처리 알고리즘

Compactor는 다음과 같은 방식으로 Retention을 적용합니다.

하루 단위 테이블(24시간 인덱스 주기 기준)을 대상으로 작업 수행
하나의 테이블에 존재하는 여러 인덱스 파일을 테넌트별 단일 인덱스 파일로 압축
테넌트 설정을 기준으로 삭제 대상 Chunk 식별
인덱스에서 해당 Chunk 참조 제거 후, 삭제 대상 Chunk를 마커 파일로 기록
수정된 인덱스 파일을 객체 스토리지에 업로드

Loki Helm values 설정 예시

아래 예시는 Compactor를 활성화하고,
기본 Retention 기간을 30일로 설정한 구성입니다.
이후 retention_period 또는 retention_stream을 통해
환경별 또는 로그 스트림별로 세분화할 수 있습니다.

loki:
  compactor:
    working_directory: /tmp/loki/retention
    compaction_interval: 10m
    retention_enabled: true
    retention_delete_delay: 10m
    retention_delete_worker_count: 100
    delete_request_store: s3

  limits_config:
    retention_period: 30d

주요 설정 항목 설명 (Grafana Labs 기준)

retention_enabled
반드시 true로 설정해야 Retention 정책이 동작합니다.
이 값이 false인 경우 Compactor는 테이블 압축만 수행하며, 로그 삭제는 발생하지 않습니다.
delete_request_store
삭제 요청 정보를 저장할 스토리지를 지정합니다.
Retention을 활성화할 경우 필수 설정이며, 일반적으로 S3와 같은 객체 스토리지를 사용합니다.
working_directory
삭제 대상으로 마킹된 Chunk 정보와 임시 테이블이 저장되는 로컬 디렉터리입니다.
Compactor Pod 재시작 시에도 안정적으로 동작할 수 있도록 충분한 디스크 공간을 확보해야 합니다.
compaction_interval
Compaction 및 Retention 작업이 수행되는 주기를 의미합니다.
Compactor가 작업을 따라가지 못한 경우, 가능한 시점에 즉시 실행됩니다.
retention_delete_delay
삭제 대상으로 표시된 Chunk가 실제 객체 스토리지에서 삭제되기까지의 대기 시간입니다.
이 지연 시간은 안정성을 확보하거나 롤백을 고려할 수 있는 완충 구간 역할을 합니다.
retention_delete_worker_count
Chunk 삭제 작업을 수행하는 최대 goroutine 워커 수를 지정합니다.
값이 너무 낮으면 삭제가 지연될 수 있고,
너무 높으면 객체 스토리지에 과도한 부하를 줄 수 있으므로 환경에 맞게 조정해야 합니다.

필수 확인 사항

Compactor 로그에서 다음과 같은 메시지가 출력되는지 확인합니다.
level=info ts=20xx-xx-xxT03:57:42.850907902Z caller=index_set.go:269
table-name=loki_index_20384
msg="removing source db files from storage"
count=6
retention_delete_delay 시간이 지난 후,
S3 버킷 내 객체 수와 전체 저장 용량이 실제로 감소하는지 확인합니다.