Single vs Cluster #

Saat kita mulai merancang arsitektur sistem pengiriman pesan untuk lingkungan produksi, kita akan dihadapkan pada satu keputusan strategis yang krusial: apakah kita cukup menggunakan satu node tunggal (Single Node), ataukah harus membangun kluster multi-node (Multi-Node Cluster)? Keputusan ini tidak boleh diambil secara sembarangan hanya dengan asumsi bahwa “kluster selalu lebih baik”. Memilih di antara keduanya menyangkut trade-off yang kompleks antara keandalan sistem (reliability), toleransi kegagalan (fault tolerance), latensi penulisan jaringan, kerumitan pemeliharaan operasional, serta biaya infrastruktur. Artikel ini akan membedah secara komprehensif perbandingan arsitektural antara Single Node dengan Kluster RabbitMQ agar kita dapat membuat keputusan desain yang matang dan sesuai kebutuhan bisnis.

Anatomi dan Batasan Single Node RabbitMQ #

Konfigurasi Single Node adalah setup di mana hanya ada satu runtime RabbitMQ (satu Erlang VM) yang berjalan pada satu server fisik atau mesin virtual. Seluruh komponen logis broker — mulai dari exchange, tabel binding, antrean, hingga data fisik pesan dan state koneksi client — terpusat di satu titik memori dan disk yang sama.

flowchart TD
    subgraph SingleNode ["Single Node Server"]
        Broker["RabbitMQ Broker Process"]
        RAM["System memory (RAM)"]
        Disk["Local SSD / Storage"]
        Broker --> RAM
        Broker --> Disk
    end
    
    P["Producer"] -->|"TCP Connection"| Broker
    C["Consumer"] -->|"TCP Connection"| Broker

Banyak pengembang beranggapan bahwa dengan mengaktifkan fitur antrean durable (durable = true) dan mempublikasikan pesan secara persisten (delivery_mode = 2), maka setup Single Node sudah cukup aman untuk lingkungan produksi. Ini adalah pemahaman yang keliru.

Meskipun data kita aman di dalam disk lokal SSD:

  1. Kegagalan Ketersediaan (Single Point of Failure): Jika server fisik mengalami kerusakan perangkat keras (misalnya kegagalan modul RAM atau motherboard terbakar), atau terjadi kegagalan jaringan pada pusat data (data center outage), maka broker RabbitMQ akan mati total. Pesan kita memang tersimpan di disk, tetapi tidak ada satu pun aplikasi produsen yang bisa menulis pesan baru, dan tidak ada konsumen yang bisa memproses pesan yang ada. Sistem bisnis kita lumpuh total sampai server tersebut berhasil dinyalakan kembali.
  2. Downtime Pemeliharaan (Maintenance Window): Setiap kali kita perlu melakukan pembaruan sistem operasi server, menaikkan versi RabbitMQ, atau sekadar melakukan restart berkala, kita terpaksa mematikan broker. Hal ini menyebabkan downtime terencana (planned downtime) yang dapat mengganggu jalannya transaksi pengguna.

Oleh karena itu, penggunaan Single Node hanya direkomendasikan untuk lingkungan non-kritis: lingkungan pengembangan lokal (local development), server staging/pengujian, atau aplikasi internal dengan toleransi downtime yang sangat longgar.

Desentralisasi Kluster RabbitMQ dan Distribusi Metadata #

Untuk mengatasi keterbatasan Single Node, RabbitMQ mendukung pembentukan Kluster. Kluster adalah kumpulan dari beberapa node RabbitMQ (biasanya minimal 3 node untuk menjaga konsensus) yang terhubung melalui jaringan lokal berlatensi rendah untuk bertindak sebagai satu broker logis tunggal bagi aplikasi client.

Karakteristik penting dalam desentralisasi kluster RabbitMQ meliputi:

  • Replikasi Metadata Global: Metadata seperti definisi vhost, pengguna, izin akses, nama exchange, dan aturan binding direplikasi secara instan ke database Mnesia di setiap node dalam kluster.
  • Konektivitas Transparan: Aplikasi produsen atau konsumen dapat terhubung ke node mana saja di dalam kluster. Jika konsumen terhubung ke Node A dan meminta data dari antrean yang secara fisik berada di Node B, Node A akan secara transparan mengalirkan pesan tersebut dari Node B ke konsumen melalui jaringan internal kluster. Client tidak perlu mendeteksi lokasi fisik antrean secara manual.

