DynamoDB On-Demand vs Provisioned Capacity

DynamoDB menagih throughput dengan dua cara. On-Demand menagih per permintaan — kamu membayar untuk yang kamu pakai, menskalakan hingga nol. Provisioned mencadangkan laju baca/tulis tetap yang kamu bayar entah kamu pakai atau tidak, dengan harga per unit yang jauh lebih rendah. Memilih yang salah adalah salah satu cara termudah untuk membayar lebih.

Audit log membuat pilihannya konkret. Tulisan audit melonjak dan tidak terduga: sepi semalaman, lalu banjir ketika seorang pelanggan menjalankan operasi massal atau sebuah insiden menghasilkan ribuan event. Bentuk trafik itulah keseluruhan keputusannya.

Haruskah saya memakai DynamoDB On-Demand atau Provisioned capacity?

On-Demand menagih per permintaan dan menskalakan hingga nol, menjadikannya default yang aman untuk trafik yang melonjak, baru, atau tidak terduga. Provisioned mencadangkan laju baca/tulis tetap dengan harga per unit yang jauh lebih rendah, menang hanya ketika trafik yang berkelanjutan dan stabil menjaga cadangan itu terpakai dengan baik. Pilih On-Demand kecuali volume-mu sudah terbukti dan bisa diprediksi.

• On-Demand = bayar per permintaan, menskalakan hingga nol. Tidak ada kapasitas yang perlu direncanakan; kamu membayar harga per baca/tulis lebih tinggi tapi hanya ketika trafik terjadi.
• Provisioned = cadangkan laju stabil, bayar selalu. Jauh lebih murah per unit kalau laju itu terpakai dengan baik; kamu menanggung biaya kapasitas yang menganggur.
• Trafik yang melonjak atau tak diketahui menuntut On-Demand. Trafik yang stabil, bisa diprediksi, bervolume tinggi menuntut Provisioned (opsional dengan auto-scaling).
• Kamu bisa berpindah mode, tapi batasnya asimetris: Provisioned ke On-Demand dibatasi empat kali per 24 jam, sementara On-Demand ke Provisioned tak dibatasi — ini bukan tombol per permintaan.

Masalahnya: membayar kapasitas yang tidak kamu pakai

Dengan Provisioned capacity kamu berkomitmen pada, katakanlah, 1.000 write unit per detik. Kalau audit log rata-rata 50 tulisan/detik tapi kamu memprovisi untuk puncak hari-insiden, kamu membayar 1.000 sepanjang waktu dan memakai seperdua puluhnya. Provisi untuk rata-rata dan banjir hari-insiden ter-throttle — tulisan ditolak.

Jadi kapasitas tetap memaksa trade-off buruk pada trafik yang melonjak: bayar lebih terus-menerus, atau under-provision dan membuang tulisan saat paling penting. On-Demand ada justru untuk menghilangkan trade-off itu.

Cara kerja kedua mode

On-Demand menagih untuk read dan write request unit yang benar-benar kamu konsumsi, tanpa kapasitas yang perlu dikonfigurasi — ia langsung mengakomodasi lonjakan hingga dua kali puncak trafik sebelumnya dan menskalakan hingga nol saat menganggur. Melampaui lompatan 2x itu dalam jendela pendek, ia masih bisa mem-throttle sambil naik. Kamu membayar premium per permintaan untuk elastisitas itu.

Provisioned mencadangkan sejumlah Read Capacity Unit (RCU) dan Write Capacity Unit (WCU) per detik. Harga per unit jauh lebih rendah, tapi kamu membayar untuk cadangan itu terus-menerus, terpakai atau tidak. Lampaui dan DynamoDB mem-throttle kecuali auto-scaling diaktifkan untuk menumbuhkan kapasitas dalam batas yang dikonfigurasi — meski auto-scaling bereaksi dalam hitungan menit, jadi lonjakan mendadak masih bisa mem-throttle sebelum ia menyusul.

