3.5 Skalabilitas, kinerja, dan ketahanan

Tinjauan dan motivasi

Skalabilitas, kinerja, dan ketahanan adalah tiga kualitas yang berbeda, dan orang sering mencampurkannya. Kinerja adalah seberapa cepat sistem merespons dan seberapa banyak pekerjaan yang dilakukannya per satuan sumber daya. Skalabilitas adalah seberapa baik sistem mempertahankan kinerja seiring beban tumbuh. Ketahanan adalah seberapa baik sistem tetap bekerja, atau merosot dengan anggun, ketika sesuatu gagal. Sistem dapat cepat tetapi tidak skalabel (hebat pada beban rendah, runtuh pada beban tinggi), skalabel tetapi rapuh (menangani volume tetapi tumbang ketika satu komponen gagal), atau tahan tetapi lambat. Organisasi besar membutuhkan ketiganya, dirancang sejak awal, karena memasang salah satunya setelah peluncuran mahal dan mengganggu.

Bagi sistem enterprise dan pemerintah, konsekuensi salah melakukannya bersifat publik dan parah. Bayangkan portal tunjangan yang ambruk pada hari pertama skema baru, sistem pengajuan pajak yang timeout pada tenggat, atau platform pembayaran yang mati saat puncak belanja. Inilah kegagalan yang menjadi berita utama, memicu penyelidikan, dan mengikis kepercayaan publik. Sistem ini juga menghadapi beban yang sangat berpuncak, sering kali berwaktu menurut hukum (tenggat pengajuan, jendela pendaftaran, hari gajian) dan kewajiban ketersediaan serta pemulihan yang ketat. Anda harus merencanakan kapasitas untuk lonjakan yang dapat diprediksi, merosot dengan anggun di bawah yang tak terduga, dan pulih dalam batas waktu dan kehilangan data yang ditetapkan setelah bencana. Ini rekayasa dengan dimensi akuntabilitas publik.

Bab ini membahas penskalaan horizontal versus vertikal, ketiadaan status (statelessness) dan sharding sebagai pemungkin skala, load balancing, autoscaling dan perencanaan kapasitas, rekayasa kinerja dengan anggaran eksplisit, pola ketahanan dan rekayasa chaos, serta pemulihan bencana multiwilayah yang dibingkai oleh RTO, RPO, dan kesinambungan bisnis. Pesan pemersatunya adalah bahwa kualitas ini produk desain yang disengaja dan pengujian berkelanjutan, bukan harapan.

Lihat juga: bab 3.3 (sistem terdistribusi), bab 9.1 (rekayasa keandalan situs), dan bab 9.2 (observabilitas dan pemantauan).

Prinsip utama

Rancang untuk scale-out, bukan scale-up. Penskalaan vertikal punya batas atas dan titik kegagalan tunggal; penskalaan horizontal adalah cara mencapai skala besar yang tahan.
Ketiadaan status adalah pemungkin skala horizontal. Jika permintaan apa pun dapat pergi ke instans mana pun, Anda dapat menambah dan membuang kapasitas dengan bebas.
Anda tidak dapat memperbaiki apa yang tidak Anda ukur. Pekerjaan kinerja digerakkan oleh profiling dan uji beban terhadap anggaran eksplisit, tidak pernah oleh tebakan.
Segalanya gagal; rancang untuk itu. Asumsikan komponen akan gagal dan bangun agar sistem selamat dari kegagalannya.
Degradasi anggun mengalahkan kegagalan keras. Sistem yang bekerja sebagian dan melepas fitur nonesensial lebih baik daripada pemadaman total.
Kapasitas direncanakan, lonjakan diserap. Perkirakan beban yang dapat diprediksi; gunakan autoscaling dan ruang kosong untuk sisanya.
Sasaran pemulihan adalah keputusan bisnis. RTO dan RPO dipilih oleh bisnis terhadap biaya, lalu direkayasa untuk dicapai.
Uji ketahanan dengan sengaja. Anda tidak tahu sistem tahan sampai Anda membuatnya gagal dengan sengaja.

