Satu aplikasi, dua jalur menuju pekerjaan yang berguna
Skenario ilustratif ini adalah produk pelaporan kecil, bukan studi kasus pelanggan atau aplikasi yang telah dikirim. Jalur sinkronnya mengautentikasi akun dan membaca metadata laporan. Jalur asinkronnya membuat ekspor CSV. PostgreSQL menyimpan status aplikasi, antrean mengirim pekerjaan, dan tujuan terpisah menyimpan salinan pemulihan.
Operator menginstal dan memelihara komponen-komponen ini. Profil VPS tidak secara otomatis membuat database, antrean, konfigurasi HTTPS, atau aplikasi. Tentukan di mana data persisten berada sebelum memulai kontainer.
Anggarkan latensi API dan throughput pekerjaan secara terpisah
Aplikasi 2 dimulai dengan 2 vCPU, RAM 4 GB, penyimpanan 60 GB, dan transfer bulanan 2 TB. Ini adalah alokasi, bukan janji tentang jumlah akun, permintaan, atau ekspor yang dapat didukungnya. Mulai lembar kerja untuk proses API, database, satu worker, host, dan pekerjaan rilis yang tumpang tindih.
Skenario lembar kerja 3,840 MiB ilustratif menyisakan terlalu sedikit keyakinan di dekat batas nominal 4 GB. Jika pengukuran mendukung bentuk tersebut, Aplikasi 2 plus RAM 2 GB berjumlah $15.00 per bulan sebelum diskon jangka waktu. Itu menambah memori, bukan CPU atau independensi database. Bandingkan Scale 4 jika CPU dan memori keduanya memerlukan anggaran awal yang lebih besar.
Pantau usia pekerjaan tertua dan tingkat penyelesaian yang berguna bersama latensi API. Antrean yang bertambah dengan CPU rendah dapat menunjukkan penyimpanan atau database yang menunggu. Jangan membeli komputasi untuk mengompensasi ekspor yang berulang kali mencoba ulang input tidak valid.
Pilih kopling yang dapat Anda operasikan
Satu host menyederhanakan peta layanan pertama dan menghindari beberapa koordinasi antar-host, tetapi berbagi memori, disk, pemeliharaan, dan kegagalan. Ekspor yang mahal dapat mengganggu permintaan biasa. Batasi konkurensi worker dan pastikan pengiriman ulang aman sebelum menambahkan proses.
Pisahkan worker ketika beban pekerjaan yang realistis secara konsisten merusak perilaku API, ketika persyaratan runtime mereka berbeda, atau ketika penskalaan dan pemeliharaan independen menjadi penting. Pisahkan database ketika kebutuhan sumber daya, akses, atau pemulihannya sendiri membenarkan tambahan jaringan dan pekerjaan operasional. Ini adalah pilihan desain, bukan fitur yang secara otomatis disediakan dengan meningkatkan paket.
Buktikan bentuknya dengan latihan yang dapat diulang
Gunakan akun sintetis dan kumpulan data yang representatif. Jalankan pembacaan API, ekspor besar, dan tumpang tindih rilis bersama-sama. Catat latensi, kesalahan, jumlah worker aktif, usia pekerjaan tertua, memori, dan disk sementara. Kemudian mulai ulang satu worker setelah keluaran ditulis tetapi sebelum penyelesaian dicatat; pastikan aplikasi tetap menerbitkan satu hasil logis.
Ulangi latihan pemulihan untuk database dan satu unggahan pada target terisolasi. Catat hasil sebenarnya dan perbaiki dependensi yang hilang. Jangan jalankan latihan ini terhadap data pelanggan atau tujuan pembayaran dan email eksternal nyata tanpa rencana operasi terpisah.
Pilih periode setelah memilih sumber daya
Total berikut menggunakan konfigurasi dasar Aplikasi 2 saat ini. Opsi sumber daya meningkatkan subtotal bulanan dan menerima diskon jangka waktu yang dipilih. Periode penuh yang dikurangi dibayar di muka; lebih banyak bulan tidak menambah alokasi CPU, RAM, atau transfer bulanan.
| Periode | Sebelum diskon | Penghematan | Total USD |
|---|---|---|---|
| 1 bulan | $12.00 | $0.00 (0%) | $12.00 |
| 3 bulan | $36.00 | $0.00 (0%) | $36.00 |
| 6 bulan | $72.00 | $20.16 (28%) | $51.84 |
| 12 bulan | $144.00 | $72.00 (50%) | $72.00 |
Konfirmasikan inventaris aktual, tanggung jawab layanan, pajak, dan persyaratan perpanjangan di fakta layanan. Referensi pembayaran lokal tidak menetapkan pesanan terdaftar atau server yang dikirim. Simpan lembar kerja beban kerja Anda dan tinjau kembali saat aplikasi berubah.
Ubah anggaran menjadi konfigurasi.
Tinjau semua pilihan dan total di muka penuh.