Lifecycle Management — Tiering & Deletion Automation

Tại Sao Quan Trọng Trong Production

Lifecycle management là cơ chế tự động hóa cost optimization trong GCS. Không có lifecycle rules → data tích lũy mãi mãi ở Standard class → bill tăng không kiểm soát. Nhưng lifecycle rules có nhiều edge case: evaluation order, interaction với versioning, minimum storage duration penalties, và asynchronous execution delay. Misconfigured lifecycle rules có thể xóa data quan trọng hoặc tạo unexpected retrieval charges.

---

Internal Model — Rule Evaluation Engine

Cấu Trúc Rule

Mỗi lifecycle rule gồm hai phần:

{
  "lifecycle": {
    "rule": [
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "NEARLINE"
        },
        "condition": {
          "age": 30,
          "matchesStorageClass": ["STANDARD"]
        }
      }
    ]
  }
}

Một rule = một action + một hoặc nhiều conditions. Object phải thỏa mãn tất cả conditions trong rule thì action mới được apply. Đây là AND logic — không có OR ở cấp condition.

Actions

1. SetStorageClass

Di chuyển object sang storage class khác. Chỉ cho phép downgrade (Standard → Nearline/Coldline/Archive, Nearline → Coldline/Archive, Coldline → Archive).

Điều quan trọng: SetStorageClass về mặt kỹ thuật là Class A operation (write) + rewrite nhưng không phát sinh retrieval fee và inter-region replication charge. GCS xử lý nó internally khác với user-initiated read + write.

SetStorageClass không = read + write
SetStorageClass = internal reclass operation (không tính retrieval fee)

2. Delete

Xóa objects matching conditions. Với soft delete enabled (default từ 2024), objects không bị hard-deleted ngay — chúng enter soft-delete state trong retention window (7–90 ngày) và vẫn tốn storage cost trong period đó.

Trong bucket có versioning:

• Delete rule trên live object → tạo delete marker (noncurrent version)
• Cần điều kiện isLive: false để xóa noncurrent versions
• Cần điều kiện numNewerVersions để giữ N versions gần nhất

3. AbortIncompleteMultipartUpload

Hủy và xóa incomplete multipart uploads — rất quan trọng vì incomplete uploads tiêu tốn storage mà không visible trong bucket listing thông thường. Chỉ hỗ trợ conditions: age, matchesPrefix, matchesSuffix.

{
  "action": { "type": "AbortIncompleteMultipartUpload" },
  "condition": { "age": 7 }
}

Đây là rule nên có trong mọi bucket production — incomplete uploads là nguồn gốc của billing surprises.

Conditions Và Semantics Của Từng Loại

age (integer, ngày)

Tính từ ngày object được tạo (timeCreated), không phải ngày last accessed. Với noncurrent versions trong versioned bucket, age tính từ khi version trở thành noncurrent (timeDeleted).

age: 30  →  apply cho objects tồn tại ≥ 30 ngày

createdBefore và noncurrentTimeBefore (date)

UTC date string. createdBefore: "2024-01-01" match objects tạo trước 2024. Hữu ích cho one-time cleanup.

customTimeBefore và daysSinceCustomTime

Object có thể có custom metadata field Custom-Time. Lifecycle có thể dùng field này làm trigger thay vì creation time. Cho phép application-controlled lifecycle timing.

isLive (boolean)

Trong versioned buckets:

• isLive: true → chỉ match live objects
• isLive: false → chỉ match noncurrent objects

numNewerVersions (integer)

Match noncurrent object khi có ít nhất N versions mới hơn. Dùng để giữ N versions gần nhất:

{
  "action": { "type": "Delete" },
  "condition": {
    "numNewerVersions": 3,
    "isLive": false
  }
}

Rule này xóa noncurrent versions khi đã có 3 versions mới hơn — effectively giữ 3 versions gần nhất.

matchesPrefix / matchesSuffix

Tối đa 1000 prefix/suffix conditions mỗi rule. Quan trọng: đây là prefix/suffix của object name, không phải wildcard glob.

matchesStorageClass

Giới hạn rule chỉ apply cho objects ở storage class cụ thể. Thường dùng để tránh re-apply rule:

"condition": {
  "age": 30,
  "matchesStorageClass": ["STANDARD"]
}

Nếu không có matchesStorageClass, rule SetStorageClass sang Nearline sẽ apply cho cả objects đã ở Nearline, tạo không cần thiết rewrite operations.

Rule Conflict Resolution

Khi nhiều rules match cùng một object, GCS dùng thứ tự ưu tiên:

