Belajar Database Administrator - Cost & Resource Optimization

#Pendahuluan

Di episode 22 kita mempertimbangkan cluster yang mahal; episode ini menghadapi kenyataan: tagihan cloud. Database biasanya komponen termahal dalam tagihan cloud — CPU, storage, IOPS, snapshot, dan transfer data bertambah diam-diam.

DBA 2026 tidak hanya menjawab "apakah sistem jalan?" tapi juga "apakah sistem jalan dengan biaya yang wajar?". Cost optimization bukan berarti mengorbankan performa — melainkan membayar tepat untuk apa yang benar-benar dipakai.

#Right-Sizing: Ukuran yang Sesuai Beban

Kesalahan termahal: over-provisioning "biar aman" lalu dibiarkan selama bertahun-tahun. Right-sizing = menyesuaikan ukuran instance dengan utilisasi nyata.

Cara membacanya:

1. Lihat metrik CPU, memory, dan IO dari monitoring (episode 7) selama 30 hari — bukan rata-rata, tapi p95.
2. Jika CPU di bawah 20% selama 95% waktu dengan puncak sesekali — instance terlalu besar.
3. Jika IOPS mendekati limit — naikkan storage/IOPS sebelum CPU (I/O bottleneck beda obat).
4. Uji pindah ke instance lebih kecil di staging, ukur p95, baru pindah produksi.

Pitfall: instance "hemat" yang tersedak saat peak season adalah keputusan yang salah. Right-sizing butuh headroom yang terukur, bukan angka mutlak.

#Storage Tiering: Panas, Hangat, Dingin

Data tidak diciptakan sama. Baris transaksi kemarin adalah "data panas" yang diakses setiap detik; data 3 tahun lalu hampir tidak pernah diakses.

Praktik umum: setelah beberapa bulan, pindahkan partisi lama (episode 21) dari tabel aktif ke tabel arsip di storage yang lebih murah, atau detach partisi dan simpan sebagai backup terkompresi. Di cloud, sesuaikan tipe storage: General Purpose untuk beban normal, io2/Provisioned IOPS hanya jika benar-benar dibutuhkan.

#Snapshot Lifecycle: Jangan Menimbun Backup

Snapshot yang menumpuk tanpa batas adalah kebocoran biaya yang paling sering dilupakan. Snapshot bersifat incremental (tambahan kecil setelah snapshot pertama), tapi snapshot pertama dan snapshot lama tetap membebani.

Buat kebijakan lifecycle: berapa lama simpan hourly, daily, weekly, monthly, dan yearly. Di AWS pakai DLM (Data Lifecycle Manager); di cloud lain buat skrip scheduler yang membersihkan snapshot sesuai aturan. Ingat kebutuhan DR (episode 15): simpan snapshot lintas-region secukupnya untuk memenuhi RPO/RTO — bukan semua snapshot di semua region.

#Kompresi dan Data Lama

Sebelum menambah storage, lihat data apa yang sebenarnya disimpan:

• Arsip log dan data audit (episode 16) sering memakan space terbesar. Pertahankan sesuai retention policy; hapus atau arsipkan sisanya.
• Kompresi: nilai panjang dan berulang sangat diuntungkan kompresi. PostgreSQL menangani nilai besar secara otomatis via TOAST; di warehouse, kompresi kolom adalah fitur utama.
• Hapus index mati (episode 21): index yang tak terpakai tetap memakan storage.

Audit storage secara rutin: tabel mana terbesar, mana yang tidak diakses 90 hari terakhir (lewat pg_stat_user_tables dan log query). Data yang tidak pernah dibaca adalah kandidat arsip.

#FinOps untuk Database

FinOps adalah praktik menyadarkan tim tentang biaya cloud secara kolaboratif, bukan sekadar "pangkas biaya". Untuk database, komponennya:

1. Tagging: beri tag setiap resource (environment, tim, aplikasi) sejak provisioning (episode 14) agar biaya bisa dialokasikan ke pemiliknya.
2. Budget dan alert: setel budget bulanan plus alert di level 50/80/100%. Anomali tagihan langsung terlihat.
3. Commitment discount: untuk beban stabil (bukan dev/uat), Reserved Instance atau Savings Plan menurunkan biaya signifikan. Jangan commit untuk beban yang fluktuatif.
4. Unit economics: biaya per fitur = total biaya DB ÷ jumlah user/transaksi. Ini membuat tim memahami apakah pertumbuhan aplikasi sepadan dengan biaya databasenya.
5. Matikan resource idle: instance dev yang menyala 24/7 tanpa dipakai adalah biaya murni. Fitur autopause (misal Neon) atau stop/start terjadwal menekan biaya signifikan.

#Biaya di On-Prem dan Self-Managed

Cloud bukan satu-satunya tempat biaya. Di on-prem, biaya database tersembunyi di tempat lain: kapasitas yang menganggur, storage array yang tidak terpakai, dan lisensi software. Prinsip yang sama berlaku:

• Ukur utilisasi nyata: server yang menyalakan 40 core dengan utilisasi 10% adalah resource terbuang — kandidat konsolidasi atau virtualisasi.
• Lisensi: engine komersial (Oracle, MSSQL) mematok harga per core/CPU — setiap upgrade hardware berdampak langsung pada biaya lisensi. PostgreSQL menghapus komponen ini.
• Power dan cooling: konsolidasi instance menekan biaya fisik — perlakukan seperti storage tiering.

Jangan lupa menghitung total cost of ownership (TCO): biaya cloud yang "mahal" kadang lebih murah daripada on-prem bila memperhitungkan SDM dan hardware yang harus dijaga. Keputusan "di mana menaruh database" seharusnya keputusan finansial, bukan sekadar preferensi.

#Praktik: Audit Tagihan Cloud Database

Checklist audit yang bisa langsung dipakai:

1. Listing semua instance DB per region: tipe, ukuran, utilisasi p95 30 hari.
2. Identifikasi instance di bawah 20% utilisasi → kandidat turun kelas.
3. Hitung jumlah snapshot per DB dan umurnya → terapkan lifecycle.
4. Cek storage yang terpakai vs yang di-provision → turunkan atau pindahkan ke arsip.
5. Pastikan semua resource punya tag biaya → perbaiki yang belum.
6. Cek apakah ada instance yang bisa di-stop di luar jam kerja.

Hasil audit jangan cuma laporan — ubah menjadi action items dengan pemilik dan deadline (budaya post-mortem episode 20 berlaku juga untuk biaya).

#Penutup

Inti yang harus dibawa pulang:

• Right-sizing dengan ukuran p95, bukan rata-rata — headroom yang terukur.
• Storage tiering: data panas-hangat-dingin; partisi lama bisa diarsipkan.
• Snapshot lifecycle dan kompresi/arsip mencegah kebocoran biaya diam-diam.
• FinOps: tagging, budget alert, commitment discount untuk beban stabil, unit economics, matikan resource idle.
• Audit berkala + action items = biaya cloud terkendali tanpa mengorbankan performa.

Di episode 24 selanjutnya kita masuk era AI: AI database & vector DB — pgvector dan Pinecone, integrasi dengan LLM/RAG, dan bagaimana AI membantu tuning query. Sampai jumpa di episode 24!