Belajar RabbitMQ - Federation & Shovel

#Pendahuluan

Sejauh ini semua berada di dalam satu cluster — satu kumpulan node yang berbagi metadata dan cookie. Tapi dunia nyata punya kebutuhan yang lebih jauh: broker di region Jakarta dan Singapore yang harus saling bertukar pesan, atau broker on-premise yang mengirim data ke cloud. Menghubungkan broker yang terpisah inilah tugas Federation dan Shovel.

Kedua plugin ini membawa RabbitMQ keluar dari satu cluster dan menjadi jaringan broker. Federation menarik pesan dari exchange atau queue upstream ke downstream secara kontinu. Shovel memindahkan pesan dari satu titik ke titik lain — antar broker, antar vhost, bahkan antar cluster — seperti pipa yang andal.

Episode ini menjelaskan cara kerja keduanya, kapan memakai yang mana, dan bagaimana merancang topologi multi-datacenter serta pola transfer pesan yang tahan terhadap kegagalan jaringan WAN.

#Federation Plugin

#Federating Exchange dan Queue

Federation bekerja dengan model upstream-downstream: broker downstream menarik pesan dari broker upstream. Untuk exchange, downstream membuat "link" yang memblokir pesan dari exchange upstream dan mem-broadcast ke queue lokal yang ter-binding. Untuk queue, downstream menarik pesan dari queue upstream.

Kelebihan Federation: pesan di-consume lokal, dan link terus berjalan — jika upstream mati, link akan mencoba lagi secara otomatis saat pulih.

#Mengonfigurasi Federation

Aktifkan plugin, definisikan upstream, lalu set policy:

rabbitmq-plugins enable rabbitmq_federation
rabbitmqctl set_parameter federation-upstream dc-sg \
  '{"uri":"amqp://arman:pass@broker-sg:5672","expires":3600000}'

Lalu terapkan policy yang menentukan exchange mana yang di-federate:

rabbitmqctl set_policy federation-orders '^orders\.' \
  '{"federation-upstream-set":"dc-sg"}' --apply-to exchanges

Perintah set_policy di atas membuat semua exchange berawalan orders. di-federate ke upstream dc-sg.

#Federating Queues dan Memantau Link

Federation tidak hanya untuk exchange; queue juga bisa di-federate dengan --apply-to queues. Downstream akan menarik pesan dari queue upstream yang namanya cocok dengan pola:

rabbitmqctl set_policy federation-q '^notif\.' \
  '{"federation-upstream-set":"dc-sg"}' --apply-to queues

Untuk memastikan link berjalan sehat, periksa status tiap link:

rabbitmqctl list_federation_links status

list_federation_links menampilkan setiap link beserta status dan pesan terakhirnya. Link yang gagal akan menunjukkan error yang bisa ditelusuri — biasanya kredensial salah atau upstream tidak bisa dijangkau.

#Use Cases: Multi-Datacenter dan Geo-Distribution

Federation cocok untuk: replikasi topologi antar region, konsumsi lokal di setiap DC agar latency rendah, dan distribusi data ke cabang regional. Karena downstream yang menarik, kalian bisa mengendalikan kapan dan berapa banyak yang disinkronkan.

#Shovel Plugin

#Forwarding Point-to-Point

Shovel memindahkan pesan dari source (queue atau exchange) ke destination (exchange atau queue) — bisa antar vhost, antar broker, atau antar cluster. Berbeda dari Federation, Shovel lebih presisi: kalian menentukan persis sumber dan tujuannya.

#Static Shovel via Konfigurasi

Shovel statis didefinisikan di rabbitmq.conf:

shovels.migrate-orders = [
  {source, [{uris, ["amqp://src-host:5672"]}, {queue, "orders.queue"}]},
  {destination, [{uris, ["amqp://dst-host:5672"]}, {queue, "orders.import"}]}
]

Shovel di atas memindahkan pesan dari queue orders.queue di broker sumber ke queue orders.import di broker tujuan.

#Dynamic Shovel via Management UI

Shovel dinamis dikelola lewat Management UI atau API tanpa restart — ideal untuk pengaturan sementara seperti migrasi. Di UI: tab Admin > Shovels > Add a shovel, isi source dan destination, lalu aktifkan.

#Konfigurasi Lanjutan Shovel

Dua parameter penting untuk transfer yang andal di jaringan lambat: ack_mode dan reconnect_delay:

shovels.reliable = [
  {source, [{uris, ["amqp://src-host:5672"]}, {queue, "jobs.queue"}]},
  {destination, [{uris, ["amqp://dst-host:5672"]}, {queue, "jobs.import"}]},
  {ack_mode, on_confirm},
  {reconnect_delay, 5}
]

ack_mode=on_confirm membuat shovel hanya menghapus pesan dari sumber setelah destination mengonfirmasi penerimaan — menjamin tidak ada pesan yang hilang di tengah jalan. reconnect_delay=5 menyetel jeda detik sebelum mencoba ulang koneksi yang putus. Kombinasi keduanya membuat shovel tahan terhadap fluktuasi jaringan WAN.

#Shovel vs Federation dan WAN

#Perbandingan dan Pemilihan

• Federation — replikasi terus-menerus untuk banyak exchange/queue, downstream menarik pesan, sinkronisasi searah.
• Shovel — pemindahan pesan yang terkontrol dan presisi, cocok untuk migrasi, satu-off forwarding, dan topologi khusus.

Aturan praktis: butuh sinkronisasi berkelanjutan antar cluster? Pakai Federation. Butuh memindahkan pesan dari satu titik ke titik tertentu, misalnya migrasi data? Pakai Shovel.

#Koneksi WAN yang Andal

Koneksi antar broker yang melintasi WAN menghadapi latency tinggi dan putus-putus. Kedua plugin menangani ini dengan koneksi ulang otomatis dan buffer internal. Untuk topologi multi-DC, pertimbangkan data locality: consumer membaca dari broker terdekat (downstream), bukan memanggil upstream melewati WAN setiap kali.

Jangan lupa memantau panjang buffer internal link: jika downstream lebih lambat dari upstream, buffer akan tumbuh dan menambah latency — sinyal bahwa downstream perlu diskalakan atau laju publish ditekan. Latency WAN tidak bisa dihapus, tapi bisa dikelola dengan konfigurasi yang tepat.

#Penutup

Di episode 26 ini kalian sudah mereplikasi exchange dan queue antar cluster dengan Federation, memindahkan pesan point-to-point dengan Shovel statis dan dinamis, membandingkan kapan memakai keduanya, serta merancang koneksi WAN yang andal untuk topologi multi-datacenter.

Inti yang harus dibawa pulang:

• Federation memakai model upstream-downstream; downstream yang menarik.
• Federation cocok untuk replikasi berkelanjutan antar region.
• Shovel memindahkan pesan dari satu titik ke titik lain secara presisi.
• Shovel statis didefinisikan di konfigurasi; dinamis via Management UI.
• Federation untuk sinkronisasi, Shovel untuk migrasi dan forwarding.
• Keduanya mendukung koneksi ulang otomatis di jaringan WAN.
• Prioritaskan data locality agar consumer membaca dari broker terdekat.

Di episode 27 selanjutnya kita akan membuka multi-protocol support — mengaktifkan plugin MQTT untuk IoT, STOMP untuk browser, dan WebSockets untuk messaging real-time, memahami pemetaan QoS level dan pola Web-STOMP serta SockJS. Satu RabbitMQ, banyak protokol di pintu yang berbeda!