Optimasi Biaya

Tagihan platform data bulan November naik 38% dibanding bulan sebelumnya, dan pertanyaan manajemen sederhana: uangnya ke mana? Jawaban “mungkin karena data bertambah” tidak diterima — jawaban yang diterima berbentuk angka: compute menyerap 61% tagihan, storage 31%, egress 8%, dan biaya per TB yang diproses naik dari bulan lalu. Optimasi biaya operasional memperlakukan tagihan sebagai data: dipecah per komponen, dihitung unit economics-nya, lalu dicari penghematan terbesar yang bisa dieksekusi tanpa menurunkan layanan. Chapter ini menjalankan proses tersebut dari awal sampai daftar eksekusi.

Membedah Tagihan dan Unit Economics #

Metodenya meniru siklus FinOps: informasi dulu, baru optimasi, baru operasional. Langkah informasi memecah tagihan sampai ke item dan menghitung unit economics; langkah optimasi mengurutkan kandidat berdasarkan penghematan yang terhitung; langkah operasional menjadwalkan eksekusi dengan syarat keandalan. Skrip berikut memodelkan tagihan November platform data TokoKita — mencakup zona raw dengan retensi tiga tahun, curated, dan salinan replika — dalam struktur baris yang sama seperti berkas tagihan penyedia cloud: grup, item, unit, volume, tarif. Dari rincian tersebut dihitung total per grup, unit economics, dan kandidat penghematan:

python
"""Pembedah tagihan bulanan platform data TokoKita: rincian compute, storage
per tier, dan egress; unit economics; lalu pencari 3 optimasi terbesar dengan
penghematan yang dihitung dari angka tagihan itu sendiri."""

TAGIHAN = [
    # (grup, item, unit, volume, tarif $/unit)
    ("compute", "worker ETL batch (on-demand, 4 unit)", "jam", 4 * 720, 0.12),
    ("compute", "warehouse query (8 vCPU)", "jam", 62, 4.80),
    ("storage", "hot tier (standard)", "GB-bulan", 12000, 0.023),
    ("storage", "warm tier (infrequent)", "GB-bulan", 1500, 0.0125),
    ("storage", "cold tier (archive)", "GB-bulan", 9000, 0.004),
    ("egress", "pull lintas region untuk processing", "GB", 500, 0.09),
    ("egress", "tarik API dashboard (JSON)", "GB", 400, 0.09),
]

JENDELA_BATCH_JAM = 240        # jam produktif batch per bulan (8 jam x 30 hari)
HARGA_SPOT = 0.036             # $/jam, diskon 70% dari on-demand
GB_TUAH_90HARI = 9000         # GB di hot tier yang berumur > 90 hari
TB_DIPROSES = 21.4             # TB data diproses batch + query bulan ini
REFRESH_DASHBOARD = 240        # jumlah refresh dashboard bulan ini


def biaya(item):
    return item[3] * item[4]


total = sum(biaya(i) for i in TAGIHAN)
print("=== Rincian tagihan November 2026 ===")
print("| Grup | Item | Volume | Tarif | Biaya |")
print("|---|---|---|---|---|")
for grup, item, unit, vol, tarif in TAGIHAN:
    print(f"| {grup} | {item} | {vol:,.0f} {unit} | ${tarif:g} |"
          f" ${vol * tarif:,.2f} |")
print(f"| total | | | | ${total:,.2f} |")

for grup in ("compute", "storage", "egress"):
    bagian = sum(biaya(i) for i in TAGIHAN if i[0] == grup)
    print(f"  porsi {grup}: ${bagian:,.2f} ({bagian / total * 100:.1f}%)")

compute_batch = biaya(TAGIHAN[0])
compute_semua = sum(biaya(i) for i in TAGIHAN if i[0] == "compute")
print(f"\nUnit economics:")
print(f"  ${compute_semua:,.2f} / {TB_DIPROSES} TB ="
      f" ${compute_semua / TB_DIPROSES:,.2f} per TB diproses")