Namun perlu dicatat: secara bawaan (by default), membuat antrean klasik (Classic Queue) di dalam kluster tidak otomatis membuat isi pesan di dalamnya terduplikasi ke node lain. Pesan fisik tetap hanya disimpan di satu node utama (home node). Jika node tersebut mati, pesan di dalamnya tidak dapat diakses sampai node tersebut menyala kembali, meskipun kluster secara keseluruhan masih aktif. Untuk mendapatkan ketersediaan tinggi sejati, kita harus mengaktifkan replikasi antrean.

Replikasi Antrean: Evolusi dari Mirrored Queues ke Quorum Queues #

Untuk menduplikasi pesan fisik lintas node kluster, arsitektur RabbitMQ mengalami evolusi penting dari sistem replikasi master-slave tradisional menuju sistem konsensus modern berbasis Raft.

flowchart TD
    subgraph ClusterHA ["Quorum Queue Replication (Raft)"]
        direction LR
        subgraph NodeA ["Node A (Leader)"]
            QL["Leader Process"]
            DL1[(Disk)]
            QL --> DL1
        end
        subgraph NodeB ["Node B (Follower)"]
            QF1["Follower Process"]
            DL2[(Disk)]
            QF1 --> DL2
        end
        subgraph NodeC ["Node C (Follower)"]
            QF2["Follower Process"]
            DL3[(Disk)]
            QF2 --> DL3
        end
        
        QL -->|"Replikasi Konsensus Raft"| QF1
        QL -->|"Replikasi Konsensus Raft"| QF2
    end

1. Era Klasik: Mirrored Queues (Deprecated) #

Pada versi terdahulu, RabbitMQ menggunakan Mirrored Queues (antrean cermin) untuk mencapai High Availability (HA). Antrean terdiri dari satu master dan beberapa mirror di node lain. Setiap kali pesan ditulis ke master, pesan diduplikasi ke seluruh mirror secara sinkron.

  • Kelemahan: Mirrored queues sangat rapuh terhadap gangguan jaringan. Jika terjadi partisi jaringan sementara, kluster dapat mengalami ketidaksinkronan data yang parah. Sinkronisasi ulang antrean yang besar setelah pemulihan jaringan membutuhkan waktu lama dan memblokir seluruh operasi antrean (blocking synchronization), menurunkan throughput secara drastis.

2. Era Modern: Quorum Queues (Rekomendasi Utama) #

Diperkenalkan pada versi 3.8, Quorum Queues adalah tipe antrean modern berbasis algoritma konsensus Raft. Quorum Queues menggantikan mirrored queues sepenuhnya dan menjadi standar wajib untuk data kritis di produksi:

  • Konsensus Raft: Setiap quorum queue terdiri dari satu Leader dan beberapa Follower. Ketika produsen mengirimkan pesan, Leader akan menulis pesan ke disk lokalnya sendiri dan mengirimkannya ke Follower.
  • Aturan Kuorum: Pesan dianggap sukses disimpan dan broker akan mengirimkan ACK ke produsen jika pesan tersebut telah berhasil ditulis ke disk oleh mayoritas node di dalam kluster ($N/2 + 1$). Pada kluster 3 node, kuorum tercapai jika minimal 2 node berhasil menyimpan pesan.
  • Auto-Healing Cepat: Jika Leader mati, sisa node Follower akan melakukan pemilihan suara (election) secara otomatis dalam hitungan milidetik untuk menunjuk Leader baru. Karena didasarkan pada disk-first storage, risiko kehilangan data akibat crash mendadak sangat minimal.

Bahaya Split-Brain dan Strategi Penanganan Partisi Jaringan #