Rekomendasi

Pilih penskalaan horizontal dan rancang layanan tanpa status

Penskalaan vertikal (mesin lebih besar) sederhana dan kadang langkah pertama yang tepat, tetapi menabrak batas atas yang keras, menjadi mahal secara tidak proporsional di ujung atas, dan meninggalkan titik kegagalan tunggal. Penskalaan horizontal (lebih banyak mesin di belakang load balancer) berskala jauh lebih jauh dan meningkatkan ketersediaan, karena kehilangan satu instans dapat diselamatkan. Prasyaratnya adalah ketiadaan status. Jangan simpan sesi klien atau status permintaan di instans; dorong ke penyimpanan bersama (basis data, cache, token). Layanan tanpa status dapat ditambah, dibuang, diganti, dan di-load-balance dengan bebas, yang membuat autoscaling dan deployment bergulir mungkin. Di tempat status harus dipartisi, shard menurut kunci yang menyebar beban merata dan menjaga data terkait pada shard yang sama.

Load-balance, autoscale, dan rencanakan kapasitas

Letakkan load balancer di depan setiap tingkatan yang diskalakan untuk mendistribusikan lalu lintas dan merutekan melewati instans tak sehat lewat pemeriksaan kesehatan. Konfigurasikan autoscaling untuk menambah kapasitas ketika indikator utama (CPU, kedalaman antrean permintaan, latensi) melewati ambang dan membuangnya ketika beban turun. Setel kecepatan penskalaan dan masa pendinginan agar Anda tidak tertinggal dari lonjakan maupun bergoyang. Autoscaling bukan pengganti perencanaan kapasitas. Untuk lonjakan yang dapat diprediksi dan kritis bisnis (tenggat pajak, periode pendaftaran, acara penjualan), perkirakan beban, sediakan atau panaskan kapasitas lebih dahulu, dan uji beban ke target itu sebelumnya. Autoscaling saja tidak dapat bereaksi seketika terhadap perubahan mendadak, dan cold start menambah latensi tepat ketika Anda paling tidak sanggup. Selalu sisakan ruang kosong. Berjalan pada 100% tidak menyisakan ruang menyerap lonjakan atau kegagalan.

Rekayasa kinerja terhadap anggaran eksplisit

Tetapkan anggaran kinerja (target konkret seperti latensi API p95 di bawah 200 ms, halaman interaktif di bawah 2 detik, atau biaya per transaksi di bawah ambang) dan tegakkan dalam pengujian dan pemantauan agar regresi menggagalkan pipeline alih-alih mencapai pengguna. Gerakkan optimasi dengan pengukuran. Lakukan profiling untuk menemukan hambatan sebenarnya, yang jarang di tempat Anda menebak, dan uji beban untuk menemukan di mana sistem patah dan bagaimana ia berperilaku mendekati batas itu. Fokus pada jalur kritis dan ekor (p95/p99), karena pada skala besar latensi ekor mendominasi pengalaman pengguna. Optimalkan hambatan terbesar lebih dulu, ukur ulang, dan berhenti ketika memenuhi anggaran. Mengoptimalkan berlebihan kode yang sudah memadai adalah upaya terbuang.

Bangun pola ketahanan dan validasi dengan rekayasa chaos

Terapkan pola ketahanan dari sistem terdistribusi: timeout, retry terbatas dengan backoff, circuit breaker (yang gagal cepat ketika dependensi tidak sehat), dan bulkhead (yang mengisolasi kolam sumber daya agar satu kegagalan tidak menghabiskan sisanya), ditambah degradasi anggun (lepas atau sederhanakan fitur nonesensial di bawah tekanan: matikan rekomendasi, sajikan konten cache, antrekan pekerjaan tidak mendesak) dan load shedding (tolak atau batasi permintaan berlebih untuk melindungi inti alih-alih runtuh seluruhnya). Hilangkan titik kegagalan tunggal lewat redundansi di setiap tingkatan. Lalu validasi ketahanan dengan rekayasa chaos. Suntikkan kegagalan dengan sengaja (matikan instans, tambah latensi, putus dependensi, gagalkan zona) dalam eksperimen terkendali, mulai dari pengujian dan matang menjadi game day produksi, untuk membuktikan sistem berperilaku sesuai desain. Ketahanan yang belum pernah diuji hanyalah hipotesis.