Titik perpotongannya adalah utilisasi. Kira-kira: kalau trafik berkelanjutan yang bisa diprediksi menjaga Provisioned capacity terpakai dengan baik, Provisioned menang soal harga; kalau trafik melonjak, meledak-ledak, atau tak diketahui, On-Demand menang dengan tidak menagih cadangan yang menganggur.

Contoh terperinci: tagihan audit log

Audit log menulis ~50 event/detik rata-rata tapi meledak hingga ribuan selama insiden, dengan trafik baca jauh lebih rendah (ekspor kepatuhan, investigasi sesekali). Setiap event kecil — jauh di bawah 1 KB.

Pada Provisioned, kamu harus mencadangkan untuk ledakannya (membayarnya 24/7) atau berisiko mem-throttle banjir hari-insiden — waktu terburuk untuk membuang tulisan audit. Pada On-Demand, jam-jam sepi hampir tak berbiaya dan ledakan hingga dua kali puncak terkini diserap tanpa konfigurasi; kamu membayar persis tulisan yang terjadi.

Untuk beban kerja ini On-Demand adalah default yang tepat. Aturan umumnya: mulai pada On-Demand untuk tabel baru atau yang melonjak, dan baru pindah ke Provisioned setelah trafik terbukti cukup stabil untuk menjaga cadangan terpakai.

Masukkan angkamu sendiri — baca/tulis per detik, ukuran item, storage — untuk melihat kedua mode berdampingan untuk satu region:

Untuk gambaran multi-region lengkap dengan free tier diterapkan, gunakan Kalkulator Harga DynamoDB.

Lakukan di DynoTable

Keputusan kapasitas dimulai dari angka nyata: seberapa besar item-nya, berapa banyak jumlahnya, seberapa cepat mereka ditulis. Menebak-nebak itu adalah cara tabel berakhir salah provisi.

Untuk mengubah sample event menjadi RCU/WCU yang benar-benar dikonsumsinya, jalankan lewat kalkulator ukuran item. Lalu dasarkan keputusan pada tabel nyatamu: DynoTable memunculkan metadatanya — jumlah dan ukuran item — dan membiarkanmu memeriksa item representatif sehingga kamu bisa mengukurnya dengan akurat.

Jebakan dan langkah selanjutnya

• Berpindah mode dibatasi laju, dan secara asimetris. Provisioned ke On-Demand dibatasi empat perpindahan per 24 jam; On-Demand ke Provisioned tak dibatasi. Perlakukan sebagai keputusan yang dipertimbangkan, bukan tombol yang kamu putar.
• Auto-scaling tidak instan. Ia bereaksi dalam hitungan menit, jadi lonjakan tajam pada Provisioned bisa mem-throttle sebelum kapasitas tumbuh. Untuk trafik yang benar-benar meledak-ledak, On-Demand menangani lonjakan lebih baik — hingga dua kali puncak sebelumnya secara instan. Kalau kamu tahu sebuah lonjakan akan melampaui itu (peluncuran atau sale), atur warm throughput pada tabel sebelumnya untuk pre-provisi headroom ledakannya.
• Hot partition mem-throttle terlepas dari mode. Bahkan On-Demand punya batas per partition — key yang tidak merata bisa mem-throttle sementara tabel tampak di bawah kapasitas. Lihat hot partition.
• GSI punya kapasitasnya sendiri. Setiap index ditagih terpisah dan bisa mem-throttle tulisan tabel dasar kalau under-provisioned — lihat kenapa GSI mem-throttle tulisan tabel dasar.

Mode kapasitas menetapkan apa yang kamu bayar untuk menjalankan tabel di satu region. Berikutnya: mereplikasinya melintasi region dengan DynamoDB Global Tables.

Unduh DynoTable untuk membaca ukuran dan jumlah item nyata tabelmu sebelum kamu berkomitmen pada mode kapasitas.