Post-Mortem & Incident Runbook: Optimasi Performa Node.js dan WebSocket untuk Real-time Chat Skala Besar

1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02:14 WIB, ponsel saya bergetar keras. PagerDuty menjerit tanpa henti. Di layar dashboard Grafana, metrik latensi loncat secara vertikal dari rata-rata 45 milidetik menembus angka 4.200 milidetik. Koneksi WebSocket yang tadinya stabil melayani 150.000 concurrent users mulai terputus secara massal, dan error rate pada layanan chat melonjak hingga 34%. Klien di sisi frontend melaporkan pesan macet di status 'sending', sementara CPU pada cluster Node.js mencatat utilisasi 100% pada single core-nya. Kami sedang berada di tengah badai traffic kampanye kilat e-commerce, dan infrastruktur real-time kami sekarat.

Sembari menyeduh kopi hitam pekat, jari-jari saya langsung bergerak membuka terminal untuk memeriksa status kontainer Docker di ekosistem Kubernetes. Ini bukan sekadar lonjakan trafik biasa; ini adalah indikasi klasik dari kebocoran sumber daya yang terakumulasi. Dari sinilah investigasi forensik infrastruktur dimulai, membawa kami menelusuri lorong-lorong gelap manajemen memori, mekanisme Event Loop, hingga sinkronisasi cluster lintas node.

2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Langkah pertama seorang engineer saat menghadapi insiden sistem skala besar adalah mengumpulkan bukti dari tempat kejadian perkara. Saya langsung mengeksekusi perintah untuk menarik log dari salah satu pod Node.js yang paling menderita:

kubectl logs -n production -l app=chat-service --tail=1000 --timestamps | grep -i "heap"

Hasilnya langsung memunculkan peringatan merah: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory. Mesin V8 Node.js telah mencapai batas maksimal alokasi memorinya yang berada di angka 1.4 GB untuk default heap 32-bit atau batas konfigurasi awal. Saya melanjutkan dengan menarik snapshot heap memory menggunakan alat bawaan dan menganalisisnya secara lokal. Grafik penggunaan memori memperlihatkan tren linier sawtooth yang gagal turun—sebuah pola memory leak klasik di mana garbage collector tidak lagi mampu membersihkan objek yang tertahan dalam memori.

[!WARNING] Jangan pernah menjalankan heap snapshot secara langsung pada pod produksi yang sedang mengalami lonjakan beban tinggi tanpa rate limiting atau pembatasan instance, karena proses dumping memori berukuran gigabytes dapat memicu event loop block total dan membuat pod tersebut langsung mati (OOM Killed).

Namun, memori bukanlah satu-satunya tersangka. Ketika kami memeriksa metrik dari Redis yang bertindak sebagai message broker, antrean pub/sub mulai membengkak karena prosesor Node.js terlalu sibuk melakukan serialization JSON ketimbang mendistribusikan payload paket data WebSocket. Transisi dari masalah memori ini membawa kita langsung ke jantung dari mesin V8 itu sendiri: bagaimana cara kerja Arsitektur Event Loop Node.js menangani beban konkuren yang masif.

3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Setelah menganalisis kode sumber dan hasil dump, kami menemukan dua akar masalah utama yang saling berkelindan. Pertama, implementasi Event Loop Node.js terhambat oleh operasi sinkronus yang tidak disengaja di dalam callback WebSocket. Setiap kali sebuah pesan chat diterima dari klien, server melakukan parsing JSON skala besar dan operasi enkripsi token secara sinkron di dalam main thread. Hal ini menyebabkan Event Loop Block, di mana tick berikutnya tertunda sekian ratus milidetik, membuat ribuan koneksi TCP tertahan (backpressure).

Kedua, Manajemen Memori WebSocket kami mengalami kebocoran parah pada objek penanganan sesi (session mapping). Setiap kali klien terputus secara tidak normal (abrupt disconnect karena sinyal seluler buruk), referensi objek socket tersebut tidak dibersihkan dari struktur data global Map di dalam memori heap. Akibatnya, jutaan listener event dan buffer data tertahan selamanya di dalam memori tanpa pernah disentuh oleh Garbage Collector.

Berikut adalah cuplikan kode lama yang menjadi biang kerok memory leak tersebut:

// KODE BERMASALAH: Menyimpan referensi socket secara global tanpa pembersihan yang benar
const activeSessions = new Map();

wss.on('connection', (ws, req) => {
    const userId = extractUserId(req);
    activeSessions.set(userId, { ws, metadata: req.headers, buffer: Buffer.alloc(1024 * 1024) });

    ws.on('message', (message) => {
        // Operasi blocking JSON.parse pada payload besar
        const parsed = JSON.parse(message); 
        broadcastToRoom(parsed.room, parsed.text);
    });

    // Lupa membersihkan activeSessions saat 'close' atau 'error'
});

Untuk mengatasi masalah ini, arsitektur harus diubah total menggunakan Clustering dengan Redis Pub/Sub agar beban state tidak menumpuk di satu instance Node.js saja, melainkan terdistribusi merata dengan manajemen memori yang ketat.

