Menangani 1 Juta Koneksi Bersamaan: Desain High Availability WebSocket Cluster

1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02:14 WIB, ponsel saya bergetar keras. PagerDuty menjerit tanpa ampun. Di layar dashboard Grafana, kurva koneksi WebSocket yang tadinya melandai indah mendadak terjun bebas, sementara metrik penggunaan memori di Node kluster backend melonjak membentuk garis vertikal lurus ke langit. Layanan real-time trading kami lumpuh total. Jutaan pengguna mendadak terputus dari server, membanjiri meja layanan pelanggan dengan keluhan bahwa grafik harga saham mereka membeku. Ini bukan sekadar gangguan kecil; ini adalah skenario mimpi buruk setiap Infrastructure Engineer ketika arsitektur yang kita bangun bertabrakan dengan tembok kenyataan trafik skala masif.

Sebelum alarm maut itu berbunyi, kami baru saja merilis fitur kampanye kilat yang menarik minat luar biasa besar. Lonjakan pengguna terjadi begitu cepat hingga melompati batas kapasitas infrastruktur eksklusif kami. Sebagai arsitek sistem, saya tahu persis bahwa masalah ini tidak akan selesai hanya dengan menekan tombol restart pada layanan Go backend kami. Ada fondasi yang jauh lebih mendasar yang runtuh di bawah tekanan satu juta koneksi simultan. Penyelidikan harus segera dimulai sebelum kerugian finansial semakin melebar.

[!WARNING] Jangan pernah meremehkan jumlah file descriptor default di sistem operasi Linux. Secara bawaan, kernel membatasi setiap proses hanya bisa membuka 1024 koneksi. Tanpa penyesuaian sistem, aplikasi Go Anda akan mengalami crash instan saat menerima koneksi ribuan pertama.

Melompat dari tempat tidur, saya langsung membuka terminal dan menyambungkan SSH ke bastion host produksi, bersiap menelusuri jejak digital dari bencana infrastruktur ini, yang membawa saya langsung ke dalam labirin log sistem yang penuh sesak.

2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Masuk ke dalam server melalui SSH, langkah pertama saya adalah memeriksa log sistem kernel menggunakan dmesg -T dan log aplikasi backend. Benar saja, baris-baris merah bertebaran dengan pesan yang sangat familiar namun selalu menakutkan: accept4 / socket: too many open files. Sistem operasi Linux kami telah menyerah kalah. Setiap koneksi WebSocket yang masuk membutuhkan satu soket jaringan, dan setiap soket direpresentasikan sebagai sebuah file descriptor. Batas kernel terlampaui jauh sebelum kapasitas CPU atau RAM habis terpakai.

# Memeriksa batas maksimal file descriptor pada proses Nginx dan Go backend
ulimit -n
# Output menunjukkan angka 1024 yang sangat menyedihkan untuk skala 1 juta koneksi

Tidak berhenti di situ, saya juga melihat masalah kedua yang jauh lebih pelik di dashboard Redis. Kluster Redis Pub/Sub kami mengalami CPU starvation dan lonjakan latensi yang masif. Mengapa? Karena ketika satu juta klien terdistribusi di tiga node server backend yang berbeda, pesan broadcast yang dikirim oleh seorang trader di node A harus disebarkan ke node B dan C melalui Redis Pub/Sub. Pola komunikasi ini menciptakan badai pesan internal (pub/sub storm) yang melumpuhkan antrean memori Redis.

// Cuplikan kode penanganan broadcast awal yang naif dan memicu lonjakan memori
func BroadcastToAll(msg []byte) {
    for client := range connectedClients {
        client.Send <- msg // Tanpa backpressure handling, berakibat OOM panic!
    }
}

Dari analisis log dan metrik ini, biang keroknya menjadi sangat jelas: kurangnya penyesuaian kernel untuk menangani batasan sistem operasi, ketiadaan strategi sticky sessions yang benar di load balancer, serta manajemen sinkronisasi Redis Pub/Sub yang rapuh. Tanpa membenahi tiga pilar ini secara bersamaan, kluster tidak akan pernah bisa stabil di angka satu juta koneksi.

