Mengamankan Daemon Audit ITSK dari Invokasi OOM Killer: Desain Isolasi cgroup v2 pada Node Perbankan

Pemberlakuan regulasi kepatuhan baru di industri fintech Indonesia—terutama pengetatan audit kepatuhan melalui amandemen UU P2SK dalam kerangka Fintech Laws and Regulations 2026—membawa konsekuensi langsung ke tumpukan kernel node perbankan. Ketentuan audit trail transaksi Inovasi Teknologi Sektor Keuangan (ITSK) menuntut setiap perubahan status saldo, validasi token, hingga mitigasi fraud terekam deterministik tanpa drop. Di lapangan, tim platform engineering meresponsnya dengan menempelkan sidecar audit log atau daemon telemetri kepatuhan ke setiap pod pemrosesan transaksi. Namun, di balik jargon compliance tersebut, ada bencana rekayasa sistem yang mengintai: ketika endpoint downstream regulator mengalami latensi tinggi, buffer in-memory pada daemon audit membengkak, memicu Linux Out-Of-Memory (OOM) Killer yang ironisnya mengeksekusi proses pembayaran utama.

Anatomi Malapetaka: Mengapa Core Engine Menjadi Korban OOM

Dalam arsitektur container default, sebuah Pod Kubernetes berbagi boundary memori yang diatur oleh cgroup level teratas. Katakanlah sebuah pod payment switch memiliki batas agregat 4 GiB, di mana engine transaksi utama memakan 2.5 GiB untuk heap runtime dan connection pool, sementara sidecar audit dialokasikan ruang sisa. Ketika konektivitas transmisi audit ke agregator Bank Indonesia atau OJK melambat, sidecar mulai menampung buffer pesan dalam anon memory. Masalah fatal muncul ketika cgroup mencapai batas memori dan mekanisme reklamasi halaman kernel (kswapd dan direct reclaim) gagal membersihkan anon memory yang aktif ditulis. Linux OOM Killer terpanggil. Algoritma oom_badness() di Linux kernel secara default menghitung skor eliminasi berdasarkan proporsi konsumsi memori fisik (anon_rss + file_rss + shmem) terhadap total memori. Engine transaksi yang memakan 2.5 GiB memori sah langsung menjadi target paling empuk dengan skor OOM tertinggi, sedangkan sidecar audit yang baru saja melompat dari 300 MiB ke 1.2 GiB dan menjadi pemicu kepanikan justru dibiarkan hidup. Transaksi perbankan terhenti seketika, menghasilkan error 502 bertingkat pada switch gateway.

Beralih ke cgroup v2: Membedah Mekanisme Throttling vs Hard Ceiling

Pada arsitektur cgroup v1, abstraksi kontrol memori sangat kaku: Anda hanya memiliki memory.limit_in_bytes. Jika batas tersebut tertembus dan kernel tidak bisa mereklamasi page cache, OOM Killer akan langsung diinvokasi secara destruktif. Di sinilah cgroups v2 mengubah paradigma melalui pemisahan kontrol bertingkat: memory.min, memory.low, memory.high, dan memory.max. Perbedaan paling krusial bagi workload audit perbankan terletak pada memory.high. File kendali ini bertindak sebagai throttler sebelum hard limit (memory.max) tersentuh. Ketika konsumsi memori daemon audit melampaui memory.high, kernel Linux tidak langsung membantai proses tersebut. Sebagai gantinya, kernel memaksa thread alokasi daemon masuk ke loop mem_cgroup_handle_over_high(), menyuntikkan latency sleep proporsional ke thread yang bersangkutan dan memaksa proses melakukan synchronous direct reclaim pada jatah CPU-nya sendiri. Proses audit mengalami backpressure alami dan melambat, tetapi runtime transaksi inti di sampingnya tidak mengalami OOM panic.

INI

# Konfigurasi slice systemd / cgroup v2 untuk Daemon Audit ITSK
[Service]
MemoryAccounting=yes
MemoryLow=256M
MemoryHigh=768M
MemoryMax=1024M
OOMScoreAdjust=900

Menyelamatkan Core Transaction Engine dengan memory.low dan oom_score_adj

Untuk menjamin ketersediaan transaksi, core engine pembayaran harus diperlakukan sebagai warga kelas satu yang dilindungi dari reklamasi agresif. Dengan menetapkan memory.low pada cgroup core process, kita memberikan sinyal ke kernel bahwa memori di bawah ambang batas tersebut adalah best-effort protected. Selama ada cgroup lain di dalam node yang mengonsumsi memori di atas nilai memory.low mereka, kernel akan memprioritaskan perebutan page cache dari cgroup yang melanggar batas tersebut sebelum menyentuh engine pembayaran. Selain itu, mitigasi deterministik wajib dipasang pada konfigurasi oom_score_adj. Daemon audit log yang bertindak sebagai agen pelaporan ITSK harus diberi nilai offset positif yang tinggi (misalnya +900), sedangkan engine transaksi perbankan dikunci pada nilai negatif atau netral (misalnya -500). Jika degradasi infrastruktur node berada pada titik ekstrem di mana direct reclaim tidak lagi mampu mengejar laju transaksi, kernel akan secara mutlak memilih mematikan daemon audit terlebih dahulu. Di ranah operasional perbankan, kehilangan buffer log audit sementara jauh lebih dapat ditoleransi melalui mekanisme fallback file storage lokal daripada membiarkan proses settlement transaksi mati di tengah jalan.

YAML

# Snippet Pod Spec: Memisahkan limit cgroup v2 per container
apiVersion: v1
kind: Pod
metadata:
  name: payment-core-gateway
spec:
  containers:
  - name: tx-engine
    resources:
      requests:
        memory: "2Gi"
      limits:
        memory: "3Gi"
  - name: itsk-audit-sidecar
    resources:
      requests:
        memory: "256Mi"
      limits:
        memory: "1Gi"

Menghindari Pitfall memory.oom.group pada Arsitektur Pod

Fitur cgroup v2 yang sering disalahpahami adalah memory.oom.group. Jika parameter ini bernilai 1, kernel akan memperlakukan seluruh cgroup sebagai satu kesatuan nasib: jika satu proses di dalam cgroup terkena OOM Killer, kernel akan mengirimkan sinyal SIGKILL ke seluruh proses lain dalam hierarki cgroup yang sama. Fitur ini sangat berguna untuk aplikasi multi-proses seperti database engine yang tidak ingin mengalami status korup parsial. Namun, pada node container perbankan yang menggabungkan engine pembayaran dan sidecar telemetri dalam satu Pod cgroup tree, mengaktifkan memory.oom.group = 1 adalah resep bencana. Hal ini meniadakan seluruh isolasi proses yang kita bangun; pembengkakan buffer sidecar audit akan otomatis menyeret container engine pembayaran ke liang kubur. Pastikan container runtime Anda (seperti containerd v1.7+ dengan runc modern) mengelola cgroup container secara modular di bawah sub-tree cgroup Pod tanpa menyalakan memory.oom.group di level induk pod, kecuali jika container tersebut memang didesain untuk fail-together.

Refleksi Arsitektural Menuju Standar 2026

Kepatuhan regulasi fintech bukanlah sekadar persoalan menyetujui kebijakan hukum atau memasang agen audit vendor di server. Tanpa isolasi level sistem operasi yang ketat, kepatuhan audit justru memperkenalkan attack surface baru terhadap ketahanan (operational resilience) sistem pembayaran. Dengan mengonfigurasi batas hierarki cgroup v2—memanfaatkan memory.high sebagai peredam lonjakan buffer dan memory.low sebagai benteng engine utama—arsitek infrastruktur dapat memastikan bahwa pemenuhan mandat kepatuhan ITSK berjalan selaras dengan zero-downtime availability pada sistem perbankan nasional.