Tantangan terbesar dalam mengoperasikan kluster terdistribusi adalah Partisi Jaringan (Network Partition), di mana koneksi jaringan antar-node terputus sementara waktu, namun node di kedua sisi pemutusan tetap menyala. Kondisi ini dapat memicu fenomena Split-Brain (Otak Terbelah).

Misalkan kita memiliki kluster 3 node: Node 1, Node 2, dan Node 3. Terjadi partisi jaringan yang mengisolasi Node 1 dari Node 2 dan Node 3.

Partisi Jaringan:
[Node 1]  <--- Terputus --->  [Node 2] <--- Terhubung ---> [Node 3]
(Minoritas)                    (Mayoritas)

Jika tidak ditangani, produsen dapat terus menulis pesan baru ke Node 1, sementara produsen lain juga menulis ke Node 2. Ketika partisi jaringan pulih, Mnesia database di kedua sisi akan memiliki riwayat state yang bertolak belakang (divergent state). Menyatukan kembali data ini secara otomatis tanpa kehilangan pesan adalah hal yang mustahil.

Untuk mengatasinya, RabbitMQ menyediakan tiga strategi penanganan partisi jaringan (cluster partition handling modes):

1. pause_minority (Rekomendasi untuk Konsistensi / CP) #

Saat partisi terdeteksi, setiap node akan menghitung berapa banyak rekan node yang masih bisa dihubungi.

  • Node 1 mendeteksi bahwa ia hanya sendirian (minoritas dari total 3 node). Ia secara otomatis akan menjeda dirinya sendiri (pause), memutus seluruh koneksi client, dan menutup port AMQP-nya.
  • Node 2 dan Node 3 melihat bahwa mereka masih berdua (mayoritas). Mereka tetap aktif melayani transaksi.
  • Keuntungan: Mencegah terjadinya penulisan data ganda yang tidak konsisten. Begitu jaringan pulih, Node 1 akan menyala kembali, menyalin state terbaru dari mayoritas, dan bergabung tanpa konflik.

2. autoheal (Rekomendasi untuk Ketersediaan / AP) #

Saat partisi terjadi, kedua belah pihak tetap berjalan secara independen. Begitu jaringan pulih, RabbitMQ secara otomatis mendeteksi pemutusan sebelumnya.

  • Broker akan memilih salah satu partisi sebagai pemenang (biasanya partisi dengan koneksi client terbanyak).
  • Partisi yang kalah (minoritas) akan di-restart secara otomatis oleh broker. Seluruh pesan yang ditulis ke partisi minoritas selama masa partisi akan hilang.
  • Keuntungan: Meminimalisir intervensi manual dari tim ops, namun berisiko tinggi kehilangan data.

3. ignore #

RabbitMQ tidak melakukan tindakan apa pun. Ini adalah opsi default yang sangat berbahaya untuk lingkungan produksi karena split-brain dijamin akan merusak integritas database kluster kita.

Strategi Rolling Upgrade dan Pemeliharaan Tanpa Downtime #

Salah satu keunggulan utama arsitektur kluster dibandingkan single node adalah kemampuan untuk melakukan pemeliharaan infrastruktur tanpa menyebabkan gangguan layanan bagi pengguna akhir kita. Proses ini disebut Rolling Upgrade atau Rolling Restart.

Langkah-langkah melakukan rolling upgrade pada kluster 3 node:

  1. Alihkan Koneksi Client: Gunakan Load Balancer (seperti HAProxy atau AWS ALB) di depan kluster untuk menghentikan pengiriman koneksi baru ke Node 1.
  2. Pindahkan Kepemimpinan Antrean (Drain Node): Jalankan perintah CLI untuk memindahkan posisi Leader dari seluruh Quorum Queues yang berada di Node 1 ke node lainnya:
    # Perintah untuk memindahkan leadership quorum queues dari Node 1
rabbitmq-queues rebalance "all"
  3. Matikan Node: Hentikan aplikasi RabbitMQ pada Node 1 secara aman:
    rabbitmqctl stop
  4. Lakukan Pemeliharaan: Lakukan upgrade versi OS, patching keamanan, atau naikkan kapasitas perangkat keras pada Node 1.
  5. Nyalakan Kembali: Aktifkan kembali RabbitMQ pada Node 1. Pastikan node tersebut sukses melakukan sinkronisasi metadata Mnesia dan berstatus green di dashboard.
  6. Ulangi: Lakukan langkah yang sama untuk Node 2 dan Node 3 secara bergiliran.