print(f"  ${biaya(TAGIHAN[1]):,.2f} / {REFRESH_DASHBOARD} refresh ="
      f" ${biaya(TAGIHAN[1]) / REFRESH_DASHBOARD:,.2f} per refresh dashboard")

# Kandidat optimasi, dihitung terpisah terhadap tagihan saat ini
kandidat = [
    ("spot untuk worker batch (diskon 70%)",
     compute_batch * (1 - HARGA_SPOT / 0.12),
     "worker interruptible + checkpoint"),
    ("jendela batch terjadwal (worker mati di luar jam produktif)",
     (720 - JENDELA_BATCH_JAM) * 4 * 0.12,
     "job batch hanya di jendela 8 jam"),
    (f"tiering {GB_TUAH_90HARI:,} GB berumur > 90 hari dari hot ke cold",
     GB_TUAH_90HARI * (0.023 - 0.004),
     "kueri analitik jarang menyentuh data tua"),
    ("egress: proses same-region + format Parquet untuk API",
     500 * 0.09 + 400 * 0.09 * 0.45,
     "pindahkan processing ke region data"),
]
kandidat.sort(key=lambda k: k[1], reverse=True)

print("\n=== Kandidat optimasi (dihitung terpisah) ===")
print("| # | Optimasi | Penghematan | % tagihan | Syarat |")
print("|---|---|---|---|---|")
for n, (nama, hemat, syarat) in enumerate(kandidat, 1):
    print(f"| {n} | {nama} | ${hemat:,.2f} | {hemat / total * 100:.1f}% |"
          f" {syarat} |")

# Skenario gabungan: spot hanya di jendela produktif + tiering + egress
hemat_tiering = next(v for n, v, s in kandidat if "tiering" in n)
hemat_egress = next(v for n, v, s in kandidat if "egress" in n)
gabungan = (compute_batch - JENDELA_BATCH_JAM * 4 * HARGA_SPOT
            + hemat_tiering + hemat_egress)
print(f"\nSkenario gabungan: spot di {JENDELA_BATCH_JAM} jam produktif saja")
print(f"  + tiering + egress = ${gabungan:,.2f} "
      f"({gabungan / total * 100:.1f}% dari tagihan)")

Output yang Dihasilkan:

text
=== Rincian tagihan November 2026 ===
| Grup | Item | Volume | Tarif | Biaya |
|---|---|---|---|---|
| compute | worker ETL batch (on-demand, 4 unit) | 2,880 jam | $0.12 | $345.60 |
| compute | warehouse query (8 vCPU) | 62 jam | $4.8 | $297.60 |
| storage | hot tier (standard) | 12,000 GB-bulan | $0.023 | $276.00 |
| storage | warm tier (infrequent) | 1,500 GB-bulan | $0.0125 | $18.75 |
| storage | cold tier (archive) | 9,000 GB-bulan | $0.004 | $36.00 |
| egress | pull lintas region untuk processing | 500 GB | $0.09 | $45.00 |
| egress | tarik API dashboard (JSON) | 400 GB | $0.09 | $36.00 |
| total | | | | $1,054.95 |
  porsi compute: $643.20 (61.0%)
  porsi storage: $330.75 (31.4%)
  porsi egress: $81.00 (7.7%)

Unit economics:
  $643.20 / 21.4 TB = $30.06 per TB diproses
  $297.60 / 240 refresh = $1.24 per refresh dashboard

=== Kandidat optimasi (dihitung terpisah) ===
| # | Optimasi | Penghematan | % tagihan | Syarat |
|---|---|---|---|---|
| 1 | spot untuk worker batch (diskon 70%) | $241.92 | 22.9% | worker interruptible + checkpoint |
| 2 | jendela batch terjadwal (worker mati di luar jam produktif) | $230.40 | 21.8% | job batch hanya di jendela 8 jam |
| 3 | tiering 9,000 GB berumur > 90 hari dari hot ke cold | $171.00 | 16.2% | kueri analitik jarang menyentuh data tua |
| 4 | egress: proses same-region + format Parquet untuk API | $61.20 | 5.8% | pindahkan processing ke region data |

Skenario gabungan: spot di 240 jam produktif saja
  + tiering + egress = $543.24 (51.5% dari tagihan)