Rencanakan multiwilayah, pemulihan bencana, dan kesinambungan bisnis

Tentukan sasaran pemulihan secara eksplisit: RTO (Recovery Time Objective, berapa lama Anda boleh mati) dan RPO (Recovery Point Objective, berapa banyak data yang sanggup hilang). Keduanya keputusan bisnis dengan implikasi biaya langsung, dan menggerakkan arsitektur. Opsi berkisar dalam biaya dan kecepatan: cadangkan-dan-pulihkan (termurah, terlambat), pilot light, warm standby, dan active-active multiwilayah (termahal, RTO/RPO hampir nol). Pilih tingkatan yang dibenarkan oleh kekritisan tiap sistem. Tidak semuanya butuh active-active. Replikasi data lintas wilayah sesuai RPO yang dipilih, otomatiskan failover, dan, di atas semuanya, uji failover secara berkala. Pemulihan bencana yang tidak diuji pasti gagal ketika akhirnya dibutuhkan. Bungkus semua ini dalam rencana kesinambungan bisnis yang mencakup orang, komunikasi, dan cadangan manual, bukan hanya teknologi.

Trade-off: kelebihan dan kekurangan

Pilihan	Kelebihan	Kekurangan
Penskalaan vertikal	Sederhana, tanpa perubahan kode, upaya awal rendah	Batas atas keras, mahal di puncak, titik kegagalan tunggal
Penskalaan horizontal	Skala hampir tak terbatas, meningkatkan ketersediaan	Butuh ketiadaan status, load balancing, lebih banyak ops
Autoscaling	Mencocokkan biaya dengan permintaan, menangani beban variabel	Bereaksi dengan lag; cold start; bisa bergoyang bila salah setel
Active-active multiwilayah	RTO/RPO hampir nol, selamat dari kehilangan wilayah	Biaya dan kompleksitas tertinggi, konsistensi data sulit
DR cadangkan-dan-pulihkan	Termurah, tersederhana	RTO panjang, jendela kehilangan data lebih besar

Trade-off pusatnya adalah biaya versus jaminan. Setiap tambahan ruang skalabilitas, kinerja, dan kemampuan pemulihan memakan uang dan kompleksitas, dan imbal hasilnya tidak linear. Beralih dari ketersediaan 99,9% ke 99,99%, atau dari RTO satu jam ke hitungan detik, dapat melipatgandakan biaya. Disiplinnya adalah menakar setiap investasi dengan kekritisan sebenarnya sistem dan toleransi bisnis terhadap downtime dan kehilangan data, alih-alih secara refleks merekayasa segalanya ke tingkat tertinggi. Sistem pembayaran yang menghadap warga layak mendapat redundansi active-active; perkakas pelaporan internal tidak.

Pertanyaan untuk didiskusikan dengan tim Anda