Dengan strategi ini, sistem pengiriman pesan kita tetap aktif 100% melayani transaksi bisnis sepanjang waktu pemeliharaan berlangsung.

Optimasi Performa Disk I/O dan Konfigurasi Filesystem #

Saat kita men-deploy RabbitMQ dalam mode kluster, terutama ketika menggunakan Quorum Queues, performa disk I/O pada setiap node akan menjadi penentu utama dari throughput keseluruhan sistem kita. Hal ini terjadi karena algoritma konsensus Raft mewajibkan setiap pesan ditulis ke disk (persist first) sebelum dianggap sukses oleh kuorum.

Untuk mencegah disk menjadi bottleneck pada kluster produksi:

  1. Gunakan SSD atau NVMe dengan IOPS Tinggi: Penggunaan HDD mekanis tradisional sangat tidak disarankan untuk kluster produksi ber-throughput tinggi karena latensi penulisan disk yang lambat akan membatasi kecepatan konfirmasi Raft.
  2. Optimasi Filesystem (XFS vs ext4): Format filesystem disk server kita menggunakan XFS atau ext4 dengan opsi mount noatime. Menonaktifkan pencatatan waktu akses terakhir (access time) ini dapat mengurangi overhead penulisan disk sebesar 5-10%.
  3. Batas Disk Free Alarm: Pastikan konfigurasi disk_free_limit disesuaikan dengan kapasitas penyimpanan kita. Secara default, RabbitMQ akan memblokir produsen jika sisa ruang disk kurang dari 50MB. Di produksi, kita sebaiknya menyetel batas ini ke persentase yang aman, misalnya:
    # Menyetel alarm batas disk kosong ke 1.5 kali total RAM fisik node
disk_free_limit.relative = 1.5

Desain Load Balancing dan Gateway di Depan Kluster #

Untuk menyajikan kluster multi-node sebagai satu broker logis yang rapi kepada aplikasi client, kita membutuhkan mekanisme penyebar beban (Load Balancer) di depan kluster. Load Balancer bertugas membagikan koneksi TCP dari ratusan kontainer produsen dan konsumen secara merata ke seluruh node kluster yang sehat.

flowchart TD
    Clients["Applications (Clients)"] -->|"TCP Connection"| LB["Load Balancer (HAProxy / Nginx)"]
    LB -->|"Weight-based Routing"| Node1["Node 1 (rabbit@host-01)"]
    LB -->|"Weight-based Routing"| Node2["Node 2 (rabbit@host-02)"]
    LB -->|"Weight-based Routing"| Node3["Node 3 (rabbit@host-03)"]

Beberapa praktik terbaik dalam mengonfigurasi load balancer di depan kluster RabbitMQ meliputi:

  1. Pilih TCP-level Load Balancing (Layer 4): Jangan gunakan HTTP load balancing untuk koneksi pesan AMQP. Konfigurasikan load balancer kita (seperti HAProxy atau AWS Network Load Balancer) untuk bekerja pada tingkat TCP murni agar koneksi jangka panjang (long-lived connections) dapat dipertahankan.
  2. Konfigurasi Heartbeat AMQP: Jaringan cloud atau load balancer sering kali memutuskan koneksi TCP yang menganggur (idle connections) secara sepihak untuk menghemat sumber daya. Kita harus menyetel properti requested_heartbeat di sisi client atau server (default 60 detik) untuk mengirimkan paket ping kecil secara berkala. Hal ini menjaga koneksi tetap hidup dan mendeteksi pemutusan fisik jaringan lebih awal.
  3. Endpoint Health Check: Gunakan endpoint HTTP API khusus dari Management Plugin RabbitMQ untuk memantau kesehatan node dari sisi load balancer:
    GET http://<node-ip>:15672/api/health/checks/node
    Jika node tersebut berstatus paused akibat masuk ke minoritas partisi jaringan, endpoint ini akan mengembalikan kode HTTP 503 Service Unavailable, sehingga load balancer dapat secara otomatis mengeluarkan node tersebut dari daftar target aktif.

