유지 및 유지 정책

1) 원칙

1. 목적 및 최소화. 우리는 처리 목적에 필요한만큼 정확하게 저장합니다.
2. 코드로서의 정책. 유지는 PDF가 아닌 실행 가능한 정책입니다.
3. 깊이의 방어. TTL/ILM + 암호화 + 감사 + 법적 보류.
4. 가역성 및 증명. 작업 로그, 암호화 파쇄, 규정 준수 보고서 등 삭제가 가능합니다.
5. 비용 및 탄소 인식. 보존은 $/GB- 월과 저장/탈출의 탄소 발자국을 고려합니다.

2) 데이터 분류 및 "Retenschen 맵"

목표와 법적 근거로 세트를 클래스로 나눕니다

운영 (OLTP): 주문, 지불, 세션.
분석 (DWH/날짜): 이벤트, 로그 사실, 슬라이스.
개인 (PII/금융/건강): 과목의 특별한 조건과 권리가 필요합니다.
기술: 로그, 메트릭, 트레일, CI 아티팩트.
문서/미디어: WORM/archive/legasi.

각 클래스마다 소유자, 목적, 법적 프레임 워크, 날짜, 보호 수준, 현재 및 대상 스토리지가 설정됩니다.

3) ILM 데이터 라이프 사이클

1. Ingest (hot) → NVMe/SSD, 높은 요청률.

2. 따뜻한 → 읽기, 압축, 열 형식이 줄어 듭니다.

3. 콜드/아카이브 → 오브젝트/테이프, 긴 액세스.

4. 퍼지/삭제 → 삭제 보장 (복제/백업 포함).

yaml dataset: events_main owner: analytics purpose: "product analytics"
classification: "pseudonymized"
lifecycle:
- phase: hot; duration: 7d; storage: nvme; format: row
- phase: warm; duration: 90d; storage: ssd; format: parquet; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d privacy:
pii: false dp_delete_window: 30d # SLA on personal deletions if ligaments appear

4) 코드로서의 정책 (유용한 스케치)

4. 1 입학 정책 (필요한 태그/TTL)

yaml policy: require-retention-tags deny_if_missing: [owner, purpose, classification, retention]
default_retention:
logs:  "30d"
traces: "7d"
metrics:"90d"

4. CI/CD 2 게이트 (레고) -억제없이 배치 금지

rego package policy. retention deny[msg] {
some d input. datasets[d].retention == ""
msg:= sprintf("Retention missing for dataset %s", [d])
}

4. 3 S3/객체 (수명주기 단편)

yaml
Rules:
- ID: logs-ttl
Filter: { Prefix: "logs/" }
Transitions:
- { Days: 7, StorageClass: STANDARD_IA }
- { Days: 30, StorageClass: GLACIER }
Expiration: { Days: 180 }
NoncurrentVersionExpiration: { NoncurrentDays: 30 }

5) 실과 줄에 보존

• '보존. ms '/' 보존. 바이트 '- 창 보존.
• 압축 ('정리. policy = compact ') -마지막 키 값을 저장하십시오.
• 계층 형 스토리지-우리는 "꼬리" 를 콜드 슈팅 갤러리로 가져갑니다.
• DLQ는 별도의 보존 및 TTL입니다.

properties cleanup. policy=delete,compact retention. ms = 604800000 # 7d for tail removal
min. cleanable. dirty. ratio=0. 5 segment. ms=86400000

• 재생/재 계산 비즈니스 창에서 주요 주제 유지를 정의하십시오.
• 청구/감사 이벤트의 경우 별도의 긴 유지 또는 WORM.

6) 데이터베이스 및 보존

• 날짜/범위별로 분할하고 오래된 당사자를 분리 및 삭제하십시오.
• 날짜 필드-TTL 요청에 대한 색인.
• 이전 버전의 임시 테이블 (시스템 버전) + 퍼지 정책.

sql
-- Monthly instalments
CREATE TABLE audit_events (id bigserial, occurred_at timestamptz, payload jsonb) PARTITION BY RANGE (occurred_at);
-- Cleaning over 365 days
DELETE FROM audit_events WHERE occurred_at < now() - interval '365 days';
VACUUM (FULL, ANALYZE) audit_events;

• 키 레벨의 TTL (MongoDB TTL 인덱스, Redis 'EXPIRE', Cassandra TTL).
• 지표에 대한 다운 샘플링 (원시 7d → 집계 90d → 긴 365d).
• TSDB의 보존 정책 (결제/집계가있는 영향/ClickHouse Materialized Views).

7) 로그, 메트릭, 트레일

로그: 한계 필드, 마스크 PD, TTL 7-30d, 보관소 90-180d.
측정 항목: 원시 고주파-7-14d; 다운 샘플 (5m/1h) -90-365sh입니다.

트레일: 테일 샘플링 및 "흥미로운" (버그/테일) 유지

yaml observability:
logs:  { ttl: "30d", archive: "90d", pii_mask: true }
metrics: { raw: "14d", rollup_5m: "90d", rollup_1h: "365d" }
traces: { sample: "tail-10%", ttl: "7d", error_ttl: "30d" }

8) 제거: 유형 및 보증

논리적 (소프트 삭제): 레코드 표시; 복구에 편리하며 "삭제할 권리" 에 맞지 않습니다.
물리적 (하드 삭제) - 실제 데이터/버전/복제본 삭제.
암호화 (암호화 소거): 암호화 키 삭제/교체 후 데이터가 복원되지 않습니다.
캐스케이드: 파생의 엔드-투-엔드 삭제 (캐시, 인덱스, 분석).

request → locate subject data (index by subject_id) → revoke tokens & unsubscribe jobs → delete in OLTP → purge caches → enqueue erasure in DWH/lakes → crypto-shred keys (per-tenant/per-dataset) → emit audit proof (receipt)