Ketika insiden serius terakhir Anda terjadi, mana dari ketiganya (kinerja, skalabilitas, ketahanan) yang sebenarnya gagal, dan apakah Anda memperbaiki yang tepat? Bab ini memisahkannya dengan sengaja: sistem dapat cepat namun runtuh di bawah beban, berskala namun tumbang ketika satu komponen mati, atau selamat dari kegagalan sambil lambat. Tim sering salah diagnosis, menambah kapasitas pada masalah ketahanan atau mengeraskan sistem yang sekadar kekurangan sumber daya untuk lonjakan. Telusuri dua insiden serius terakhir dan sebut kualitas mana yang patah dan apa yang sebenarnya diperbaiki oleh respons itu. Pembedaan mengubah perbaikannya: ketiadaan status dan sharding untuk skala, redundansi dan circuit breaker untuk ketahanan, profiling dan anggaran untuk kinerja. Mendapat kategori yang benar adalah beda antara membelanjakan untuk obat dan membelanjakan untuk gejala.
Apakah regresi kinerja menggagalkan pipeline Anda, atau mencapai pengguna sebelum ada yang menyadari? Anggaran kinerja (latensi p95, waktu halaman-interaktif, biaya per transaksi) hanya melindungi pengguna jika ditegakkan otomatis, sehingga perubahan yang melanggarnya menggagalkan build alih-alih dirilis. Pada tim besar dengan banyak kontributor, latensi merayap lewat seribu komit kecil, dan tanpa gerbang ekor perlahan membusuk sampai peluncuran membongkarnya. Bawa anggaran Anda saat ini dan periksa apakah mereka terhubung ke CI dan pemantauan, dan apakah menargetkan p95 dan p99 alih-alih rata-rata, karena ekor yang dirasakan pengguna pada skala besar. Di tempat anggaran tidak ada, menetapkannya adalah langkah pertama. Penegakan mengubah niat baik menjadi sifat yang bertahan dari pertumbuhan tim.
Di bawah tekanan, apa yang dilepas lebih dulu, dan apakah Anda merancang urutan itu atau akan menemukannya dalam pemadaman? Degradasi anggun dan load shedding berarti sistem menyerahkan pekerjaan nonesensial untuk melindungi inti, tetapi hanya jika Anda sudah memutuskan sebelumnya apa yang esensial. Untuk layanan yang menghadap warga, peringkat itu sering keputusan kebijakan: menyerahkan pengembalian pajak harus selamat meski dasbor status dan pencarian historis padam. Jika tak ada yang memilih, sistem melepas apa pun yang gagal lebih dulu, yang mungkin persis hal yang paling dibutuhkan pengguna. Daftar fitur Anda menurut prioritas dan pastikan arsitektur dapat menjatuhkan yang berprioritas rendah (respons cache, rekomendasi dimatikan, pekerjaan tidak mendesak diantrekan) tanpa membawa jalur kritis bersamanya. Lalu uji di bawah beban nyata, karena degradasi yang tidak diuji hanyalah harapan.
Untuk sistem paling kritis Anda, berapa RTO dan RPO-nya, siapa yang sebenarnya memilih angka itu, dan kapan terakhir kali Anda membuktikan dapat memenuhinya? Recovery Time Objective (berapa lama Anda boleh mati) dan Recovery Point Objective (berapa banyak data yang sanggup hilang) adalah keputusan bisnis dengan implikasi biaya langsung, namun pada tim besar sering diciptakan oleh siapa pun yang menulis runbook alih-alih dimiliki orang yang bertanggung jawab atas layanan. Tarikan yang bersaing adalah biaya melawan jaminan: mengecilkan RTO dari satu jam ke hitungan detik atau RPO dari menit ke nol dapat melipatgandakan tagihan infrastruktur, sehingga angka yang tepat adalah yang benar-benar mau dibayar bisnis, bukan yang paling mengesankan. Bawa sasaran terdokumentasi, tanggal uji failover nyata terakhir, dan waktu serta kehilangan data terukur yang dihasilkan uji itu, karena sasaran yang tidak teruji adalah angan-angan. Dalam lingkungan enterprise dan pemerintah angka ini mungkin ditetapkan oleh undang-undang, kontrak, atau SLA, jadi namai siapa yang menyetujuinya dan apakah latihan terakhir memenuhi kewajiban atau diam-diam meleset.
Untuk lonjakan terbesar Anda yang dapat diprediksi, apakah Anda mempercayai autoscaling bereaksi saat itu juga, atau Anda sudah memperkirakan beban, menyediakan lebih dulu, dan menguji beban ke target itu? Autoscaling bereaksi dengan lag dan cold start menambah latensi tepat ketika Anda paling tidak sanggup, sehingga perubahan mendadak yang diketahui (tenggat pengajuan, jendela pendaftaran, acara penjualan) persis kasus di mana penskalaan reaktif gagal dan perencanaan kapasitas yang disengaja menang. Ketegangannya biaya: memanaskan kapasitas untuk puncak berarti membayar ruang kosong yang menganggur sebagian besar tahun, dan godaannya berharap autoscaling menutupnya gratis. Bawa angka puncak tahun lalu, perkiraan tahun ini dengan pertumbuhan, dan hasil uji beban yang dijalankan pada kelipatan perkiraan itu alih-alih pada lalu lintas rata-rata hari ini. Untuk layanan pemerintah atau enterprise yang menghadapi lonjakan berwaktu hukum, tambahkan konsekuensi salah melakukannya, karena portal tunjangan atau sistem pajak yang ambruk pada hari pertama menjadi penyelidikan publik, bukan sekadar sore yang lambat.
Pernahkah Anda dengan sengaja menggagalkan komponen di produksi, dan apakah tingkatan redundansi setiap sistem benar-benar cocok dengan kekritisan dan biayanya? Ketahanan yang belum pernah diuji adalah hipotesis, dan tingkatan yang dapat Anda beli berkisar dari cadangkan-dan-pulihkan yang murah lewat warm standby hingga active-active multiwilayah yang mahal, sehingga disiplinnya membelanjakan jaminan di tempat yang dibenarkan alih-alih menyepuh segalanya atau tak melindungi apa pun. Pertimbangan yang bersaing adalah radius ledakan dan anggaran: eksperimen chaos harus punya pagar pembatas dan sakelar pembatalan, dan active-active untuk perkakas pelaporan internal adalah pemborosan sementara hanya-cadangan untuk platform pembayaran adalah kelalaian. Bawa inventaris titik kegagalan tunggal Anda, tingkat redundansi setiap sistem kritis, dan bukti injeksi kegagalan terkendali terakhir serta apa yang diungkapnya. Dalam portofolio enterprise dan pemerintah, petakan setiap tingkatan ke peringkat kekritisan terdokumentasi agar auditor dapat melihat bahwa uang mengikuti risiko, dan agar tak seorang pun harus membela pengeluaran itu untuk pertama kali selama pemadaman.

