본문으로 건너뛰기

데이터 보존 기간 (TTL) 설정

수집한 데이터를 얼마나 오래 두는지 정하는 설정입니다. 디스크 용량을 정하는 값이기도 합니다 — 데이터 저장 용량 산정 과 함께 보세요.

정본은 프로퍼티 파일 하나입니다​

보존 기간은 plantpulse-storage.properties 의 storage.*.ttl 값이 정합니다. 단위는 «일» 입니다(초가 아닙니다).

환경변수로는 바꿀 수 없습니다

PP_* 환경변수에 보존 기간을 정하는 값은 없습니다. 같은 파일에서 접속 정보와 비밀번호만 환경변수로 뚫려 있고, TTL 값은 전부 파일에 직접 적혀 있습니다.

기본값​

2026-09 출하 기준입니다. 컨테이너 안의 파일에서 직접 확인한 값입니다.

프로퍼티기본값(일)걸리는 데이터
storage.tag.point.ttl3650 (10년)태그 원시 수집값
storage.tag.point.map.ttl1태그 맵
storage.tag.point.sampling.ttl93샘플링 테이블 (10초~1시간)
storage.tag.point.snapshot.ttl93스냅샷
storage.tag.point.aggregation.ttl93집계 테이블 (1분~1시간)
storage.tag.point.archive.ttl365아카이브 — 오브젝트 스토리지로 넘어가는 원본
storage.tag.blob.ttl93태그 blob
storage.blob.object.ttl31blob 오브젝트
storage.asset.data.ttl10설비 데이터
storage.asset.data.sampling.ttl31설비 데이터 샘플링
storage.asset.alarm.timeline.ttl30알람 타임라인
storage.asset.alarm.timeline.rollup.ttl90알람 타임라인 롤업
storage.asset.standard.ttl0 = 무한설비 표준 데이터
문서에 오래 남아 있던 62일은 사실이 아닙니다

예전 자료에 「기본 TTL 5356800초 = 62일」로 적힌 것이 있습니다. 지금은 3650일입니다. 62일이라는 값은 SSOT 가 아니라고 스스로 밝힌 옛 스키마 저장소에서 흘러나온 것입니다.

카운터와 «현재 상태» 계열 테이블은 만료가 없습니다(default_time_to_live = 0). 시간축이 없어 만료시킬 대상이 아니기 때문입니다.

어떻게 적용되나​

  1. 서버가 부팅할 때 프로퍼티를 한 번 읽습니다.
  2. 값이 «명시된» 테이블에 대해서만 ALTER TABLE … WITH default_time_to_live = <일 × 86400> 문을 만듭니다.
  3. 현재 스키마를 읽어 다른 것만 실행합니다.

그래서 운영자가 cqlsh 로 ALTER 를 직접 칠 필요가 없습니다. 반대로, 프로퍼티에서 키를 지우면 그 테이블은 건너뜁니다 — 지운다고 무한 보존이 되지는 않습니다.

이미 저장된 데이터는 바뀌지 않습니다

Aster TSDB 의 default_time_to_live 는 쓸 때 각 값에 박힙니다. 그래서 설정을 바꿔도 그 뒤에 들어온 데이터부터 적용됩니다. 어제까지 쌓인 데이터의 만료 시점은 그대로입니다.

이것이 「늘리는 것은 안전하고 줄이는 것은 위험한」 이유입니다.

바꾸는 법​

🔴 컨테이너 설치본에서는 지금 이 파일을 호스트에서 고칠 수 없습니다. plantpulse-storage.properties 는 이미지 안(…/webapps/ROOT/WEB-INF/classes/)에만 있고, 외부 설정 디렉터리(…/plantpulse-server/config/)는 존재하지만 호스트로 바인드 마운트되어 있지 않습니다(2026-09-08 실측 — 마운트는 로그·오프로드·보안 볼륨 셋뿐입니다).

컨테이너 안에서 고치면 컨테이너를 교체하는 순간 사라집니다. 재설치·업그레이드가 곧 원복입니다.

보존 기간을 바꿔야 한다면 제품팀과 함께 진행하세요. 값 자체는 아래처럼 바꿉니다.

# 외부 설정 디렉터리의 파일을 고친다 (WAR 안의 사본이 아니라 이쪽)
cp plantpulse-storage.properties plantpulse-storage.properties.$(date +%F)
sed -i 's/^storage.tag.point.ttl=.*/storage.tag.point.ttl=1825/' plantpulse-storage.properties

# 서버를 재시작한다 — 프로퍼티는 부팅 때 한 번만 읽는다

재시작 없이는 반영되지 않습니다. 무중단 반영 경로도, 관리 콘솔에서 TTL 을 바꾸는 화면도 없습니다.

반영됐는지 확인하기​

부팅 로그에 적용값이 표로 찍힙니다. DATA STORAGE TTL 배너를 찾으세요 — 프로퍼티 이름과 보존 기간, 그리고 그 값이 어디서 왔는지(파일인지 코드 기본값인지)가 함께 나옵니다.

스키마에 실제로 걸린 값은 이렇게 봅니다.

SELECT table_name, default_time_to_live, gc_grace_seconds
FROM system_schema.tables
WHERE keyspace_name = 'pp';

초 단위로 나오므로 86400 으로 나누면 일수입니다. 0 은 무한 보존입니다.

함정​

줄이면 데이터가 사라집니다. 새로 들어오는 데이터의 만료가 그만큼 앞당겨집니다. 줄이기 전에 백업 을 확보하세요.

줄여도 «즉시» 지워지지는 않습니다. 만료된 값은 먼저 tombstone 이 되고, gc_grace_seconds 가 지난 뒤 compaction 이 실제로 디스크를 회수합니다. 그래서 설정을 줄인 날 디스크가 바로 줄지 않습니다.

늘리면 디스크가 선형으로 늡니다. 62일에서 3650일은 보존량이 약 59배입니다. 보존 기간을 늘릴 때는 용량 산정 을 다시 하세요.

TTL = 0(무한)은 용량만의 문제가 아닙니다. 만료 기준이 없으면 compaction 이 오래된 구간을 정리할 수단을 잃습니다. 조각이 쌓이고 읽기가 느려집니다.

TTL 을 너무 짧게 내리면 서버가 ALTER 를 거부할 수 있습니다. compaction 창 설정과 보존 기간 사이에 지켜야 할 관계가 있어서입니다. 이때 그 테이블은 만들 때 받은 설정을 조용히 유지하므로, 로그의 경고를 확인해야 합니다.

CEP 데드레터​

CEP 가 처리하지 못한 이벤트는 Valkey 스트림 PP:CEP-DEAD-LETTER:{샤드} 에 남습니다. 이것은 조사용 임시 보관이고, TTL 설정이 아니라 plantpulse-cep.properties 로 정합니다.

프로퍼티기본값뜻
cep.stream.max_deliveries3세 번 배달돼도 처리되지 못한 이벤트만 데드레터로 갑니다
cep.stream.dead_letter.retention_ms86400000 (24시간)쓸 때마다 이보다 오래된 것을 자릅니다
cep.stream.dead_letter.max_bytes268435456 (256 MiB)전체 합계. 샤드 수로 나눈 몫을 넘으면 오래된 것부터 자릅니다

조사가 필요하면 24시간 안에 봐야 합니다.

오브젝트 스토리지 쪽​

TTL 을 넘긴 데이터가 사라지기만 하는 것은 아닙니다. 아카이브 테이블 (storage.tag.point.archive.ttl, 기본 365일)의 데이터는 오브젝트 스토리지의 Iceberg 테이블로 옮겨져 장기 보관됩니다.

항목값
Iceberg 스냅샷 보존기본 3일 (SNAPSHOT_RETENTION_DAYS)
웨어하우스 감사 테이블31일
용량 사용량 이력1095일 (3년)
스냅샷 보존은 데이터 보존이 아닙니다

Iceberg 스냅샷 만료는 데이터를 지우는 것이 아니라 과거 시점으로 되돌아가는 능력 (time travel · rollback)을 끊는 것입니다. 기본 3일이 지나면 그 이전 시점으로는 되돌릴 수 없습니다.

Iceberg 테이블 자체에는 자동 만료 장치가 없습니다. 지우려면 명시적으로 지워야 합니다.

관련 문서​