1. Delete > SetStorageClass: Nếu một rule delete và rule khác tiering, delete wins
2. Lowest cost class wins: Nếu nhiều rules cùng SetStorageClass, class rẻ nhất được chọn

Rule A: SetStorageClass → Nearline (age: 30)
Rule B: SetStorageClass → Archive (age: 30)
Rule C: Delete (age: 30)

Kết quả nếu cả 3 match: Delete (Rule C) thực thi

Đây là behavior quan trọng: không có way để "protect" một object khỏi lifecycle delete ngoài locks và holds.

---

Constraints & Gotchas

Asynchronous Execution — Không Guarantee Timing Chính Xác

Lifecycle rules không execute real-time. GCS chạy lifecycle evaluation theo batches, thường một lần mỗi ngày, và có thể bị delay thêm:

Theo GCS documentation: "Changes to lifecycle rules can take up to 24 hours to take effect."

Production implication: Đừng design system phụ thuộc vào lifecycle execute đúng giờ. Nếu cần cleanup xác định, dùng explicit API calls hoặc Cloud Scheduler + Cloud Functions.

Minimum Storage Duration Và Lifecycle Anti-Pattern

Nếu lifecycle rule xóa/tier objects trước minimum storage duration của class hiện tại, penalty charge vẫn áp dụng:

Object ở Coldline (min 90 ngày)
Lifecycle rule Delete: age ≥ 45 ngày
→ Object bị xóa lúc 45 ngày
→ Charge: 45 ngày actual + 45 ngày remaining minimum
→ Total: 90 ngày charge

# Cost tương đương giữ 90 ngày nhưng đã xóa sớm!

Pattern đúng: Match lifecycle delete timing với minimum storage duration:

// Tier sang Coldline ở 60 ngày, xóa ở 150 ngày
// Coldline min = 90 ngày → 60 + 90 = 150 ngày xóa là break-even
{
  "rules": [
    {
      "action": { "type": "SetStorageClass", "storageClass": "COLDLINE" },
      "condition": { "age": 60, "matchesStorageClass": ["STANDARD"] }
    },
    {
      "action": { "type": "Delete" },
      "condition": { "age": 150 }
    }
  ]
}

Interaction Với Object Holds

GCS hỗ trợ hai loại holds ngăn deletion:

• Event-based hold: Manual hold, phải explicitly release
• Temporary hold: Automatic release sau retention period (set ở bucket level)

Lifecycle delete rules không thể xóa objects đang có hold. Action sẽ fail silently — object không bị xóa, không có error. Đây là ẩn dụ hay cho compliance use cases nhưng là gotcha nếu không aware.

Interaction Với Versioning

Trong versioned bucket, một lifecycle Delete rule không phải là hard delete:

isLive: true  + Delete → tạo delete marker (soft delete)
isLive: false + Delete → thực sự xóa noncurrent version

Để cleanup versioned bucket một cách sạch sẽ cần hai rules riêng biệt:

{
  "rules": [
    {
      "action": { "type": "Delete" },
      "condition": { "isLive": true, "age": 365 }
    },
    {
      "action": { "type": "Delete" },
      "condition": { "isLive": false, "age": 30 }
    }
  ]
}

Rule 1 xóa live objects sau 1 năm (tạo delete marker). Rule 2 xóa noncurrent versions sau 30 ngày. Không có rule 2 → noncurrent versions tích lũy mãi mãi, tốn storage.

---

Autoclass Vs. Manual Lifecycle — Khi Nào Dùng Gì

Autoclass:

• GCS tự theo dõi access pattern và tier objects
• Không cần biết access pattern trước
• Objects không được access xuống Nearline sau 30 ngày → Coldline sau 90 ngày → Archive sau 365 ngày
• Objects được access quay về Standard ngay lập tức
• Không tương thích với manual lifecycle SetStorageClass

Manual Lifecycle:

• Khi access pattern biết trước và predictable
• Khi cần control chính xác timing
• Khi cần integration với object versioning (numNewerVersions)
• Khi cần AbortIncompleteMultipartUpload

Một số workloads cần cả hai: Autoclass cho tiering data thông thường + manual lifecycle cho cleanup noncurrent versions và incomplete uploads.

// Bucket với Autoclass ON nhưng vẫn có cleanup rules:
{
  "rules": [
    {
      "action": { "type": "AbortIncompleteMultipartUpload" },
      "condition": { "age": 7 }
    },
    {
      "action": { "type": "Delete" },
      "condition": { "isLive": false, "numNewerVersions": 3 }
    }
  ]
}
// Autoclass quản lý tiering, lifecycle chỉ cleanup

---

References

• Object Lifecycle Management
• Autoclass
• Managing Retention
• Object Holds