Lensa sektor

Startup. Anda tidak dapat memprediksi apakah peluncuran membawa lima puluh pendaftar atau lima puluh ribu, jadi beli skala alih-alih membangunnya: jalankan layanan tanpa status di belakang load balancer terkelola dan biarkan platform melakukan autoscale menurut laju permintaan. Tetapkan satu anggaran kinerja sederhana dan pilih penyimpanan data terkelola agar lonjakan tidak memaksa rearsitektur pukul 2 pagi. Lewati pemulihan bencana multiwilayah dan program chaos untuk saat ini; jaga cadangan yang teruji dan belanjakan perhatian rekayasa langka Anda pada produk, bukan pada redundansi yang belum dibenarkan lalu lintas Anda.

Bisnis kecil. Tanpa spesialis keandalan dan dengan anggaran ketat, pilihan beli-versus-bangun condong keras ke beli: platform terkelola atau tumpukan serverless menjadikan penskalaan dan failover tugas penyedia, dan satu wilayah yang dijalankan baik biasanya cukup. Bingkai ketahanan sebagai sejumlah kecil janji konkret yang dapat Anda tepati, seperti cadangan malam yang pernah benar-benar Anda pulihkan sekali dan jendela pemulihan realistis yang telah Anda komunikasikan kepada pelanggan. Hindari membayar untuk active-active atau uji beban berkelanjutan yang tidak dibenarkan oleh lalu lintas maupun staf Anda.

Enterprise. Masalahnya konsistensi di banyak tim: bakukan anggaran kinerja yang ditegakkan di CI, pustaka bersama pola ketahanan (timeout, circuit breaker, bulkhead), dan tingkat redundansi terdokumentasi untuk setiap sistem yang terikat pada kekritisannya. Sisihkan active-active multiwilayah untuk layanan tingkat satu, jalankan program rekayasa chaos dengan pagar pembatas dan game day produksi, dan perlakukan perencanaan kapasitas untuk lonjakan yang diketahui sebagai disiplin terjadwal alih-alih renungan belakangan. Atur RTO dan RPO secara terpusat agar setiap sistem kritis memiliki sasaran yang dimiliki dan teruji yang dapat diverifikasi auditor.

Pemerintah. Beban sering berwaktu hukum dan kewajiban ketersediaan bersifat undang-undang, sehingga perencanaan kapasitas tidak boleh bergantung pada autoscaling yang bereaksi saat itu juga: perkirakan lonjakan tenggat, sediakan lebih dulu, dan uji beban jauh di atas perkiraan. Pengadaan harus menetapkan RTO, RPO, dan jadwal failover yang dilatih sebagai persyaratan kontraktual, bukan janji vendor, dan harus menghindari lock-in satu wilayah untuk layanan kritis. Putuskan sebelumnya jalur mana yang esensial secara hukum (menyerahkan pengembalian, mengklaim tunjangan) agar degradasi melepas dasbor status dan pencarian lebih dulu, dan bersikaplah transparan kepada publik tentang pemadaman dan pemulihan alih-alih berharap tak ada yang menyadari.

Contoh

Startup. Sebuah startup kecil yang meluncur di Product Hunt tidak dapat memprediksi apakah akan mendapat lima puluh pendaftar atau lima puluh ribu, jadi ia menjaga layanannya tanpa status di belakang load balancer terkelola dan membiarkan platform melakukan autoscale menurut laju permintaan. Ia menetapkan satu anggaran kinerja sederhana (halaman merespons di bawah 300 ms pada persentil ke-95) dan memilih basis data terkelola agar lonjakan lalu lintas tidak memaksa rearsitektur pukul 2 pagi. Ketika lonjakan hari peluncuran benar-benar tiba, situs melambat sedikit alih-alih tumbang, dan tim menghabiskan hari berbicara dengan pengguna baru alih-alih melawan pemadaman.

Enterprise. Sebuah perusahaan media streaming menjalankan layanan tanpa status di beberapa wilayah di belakang load balancing global, melakukan autoscale menurut laju permintaan mengikuti gelombang jam tayang utama harian. Anggaran kinerja menggerbangi setiap rilis pada latensi mulai p99. Di bawah kegagalan wilayah, lalu lintas bergeser otomatis ke wilayah sehat, dan fitur nonesensial (gambar sampul personal, penyegaran rekomendasi) merosot lebih dulu untuk melindungi pemutaran. Perusahaan menjalankan eksperimen chaos berkelanjutan di produksi, rutin menghentikan instans dan menyuntikkan latensi, sehingga kegagalan nyata tak dapat dibedakan dari latihan dan tidak menyebabkan pemadaman yang terlihat pelanggan.

Pemerintah. Sebuah otoritas pajak tahu sistem pengajuannya menghadapi lonjakan tenggat besar yang ditetapkan hukum setiap tahun. Alih-alih mengandalkan autoscaling bereaksi saat itu juga, ia memperkirakan beban puncak dari tahun-tahun sebelumnya, menyediakan kapasitas berminggu-minggu sebelumnya, dan menguji beban hingga 150% perkiraan. Arsitekturnya tanpa status di belakang load balancer dengan wilayah kedua warm-standby. RTO dan RPO ditetapkan oleh kebijakan (downtime tidak lebih dari 15 menit dan kehilangan data hampir nol untuk pengembalian yang diserahkan), dan failover dilatih per kuartal. Di bawah beban ekstrem, fitur nonkritis (dasbor status, pencarian historis) dilepas lebih dulu agar penyerahan pengembalian, jalur esensial secara hukum, tetap tersedia.

Kasus bisnis: motivasi, ROI, dan TCO