3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Mari kita bedah secara mendalam mengapa infrastruktur konvensional langsung bertekuk lutut di bawah beban satu juta koneksi aktif. Pertama, secara arsitektural, protokol WebSocket bersifat stateful dan long-lived. Berbeda dengan HTTP stateless di mana koneksi langsung ditutup setelah request selesai, WebSocket mempertahankan koneksi TCP tetap terbuka secara terus-menerus. Ini berarti satu juta klien berarti satu juta soket TCP aktif yang memakan memori kernel secara konstan untuk menjaga status keep-alive.

Kedua, mari kita lihat peran krusial dari Sticky Sessions di Load Balancer. Tanpa sticky sessions berbasis IP atau cookie yang konsisten, load balancer akan mendistribusikan ulang paket handshake secara acak ke node backend yang berbeda, merusak pemetaan sesi lokal. Namun, sticky sessions saja tidak cukup jika node backend di belakangnya tidak berbagi konteks pesan. Di sinilah Redis Pub/Sub Cluster Sync menjadi jembatan penyelamat. Redis bertindak sebagai pusat saraf terdistribusi yang memastikan pesan dari satu node backend direplikasi ke seluruh kluster secara instan tanpa mengorbankan performa.

Ketiga, seluruh arsitektur canggih di atas akan menjadi sia-sia jika Kernel Tuning Linux untuk 1M Concurrent Connections diabaikan. Linux mendesain pengaturannya untuk server umum, bukan untuk mesin high-throughput real-time. Kita harus mengubah parameter kernel mulai dari alokasi memori TCP hingga batas maksimal file descriptor. Mari kita lihat bagaimana konfigurasi nyata yang menyelamatkan sistem kami diterapkan di lapangan.

4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Hitungan Menit

Saat insiden terjadi, kita tidak punya waktu untuk berteori panjang lebar. Kita butuh eksekusi perintah darurat yang presisi untuk menghidupkan kembali layanan dalam waktu kurang dari 60 detik. Berikut adalah serangkaian eksekusi terminal dan konfigurasi ulang yang langsung saya terapkan pada sistem produksi malam itu.

Pertama, kita suntikkan pengaturan kernel Linux secara langsung melalui /etc/sysctl.conf untuk membuka batasan koneksi jaringan dan memori buffer:

# /etc/sysctl.d/99-websocket-tuning.conf
# Menambah batas maksimal file descriptor secara global
fs.file-max = 2097152

# Mengoptimalkan port ephemeral untuk koneksi keluar/masuk yang masif
net.ipv4.ip_local_port_range = 1024 65535

# Mengaktifkan reuse TCP sockets dan recycling untuk koneksi TIME_WAIT
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Memperbesar ukuran memori buffer TCP (Read & Write)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Memperbesar antrean backlog untuk koneksi TCP baru
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

Terapkan perubahan kernel tersebut secara instan tanpa perlu reboot server menggunakan perintah berikut:

sysctl --system

Selanjutnya, sesuaikan batas batasan file descriptor tingkat sistem untuk pengguna layanan web (misalnya user www-data atau goapp) di /etc/security/limits.conf:

goapp soft nofile 1048576
goapp hard nofile 1048576

Untuk sisi load balancer Nginx yang berada di garis depan, kita atur agar mampu meneruskan koneksi upstream dengan dukungan sticky sessions dan manajemen keepalive yang optimal:

worker_processes auto;
worker_rlimit_nofile 1048576;

events {
    worker_connections 1048576;
    use epoll;
    multi_accept on;
}

http {
    upstream websocket_cluster {
        ip_hash; # Implementasi sticky session sederhana berbasis IP klien
        server 10.0.1.10:8080 max_fails=3 fail_timeout=10s;
        server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
        keepalive 64;
    }

    server {
        listen 80;
        server_name ws.production.internal;

        location / {
            proxy_pass http://websocket_cluster;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            
            # Timeout long-lived connection agar tidak terputus prematur
            proxy_read_timeout 3600s;
            proxy_send_timeout 3600s;
        }
    }
}

[!TIP] Penggunaan epoll pada Nginx (use epoll;) adalah kunci mutlak performa tinggi di Linux. Mekanisme ini menggunakan event-driven I/O yang tidak memblokir proses meskipun harus memantau jutaan soket secara bersamaan.

