Sesi 16 — Pods Naik, Database Tumbang: Aritmatika Connection Storm & Lock Contention

1. Bayangkan Jika

Di sebuah bank, loket teller yang awalnya 5 ditambah menjadi 100 loket agar antrean nasabah cepat selesai.

Namun semua 100 teller itu harus meminta tanda tangan ke satu orang manajer cabang yang duduk di satu ruangan kecil dengan satu meja. Sekarang bukan hanya nasabah yang antre, tapi 100 teller berdesakan di depan pintu manajer, saling dorong, dan manajer menghabiskan 90% waktunya hanya untuk mengusir teller yang berebut map berkas.

2. Apa yang Sebenarnya Terjadi

Inilah fenomena Bottleneck Shifting. Ketika kita menaikkan kapasitas lapisan komputasi (Pod / App Server) tanpa memperhatikan lapisan stateful (Database), kita menciptakan Connection Storm:

Aritmatika Sederhana yang Mematikan: - 10 Pod × 20 koneksi di pool = 200 koneksi database (aman pada max_connections = 300). - HPA terpicu, pod naik jadi 100 Pod. - 100 Pod × 20 koneksi = 2.000 koneksi bersamaan!
Biaya per Koneksi Database: - Di PostgreSQL/MySQL, tiap koneksi backend bukan thread gratisan, melainkan proses/thread memori terpisah (2–10 MB RAM per koneksi) + alokasi buffer kerja (work_mem). - 2.000 koneksi menghabiskan gigabytes RAM hanya untuk manajemen koneksi, merebut jatah memori dari Buffer Pool / Shared Buffers (tempat cache data halaman DB disimpan).
Context Switching & Lock Contention: - CPU database dengan 16 core dipaksa melakukan time-slicing di antara 2.000 proses yang aktif. Waktu CPU habis untuk context switching (kernel overhead) alih-alih mengeksekusi query. - Ribuan transaksi berebut row lock dan page latch pada tabel/indeks yang sama, menyebabkan antrean lock internal meledak (heavy lock contention).
Checkpoint & IOPS Saturation: - Ribuan transaksi write memicu penulisan WAL (Write-Ahead Log) dan dirty page flush ke disk NVMe, membuat disk I/O menyentuh 100% utilisasi dan IOPS habis.

3. Bagaimana Jika Kita Coba...

"Kita naikkan saja max_connections = 5000 di konfigurasi database!"

Mengapa ini memperparah kehancuran? - Menaikkan max_connections tidak menambah core CPU atau IOPS disk. - Database yang tadinya hanya menolak koneksi (error too many connections) kini menerima semua 5.000 koneksi, kehabisan RAM, terkena OOM kernel killer, dan seluruh database crash seketika!

4. Nama Resminya

Connection Storm / Thundering Herd on DB: Lonjakan masif koneksi klien ke database.
max_connections Limit: Batas keras koneksi simultan yang diizinkan database engine.
Lock Contention: Kondisi persaingan transaksi terhadap resource lock yang sama.
Buffer Pool Thrashing: Cache database terbuang keluar karena memori direbut koneksi.
Bottleneck Shifting: Memperluas satu pipa hanya untuk membentur pipa berikutnya yang lebih sempit.

5. Di Dunia Kita

PostgreSQL Connection Overhead: Postgres menggunakan model process-per-connection. Di atas 300–500 active connection, performa Postgres anjlok drastis (hockey-stick latency degradation).
Kubernetes HPA Thrashing: Pod bertambah karena response time lambat -> koneksi DB naik -> DB makin lambat -> response time makin parah -> HPA menambah pod lagi hingga sistem kolaps total (vicious death spiral).

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Active Connections vs Idle Connections: Pantau rasio koneksi aktif vs idle (pg_stat_activity / SHOW PROCESSLIST). 2. Lock Wait Time: Metrik waktu yang dihabiskan query untuk menunggu pelepasan kunci baris data. 3. Buffer Pool Hit Ratio: Harus tetap > 98%. Jika anjlok ke 80%, query mulai membaca disk fisik. 4. Saturation Curve: Temukan titik belok (sweet spot) di mana penambahan koneksi justru menurunkan total throughput (TPS).

7. Pertanyaan untuk Ronde Berikutnya

Jika database tidak boleh menerima ribuan koneksi langsung dari ratusan pod, bagaimana caranya kita menampung ribuan request pengguna tersebut tanpa membiarkan pod menyerbu pintu database secara liar?

Jawabannya ada di Sesi 17: Penjaga Pintu Database (SQL Proxy & Connection Pooler: PgBouncer / ProxySQL).