Anti-Pattern vs Solusi: Menggunakan Kluster Lintas Wilayah Geografis (WAN) #

Mari kita pelajari salah satu kesalahan fatal dalam desain infrastruktur yang sering dilakukan demi mengejar jaminan ketersediaan tinggi lintas benua (Multi-Region Disaster Recovery).

Kasus Anti-Pattern: Membuat Kluster Lintas WAN / Multi-Region #

Dalam skenario ini, tim operasi mencoba membuat satu kluster RabbitMQ terpadu di mana Node 1 berada di pusat data Jakarta, Node 2 di Singapura, and Node 3 di Tokyo. Mereka berasumsi bahwa jika satu negara mengalami gempa bumi, sistem pesan mereka akan otomatis berpindah secara instan.

          [Kluster Lintas Wilayah WAN]
  Node 1 (Jakarta) <== Latency 80ms ==> Node 2 (Singapura)
       \\                                //
        \\==== Latency 150ms ===========//
                Node 3 (Tokyo)

Kenapa ini fatal? Protokol konsensus Raft pada Quorum Queues dan sinkronisasi database Mnesia didesain untuk beroperasi pada jaringan lokal berlatensi sangat rendah (LAN, sub-milidetik). Ketika latensi antar-node mencapai puluhan hingga ratusan milidetik lintas samudra:

  1. Raft Heartbeat Timeout: Latensi jaringan yang berfluktuasi akan memicu false-positive timeout. Node akan terus-menerus mengira node lain mati dan melakukan pemilihan suara Leader baru tanpa henti (infinite leader election).
  2. Throughput Drop: Setiap publikasi pesan harus menunggu ACK dari disk lintas negara untuk mencapai kuorum. Throughput sistem akan turun dari ribuan pesan per detik menjadi hanya belasan pesan per detik.
  3. Partisi Jaringan Konstan: Koneksi internet internasional yang rentan mati sesaat akan memicu alarm partisi jaringan secara konstan, memaksa node masuk ke status pause_minority berulang kali.

Solusi Praktis: Menggunakan Kluster Lokal dengan Federasi Pesan #

Solusi terbaik adalah menjaga kluster RabbitMQ tetap berada di dalam satu wilayah geografis (Availability Zone lokal) dengan latensi LAN yang stabil. Untuk menghubungkan dua wilayah yang berbeda, kita harus menggunakan plugin Federation atau Shovel yang meretransmisikan pesan lintas WAN secara asinkron tanpa memblokir performa kluster lokal.

flowchart LR
    subgraph RegionJKT ["Region Jakarta (LAN)"]
        direction TB
        NodeJ1[Node 1] <--> NodeJ2[Node 2]
    end
    
    subgraph RegionSIN ["Region Singapura (LAN)"]
        direction TB
        NodeS1[Node 1] <--> NodeS2[Node 2]
    end
    
    RegionJKT -->|"Federation Plugin (Asinkron / WAN)"| RegionSIN

Ringkasan #

  • Single Point of Failure — Kerentanan utama pada setup Single Node di mana kegagalan server fisik akan melumpuhkan seluruh sistem pesan meskipun data tersimpan di disk.
  • Quorum Queues (Raft) — Standar replikasi modern RabbitMQ yang menjamin ketersediaan data secara konsisten melalui mayoritas suara disk-write ($N/2 + 1$).
  • pause_minority Strategy — Kebijakan terbaik penanganan partisi jaringan untuk melindungi konsistensi data dari risiko split-brain dengan menonaktifkan node minoritas.
  • LAN Cluster Dependency — Batasan fisik kluster RabbitMQ yang mengharuskan koneksi antar-node berada di jaringan lokal berlatensi rendah untuk mencegah kegagalan konsensus Raft.

← Sebelumnya: Broker & Node   Berikutnya: Erlang VM →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact