RabbitMQ untuk Antrean Pesan, Kapan Aplikasi Butuh?

Tokomu sedang ramai. Setiap pesanan memicu beberapa pekerjaan: mengirim email konfirmasi, membuat invoice PDF, mengurangi stok, dan memberi tahu gudang lewat WhatsApp. Kalau semua dikerjakan saat pembeli menekan tombol bayar, halaman jadi lambat. Kalau server email sedang bermasalah, pesanan bisa ikut gagal. Di titik inilah orang mulai mendengar istilah antrean pesan dan nama RabbitMQ.

RabbitMQ adalah perantara pesan (message broker) sumber terbuka. Aplikasi menitipkan pesan berisi tugas, RabbitMQ menyimpannya di antrean, lalu worker mengambil dan mengerjakannya di latar belakang. Pengirim tidak perlu menunggu tugas selesai, dan tugas tidak hilang hanya karena satu worker sedang mati. Pertanyaannya, apakah aplikasimu benar-benar butuh RabbitMQ, atau cukup dengan sesuatu yang lebih sederhana?

Cara kerja RabbitMQ dalam bahasa sederhana

Ada empat istilah yang perlu kamu kenal. Producer adalah aplikasi yang mengirim pesan. Exchange adalah pintu masuk yang memutuskan pesan diteruskan ke antrean mana. Queue adalah antrean tempat pesan menunggu. Consumer adalah worker yang mengambil pesan dari antrean.

Kekuatan RabbitMQ ada di exchange. Exchange jenis direct meneruskan pesan berdasarkan kunci yang persis sama, fanout menyalinnya ke semua antrean yang terhubung, dan topic memakai pola seperti pesanan.*.dibayar. Dengan begitu satu kejadian, misalnya "pesanan dibayar", bisa sekaligus memicu worker email, worker invoice, dan worker gudang tanpa aplikasi utama tahu siapa saja yang mendengarkan.

Pesan juga punya mekanisme konfirmasi (acknowledgement). Worker baru menyatakan pesan selesai setelah tugasnya benar-benar berhasil. Kalau worker mati di tengah jalan sebelum konfirmasi, RabbitMQ mengirim ulang pesan itu ke worker lain. Inilah yang membuat tugas penting tidak menguap.

Tanda aplikasi mulai butuh antrean pesan

Tidak semua aplikasi perlu RabbitMQ. Tabel berikut membantu membandingkan pilihan yang umum dipakai.

Kalau aplikasimu satu kode Laravel, Django, atau Node.js dengan beberapa tugas latar, antrean di database atau Redis umumnya sudah lebih dari cukup. Framework populer menyediakan driver untuk keduanya. Redis bahkan mungkin sudah kamu pakai untuk cache, seperti dibahas di cara pasang Redis untuk cache aplikasi.

RabbitMQ mulai masuk akal ketika sistem terdiri dari beberapa layanan yang dikembangkan terpisah, satu kejadian perlu sampai ke banyak penerima dengan aturan yang berbeda, atau tim butuh fitur seperti antrean pesan gagal (dead letter), prioritas, dan pengaturan ulang kirim tanpa membangunnya sendiri. Alat otomasi juga memakai pola serupa. n8n, misalnya, memakai Redis untuk membagi eksekusi ke beberapa worker, dijelaskan di n8n queue mode.

Nama lain yang sering muncul adalah Apache Kafka. Keduanya kerap disandingkan, padahal cara pandangnya berbeda. Kafka menyimpan pesan sebagai log yang bisa dibaca ulang oleh banyak pembaca dari posisi mana pun, cocok untuk aliran data bervolume sangat besar seperti catatan aktivitas atau analitik. RabbitMQ lebih condong ke pembagian tugas: pesan diantar ke penerima yang tepat, dikerjakan, lalu dihapus dari antrean. Untuk pekerjaan latar di aplikasi bisnis, pola RabbitMQ biasanya lebih dekat dengan kebutuhan.

Apa yang berubah di RabbitMQ 4?

Kalau kamu membaca tutorial lama, kamu akan menemukan istilah "mirrored queue" untuk membuat antrean tetap hidup di beberapa node. Fitur itu sudah dihapus di RabbitMQ 4.0, sesuai catatan rilis resminya. Antrean klasik masih ada, tapi kini tidak direplikasi. Untuk antrean yang harus bertahan saat satu node mati, RabbitMQ mengarahkan pemakainya ke quorum queue, jenis antrean yang direplikasi dengan algoritma konsensus, atau ke stream untuk pola baca ulang pesan.

Untuk server tunggal, perbedaan ini tidak terlalu berpengaruh. Tapi bila kamu merencanakan klaster, rancang sejak awal dengan quorum queue agar tidak perlu migrasi belakangan. Pengaturan lama yang berkaitan dengan mirroring juga sebaiknya dibersihkan sebelum upgrade dari seri 3.x.

Hal yang wajib disiapkan sebelum produksi

Pertama, keamanan akses. User bawaan guest hanya bisa login dari localhost, dan memang sebaiknya begitu. Buat user sendiri dengan password kuat dan izin per virtual host. Jangan buka port AMQP (5672) dan panel manajemen (15672) ke internet. Batasi dengan firewall hanya untuk server aplikasi, atau akses panel lewat SSH tunnel. Prinsipnya sama dengan mengunci layanan data lain, seperti dibahas di cara mengunci Redis dan MongoDB agar tidak terbuka publik.

Kedua, ketahanan pesan. Antrean perlu dideklarasikan durable dan pesan dikirim sebagai persisten bila tidak boleh hilang saat RabbitMQ di-restart. Worker sebaiknya memakai konfirmasi manual, bukan otomatis, supaya pesan baru dianggap selesai setelah tugas berhasil. Karena pesan bisa dikirim ulang saat worker mati sebelum konfirmasi, rancang tugasnya agar aman bila dijalankan dua kali. Contohnya, sebelum mengirim email konfirmasi, worker memeriksa dulu apakah email untuk pesanan itu sudah tercatat terkirim.

Ketiga, pemantauan. Antrean yang terus memanjang adalah tanda worker kalah cepat atau sedang mati. Pantau jumlah pesan yang menunggu, jumlah consumer aktif, pemakaian memori, dan ruang disk. RabbitMQ akan menahan producer bila memori atau disk melewati ambang batasnya, sehingga aplikasi pengirim bisa ikut tersendat.

Keempat, sumber daya server. RabbitMQ berjalan di atas Erlang dan menyimpan pesan di memori serta disk. Untuk beban kecil sampai menengah, ia bisa berbagi VPS dengan aplikasi. Saat volumenya besar, pisahkan ke server sendiri supaya lonjakan antrean tidak mengganggu aplikasi utama.

Pada akhirnya, antrean pesan adalah alat untuk memisahkan pekerjaan lambat dari permintaan pengguna dan membuat tugas penting tidak hilang. Mulailah dari yang paling sederhana yang memenuhi kebutuhan, lalu pindah ke RabbitMQ ketika jumlah layanan, pola pengiriman, atau tuntutan keandalan memang sudah melampaui kemampuan antrean berbasis Redis atau database.