Skalabilitas, kinerja, dan ketahanan adalah kasus klasik di mana biaya kegagalan jauh melampaui biaya pencegahan. Tetapi pencegahan terlihat di anggaran sedangkan kegagalan hanya potensial, itulah sebabnya mereka kurang didanai secara kronis sampai bencana pertama. Biaya adopsi nyata: infrastruktur redundan, kapasitas multiwilayah, perkakas uji beban dan chaos, serta waktu rekayasa untuk membangun ketiadaan status dan pola ketahanan. Biaya tidak berinvestasi adalah pemadaman profil tinggi saat permintaan puncak: pendapatan hilang per menit untuk perdagangan, kewajiban undang-undang terlewat dan penyelidikan publik untuk pemerintah, penalti perjanjian tingkat layanan (SLA), dan kerusakan reputasi yang bertahan lama.

Bingkai kasus kepada pimpinan dengan angka yang sudah dipahami bisnis. Perkirakan biaya satu jam downtime saat puncak (transaksi hilang, penalti, perbaikan, reputasi), lalu bandingkan dengan biaya tahunan redundansi dan pengujian yang mencegahnya. Untuk sistem kritis pencegahan hampir selalu sebagian kecil dari satu insiden besar. Ikat RTO dan RPO pada uang eksplisit: berapa pendapatan atau berapa transaksi per jam downtime, dan berapa kehilangan data yang dapat ditoleransi secara hukum atau komersial. Sajikan kinerja sebagai tuas pendapatan dan kepuasan, karena sistem lebih cepat berkonversi lebih baik dan lebih murah per transaksi, dan sajikan ketahanan sebagai asuransi yang preminya kecil dibanding kerugian yang ditanggung. Argumen terkuatnya adalah bahwa kualitas ini murah dirancang masuk dan menghancurkan jika dipasang setelah pemadaman yang memaksa persoalan.

Anti-pola dan jebakan

Sesi lengket dan status dalam instans. Menyimpan status sesi di server, mencegah penskalaan horizontal bebas dan penggantian instans yang aman.
Autoscaling sebagai perencanaan kapasitas. Mengasumsikan autoscaling akan menyerap lonjakan mendadak yang diketahui padahal terlalu lambat bereaksi.
Berjalan panas tanpa ruang kosong. Beroperasi pada utilisasi hampir 100%, tidak menyisakan apa pun untuk menyerap lonjakan atau kegagalan.
Mengoptimalkan tanpa profiling. Menyetel kode yang bukan hambatan sementara hambatan sebenarnya tak tersentuh.
Mengabaikan ekor. Melaporkan latensi rata-rata sementara pengguna p99 menderita; rata-rata menyembunyikan rasa sakit pada skala besar.
Pemulihan bencana yang tidak diuji. Rencana DR dan cadangan yang belum pernah dilatih dan akan gagal saat dibutuhkan.
Titik kegagalan tunggal. Satu load balancer, satu primer basis data, satu wilayah: komponen tanpa redundansi yang menjatuhkan segalanya.
Rekayasa chaos tanpa pagar pembatas. Menyuntikkan kegagalan tanpa kendali radius ledakan atau sakelar pembatalan, menyebabkan pemadaman yang justru hendak dicegah.

Model kematangan

