保持ポリシーと保持ポリシー

1）原則

1.目的と最小化。私たちは正確にそれを保管し、処理のために必要なだけを保管します。
2.コードとしてのポリシー。保持は実行可能なポリシーであり、PDFではありません。
3.ディフェンス・イン・デプス。TTL/ILM+暗号化+監査+Legal Hold。
4.可逆性及び証拠。削除は検証可能です：アクションログ、暗号シュレッディング、コンプライアンスレポート。
5.Cost&Carbon対応。保持には、$/GB-monthとストレージ/排出のカーボンフットプリントが考慮されます。

2）データ分類と「Retenschen map」

• 運用（OLTP）：注文、支払い、セッション。
• 分析（DWH/日付）：イベント、ログファクト、スライス。
• 個人（PII/財務/健康）：被験者の特別な条件と権利を必要とします。
• テクニカル：ログ、メトリック、トレイル、CIアーティファクト。
• ドキュメント/メディア：WORM/archive/legasi。

各クラスには、所有者、目的、法的枠組み、日付、保護レベル、現在およびターゲットストレージを設定します。

3） ILMデータライフサイクル

1.Ingest （hot）→NVMe/SSD、高いリクエストレート。

2.暖かい→読み取り、圧縮、列形式が少ない。

3.Cold/Archive→object/tape、長いアクセス。

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.2 CI/CD （Rego）のゲート-リテンションなしでの展開の禁止

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

4.3 S3/object（ライフサイクルフラグメント）

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）スレッドとキューの保持

• 'retention。ms'/'保持。bytes'-ウィンドウの保持。
• 圧縮（'クリーンアップ。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）。
• メトリックのダウンサンプリング（raw 7d→aggregates 90d→long 365d）
• TSDBの保持ポリシー（dedup/aggregationを使用した影響/ClickHouse Materialized Views）。

7）ログ、メトリック、トレイル

ログ：リミットフィールド、マスクPD、 TTL 7-30d、アーカイブ90-180d。
メトリクス：未加工高頻度-7-14d；ダウンサンプル（5m/1h）-90-365°。
トレイル：テールサンプリングと「面白い」（バグ/尾）を長く保ちます。

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）取り外し： タイプおよび保証

論理（soft-delete）：レコードのマーキング；回復のために便利、合わない「削除する権利」。
物理的（hard-delete）-データ/バージョン/レプリカの実際の削除。
暗号化（暗号消去）：暗号化キーを削除/置換します。その後、データは復元されません。
カスケード：デリベーション（キャッシュ、インデックス、分析）のエンドツーエンドの削除。

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

バックアップ-損失/損傷から回復する。短いretension、速いRTO。
アーカイブ-監査/分析のための長期保存、安価で長いアクセス。
WORM-コンプライアンス（財務/報告）のための不変メディア。「write-once、 read-many」ポリシー。

• バックアップを「何世紀にもわたってアーカイブ」としてカウントしないでください。
• 回復リハーサル（DR日）、時間と完全性レポート。
• 保存、暗号化、およびストレージとは別にキーを持つバックアップのディレクトリ。

11）プライバシーと匿名化

エイリアシング：キーテーブルを介したPII遅延バインド（キーによる暗号消去が可能）。
匿名化：不可逆的な技術（k-anonymity、 noise、 generalization）；文書の方法、再同定と有効期限のリスク。

12）コンプライアンスの監視と報告

コントロールパネル：有効な保持を持つデータセットの割合、ILMフェーズによるボリューム、削除エラー。
アラート：ホットダッシュでターゲットボリュームを超えると、Legal Holdの期限切れになる削除が「ハング」されます。
レポート：毎月の削除監査（リクエスト数、平均期間、失敗数）、暗号切断印刷。

13）プロセスへの統合： ゲートとレビュー

Design-gate：新しいデータセットは'owner/purpose/retention'なしでレビューを取得しません。
Release-gate：所有者/正当化なしで保持を増加させる移行がブロックされます。
コストゲート：ホット/ウォームのボリュームが予算を超えます-ILM締め付けのトリガー。
セキュリティゲート：偽装およびTTLなしでログ/トレイルにPDを含めることを禁止します。

14）アンチパターン

「私たちはすべてを永遠に保ちます-それは突然便利になります。」

ポリシーでレンダリングされていないアプリケーションのハードコードされたTTL。
マスキング/TTL/削除せずにログとトレースのPD。
不完全な削除（キャッシュ/DWH/バックアップに残っています）。
法的保持の欠如-調査中のデータ消去。
すべてのための1つの一般的な暗号化キー-「暗号消去」を指すことは不可能です。
ゼロの観測可能性：「私たちは削除したと信じています」、しかし、証拠はありません。

15）建築家のチェックリスト

1.各データセットには、所有者、目的、分類、保持、ストレージ階層がありますか？
2.ILM/TTLポリシーはコードとして宣言され、自動的に適用されますか？
3.PDはログ/トラックでマスクされます。「白い」セットの外で禁止？
4.個人の削除プロセス（SLA、監査、領収書）はありますか？
5.暗号消去可能（テナントごと/データセットキーごと、KMS/回転）？
6.バックアップ：スケジュール、暗号化、リカバリテスト、個々のキー？
7.Legal Hold/eDiscovery：サポート、TTLを優先、アクティビティログを維持？
8.Kafka/queues：指定された保持/圧縮/階層化、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： TTLのゆったりパージ

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を接続し、可視性とゲートを可能にします。