Lifecycle & Data Tiering #
Tidak semua data punya nilai yang sama sepanjang waktu. Log aplikasi dari tiga tahun lalu, transaksi bulan lalu, dan data aktif hari ini — masing-masing punya frekuensi akses yang sangat berbeda. Menyimpan semuanya di storage tier yang sama dengan biaya yang sama adalah pemborosan. Lifecycle management dan data tiering adalah mekanisme untuk secara otomatis memindahkan data ke tier storage yang paling ekonomis sesuai usianya — tanpa perlu intervensi manual. Ini adalah salah satu cara paling efektif untuk memangkas biaya storage sambil tetap mempertahankan data yang dibutuhkan.
Konsep Data Tiering #
Data tiering adalah praktik membagi storage ke dalam beberapa “tier” berdasarkan frekuensi akses, dengan biaya yang berbeda di setiap tier.
Hierarki Data Tiering:
┌──────────────────────────────────────────────────────┐
│ HOT TIER (Standard) │
│ Data aktif yang sering diakses │
│ Latensi: milidetik │ Biaya per GB: $$$ │
│ Contoh: data hari ini, minggu ini │
└──────────────────────────────────────────────────────┘
│ (setelah 30 hari, tidak banyak diakses)
▼
┌──────────────────────────────────────────────────────┐
│ WARM TIER (Infrequent Access) │
│ Data yang masih relevant tapi jarang diakses │
│ Latensi: milidetik │ Biaya per GB: $$ │
│ Contoh: data 1-12 bulan lalu │
└──────────────────────────────────────────────────────┘
│ (setelah 1 tahun, hampir tidak diakses)
▼
┌──────────────────────────────────────────────────────┐
│ COLD TIER (Archive / Glacier) │
│ Data yang disimpan untuk compliance / audit │
│ Latensi: menit-jam │ Biaya per GB: $ │
│ Contoh: data > 1 tahun, backup jangka panjang │
└──────────────────────────────────────────────────────┘
│ (setelah 7 tahun, regulasi tidak wajibkan lagi)
▼
┌──────────────────────────────────────────────────────┐
│ EXPIRED / DELETE │
│ Data yang sudah melewati retention period │
└──────────────────────────────────────────────────────┘
Lifecycle Policy — Otomasi Perpindahan Data #
Lifecycle policy adalah aturan yang kamu definisikan untuk mengotomasi perpindahan objek antar tier berdasarkan usia atau kondisi tertentu.
Contoh Lifecycle Policy untuk Log Aplikasi:
Rule 1 — Transition ke Infrequent Access:
Kondisi: objek berusia > 30 hari
Aksi: pindah ke tier Infrequent Access
Estimasi penghematan: ~40% dari biaya hot storage
Rule 2 — Transition ke Archive:
Kondisi: objek berusia > 365 hari
Aksi: pindah ke tier Archive (Glacier)
Estimasi penghematan: ~80% dari biaya hot storage
Rule 3 — Delete:
Kondisi: objek berusia > 2555 hari (7 tahun)
Aksi: hapus objek
Alasan: sudah melewati masa retensi wajib regulasi
Implementasi:
→ Kamu definisikan policy sekali
→ Provider menjalankan otomatis setiap hari
→ Tidak ada kode yang perlu ditulis
→ Tidak ada cron job yang perlu dikelola
Strategi Tiering untuk Berbagai Jenis Data #
Setiap jenis data punya karakteristik akses yang berbeda, sehingga butuh strategi tiering yang berbeda.
Log dan Event Data #
Karakteristik akses log:
→ Sangat aktif diakses 0-7 hari pertama (debug, monitoring)
→ Kadang diakses 7-30 hari (investigasi insiden)
→ Jarang diakses 30-365 hari (audit, analisis historis)
→ Hampir tidak pernah diakses > 1 tahun (compliance saja)
Policy yang disarankan:
0-7 hari: Hot (Standard)
7-30 hari: Infrequent Access
30-365 hari: Archive
> 365 hari: Hapus (atau archive lebih lama jika regulasi wajibkan)
Potensi penghematan vs simpan semua di hot:
≈ 60-70% pengurangan biaya storage
Database Backup #
Karakteristik akses backup:
→ Backup harian — hampir tidak pernah diakses kecuali disaster
→ Jika diakses, biasanya diakses dalam 30 hari pertama
→ Backup lebih tua → makin kecil kemungkinan dibutuhkan
Policy yang disarankan:
0-7 hari: Hot (untuk restore cepat jika diperlukan)
7-30 hari: Infrequent Access
30-365 hari: Archive (restore butuh waktu, tapi jarang diperlukan)
> 365 hari: Deep Archive (biaya paling murah)
> 7 tahun: Hapus (sesuaikan dengan kebijakan retensi)
Catatan penting:
Jika disaster recovery membutuhkan restore dalam hitungan jam,
pertahankan 1-2 backup terbaru di hot tier
Sisanya bisa di archive
Media dan Konten #
Karakteristik akses media:
→ Video/gambar baru: sangat aktif diakses (viral content)
→ Konten lama: frekuensi akses menurun seiring waktu
→ Long-tail content: ada yang diakses, ada yang tidak sama sekali
Strategi yang lebih kompleks (berbasis akses, bukan hanya usia):
Access-based tiering (beberapa provider mendukung):
→ Provider memantau frekuensi akses setiap objek
→ Objek yang tidak diakses dalam N hari otomatis turun tier
→ Objek yang diakses kembali bisa naik tier
Atau: kombinasi usia + metadata
→ Konten yang ditandai "archived" di database → policy khusus
→ Konten yang aktif tetap di hot
Versioning dan Lifecycle #
Versioning menciptakan banyak versi objek — yang jika tidak dikelola bisa sangat mahal.
Problem: Versioning tanpa lifecycle policy
Objek "data.json" diupdate 100x per hari
Setelah sebulan: 3.000 versi tersimpan
Storage cost: 3.000x biaya satu objek!
Solusi: Lifecycle policy untuk versi lama
Rule untuk non-current versions:
→ Versi non-current berusia > 7 hari → pindah ke Infrequent Access
→ Versi non-current berusia > 30 hari → pindah ke Archive
→ Versi non-current berusia > 90 hari → hapus
Pertahankan versi terbaru di hot storage selalu
Versi lama otomatis di-tier atau dihapus
Lifecycle untuk incomplete multipart uploads:
→ File besar di-upload dalam beberapa bagian (multipart)
→ Jika upload gagal di tengah jalan, bagian yang sudah
terupload tetap tersimpan dan dikenakan biaya
→ Policy: hapus incomplete multipart uploads setelah 7 hari
Menghitung Penghematan #
Contoh kalkulasi penghematan nyata:
Skenario: 10 TB log yang terakumulasi setiap bulan
Tanpa tiering (semua di hot storage):
10 TB × 12 bulan = 120 TB setelah 1 tahun
Biaya: $0.023/GB × 120.000 GB = $2.760/bulan
Dengan tiering:
0-1 bulan: 10 TB × $0.023 = $230
1-12 bulan: 90 TB × $0.0125 (IA) = $1.125
> 12 bulan: data dihapus
Total: $1.355/bulan
Penghematan: ~51% hanya dari tiering sederhana
Tanpa effort tambahan setelah policy dikonfigurasi
Best Practice Lifecycle Management #
Checklist Lifecycle Policy:
Untuk setiap bucket/container storage:
□ Identifikasi jenis data yang disimpan
□ Tentukan pola akses yang diharapkan
□ Definisikan retention period (berapa lama data perlu disimpan)
□ Buat policy transisi antar tier
□ Tambahkan policy expiry untuk data yang tidak perlu disimpan selamanya
Yang sering terlupakan:
□ Policy untuk incomplete multipart uploads
□ Policy untuk versi objek yang sudah non-current
□ Policy untuk objek yang di-delete markers (jika versioning aktif)
Monitor dan review:
□ Cek storage cost per bucket setiap bulan
□ Verifikasi policy berjalan sesuai yang diharapkan
□ Adjust jika pola akses berubah
Ringkasan #
- Data tiering mengoptimalkan biaya berdasarkan frekuensi akses — hot untuk data aktif, warm untuk yang jarang diakses, cold untuk compliance dan archive.
- Lifecycle policy mengotomasi perpindahan data — definisikan sekali, berjalan terus secara otomatis tanpa intervensi.
- Potensi penghematan 50-80% dibanding simpan semua di hot storage — penghematan nyata yang signifikan untuk data volume besar.
- Versioning tanpa lifecycle policy bisa sangat mahal — setiap update membuat versi baru; definisikan policy untuk tier atau hapus versi lama.
- Ingat incomplete multipart uploads — sering terlupakan tapi terus dikenakan biaya jika tidak dibersihkan.
- Review dan adjust policy secara berkala — pola akses berubah seiring waktu; policy yang optimal hari ini mungkin tidak optimal setahun lagi.
← Sebelumnya: Durability vs Availability Berikutnya: Virtual Machine →