Tingkat 1: Memulai. Ad hoc dan reaktif. Instans tunggal atau diskalakan vertikal, dengan status disimpan di server. Tanpa uji beban, tanpa anggaran kinerja, dan tanpa pemulihan bencana selain cadangan sesekali yang belum pernah dipulihkan siapa pun. Kegagalan komponen mana pun menyebabkan pemadaman penuh, dan masalah skala ditemukan di produksi.
Tingkat 2: Mengembangkan. Praktik dasar muncul tetapi bervariasi antartim. Beberapa layanan diskalakan horizontal dan tanpa status di belakang load balancer, dengan autoscaling dasar pada beberapa di antaranya. Uji beban terjadi sebelum peluncuran besar tetapi tidak rutin, dan cadangan ada sementara pemulihan bencana terdokumentasi namun jarang dilatih. Apa yang dilakukan satu tim dengan baik belum dimulai tim lain.
Tingkat 3: Membakukan. Praktik terdokumentasi dan ditegakkan di seluruh organisasi. Kapasitas direncanakan untuk lonjakan yang diketahui dengan ruang kosong, anggaran kinerja ditegakkan di CI sehingga regresi menggagalkan build, dan pola ketahanan (timeout, retry terbatas, circuit breaker, bulkhead) ditambah degradasi anggun adalah bawaan. RTO dan RPO ditetapkan per sistem, tingkat redundansi ditetapkan menurut kekritisan, dan failover pemulihan bencana diuji menurut jadwal rutin lintas tim.
Tingkat 4: Mengelola. Kualitas diukur dan dikendalikan terhadap garis dasar. Tim melacak latensi p95 dan p99, anggaran galat, serta utilisasi dan ruang kosong terhadap perkiraan, dan memberi peringatan pada pelanggaran alih-alih menemukannya saat peluncuran. Waktu failover teruji dibandingkan dengan target RTO dan RPO, ambang degradasi dan load-shedding divalidasi dengan metrik, dan keputusan go atau no-go atas rilis dan kapasitas digerakkan data. Di tempat angka menyimpang dari garis dasar, celahnya terlihat dan dimiliki alih-alih tersembunyi di balik rata-rata.
Tingkat 5: Mengorkestrasi. Skalabilitas, kinerja, dan ketahanan terus diperbaiki dan terintegrasi di seluruh organisasi. Active-active multiwilayah dipakai di mana pun kekritisan membenarkan, rekayasa chaos berjalan terus-menerus termasuk game day produksi, dan perkiraan kapasitas langsung memberi masukan ke perencanaan dan pengadaan. Ketahanan divalidasi secara berkelanjutan, sasaran pemulihan konsisten terpenuhi dan terbukti, dan arsitektur beradaptasi seiring bergesernya pola beban dan gambaran risiko, terikat pada kesinambungan bisnis dan perencanaan risiko.

Gagasan untuk didiskusikan

Layanan Anda yang mana yang masih menyimpan status di instans, dan apa yang mencegah Anda menjadikannya tanpa status?
Untuk sistem paling kritis Anda, berapa RTO dan RPO-nya, siapa yang menetapkannya, dan kapan terakhir kali Anda membuktikan dapat memenuhinya?
Apakah autoscaling benar-benar melindungi Anda dari lonjakan terbesar yang diketahui, atau Anda mengandalkannya melakukan sesuatu yang tidak dapat dilakukannya?
Di mana titik kegagalan tunggal Anda yang tersisa, dan apa rencana untuk menghilangkannya?
Apakah Anda mengukur dan menganggarkan latensi p99, atau bersembunyi di balik rata-rata?
Pernahkah Anda dengan sengaja menggagalkan komponen di produksi? Jika belum, bagaimana Anda tahu ketahanan Anda berfungsi?

Poin-poin utama

Bedakan kinerja, skalabilitas, dan ketahanan; sistem besar membutuhkan ketiganya, dirancang sejak awal.
Penskalaan horizontal dan layanan tanpa status adalah fondasi skala, ketersediaan, dan deployment yang aman.
Padukan autoscaling dengan perencanaan kapasitas nyata dan ruang kosong untuk lonjakan kritis bisnis yang dapat diprediksi.
Gerakkan kinerja dengan profiling dan uji beban terhadap anggaran eksplisit, berfokus pada jalur kritis dan ekor.
Bangun ketahanan dengan timeout, circuit breaker, bulkhead, degradasi anggun, dan redundansi, lalu validasi dengan rekayasa chaos.
Tetapkan RTO dan RPO sebagai keputusan bisnis, rekayasa DR agar sesuai kekritisan tiap sistem, dan uji failover secara berkala.

Referensi dan bacaan lanjutan

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering dan The Site Reliability Workbook
Casey Rosenthal dan Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile