Menghentikan OOM Cascade pada API Gateway Perbankan: Fine-Tuning memory.high dan PSI di cgroups v2

Awal bulan dan jam makan siang selalu menjadi jendela waktu paling menegangkan bagi tim platform perbankan. Ketika jutaan nasabah secara serentak mengecek saldo, mentransfer gaji, atau membayar tagihan, beban di edge proxy meledak bukan sekadar dalam hitungan requests per second (RPS), melainkan pada konsumsi alokasi memori kernel dan daemon gateway. Fenomena lumpuhnya akses transaksi seluler seperti yang dilaporkan dalam insiden BCA Akui M-Banking Sempat Error, Kini Sudah Normal Lagi menyoroti seberapa rapuhnya infrastruktur transaksi kritis saat menghadapi saturasi tak terduga. Di balik layar, kegagalan beruntun ini sering kali bukan akibat bug logika aplikasi perbankan, melainkan fenomena OOM cascade yang mematikan worker pool di layer API Gateway.

Anatomi Ledakan Buffer di Layer Gateway

Ketika volume koneksi TLS masuk melonjak secara drastis, gateway perbankan (seperti NGINX, Envoy, atau Traefik) tidak hanya mengalokasikan memori untuk user-space process. Setiap koneksi HTTP/2 atau HTTP/3 persisten memegang kernel socket buffers (sk_buff), connection states, TLS session cache, serta buffer dekompresi payload JSON/XML transaksi perbankan. Dalam arsitektur microservices finansial, gateway juga membuka connection pool ke lusinan service backend seperti otentikasi, ledger inti, dan fraud detection. Ketika salah satu backend mengalami perlambatan mikro (micro-latency), in-flight requests di gateway tertahan lebih lama dari biasanya. Sambungan TCP klien tetap terbuka, buffer terus bertumpuk, dan alokasi memori per kontainer gateway merangkak naik secara eksponensial. Jika gateway dibatasi dengan konfigurasi memori kaku berbasis batas atas tunggal, kernel Linux tidak memiliki ruang manuver untuk menyelamatkan proses vital ini dari eksekusi mati.

Jebakan Batas Kaku memory.max dan Bencana Thundering Herd

Di cgroups v1 (dan konfigurasi default Kubernetes pada umumnya), parameter limits.memory diterjemahkan langsung menjadi memory.limit_in_bytes, atau memory.max pada cgroups v2. Nilai ini adalah hard wall. Begitu memory footprint kontainer menyentuh angka ini dan kernel gagal merebut kembali page cache melalui mekanisme reclaim, Linux Out-Of-Memory (OOM) Killer akan langsung diaktifkan. Kernel memilih proses dengan oom_score tertinggi—yang hampir selalu merupakan proses master atau worker gateway yang sedang menahan ribuan koneksi aktif—dan mengirimkan sinyal SIGKILL tanpa ampun.

BASH

# Memeriksa trigger OOM killer di level cgroups v2
cat /sys/fs/cgroup/system.slice/banking-gateway.service/memory.events
# Output:
# oom 14
# oom_kill 12

Masalah fatalnya adalah cascading effect. Begitu sebuah pod atau VM gateway dimatikan OOM Killer, puluhan ribu koneksi TCP terputus seketika. Klien mobile banking secara otomatis menginisiasi koneksi ulang (retry storm) secara serempak. Beban tersebut terdistribusi ke node gateway yang tersisa, yang sudah beroperasi di ambang batas memori. Dalam hitungan detik, node-node tersisa mengalami OOM Killer bergiliran seperti efek domino, melumpuhkan seluruh gerbang transaksi mobile banking.

Menjinakkan Reclaiming dengan memory.high di cgroups v2

Strategi pertahanan pertama adalah membuang paradigma batas tunggal. Pada cgroups v2, kernel Linux memperkenalkan hierarki proteksi memori yang jauh lebih granular, seperti yang sebelumnya juga kita bedah dalam mitigasi OOM Killer pada DNS infrastructure. Alih-alih membiarkan kontainer menabrak memory.max, kita menerapkan memory.high sebagai katup pengaman (soft limit).

INI

# Snippet systemd unit atau drop-in cgroup config
[Service]
MemoryHigh=7G
MemoryMax=8G
MemoryMin=2G

Ketika pemakaian memori gateway melampaui memory.high (misalnya 7 GB dari total plafon 8 GB pada memory.max), kernel tidak langsung membunuh worker process. Sebaliknya, kernel memaksa proses yang bersangkutan untuk melakukan synchronous page reclaim dan menyuntikkan sleep delay mikro secara proporsional pada thread yang sedang meminta alokasi alih-alih melempar error. Perlambatan buatan di level syscall alokasi memori ini secara efektif membatasi laju masuknya transaksi baru tanpa mengorbankan transaksi yang sedang diverifikasi di backend ledger.

Deteksi Dini Saturasi Menggunakan Pressure Stall Information (PSI)

Memantau persentase penggunaan memori (free -m atau metrik cgroup usage biasa) sering kali menipu karena Linux secara alami memaksimalkan penggunaan RAM untuk page cache. Memori 98% tidak selalu berarti sistem sekarat jika cache tersebut sewaktu-waktu bisa di-reclaim. Kebutuhan riil kita adalah mengetahui seberapa parah thread CPU terbuang sia-sia hanya untuk mengantre halaman memori. Di sinilah Pressure Stall Information (PSI) masuk sebagai metrik deterministik. Melalui antarmuka /proc/pressure/memory, kernel mengekspos metrik some (persentase waktu ketika beberapa proses tertahan akibat kelaparan alokasi memori) dan full (seluruh proses dalam cgroup terhenti total karena menunggu reclaim atau swap I/O):

BASH

cat /proc/pressure/memory
# some avg10=24.15 avg60=8.40 avg300=2.10 total=48210332
# full avg10=11.20 avg60=3.15 avg300=0.80 total=18492011

Jika metrik some avg10 melompat di atas 20–25% secara konsisten selama jam transaksi puncak, ini merupakan indikasi mutlak bahwa subsistem alokasi memori mulai mengalami degradasi performa, jauh sebelum kernel memutuskan untuk memanggil OOM Killer. Kita dapat menyambungkan PSI trigger ini ke daemon pemantau berbasis epoll di node host untuk merespons saturasi sebelum sistem ambruk.

Membangun Arsitektur Resiliensi Transaksi

Dengan memadukan pembatasan memory.high dan telemetri PSI, tim platform dapat mengimplementasikan mekanisme dynamic load-shedding. Saat kernel melaporkan memory pressure berada di zona bahaya, gateway dapat dikonfigurasi untuk secara cerdas menolak koneksi non-esensial (misalnya fitur download e-statement, banner promosi, atau tracking analitik aplikasi) dengan status HTTP 429 atau 503 berserta header Retry-After acak. Koneksi transaksi kritis seperti validasi transfer dan pembayaran tetap dilayani menggunakan sisa ruang antara memory.high dan memory.max. Melalui pola rekayasa sistem yang memprioritaskan degradasi anggun (graceful degradation) daripada kegagalan biner (antara jalan normal atau mati total oleh SIGKILL), API gateway perbankan dapat bertahan melewati badai transaksi sibuk tanpa memicu kepanikan nasabah maupun tim operasional.