9) 제거 권리, 법적 보류 및 eDiscovery

삭제/수정할 권리: 실행의 SLA (예: 소 30 일), 추적 된 동작, 영수증.
법적 보류: 법적 요청-지정된 세트/키에 대한 삭제 동결; TTL보다 우선 순위 정책.
eDiscovery: 데이터 카탈로그, 전체 텍스트/속성 아티팩트 검색, 일관된 형식으로 내보냅니다.

yaml legal_hold:
dataset: payments scope: ["txn_id:123", "user:42"]
from: "2025-10-31"
until: "2026-03-31"
reason: "regulatory investigation"

10) 백업 vs 아카이브 vs WORM

백업-손실/손상으로부터 회복하기 위해; 짧은 치료, 빠른 RTO.
아카이브-감사/분석을위한 장기 유지, 저렴하고 긴 액세스.
WORM-규정 준수를위한 불변의 미디어 (재무/보고); "한 번 쓰기, 많은 읽기" 정책.

• 백업을 "수세기 동안의 아카이브" 로 계산하지 마십시오.
• 회복 리허설 (DR 일), 시간 및 완전성 보고서.
• 스토리지와 별도로 보존, 암호화 및 키가있는 백업 디렉토리.

11) 개인 정보 보호 및 익명화

앨리어싱: 키 테이블을 통한 PII 바인딩 지연 (키별로 암호화 지우기 허용).
불명확성: 돌이킬 수없는 기술 (k-econmary, noise, 일반화); 문서 방법, 재 식별 위험 및 만료 날짜.

12) 준수 모니터링 및보고

제어 패널: 유효한 보존, ILM 단계별 볼륨, 삭제 오류가있는 데이터 세트 비율.
경고: 핫 대시에서 대상 볼륨을 초과하면 "중단 된" 삭제가 법적 보류를 만료합니다.
보고서: 월별 삭제 감사 (요청 횟수, 평균 기간, 실패), 암호화 파쇄 인쇄.

13) 프로세스로의 통합: 게이트 및 리뷰

디자인 게이트: 새로운 데이터 세트는 '소유자/목적/유지' 없이 검토를받지 않습니다.
릴리스 게이트: 소유자/정당화없이 유지를 증가시키는 마이그레이션이 차단됩니다.
비용 게이트: 뜨거운/따뜻한 양이 예산을 초과합니다. ILM 강화를위한 트리거.
보안 게이트: 변장없이 로그/트레일에 PD 포함 금지 및 TTL.

14) 반 패턴

"우리는 모든 것을 영원히 유지합니다. 갑자기 유용 할 것입니다".
정책으로 렌더링되지 않은 응용 프로그램의 하드 코딩 된 TTL.
마스킹/TTL/삭제없이 로그 및 추적의 PD.
불완전한 삭제 (캐시/DWH/백업에 남음).
법적 보유 부족-조사 중 데이터 삭제.
모든 것에 대한 하나의 일반적인 암호화 키-" 암호화 지우기 "를 가리키는 것은 불가능합니다.
관찰 가능성 없음: "우리는 제거했다고 생각하지만" 증거는 없습니다.

15) 건축가 점검표

1. 각 데이터 세트에는 소유자, 목적, 분류, 보존, 스토리지 등급이 있습니까?
2. ILM/TTL 정책이 코드로 선언되어 자동으로 적용됩니까?

3. PD는 로그/트랙에 가려져 있습니다. "흰색" 세트 외부에서 금지 되었습니

4. 개인 삭제 프로세스 (SLA, 감사, 영수증) 가 있습니까?
5. 암호화 가능 (테넌트/데이터 세트 키 당, KMS/회전)?
6. 백업: 일정, 암호화, 복구 테스트, 개별 키?

7. Legal Hold/eDiscovery: 지원되고 TTL보다 우선하며 활동 로그가 유지 관리됩니까

8. 카프카/대기열: 지정된 보존/압축/계층, DLQ에는 별도의 정책이 있습니까?
9. Retenschen 준수에 대한 메트릭 및 경고 및 촬영 갤러리의 볼륨이 구성됩니까?
10. SDLC의 리뷰와 게이트가 Retenschen이없는 아티팩트를 차단하고 있습니까?

16) 미니 레시피

16. 1 ClickHouse: 180 일 동안 '꼬리를 자르십시오'

sql
ALTER TABLE events DELETE WHERE event_date < today() - 180;
OPTIMIZE TABLE events FINAL;

16. 2 Redis: 게으른 퍼지

bash
SET session:123 value EX 3600
CONFIG SET maxmemory-policy allkeys-lru

16. 트레일을위한 3 개의 꼬리 샘플링

yaml tail_sampling:
policies:
- name: keep-errors-and-slow latency_threshold_ms: 500 status_codes: ["5xx"]
rate_limit_per_min: 5000 default_ttl: "7d"

16. 4 암호화 (아이디어)

keys:
dataset: users_pii key_id: kms://pii/users/tenant-42 erase(user_id=42):
rotate_or_destroy (key_id) # inability to restore former purge_indexes blocks ("user _ id = 42")
audit("crypto-erasure", user_id)

결론

보존 정책은 데이터 플랫폼의 "골격" 입니다. 서로 다른 클래스의 데이터가 얼마나 오래 사는지, 각 순간에 어디에 있는지, 시간이 지남에 따라 더 저렴 해지는 방법, 그리고 법적, 투명성 및 검증 가능한 흔적없이 사라질 때. 코드와 같은 정책을 유지하고 ILM을 보안 및 비용으로 연결하고 관찰 가능성과 게이트를 활성화하며 효과적이고 준수하며 성장할 수있는 시스템을 얻습니다.