LangSmith Self-Hosted는 trace의 자동 TTL 및 데이터 보존 기능을 활성화할 수 있습니다. 이는 데이터 프라이버시 규정을 준수하거나, 더 효율적인 공간 사용과 trace의 자동 정리를 원할 때 유용합니다. Trace는 특정 작업이나 run rule 적용에 따라 데이터 보존 기간이 자동으로 연장됩니다.

​
Requirements

helm 또는 환경 변수 설정을 통해 보존 기간을 구성할 수 있습니다. 구성 가능한 몇 가지 옵션이 있습니다:
  • Enabled: 데이터 보존이 활성화 또는 비활성화되었는지 여부. 활성화된 경우 UI를 통해 trace에 적용할 기본 organization 및 project TTL tier를 설정할 수 있습니다 (자세한 내용은 데이터 보존 가이드 참조).
  • Retention Periods: shortlived 및 longlived trace에 대한 시스템 전체 보존 기간을 구성할 수 있습니다. 구성이 완료되면 각 project의 보존 수준을 관리하고 새 project에 대한 organization 전체 기본값을 설정할 수 있습니다.
config:
  ttl:
    enabled: true
    ttl_period_seconds:
      # -- 400 day longlived and 14 day shortlived
      longlived: "34560000"
      shortlived: "1209600"

​
ClickHouse TTL Cleanup Job

버전 0.11부터 ClickHouse의 내장 TTL 메커니즘으로 정리되지 않은 만료된 데이터를 삭제하는 데 도움이 되는 cron job이 주말에 실행됩니다.
이 job은 잠재적으로 오래 실행되는 mutation (ALTER TABLE DELETE)을 사용하며, 이는 ClickHouse의 성능에 영향을 줄 수 있는 비용이 많이 드는 작업입니다. 이러한 작업은 사용량이 적은 시간(야간 및 주말)에만 실행하는 것을 권장합니다. 1개의 동시 활성 mutation(기본값)으로 테스트하는 동안 CPU, 메모리 또는 지연 시간의 상당한 증가는 관찰되지 않았습니다.

​
Default Schedule

기본적으로 cleanup job은 다음 시간에 실행됩니다:
  • 토요일: 오후 8시 및 오후 10시 UTC
  • 일요일: 오전 12시, 오전 2시 및 오전 4시 UTC

​
Disabling the Job

cleanup job을 완전히 비활성화하려면: 
queue:
  deployment:
    extraEnv:
      - name: "ENABLE_CLICKHOUSE_TTL_CLEANUP_CRON"
        value: "false"

​
Configuring the Schedule

cron 표현식을 수정하여 cleanup job이 실행되는 시간을 사용자 정의할 수 있습니다: 
queue:
  deployment:
    extraEnv:
      # UTC: Sunday 12am/2am/4am
      - name: "CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_MORNING"
        value: "0 0,2,4 * * 0"
      # UTC: Saturday 8pm/10pm
      - name: "CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_EVENING"
        value: "0 20,22 * * 6"
단일 cron 일정으로 job을 실행하려면 CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_EVENING과 CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_MORNING을 동일한 값으로 설정하세요. Job 잠금은 중복 실행을 방지합니다.

​
Configuring Minimum Expired Rows Per Part

job은 테이블별로 진행되며, part를 스캔하고 최소 개수의 만료된 행을 포함하는 part에서 데이터를 삭제합니다. 이 임계값은 효율성과 철저함의 균형을 맞춥니다:
  • 너무 낮음: job이 최소한의 데이터를 지우기 위해 전체 part를 스캔합니다 (비효율적)
  • 너무 높음: job이 상당한 만료된 데이터가 있는 part를 놓칩니다
queue:
  deployment:
    extraEnv:
      - name: "CLICKHOUSE_TTL_CRON_MIN_EXPIRED_ROWS_PER_PART"
        value: "100000" # 100k expired rows

​
Checking Expired Rows

이 쿼리를 사용하여 테이블의 만료된 행을 분석하고 그에 따라 최소값을 조정하세요: 
-- Query for Runs table. For other tables, replace 'ttl_seconds' with 'trace_ttl_seconds'
SELECT
    _part,
    count() AS expired_rows
FROM runs
WHERE trace_first_received_at IS NOT NULL
AND ttl_seconds IS NOT NULL
AND toDateTime(assumeNotNull(trace_first_received_at) + toIntervalSecond(assumeNotNull(ttl_seconds))) < now()
GROUP BY _part
ORDER BY expired_rows DESC

​
Configuring Maximum Active Mutations

삭제 작업은 시간이 오래 걸릴 수 있습니다(100GB part의 경우 약 50분). 프로세스 속도를 높이기 위해 동시 mutation을 늘릴 수 있습니다: 
queue:
  deployment:
    extraEnv:
      - name: "CLICKHOUSE_TTL_CRON_MAX_ACTIVE_MUTATIONS"
        value: "1"
동시 DELETE 작업을 늘리면 시스템 성능에 심각한 영향을 줄 수 있습니다. 시스템을 주의 깊게 모니터링하고 잠재적으로 느린 insert 및 read 지연 시간을 허용할 수 있는 경우에만 이 값을 늘리세요.

​
Emergency: Stopping Running Mutations

지연 시간 급증이 발생하고 실행 중인 mutation을 종료해야 하는 경우:
  1. 활성 mutation 찾기: 
    SELECT * FROM system.mutations WHERE is_done = 0;
    command 열에 DELETE 문이 포함된 mutation_id를 찾으세요.
  2. mutation 종료: 
    KILL MUTATION WHERE mutation_id = '<mutation_id>';

​
Backups and Data Retention

이 job을 실행한 후 디스크 공간이 감소하지 않거나 계속 증가하는 경우, 백업이 파일 시스템 하드 링크를 생성하여 문제를 일으킬 수 있습니다. 이러한 링크는 ClickHouse가 데이터를 정리하는 것을 방지합니다. 확인하려면 ClickHouse pod 내부의 다음 디렉토리를 확인하세요:
  • /var/lib/clickhouse/backup
  • /var/lib/clickhouse/shadow
백업이 있는 경우 외부 파일 시스템 또는 blob storage(예: S3)로 복사한 다음 디렉토리를 지우세요. 몇 분 내에 디스크 공간이 해제되는 것을 확인할 수 있습니다.
Edit the source of this page on GitHub.
Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.
⌘I