Cara Menyiapkan Auto Scaling DynamoDB

Auto scaling DynamoDB menyesuaikan kapasitas baca dan tulis sebuah tabel provisioned menuju target utilisasi yang Anda pilih, sehingga Anda berhenti menyetel RCU/WCU dengan tangan dan berhenti membayar cadangan skenario-terburuk sepanjang waktu. Panduan ini adalah paruh praktis dari cerita kapasitas: jalur console, perintah CLI, cara benar-benar memilih angkanya, dan batas waktu yang tetap mem-throttle lonjakan tajam. Kalau Anda belum memilih mode kapasitas, mulailah dengan On-Demand vs Provisioned — auto scaling hanya berlaku untuk Provisioned.

Bagaimana cara mengaktifkan auto scaling pada tabel DynamoDB?

Di console: buka tabel Anda, masuk ke Additional settings → Read/write capacity → Edit, pilih Provisioned, lalu setel Auto scaling ke On untuk kapasitas baca, kapasitas tulis, atau keduanya, dengan memberi masing-masing sebuah minimum, maksimum, dan target utilisasi (bisa disetel antara 20 dan 90 persen). Dari CLI, daftarkan sebuah scalable target dan pasang sebuah target-tracking scaling policy dengan aws application-autoscaling. Tabel yang dibuat lewat console mendapat auto scaling aktif secara default.

Apa yang sebenarnya dilakukan auto scaling

Sebuah scaling policy memberi tahu Application Auto Scaling untuk menjaga rasio consumed-terhadap-provisioned sebuah tabel tetap dekat dengan target utilisasi Anda, di dalam batas kapasitas minimum dan maksimum yang Anda setel. Di balik layar ia membuat sepasang alarm CloudWatch untuk batas atas dan bawah; ketika konsumsi melewati salah satunya, Application Auto Scaling mengeluarkan panggilan UpdateTable untuk menggeser kapasitas provisioned.

Dua fakta struktural penting sebelum penyiapan:

• Policy bersifat per tabel dan per GSI. Setiap global secondary index punya provisioned throughput-nya sendiri, jadi masing-masing butuh policy-nya sendiri (atau checkbox "same settings for all GSIs" di console). GSI yang kurang diskalakan bisa mem-throttle tulisan tabel dasar — lihat kenapa GSI mem-throttle tabel dasar.
• Tabel yang dibuat di console ikut secara default; GSI yang ditambahkan belakangan tidak menskala selama dibangun. GSI baru pada tabel yang sudah ada dimulai dengan kapasitas manual selama backfill-nya — awasi sampai policy-nya terpasang.

Waktu reaksi yang Anda setujui

Auto scaling bersifat reaktif, dan waktu reaksinya tetap — AWS mendokumentasikan bahwa jumlah titik data alarmnya tidak bisa disetel:

• Scale-up terpicu setelah consumed capacity menembus targetnya selama dua menit berturut-turut (ditambah hingga beberapa menit keterlambatan alarm CloudWatch).
• Scale-down menunggu 15 titik data satu-menit berturut-turut di bawah targetnya.
• Setelah salah satunya terpicu, panggilan UpdateTable memakan beberapa menit untuk diterapkan — dan permintaan di atas plafon lama di-throttle selama itu berjalan.

Lantai ~5 menit dari pelanggaran sampai kapasitas baru itu adalah batas jujur fitur ini: auto scaling menyerap trafik yang tumbuh, bukan trafik yang melompat. Sebuah flash sale yang melipattigakan beban dalam satu menit akan mem-throttle pada kapasitas provisioned terlepas dari policy Anda; bentuk seperti itu menginginkan On-Demand, yang seketika mengakomodasi hingga dua kali lipat puncak Anda sebelumnya (dan mem-throttle di atas dua kali lipat dalam 30 menit — versinya sendiri dari fisika yang sama).

Penyiapan lewat console

Untuk tabel yang sudah ada (langkah AWS):

1. Console DynamoDB → Tables → pilih tabelnya.
2. Tab Additional settings → Read/write capacity → Edit.
3. Capacity mode: Provisioned.
4. Di bawah Table capacity, ubah Auto scaling ke On untuk baca, tulis, atau keduanya, lalu setel Minimum capacity units, Maximum capacity units, dan Target utilization untuk masing-masing.
5. Opsional, terapkan setelan yang sama ke setiap GSI, lalu Save.

Satu keterbatasan console yang perlu diketahui: cooldown tidak tersedia di sana. Dokumentasi AWS sendiri mengarahkan Anda ke CLI "for more advanced features like setting scale-in and scale-out cooldown times".

Penyiapan lewat CLI

Dua panggilan per dimensi: daftarkan scalable target-nya (batas min/maks), lalu pasang target-tracking policy-nya. Verbatim dari panduan CLI AWS, untuk kapasitas tulis pada sebuah tabel:

aws application-autoscaling register-scalable-target \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --min-capacity 5 \
    --max-capacity 10

Konfigurasi policy-nya tinggal di sebuah file JSON:

{
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
  },
  "ScaleOutCooldown": 60,
  "ScaleInCooldown": 60,
  "TargetValue": 50.0
}

aws application-autoscaling put-scaling-policy \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --policy-name "MyScalingPolicy" \
    --policy-type "TargetTrackingScaling" \
    --target-tracking-scaling-policy-configuration file://scaling-policy.json

Untuk baca, ganti dimensinya menjadi dynamodb:table:ReadCapacityUnits dan metriknya menjadi DynamoDBReadCapacityUtilization. Untuk sebuah GSI, resource id-nya menjadi table/TestTable/index/test-index dengan dimensi dynamodb:index:*. Sebuah tabel dengan tiga GSI yang menskalakan kedua dimensi karena itu butuh delapan pasang target/policy — buat script-nya.

Kedua cooldown default-nya 0 untuk DynamoDB dan merupakan tombol yang hanya ada di CLI: ScaleOutCooldown adalah jumlah detik minimum antara kenaikan kapasitas (scale-out yang lebih besar tetap langsung diproses), dan ScaleInCooldown memblokir penurunan berikutnya — meski sebuah scale-out menyela cooldown scale-in alih-alih menunggunya.

Memilih angkanya

Target utilisasi adalah tombol headroom-lawan-biaya. Pada target T persen, Anda membayar kira-kira 100/T kali kapasitas yang Anda konsumsi: target 70% membeli ~1,4× headroom di atas trafik stabil, target 50% membeli 2×. Target yang lebih rendah melewati pertumbuhan yang lebih tajam tanpa throttling; target yang lebih tinggi membuang lebih sedikit cadangan. Rentangnya 20–90%.

Tombol itu terhubung langsung ke tagihan. Dari tarif us-east-1 saat ini (turunan yang sama dengan Bisakah DynamoDB melakukan auto scaling?): kapasitas provisioned pada utilisasi 100% ~3,46× lebih murah per permintaan daripada on-demand, dan titik impasnya ada di ~29% utilisasi. Tugas auto scaling adalah menjaga utilisasi nyata tetap dekat dengan target Anda, jadi target itu sebenarnya memilih diskon Anda: dipertahankan pada 70%, provisioned berjalan ~2,4× lebih murah daripada on-demand; pada 50%, ~1,7×; di bawah ~29%, Anda semestinya memakai on-demand saja. Periksa angka beban kerja Anda sendiri di kalkulator harga.

Minimum capacity adalah lantai lonjakan Anda: itulah kapasitas yang sudah ada di sana selama ~5 menit yang dibutuhkan auto scaling untuk bereaksi. Setel berdasarkan ledakan paling tajam yang harus Anda serap tanpa throttling, bukan berdasarkan trafik rata-rata.

Maximum capacity adalah proteksi dari kebablasan — plafon atas apa yang bisa ditagihkan oleh sebuah bug, loop Lambda yang panas, atau load test. Setel di atas puncak realistis Anda dan perlakukan saat menyentuhnya sebagai alert, bukan operasi normal.

Scale-down dibatasi jatah. Penurunan provisioned berasal dari sebuah token bucket: Anda memulai setiap hari UTC dengan 4 tersedia, satu lagi bertambah setiap jam (maksimum 4 tertahan), untuk paling banyak 27 penurunan per tabel per hari — batas GSI terpisah, tapi satu permintaan yang menurunkan tabel dan index sekaligus ditolak seluruhnya kalau salah satu sisinya kehabisan jatah. Scale-down 15-menit auto scaling yang konservatif sudah menghormati ini dalam praktik, tapi inilah alasan kapasitas turun perlahan setelah sebuah lonjakan — dan alasan trafik yang berayun mengakhiri hari terpaku lebih tinggi daripada rata-ratanya.

Lakukan di DynoTable

Mengukur minimum dan memvalidasi target sama-sama dimulai dari angka nyata, bukan tebakan: seberapa besar item-nya, berapa banyak jumlahnya, dan berapa yang benar-benar dikonsumsi sebuah pembacaan atau penulisan representatif. Tampilan tabel DynoTable memunculkan jumlah item dan ukuran tabel secara langsung, dan pratinjau biaya query-nya menunjukkan perkiraan RCU sebuah statement sebelum ia dijalankan — angka yang sama yang menyusun sebuah rencana kapasitas. Untuk mengukur satu item, kalkulator ukuran item gratis menghitung jejak RCU/WCU-nya.

Jebakan dan langkah berikutnya

• Auto scaling tidak mengalahkan fisika per-partisi. Sebuah hot key tetap di-throttle meski kapasitas masih berlebih — lihat hot partition dan adaptive capacity.
• Jangan lupakan GSI-nya. Setiap index menskala (atau mem-throttle) sendiri.
• Reserved capacity hanya menumpuk pada provisioned. Kalau sebuah beban kerja cukup stabil sampai auto scaling nyaris tidak bergerak, reserved capacity (table class Standard, mode provisioned saja) adalah diskon berikutnya — tabel on-demand tidak bisa memakainya.
• Awasi hari pertama. ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits terhadap garis provisioned di CloudWatch memberi tahu Anda dengan cepat apakah targetnya bertahan atau berayun.

Kapasitas adalah satu sumbu dari model biaya; apa yang dikonsumsi query Anda adalah sumbu satunya — Scan vs Query dan model biaya SQL-scan membahas paruh itu.

Unduh DynoTable untuk membaca ukuran nyata tabel Anda, jumlah item, dan biaya per-query sebelum Anda menetapkan angka kapasitas untuknya.