UNDER PRESSURE

Level 3 · Sistem yang Saling Bergantung

Sesi 29: Menembak Server Sendiri: Load Testing, Spike Testing, & Chaos Engineering

Bagaimana jika cara terbaik memastikan sistem tidak mati di tangan pengguna saat flash sale jam 12 malam adalah dengan menembak dan membunuh server kita sendiri secara sengaja saat jam kerja siang hari?

Sesi 29 / 343 menit baca

1. Bayangkan Jika

Sebuah tim astronot NASA tidak pernah langsung terbang ke bulan hanya dengan membaca buku manual di atas kertas. Mereka masuk ke ruang simulasi gravitasi nol, mematikan suplai oksigen tiruan, menyabotase sistem navigasi, dan melatih respon kepanikan sampai menjadi refleks otomatis di bawah tekanan (GameDay & Chaos Simulation).

Jika kita baru mengetahui server kita crash saat peluncuran produk di depan 50.000 pembeli asli, itu bukan pengujian — itu adalah bunuh diri reputasi bisnis.

2. Mengapa Testing di Lingkungan Dev Sering Menipu?

Aplikasi yang berjalan mulus di laptop developer (localhost) atau staging sering kali hancur lebur di production karena 3 kebohongan klasik: 1. Volume Data Kosong: Database staging hanya berisi 100 baris data dummy (semua query secepat kilat), sedangkan production menampung 50 juta baris (full table scan mematikan memori). 2. Ketiadaan Latensi Jaringan: Di localhost, latensi antar service adalah 0 ms. Di production lintas region, latensi 30 ms mengamplifikasi blocking thread. 3. Konkurensi Nol: Diuji oleh 1 orang QA vs diserbu 10.000 koneksi bersamaan yang berebut lock database.

3. Taksonomi Beban: 5 Jenis Uji Beban

  1. Smoke Test: Uji beban minimal (1–5 user) untuk memverifikasi fungsionalitas dasar script pengujian.
  2. Load Test: Menguji performa sistem pada beban puncak normal yang diharapkan (misal: 2.000 QPS selama 30 menit).
  3. Stress Test: Menaikkan beban secara bertahap melebihi kapasitas normal untuk menemukan titik patah (breaking point) sistem.
  4. Spike Test: Menembakkan lonjakan trafik ekstrem seketika (dari 100 QPS melonjak ke 10.000 QPS dalam 5 detik) untuk menguji respon auto-scaler dan rate limiter.
  5. Soak Test (Endurance): Menjalankan beban konstan selama 12–48 jam nonstop untuk mendeteksi Memory Leak atau kebocoran resource handle yang tersembunyi.

4. Chaos Engineering: Menyuntikkan Kehancuran

Dipelopori oleh Netflix melalui Chaos Monkey: - Prinsip dasar: Asumsikan segala sesuatu yang bisa rusak, pasti akan rusak di production. - Secara acak mematikan pod Kubernetes, memutuskan kabel jaringan antar data center, menyuntikkan latensi 5 detik ke basis data, atau mengisi disk hingga 100% penuh saat hari kerja normal. - Tujuannya adalah membuktikan bahwa arsitektur Failover, Circuit Breaker, dan Self-Healing bekerja otomatis tanpa campur tangan manusia.

5. Nama Resminya

  • Load Testing: Pengujian untuk mengukur respon sistem di bawah beban tertentu.
  • Breaking Point: Titik beban di mana sistem mulai gagal mempertahankan SLA (latensi meroket atau error rate >1%).
  • Soak Testing: Pengujian beban berdurasi panjang untuk mencari degradasi performa bertahap (memory leak).
  • Chaos Engineering: Disiplin bereksperimen pada sistem untuk membangun keyakinan terhadap kemampuan sistem bertahan dari kondisi kacau di production.
  • GameDay: Latihan simulasi insiden terjadwal di mana tim engineer mempraktikkan respon tanggap darurat.

6. Di Dunia Kita

  • k6 (Grafana): Tool modern berbasis JavaScript/Go untuk mendefinisikan skenario load test as-code dengan metrik p95/p99 presisi tinggi.
  • Chaos Mesh / LitmusChaos: Platform Chaos Engineering open-source untuk ekosistem Kubernetes.

7. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Threshold Pass/Fail Criteria: Definisikan batas toleransi ketat di CI/CD pipeline (contoh: http_req_duration: ['p(95)<200'], http_req_failed: ['rate<0.01']). 2. Memory Leak Slope: Analisis grafik alokasi memori RAM selama 24 jam soak test: pastikan grafik berbentuk datar (flat plateau), bukan garis miring naik permanen (staircase memory leak). 3. Chaos Recovery RTO: Ukur berapa detik waktu yang dibutuhkan kluster untuk kembali 100% sehat setelah 1 node worker dimatikan mendadak saat beban 3.000 QPS.

8. Pertanyaan untuk Ronde Berikutnya

Ketika sistem kita sudah diuji dengan ribuan request dan siap bertarung di dunia nyata, bagaimana tim engineer tahu apa yang sedang terjadi di dalam perut ratusan microservices saat terjadi keanehan di tengah malam?

Jawabannya ada di sesi pamungkas kurikulum: Sesi 30: Melihat Apa yang Terjadi di Dalam: Tiga Pilar Observability (Logs, Metrics, & Traces).