Apa itu chaos engineering?
Chaos engineering adalah proses pengujian sistem komputasi terdistribusi untuk memastikan sistem tersebut bisa tetap berjalan meskipun mengalami gangguan tak terduga. Teknik ini didasarkan pada teori Chaos, yang mempelajari perilaku acak dan tidak dapat diprediksi. Tujuan utama dari chaos engineering adalah menemukan kelemahan sistem lewat eksperimen yang terkendali dengan cara mensimulasikan situasi kacau atau error yang tidak terduga.
Manfaat utama dari chaos engineering adalah memungkinkan organisasi mendeteksi celah keamanan atau potensi kegagalan sistem lebih awal—sebelum hacker atau kerusakan sistem yang nyata terjadi. Perubahan yang dilakukan setelah eksperimen chaos ini biasanya akan meningkatkan kepercayaan terhadap sistem IT organisasi.
Beberapa tim IT bahkan rutin mengadakan “game day” chaos engineering, yaitu semacam simulasi di mana mereka secara sengaja mencoba ‘merusak’ atau ‘menyerang’ sistem. Mereka bisa menggunakan pendekatan seperti failure mode and effects analysis (FMEA) untuk mengidentifikasi titik-titik rawan dalam infrastruktur mereka.
Konsep dasar dari chaos engineering
Konsep utama dari chaos engineering adalah merusak sistem secara sengaja untuk mendapatkan insight yang bisa meningkatkan ketahanan (resiliency) sistem. Chaos engineering ini termasuk bagian dari software testing dan quality assurance yang cocok digunakan dalam lingkungan sistem terdistribusi modern.
Chaos engineering sangat relevan untuk sistem komputasi terdistribusi, yaitu sistem yang terdiri dari banyak komputer yang terhubung lewat jaringan dan berbagi sumber daya. Sistem kayak gini gampang banget error kalau ada kejadian tak terduga. Karena komponennya banyak dan saling bergantung, troubleshooting jadi lebih susah dan error sering muncul tanpa tanda.
Banyak hal bisa bikin sistem terdistribusi gagal. Makin besar dan kompleks sistemnya, makin susah juga buat diprediksi—dan di sinilah chaos engineering berperan.
Eksperimen chaos sengaja dibuat untuk menciptakan kondisi ‘kacau’ di dalam sistem, biar bisa dicari tahu kelemahannya. Contoh masalah yang mungkin ketahuan lewat chaos experiment antara lain:
- Blind spot. Area yang tidak terdeteksi oleh sistem monitoring.
- Bug tersembunyi. Glitch atau error kecil yang bisa menyebabkan kerusakan fungsi.
- Bottleneck performa. Titik di mana performa sistem bisa meningkat kalau dioptimasi.
Seiring makin banyak perusahaan pindah ke cloud atau ke edge computing, sistem makin kompleks dan terdistribusi. Hal yang sama juga terjadi dalam pengembangan software yang sekarang fokus pada continuous delivery. Karena itu, adaptasi terhadap potensi chaos jadi penting banget.
Gimana sih cara kerja chaos engineering?
Chaos engineering mirip kayak stress testing karena dua-duanya dipakai buat cari dan benerin masalah di sistem atau jaringan. Tapi, perbedaannya adalah chaos engineering nggak fokus pada satu komponen saja.
Chaos engineering melihat masalah yang kemungkinan penyebabnya banyak banget. Jadi, pendekatannya lebih luas dan nyoba berbagai skenario yang mungkin jarang terjadi. Tujuannya adalah mendapatkan wawasan baru tentang sistem.
Biasanya, proses chaos engineering dilakukan dalam beberapa langkah:
- Menentukan baseline. Pertama-tama, kita harus tahu seperti apa kondisi sistem saat berjalan normal.
- Bikin hipotesis. Identifikasi potensi kelemahan dan bayangkan efeknya. Misalnya: gimana kalau traffic mendadak melonjak?
- Eksperimen. Lakukan eksperimen untuk melihat dampaknya. Misalnya, spike traffic ternyata menyebabkan masalah di performa storage.
- Evaluasi hasil. Bandingkan hasil eksperimen dengan hipotesis dan putuskan masalah mana yang harus diperbaiki.
Tim chaos engineering biasanya ngetes hal-hal ini:
- Hal-hal yang mereka tahu dan pahami.
- Hal-hal yang mereka tahu tapi belum sepenuhnya paham.
- Hal-hal yang mereka paham tapi belum sadar keberadaannya.
- Hal-hal yang belum mereka sadari dan juga belum mereka pahami.
Mereka menggunakan pendekatan “what if” untuk memicu error dan memvalidasi ketahanan sistem.
Prinsip lanjutan dalam chaos engineering
L. Peter Deutsch dan timnya di Sun Microsystems pernah menyusun daftar 8 asumsi salah (fallacies) dalam distributed computing. Ini adalah asumsi yang sering dibuat oleh programmer padahal nggak sesuai kenyataan. Daftar ini cocok banget buat jadi pegangan dalam chaos engineering:
- Jaringan itu selalu andal.
- Latency itu nol.
- Bandwidth itu nggak terbatas.
- Jaringan itu selalu aman.
- Topologi jaringan nggak pernah berubah.
- Hanya ada satu admin.
- Biaya transport data itu nol.
- Jaringannya homogen (seragam).
Meski ada perdebatan apakah asumsi-asumsi itu masih valid di zaman sekarang, banyak engineer masih menganggapnya sebagai prinsip penting untuk memahami masalah di sistem. Intinya: sistem dan jaringan nggak pernah benar-benar sempurna. Makanya ada istilah “five nines” (99.999%) dalam availability system, karena 100% uptime itu hampir mustahil.
Best practice dalam chaos engineering
Chaos engineering itu bukan hal yang sederhana. Supaya eksperimen berhasil dan minim risiko, ada beberapa best practice yang bisa diterapkan:
- Pahami perilaku normal sistem. Kalau tahu sistem dalam kondisi sehat itu seperti apa, jadi lebih mudah mengenali error saat eksperimen.
- Simulasikan skenario realistis. Fokus pada bug atau gangguan yang kemungkinan terjadi, misalnya: delay karena latency tinggi.
- Lakukan pengujian di kondisi nyata. Biasanya dilakukan langsung di environment produksi, karena sistem besar susah disalin di lingkungan test.
- Minimalkan dampak eksperimen. Karena bisa bikin kerusakan nyata, eksperimen harus dikontrol banget. Tim IT, dev, dan bisnis harus koordinasi. Idealnya, user nggak boleh notice kalau lagi ada eksperimen.
Contoh chaos engineering
Misalnya, ada sistem terdistribusi yang bisa handle sekian transaksi per detik. Kita bisa pakai chaos engineering buat lihat apa yang terjadi kalau jumlah transaksi itu tiba-tiba melonjak. Apakah sistemnya lemot? Atau langsung crash?
Chaos engineering juga bisa dipakai buat ngetes kondisi seperti kekurangan resource atau single point of failure. Kalau sistem gagal, dev bisa ubah desainnya dan ulangi tes buat pastikan masalahnya sudah kelar.
Salah satu kasus nyata adalah insiden Amazon DynamoDB tahun 2015. Saat itu, ada masalah di salah satu zona AWS yang bikin lebih dari 20 layanan gagal—termasuk Netflix. Tapi Netflix tetap stabil karena mereka udah punya alat chaos engineering sendiri yang namanya Chaos Kong.
Chaos Kong ini bisa mematikan satu zona AWS sepenuhnya, jadi Netflix sudah terbiasa simulasi kegagalan regional seperti itu. Karena persiapan itulah Netflix bisa bertahan lebih baik dibanding layanan lain. Kamu bisa baca penjelasan lengkapnya di sini.
Alat-alat chaos engineering
Netflix adalah salah satu pelopor chaos engineering dan mereka sudah open source banyak tools buat eksperimen chaos di sistem produksi. Kumpulan tools mereka dinamakan **Simian Army**.
Beberapa tools di Simian Army antara lain:
- Chaos Kong. Mematikan seluruh zona AWS.
- Chaos Monkey. Mematikan instance di environment produksi secara acak, tapi dijaga agar nggak sampai ganggu user.
- Chaos Gorilla. Versi yang lebih besar dari Chaos Monkey.
- Latency. Menambahkan delay untuk mensimulasikan masalah jaringan.
Selain Netflix, ada juga tools dari komunitas dan perusahaan lain seperti:
Simoorg. Tool open source yang dipakai LinkedIn untuk melakukan eksperimen chaos.
Monkey-Ops. Tool open source yang ditulis dengan bahasa Go dan berfungsi mematikan komponen atau konfigurasi deployment secara acak.
Gremlin. Tool chaos engineering yang kompatibel dengan AWS dan Kubernetes. Gremlin banyak dipakai di industri ritel dan finansial karena punya sistem proteksi otomatis.
AWS Fault Injection Simulator. Layanan dari AWS yang bisa menyuntikkan gangguan ke sistem produksi. Sudah ada template fault dan fitur pengaman supaya eksperimen tetap aman.
Pengujian, ketahanan, dan quality assurance dalam pengembangan software modern (DevOps) itu penting banget. Chaos engineering adalah salah satu pendekatan yang efektif buat menghadapi tantangan ini, terutama saat praktik continuous delivery dan eksperimen makin sering dilakukan.