4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Hitungan Menit

Sebelum melakukan perbaikan kode secara permanen, layanan harus diselamatkan seketika agar bisnis tidak mengalami kerugian lebih lanjut. Berikut adalah Emergency Runbook one-liner terminal yang kami eksekusi untuk melakukan rolling restart, menaikkan batas memori heap V8 sementara, dan mengaktifkan circuit breaker pada Nginx reverse proxy:

# 1. Paksa Kubernetes melakukan rolling update dengan limit heap V8 yang diperbesar
kubectl set env deployment/chat-service -n production NODE_OPTIONS="--max-old-space-size=4096"

# 2. Lakukan drain koneksi lama secara bertahap dan restart pod
kubectl rollout restart deployment/chat-service -n production

# 3. Validasi ulang status kesehatan cluster melalui curl ke health check endpoint
curl -I https://chat.production.internal/healthz

[!TIP] Selalu pastikan Anda menyiapkan graceful shutdown handler di dalam kode aplikasi Node.js Anda (process.on('SIGTERM', ...)) agar server sempat menutup koneksi WebSocket yang aktif dengan kode status penutupan yang bersih sebelum pod benar-benar dimatikan oleh orkestrator.

Langkah darurat ini berhasil meredam lonjakan latensi dan mengembalikan stabilitas sistem dalam kurun waktu kurang dari 5 menit. Namun, pekerjaan rumah sesungguhnya adalah memastikan arsitektur defensif diterapkan agar kejadian serupa tidak terulang kembali.

5. Kebijakan Retrospektif: Menambal Celah agar Tak Pernah Terulang

Belajar dari insiden dini hari tersebut, kami merombak total arsitektur kode backend. Kami memindahkan pengelolaan sesi WebSocket menggunakan WeakMap atau sistem TTL berbasis Redis, serta menerapkan Worker Threads untuk menangani parsing JSON berukuran besar agar Event Loop utama tetap bersih dari beban komputasi berat.

Berikut adalah implementasi kode baru yang aman dari memory leak dan mendukung Clustering dengan Redis Pub/Sub:

const { Worker } = require('worker_threads');
const Redis = require('ioredis');
const pubClient = new Redis(process.env.REDIS_URL);
const subClient = pubClient.duplicate();

// Menggunakan WeakMap atau Map dengan mekanisme pembersihan eksplisit
const activeSessions = new Map();

wss.on('connection', (ws, req) => {
    const userId = extractUserId(req);
    const sessionData = { ws, lastActive: Date.now() };
    activeSessions.set(userId, sessionData);

    ws.on('message', (message) => {
        // Offload parsing berat ke Worker Thread agar Event Loop tidak terblokir
        runWorkerParser(message, (err, parsed) => {
            if (err) return;
            pubClient.publish('chat-channel', JSON.stringify({ userId, ...parsed }));
        });
    });

    // PENTING: Bersihkan memori secara mutlak saat koneksi terputus
    ws.on('close', () => {
        activeSessions.delete(userId);
    });

    ws.on('error', () => {
        activeSessions.delete(userId);
        ws.terminate();
    });
});

subClient.subscribe('chat-channel');
subClient.on('message', (channel, message) => {
    const data = JSON.parse(message);
    // Broadcast ke klien lokal yang terhubung ke pod ini
    for (const [id, session] of activeSessions.entries()) {
        if (session.ws.readyState === WebSocket.OPEN) {
            session.ws.send(JSON.stringify(data));
        }
    }
});

Melalui pendekatan ini, komunikasi antar pod Node.js di-handle secara efisien oleh Redis Pub/Sub, sementara event loop dibebaskan dari tugas-tugas heavy lifting.

6. Pasang Alarm: Otomasi Deteksi Dini untuk Tim On-Call

Agar tim on-call tidak perlu lagi dikejutkan oleh alarm tengah malam tanpa persiapan, kami memasang aturan alerting otomatis di Prometheus dan Grafana yang memantau metrik spesifik:

# Konfigurasi Prometheus Alert Rule untuk deteksi dini Memory Leak
groups:
- name: chat-service-alerts
  rules:
  - alert: NodeMemoryLeakWarning
    expr: container_memory_usage_bytes{container="chat-service"} / container_spec_memory_limit_bytes{container="chat-service"} > 0.80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Penggunaan memori pod chat-service melampaui 80% selama 5 menit."
      description: "Segera periksa potensi memory leak atau lakukan scaling pod tambahan."
  - alert: WebSocketHighLatency
    expr: histogram_quantile(0.99, rate(websocket_request_duration_seconds_bucket[2m])) > 1.5
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Latensi WebSocket P99 melampaui 1.5 detik!"
      description: "Event loop kemungkinan besar mengalami blocking atau antrean Redis penuh."

Dengan sistem pemantauan berlapis ini, anomali sekecil apapun akan terdeteksi jauh sebelum berdampak buruk pada pengalaman pengguna akhir. Stabilitas infrastruktur bukan dicapai dengan keberuntungan, melainkan melalui arsitektur yang tangguh, pemantauan yang presisi, dan kesiapan operasional yang matang.