Mari kita telaah baris-baris kode di atas:

Baris 6-14 (TAGIHAN): tagihan disimpan sebagai baris data — grup, item, unit, volume, tarif — sehingga setiap perhitungan berikutnya bisa dilacak ke sumbernya, persis pola tabel run ledger pada chapter-chapter sebelumnya.
Baris 30-32 (porsi per grup): pembagian per grup menunjukkan compute menyerap 61% — sinyal kuat ke mana usaha optimasi pertama diarahkan.
Baris 35-39 (unit economics): biaya dibagi hasil kerja nyata (TB diproses, refresh dashboard); angka inilah yang dibandingkan antar bulan, karena total saja bisa menyesatkan saat volume kerja memang naik.
Baris 42-57 (kandidat): setiap penghematan dihitung dari angka tagihan dengan asumsi eksplisit — diskon spot 70% sesuai simulasi Chapter Autoscaling, jendela produktif 240 jam, umur data dari kebijakan retensi.
Baris 64-69 (skenario gabungan): kandidat spot dan jendela batch tumpang tindih — keduanya menyasar baris worker yang sama — sehingga skenario gabungan menghitung ulang secara jujur: spot hanya pada jam produktif.

Dua angka unit economics di atas menjadi patokan bulan-bulan berikutnya. Biaya $30,06 per TB diproses naik-turun mengikuti efisiensi kode pipeline, sedangkan $1,24 per refresh dashboard mengikuti pola pemakaian warehouse — keduanya lebih informatif daripada total tagihan karena tidak berubah hanya karena volume bisnis naik.

Membaca Kandidat dan Batas Optimasi #

Tiga kandidat teratas menyasar tiga kebiasaan berbeda. Spot mengubah cara membeli compute: worker batch yang interruptible dan ber-checkpoint tidak perlu memakai harga penuh. Jendela batch mengubah kebiasaan operasional: worker yang menyala 24 jam untuk pekerjaan 8 jam adalah tabungan yang bocor. Tiering mengubah kebijakan data: berkas berumur di atas 90 hari pindah ke tier murah seperti kelas penyimpanan yang dijelaskan di Amazon S3 Storage Classes — pemilihan format berkas, kompresi, dan deduplikasi di level storage sendiri dibahas tuntas pada Chapter Mengoptimalkan Biaya Storage, sehingga chapter ini mempertahankan sudut operasional infrastruktur.

Kandidat keempat, egress, menempati posisi terbawah dari sisi nominal tetapi tetap dieksekusi: memproses data di region penyimpanannya menghapus pola tarik-menyimpan lintas region yang tumbuh mengikuti volume, dan format Parquet memangkas ukuran respons API hampir separuh. Perhatikan pula bahwa skenario gabungan lebih kecil daripada penjumlahan keempat kandidat — spot dan jendela batch menyasar baris worker yang sama, sehingga penghematannya tidak boleh dijumlahkan mentah-mentah.

Checklist FinOps #

Disiplin bulanan menjaga penghematan agar tidak menguap setelah kuartal pertama. Praktik minimal yang dijalankan tim TokoKita mengikuti prinsip AWS Well-Architected Cost Optimization Pillar :

Setiap resource diberi label tim dan environment sehingga tagihan bisa diperingkat per pemilik.
Tagihan bulan berjalan dibandingkan bulan lalu per grup; lonjakan di atas 10% wajib dijelaskan.
Unit economics dipantau trennya: biaya per TB yang naik menandakan inefisiensi baru yang menyusup.
Kebijakan tiering dieksekusi otomatis oleh lifecycle rule, bukan dipindahkan manual saat ingat.
Setiap kandidat optimasi diberi syarat keandalan eksplisit sebelum dieksekusi.

Angka-angka pada checklist di atas bermuara ke satu pertanyaan: seberapa jauh keandalan boleh ditekan sebelum konsumen data menyadari? Pertanyaan tersebut tidak boleh dijawab dengan perasaan — jawabannya adalah perjanjian tertulis berupa SLO, pokok bahasan penutup section ini, Chapter Service Level Objectives.