EC2 VPN Burstable: Kredit CPU Standard atau Unlimited?

Gateway VPN kecil lulus uji kecepatan, terasa baik-baik saja, lalu melambat setelah makan siang. Instance itu tidak berbohong saat pengujian; ia membelanjakan kredit yang diperoleh saat menganggur. Instance burstable memang dirancang untuk itu, sehingga benchmark singkat menjadi prediktor buruk untuk satu sore penuh transfer. Kedua mode kredit juga gagal dengan cara berbeda, dan memilih di antara keduanya adalah keputusan yang sebenarnya.

Dari mana uji kecepatan meminjam

Satu kredit CPU adalah satu vCPU yang berjalan pada pemanfaatan penuh selama satu menit. Instance burstable memperoleh kredit pada laju baseline-nya dan membelanjakannya ketika melewati baseline itu. Malam yang menganggur membangun saldo; pagi yang sibuk mengurasnya.

Itulah sebabnya uji pertama terlihat bagus. Instance memiliki anggaran tersimpan, membelanjangkannya untuk pekerjaan enkripsi, dan melaporkan laju yang sehat. Tidak ada dalam hasil yang memberi tahu Anda apa yang terjadi ketika saldo mencapai nol. Benchmark mengukur burst, dan burst itulah yang dirancang untuk diberikan instance. Ia tidak pernah mengukur kondisi tunak yang akan Anda andalkan.

Aritmetika yang harus Anda hitung

Inputnya adalah persentase baseline per vCPU, jumlah vCPU, saldo yang terakumulasi, dan beban yang Anda perkirakan. Hanya sebagai ilustrasi, ambil instance hipotetis dengan dua vCPU, baseline sepuluh persen per vCPU, 24 kredit terakumulasi, dan satu vCPU sepenuhnya sibuk sementara yang lain menganggur. Angka-angka ini adalah input yang dinyatakan, bukan spesifikasi ukuran instance tertentu.

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

Dengan asumsi itu, anggaran habis dalam sekitar setengah jam. Pekerjaan latar belakang, beban yang berubah, dan pembukuan instance itu sendiri menggeser hasilnya, dan semua ini tidak memprediksi throughput VPN. Yang diprediksi adalah kapan batasan berkelanjutan mulai terasa.

Perhatikan juga pembacaan kedua: satu vCPU yang sibuk kira-kira separuh kapasitas CPU agregat dalam contoh ini. Persentase keseluruhan yang moderat dapat menyembunyikan inti yang jenuh, jadi lihat perilaku per inti bersama angka kredit.

Standard dan Unlimited: nol yang sama, makna berbeda

Dalam mode Standard, saldo yang habis membatasi CPU berkelanjutan menuju baseline. Instance terus bekerja, hanya lebih lambat, dan plafonnya dapat diprediksi. Dalam mode Unlimited, instance dapat terus menarik kredit surplus setelah saldo mencapai nol, dan penggunaan berkelanjutan di atas baseline dapat menghasilkan tagihan menurut aturan pembukuan layanan.

Jadi CPUCreditBalance bernilai nol berarti throttling dalam satu mode dan kemungkinan penagihan di mode lain. Itulah seluruh perbandingannya, dan itulah sebabnya membaca metrik tanpa membaca mode menyesatkan.

Surplus juga bukan tagihan per kredit yang sederhana. Operasi berikutnya di bawah baseline dapat melunasi penggunaan surplus, dan kondisi biaya lain berlaku. Periksa mode yang dikonfigurasi dan aturan layanan saat ini alih-alih mengandalkan klaim free tier dari posting blog lama.

Apa yang harus dipantau selama pekerjaan nyata

Catat CPUCreditUsage dan CPUCreditBalance di samping durasi dan laju transfer. Pada Unlimited, tambahkan CPUSurplusCreditBalance dan CPUSurplusCreditsCharged. Panduan pemantauan kredit CPU dari AWS menjelaskan apa yang dilaporkan masing-masing dan seberapa sering.

Uji ulang dengan konkurensi yang representatif dan durasi yang cukup untuk melihat tren, dan catat saldo awal. Pagi yang menganggur dan sore yang sibuk bukan eksperimen yang sama, bahkan dengan perintah identik.

Batas yang bukan CPU

Bandwidth jaringan memiliki baseline dan perilaku burst sendiri, dan batas laju paket atau koneksi dapat mengikat sebelum CPU. Memori penting ketika implementasi VPN menyimpan status per koneksi, dan instance kecil dapat kehabisannya jauh sebelum kehabisan kredit.

Saldo kredit yang sehat karena itu membuktikan satu hal: anggaran CPU bukan batasan saat ini. Itu tidak mengatakan apa pun tentang jalur jaringan, dan tidak mengatakan apa pun tentang apa yang terjadi pada konkurensi dua kali lipat. Pantau metrik jaringan dalam jendela yang sama dengan metrik kredit, sehingga penurunan throughput memiliki penyebab kandidat, bukan sekadar teori.

Memilih baseline dengan sengaja

Gunakan beban berkelanjutan yang terukur untuk memilih baseline, atau terima bursting secara eksplisit dan anggarkan untuk itu. Kedua jawaban dapat dipertahankan jika dituliskan; tidak satu pun dapat dipertahankan jika disimpulkan dari streaming video orang lain yang berhasil.

Jika gateway menanggung beban, perlakukan mode kredit sebagai bagian dari rencana kapasitas, bukan sebagai default yang tidak pernah Anda buka. Mode yang Anda pilih adalah kegagalan yang dapat Anda prediksi.