Setelah Nginx dan kernel disetel ulang, kita juga perlu memastikan backend Go kita mengelola sinkronisasi pesan menggunakan Redis Pub/Sub dengan aman melalui arsitektur penyangga yang tahan banting.

5. Kebijakan Retrospektif: Menambal Celah agar Tak Pernah Terulang

Setelah badai mereda dan metrik kembali hijau, kami mengadakan pertemuan post-mortem bersama seluruh tim engineering. Insiden pukul 2 pagi itu memberikan pelajaran mahal tentang pentingnya desain defensif. Kami menyusun kebijakan retrospektif yang ketat agar kegagalan serupa tidak pernah terulang kembali di masa mendatang.

Pertama, kami meninggalkan pendekatan broadcast naif dan beralih ke pola arsitektur Redis Cluster Pub/Sub dengan pembagian channel yang terpartisi secara dinamis berdasarkan wilayah ID pengguna. Setiap instance backend Go kini berlangganan (subscribe) ke channel Redis lokal mereka sendiri dan menggunakan worker pool berkapasitas terukur untuk mengirim pesan ke klien tanpa membebani memori utama.

// Implementasi aman pengiriman pesan menggunakan Go channels dengan backpressure
package main

import (
    "context"
    "log"
    "github.com/redis/go-redis/v9"
)

type Client struct {
    Send chan []byte
}

func (c *Client) WritePump(ctx context.Context) {
    for {
        select {
        case message, ok := <-c.Send:
            if !ok {
                return
            }
            // Kirim pesan dengan timeout pengaman untuk mencegah deadlock
            if err := c.WriteMessage(message); err != nil {
                log.Printf("Gagal mengirim pesan ke klien: %v", err)
                return
            }
        case <-ctx.Done():
            return
        }
    }
}

Kedua, kami menerapkan protokol pengujian beban (load testing) rutin menggunakan alat simulasi modern seperti k6 atau tsung yang dijalankan di lingkungan staging sebelum setiap rilis besar dilakukan. Kapasitas infrastruktur kini dipantau secara proaktif menggunakan metrik kustom di Prometheus dan Alertmanager.

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

Tidak ada sistem yang benar-benar aman tanpa sistem peringatan dini yang cerdas. Kami tidak ingin lagi mengetahui masalah dari keluhan pengguna di tengah malam. Oleh karena itu, kami merombak total aturan pengawasan PagerDuty dengan memasang alarm berbasis metrik krusial yang mendeteksi anomali jauh sebelum layanan benar-benar tumbang.

Berikut adalah aturan peringatan Prometheus (Prometheus Alerting Rules) yang kami pasang untuk mengawasi kesehatan kluster WebSocket secara real-time:

groups:
  - name: websocket_cluster_alerts
    rules:
      - alert: HighSocketSaturation
        expr: (node_filefd_allocated / node_filefd_maximum) * 100 > 80
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Penggunaan File Descriptor kritis (> 80%)"
          description: "Node {{ $labels.instance }} mendekati batas maksimal file descriptor. Segera lakukan eskalasi."

      - alert: RedisPubSubMemorySpike
        expr: redis_memory_used_bytes{area="pubsub"} > 10737418240
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Konsumsi memori Redis Pub/Sub melampaui 10GB"
          description: "Kluster Redis mengalami penumpukan pesan. Periksa backpressure pada worker backend Go."

      - alert: WebSocketConnectionDropRate
        expr: rate(websocket_connections_closed_total[5m]) > 5000
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Lonjakan pemutusan koneksi WebSocket yang tidak normal"
          description: "Lebih dari 5000 koneksi terputus per detik dalam 5 menit terakhir. Periksa stabilitas Load Balancer."

Dengan otomatisasi deteksi dini ini, tim on-call kini memiliki waktu bernapas dan ruang gerak yang cukup untuk melakukan mitigasi sebelum bencana operasional benar-benar terjadi. Arsitektur WebSocket skala satu juta koneksi bukan lagi sekadar mimpi buruk di tengah malam, melainkan sebuah mahakarya infrastruktur yang kokoh, tangguh, dan siap menghadapi masa depan.