ApsaraMQ for RabbitMQ menyediakan layanan perpesanan yang sangat tersedia dan kompatibel dengan RabbitMQ, serta mendukung protokol AMQP 0-9-1. SLA produk ini menjamin ketersediaan layanan dari sisi platform, yang tidak setara dengan ketersediaan end-to-end sebesar 100% untuk bisnis Anda.
SLA produk dan ketersediaan bisnis
Berdasarkan Perjanjian Tingkat Layanan (SLA) resmi ApsaraMQ for RabbitMQ, ketersediaan layanan diukur per instans berdasarkan kalender bulanan. Komitmen garis dasar dalam perjanjian saat ini adalah tidak kurang dari 99,95%. Dalam bulan kalender 30 hari, angka tersebut setara dengan sekitar 21,6 menit ketidakterjangkauan sebagaimana didefinisikan dalam perjanjian. Nilai ini hanya mencerminkan metrik SLA dan tidak menentukan jendela kegagalan yang dapat diterima untuk bisnis Anda. Perhitungan aktual mengacu pada definisi ketidakterjangkauan layanan, pengecualian, serta perjanjian yang berlaku pada saat pembelian.
Ketersediaan bisnis juga dipengaruhi oleh rekoneksi client, kondisi jaringan dan DNS, penerapan aplikasi, kapasitas pemrosesan konsumsi, kemampuan pemrosesan idempoten, bencana lintas wilayah (cross-region), siklus hidup versi, dan konfigurasi spesifik pelanggan. Jika tujuan kelangsungan bisnis Anda melebihi SLA satu instans, Anda harus membangun kemampuan multi-instans, multi-wilayah, failover, dan idempotensi pesan baik di sisi aplikasi maupun arsitektur sumber daya.
Metrik SLA dapat bervariasi berdasarkan tipe instans atau spesifikasi. Hak spesifik mengacu pada halaman pembelian, situs resmi Alibaba Cloud, dan perjanjian yang berlaku pada saat pembelian. Solusi multi-instans tidak menciptakan SLA produk baru, dan Anda tidak dapat mengalikan SLA dua instans. Ketersediaan bisnis bergantung pada isolasi kesalahan, sinkronisasi pesan, failover client, dan efektivitas latihan simulasi (drill).
Batasan arsitektur
ApsaraMQ for RabbitMQ kompatibel dengan protokol AMQP 0-9-1 dan menggunakan arsitektur multi-node terkelola di sisi server. Metode akses seperti titik akhir publik (public endpoint), VPC, dan titik akses koneksi jaringan pribadi PrivateLink mengacu pada Konsol dan dokumentasi resmi.
ApsaraMQ for RabbitMQ meningkatkan ketersediaan instans melalui kemampuan multi-node dan multi-zona. Sisi server menggunakan beberapa node untuk menangani koneksi dan permintaan. Ketika satu node atau zona di sisi server mengalami anomali, kemampuan multi-node membantu mengurangi dampak terhadap ketersediaan instans. Kemampuan spesifik mengacu pada tipe instans, wilayah, dan halaman pembelian.
Koneksi client ditangani pada tingkat granularitas Connection. Membuat beberapa Connection berumur panjang (long-lived) mendistribusikan trafik lebih merata di beberapa node, tetapi tidak menjamin bahwa setiap Connection mendarat di node yang berbeda. Membuat beberapa Channel pada satu Connection AMQP meningkatkan multiplexing konkuren dalam Connection tersebut, tetapi tidak dapat menggantikan distribusi node server-level berbasis Connection. Untuk workload berkonkurensi tinggi atau mission-critical, buat beberapa Connection berumur panjang dan distribusikan produsen serta konsumen di seluruh kolam koneksi (connection pool) untuk menghindari konsentrasi seluruh trafik pada satu atau beberapa Connection saja.
Skenario berikut tidak ditangani oleh arsitektur single-instance:
Kegagalan tingkat wilayah (region-level failures), kegagalan jaringan lintas wilayah (cross-region network failures), atau anomali VPC, DNS, atau security group di sisi pelanggan
Client yang belum dikonfigurasi untuk rekoneksi otomatis, pembuatan ulang Channel, atau resubskripsi konsumen
Client yang hanya menggunakan beberapa Connection berumur panjang, sehingga trafik tidak cukup tersebar di node sisi server
Pemrosesan konsumen lambat, kegagalan pemrosesan bisnis, backlog pesan, atau throttling akibat kuota terlampaui
Kurangnya pemrosesan idempoten, yang menyebabkan konsumsi duplikat, pengiriman tidak sesuai urutan, atau efek samping bisnis selama failover atau replay
Penyempurnaan sisi client
Tidak peduli solusi penerapan mana yang Anda pilih, pastikan implementasi client Anda memenuhi persyaratan berikut. Untuk panduan lengkap, lihat catatan penggunaan SDK dan praktik terbaik penggunaan client Spring Boot.
Rekoneksi otomatis — Bangun ulang Connection secara otomatis setelah terputus. Bergantung pada SDK yang Anda gunakan, verifikasi kemampuan pemulihan topologi dan konsumen. Untuk informasi lebih lanjut, lihat Konfigurasikan rekoneksi otomatis untuk client.
Beberapa Connection untuk distribusi trafik — Konfigurasikan beberapa Connection berumur panjang berdasarkan konkurensi produksi dan konsumsi serta kuota Connection instans. Gunakan Connection terpisah untuk produksi dan konsumsi. Jangan konsentrasikan seluruh produksi dan konsumsi pada satu Connection, dan hindari sering membuat serta menutup Connection. Untuk rekomendasi umum, lihat Connections and channels. Untuk client Spring, lihat praktik terbaik penggunaan client Spring Boot.
Pembuatan ulang Channel — Channel RabbitMQ bukanlah resource permanen. Jika terjadi exception protokol, konflik deklarasi resource, atau throttling, bangun ulang Channel tersebut. Untuk konflik deklarasi resource, perbaiki parameter deklarasi terlebih dahulu. Pada skenario throttling, terapkan backoff dan load shedding sebelum membangun ulang untuk menghindari loop pembuatan ulang. Channel dapat menggunakan kembali Connection, tetapi tidak dapat menggantikan distribusi node server-level berbasis Connection. Untuk informasi lebih lanjut, lihat praktik terbaik untuk throttling instans.
Pemulihan konsumen — Setelah rekoneksi, bangun ulang langganan konsumen dengan memulihkan
basic.consumedan callback konsumen. Verifikasi bahwa perilaku pemulihan Queue eksklusif, Consumer Tag, dan resource lainnya setelah rekoneksi sesuai ekspektasi Anda.Publisher Confirm — Gunakan Publisher Confirm di sisi produksi untuk menentukan apakah server telah menerima dan bertanggung jawab atas pesan tersebut. Publisher Confirm tidak berarti bahwa konsumen telah memproses pesan tersebut. Saat konfirmasi timeout atau tidak diakui, lakukan retry dengan ID pesan bisnis yang sama mengikuti aturan idempoten.
ACK dan retry konsumen — Kirim ACK hanya setelah pemrosesan bisnis berhasil. Jika gagal, lakukan reject, nack, retry terbatas, atau arahkan ke dead letter queue sesuai strategi bisnis Anda. Hindari requeue tak terbatas yang menciptakan loop retry.
Pemrosesan idempoten — Produksi, routing, failover, dan replay semuanya dapat menghasilkan pesan duplikat. Produsen harus mempertahankan ID pesan bisnis yang stabil untuk pesan bisnis yang sama, dan konsumen harus melakukan deduplikasi berdasarkan ID bisnis. Untuk informasi lebih lanjut, lihat Message idempotence.
Throttling dan circuit breaking — Saat instans mengalami anomali atau downstream tidak sehat, produsen harus melakukan throttling dan menerapkan backoff dengan batas maksimum retry untuk menghindari amplifikasi retry, backlog, dan kegagalan berantai. Untuk informasi lebih lanjut, lihat praktik terbaik untuk throttling instans.
Refresh alamat akses — Jika Anda mengganti instans melalui pusat konfigurasi atau nama domain yang dikelola pelanggan, client harus mendukung refresh alamat akses untuk menghindari penggunaan alamat lama secara terus-menerus. Saat menggunakan nama domain yang dikelola pelanggan, verifikasi TTL DNS, caching DNS client atau JVM, serta perilaku verifikasi hostname TLS.
Solusi yang direkomendasikan
Bagian berikut menjelaskan empat solusi penerapan pada tingkat ketersediaan yang meningkat. Tabel berikut merangkum setiap solusi untuk membantu Anda memilih yang paling sesuai dengan workload Anda. Selain pertimbangan spesifik solusi, pastikan client Anda memenuhi persyaratan yang dijelaskan dalam Penyempurnaan sisi client.
Untuk workload yang memerlukan stabilitas lebih tinggi, isolasi resource, atau prediktabilitas kapasitas, pilih Platinum Edition atau Serverless Exclusive Edition. Kemampuan spesifik dan ketentuan SLA mengacu pada deskripsi tipe instans dan halaman pembelian.
Solusi | Cakupan penerapan | Prasyarat utama | Keterbatasan utama |
Baseline single-instance | Jalur non-kritis dengan persyaratan RTO/RPO yang longgar | Rekoneksi client, pemantauan, dan alerting | Hanya SLA platform berdasarkan tipe instans |
Standby dual-instans dalam satu wilayah | Workload inti yang memerlukan pemulihan kegagalan tingkat instans dalam satu wilayah | Pusat konfigurasi, sinkronisasi pesan, dan pemrosesan idempoten | Tidak menggantikan pemulihan bencana lintas wilayah |
Primary-standby lintas wilayah | Workload yang memerlukan perlindungan terhadap kegagalan tingkat wilayah | Instans lintas wilayah, routing pesan, serta kondisi RTO/RPO dan switchback yang ditentukan | Tidak ada failover transparan secara default |
Aktif-aktif | Workload dengan pemrosesan idempoten, deduplikasi, dan resolusi konflik yang matang | ID pesan global, strategi deduplikasi, dan resolusi konflik | Tidak direkomendasikan sebagai solusi default |
Solusi baseline single-instance
Solusi ini berlaku untuk jalur non-kritis, workload yang dapat mentoleransi ketidakterjangkauan singkat, dan skenario dengan persyaratan RTO dan RPO yang longgar.
Pertimbangan desain utama
Berdasarkan tipe instans dan batasan, pilih spesifikasi instans yang memenuhi kebutuhan bisnis Anda untuk TPS, Queue, Connection, ukuran pesan, dan periode retensi.
Aktifkan rekoneksi Connection otomatis di sisi client, dan pastikan client memiliki kemampuan pembuatan ulang Channel dan pemulihan konsumen.
Buat beberapa Connection AMQP berumur panjang per instans aplikasi berdasarkan konkurensi bisnis, dan distribusikan trafik produksi dan konsumsi melalui connection pool. Jangan bawa seluruh trafik pada satu Connection lalu hanya menambah jumlah Channel.
Konfigurasikan Publisher Confirm, ACK konsumen, retry timeout, dead letter queue, dan alert.
Lakukan peningkatan versi instans sesuai kebijakan resmi manajemen versi dan notifikasi peningkatan. Jangan menjalankan versi yang sudah kedaluwarsa atau berakhir masa pemeliharaannya dalam jangka waktu lama.
Konfigurasikan alert untuk metrik utama termasuk jumlah koneksi, throughput kirim dan konsumsi, kode kesalahan, backlog Queue, latensi konsumsi, dan throttling berdasarkan Pemantauan Peringatan.
Risiko dan keterbatasan
Solusi single-instance hanya menyediakan SLA produk sesuai tipe instans, yang tidak setara dengan ketersediaan 100% di sisi bisnis.
Jika bisnis Anda tidak dapat mentoleransi jendela kegagalan satu instans, tingkatkan ke solusi pemulihan bencana multi-instans.
Solusi standby dual-instans dalam satu wilayah
Solusi ini berlaku untuk workload inti yang perlu meningkatkan pemulihan kegagalan tingkat instans dalam satu wilayah, tetapi tidak memerlukan pemulihan bencana lintas wilayah.
Ikhtisar arsitektur
Pertimbangan desain utama
Beli dua instans RabbitMQ dalam satu wilayah. Konfigurasi dual-instans dalam satu wilayah tidak menggantikan pemulihan bencana lintas wilayah.
Pastikan Vhost, Exchange, Queue, Binding, izin akun, dan kebijakan akses jaringan instans primary dan standby secara fungsional setara. (Direkomendasikan) Kelola resource melalui konfigurasi otomatis atau deklarasi startup aplikasi untuk menghindari deviasi konfigurasi. Kelola kredensial untuk instans primary dan standby secara terpisah, dan rotasi sesuai kebijakan keamanan Anda.
Opsi sinkronisasi pesan:
Dual-write aplikasi — Produsen menulis ke instans primary dan standby secara simultan. Dual-write aplikasi dapat mengurangi celah data akibat kegagalan penulisan jalur tunggal, tetapi tidak memberikan jaminan atomicity lintas instans. Tangani keberhasilan parsial, timeout konfirmasi, retry idempoten, dan kompensasi.
Routing pesan global — Gunakan routing pesan global untuk meneruskan pesan secara asinkron dari Queue sumber di instans primary ke Queue atau Exchange di instans standby. Metode ini memiliki latensi sinkronisasi, dan RPO bergantung pada backlog routing dan kondisi jaringan. Dukungan fitur mengacu pada deskripsi tipe instans dan Konsol.
Routing pesan global mengonsumsi dari Queue sumber dan meneruskan pesan ke target. Ini bukan replikasi sidecar dari Queue sumber. Jangan langsung menggunakan kembali Queue yang sedang dikonsumsi aktif oleh konsumen bisnis sebagai sumber routing. Bind Exchange sumber ke Queue bisnis dan Queue sinkronisasi pemulihan bencana khusus, lalu gunakan Queue khusus tersebut sebagai sumber routing. Untuk semantik, lihat routing pesan global dan RabbitMQ Shovel.
Jika tipe target routing pesan global diatur ke Exchange, verifikasi bahwa Exchange target memiliki Queue yang terikat dan dapat menyimpan pesan. Jika tidak, pesan yang dirutekan ke Exchange tersebut dapat hilang jika tidak ada Queue yang tersedia untuk menerimanya.
Konsumen secara default hanya mengonsumsi dari instans primary. Selama failover, mulai atau tingkatkan skala konsumen di instans standby dan hindari konsumsi simultan dari aliran bisnis yang sama oleh primary dan standby untuk mencegah efek samping duplikat.
Implementasikan pemrosesan idempoten berdasarkan ID pesan bisnis, sehingga memungkinkan pengiriman duplikat atau kompensasi setelah failover.
Prosedur failover yang direkomendasikan
Konfirmasi melalui pemantauan bahwa instans primary tidak tersedia atau mengalami anomali performa yang memengaruhi operasi kirim atau konsumsi bisnis, dan belum pulih dalam jendela yang diharapkan.
Jeda, throttle, atau turunkan kualitas penulisan di sisi produksi sesuai rencana darurat bisnis Anda untuk mencegah celah data primary-standby melebar selama jendela kegagalan.
Beralih ke instans standby melalui pusat konfigurasi atau konfigurasi alamat akses aplikasi. Jika Anda menggunakan DNS yang dikelola pelanggan, verifikasi bahwa caching DNS dan verifikasi TLS tidak menghalangi failover.
Mulai konsumen di instans standby atau tingkatkan bobot konsumsi instans standby.
Pantau tingkat keberhasilan pengiriman, laju konsumsi, backlog Queue, dan tingkat keberhasilan bisnis.
Setelah instans primary pulih, lakukan rekonsiliasi, kompensasi, dan deduplikasi berdasarkan catatan kirim dan konsumsi bisnis, metrik backlog, dan ID pesan bisnis sebelum beralih kembali melalui proses perubahan terkendali.
Solusi pemulihan bencana primary-standby lintas wilayah
Solusi ini berlaku untuk workload inti yang perlu dilindungi dari kegagalan tingkat wilayah, atau workload yang secara inheren diterapkan lintas wilayah.
Ikhtisar arsitektur
Pertimbangan desain utama
Buat instans RabbitMQ di dua wilayah terpisah. Pastikan topologi, izin akun, dan kebijakan akses jaringan secara fungsional setara. Kelola kredensial secara terpisah untuk setiap instans.
Gunakan routing pesan global, dual-write aplikasi, atau mekanisme Outbox bisnis untuk menyinkronkan pesan kritis. Dukungan fitur routing pesan global mengacu pada deskripsi tipe instans dan Konsol.
Saat menggunakan routing pesan global, terapkan desain Queue sinkronisasi pemulihan bencana khusus yang sama seperti solusi dalam satu wilayah untuk menghindari persaingan dengan konsumen bisnis atas Queue sumber.
Jika tipe target routing pesan global diatur ke Exchange, verifikasi bahwa Exchange target memiliki Queue yang terikat dan dapat menyimpan pesan.
Saat menggunakan routing pesan global, evaluasi biaya EventBridge dan Cloud Enterprise Network (CEN), latensi sinkronisasi pesan, dan backlog routing. Saat menggunakan dual-write aplikasi atau Outbox, rencanakan secara terpisah untuk jaringan client, titik akses, daftar putih, biaya tautan, dan pendekatan failover.
Batas ukuran pesan di target harus tidak kurang dari batas di sumber. Pesan yang melebihi batas target mungkin gagal dirutekan.
Routing pesan global tidak mendukung routing transitif. Rute dari A ke B ke C tidak secara otomatis meneruskan pesan dari A melalui B ke C. Jika Anda memerlukan routing A-ke-C, konfigurasikan rute langsung A-ke-C.
Pemulihan bencana lintas wilayah tidak boleh mengasumsikan failover sepenuhnya transparan secara default. Definisikan secara jelas RTO, RPO, pihak yang menyetujui failover, kondisi switchback, dan mekanisme kompensasi data.
Solusi aktif-aktif
Solusi ini berlaku untuk workload yang telah memiliki kemampuan pemrosesan idempoten, deduplikasi, resolusi konflik, dan konsistensi akhir yang kuat, serta di mana kedua wilayah atau instans perlu menangani trafik secara simultan. Aktif-aktif merupakan desain arsitektur aplikasi pelanggan dan tidak berarti produk secara otomatis menyediakan kemampuan aktif-aktif lintas instans atau konsistensi global.
Pertimbangan desain utama
Produsen harus menggunakan ID pesan bisnis unik global yang tetap stabil selama retry.
Konsumen harus mengimplementasikan pemrosesan idempoten dan deduplikasi berdasarkan kunci primer bisnis. Jangan mengandalkan delivery count RabbitMQ sebagai satu-satunya sumber kebenaran.
Definisikan secara jelas jalur tulis utama dan arah sinkronisasi untuk setiap pesan guna menghindari loop sinkronisasi dua arah atau amplifikasi duplikasi.
Definisikan secara jelas batasan semantik pengurutan. Aktif-aktif lintas instans biasanya tidak memberikan jaminan pengurutan ketat global.
Definisikan secara jelas strategi resolusi konflik, termasuk pembayaran duplikat, pesanan duplikat, pengurangan inventaris, dan efek samping bisnis lainnya.
Pertahankan kemampuan drill berkelanjutan dan rekonsiliasi otomatis.
Risiko dan keterbatasan
Aktif-aktif tidak direkomendasikan sebagai solusi default. Sebagian besar workload sebaiknya memilih primary-standby atau degradasi bertingkat untuk menghindari penurunan stabilitas akibat kompleksitas.
Latihan simulasi dan kriteria penerimaan
Sebelum meluncurkan solusi pemulihan bencana multi-instans, selesaikan setidaknya latihan simulasi berikut:
Item latihan simulasi | Tujuan verifikasi |
Kegagalan akses instans primary | Client melakukan failover ke instans standby sesuai ekspektasi. RTO memenuhi target. |
Kegagalan pengiriman instans primary | Produsen mengidentifikasi kegagalan dan melakukan retry atau kompensasi tanpa duplikasi tak terkendali. |
Distribusi multi-koneksi | Instans aplikasi membuat beberapa Connection berumur panjang sesuai konfigurasi. Setelah restart atau failover, connection pool pulih dan trafik tidak tetap terkonsentrasi pada satu Connection. |
Restart konsumen | Aplikasi membangun ulang Channel dan membangun kembali langganan konsumen. |
Latensi routing pesan global | Backlog Queue sumber khusus, aliran masuk target, dan latensi sinkronisasi dapat diamati. |
Pengambilalihan konsumsi instans standby | Konsumen instans standby memproses pesan yang ada setelah startup. Idempotensi bisnis efektif. |
Switchback ke instans primary | Rekonsiliasi bisnis, kompensasi, deduplikasi, dan switchback canary berhasil diselesaikan. |
Metrik berikut menentukan kriteria penerimaan untuk solusi pemulihan bencana Anda:
RTO — Waktu sejak bisnis terdampak atau kondisi failover terpenuhi hingga pemulihan bisnis.
RPO — Rentang maksimum pesan yang mungkin hilang atau memerlukan kompensasi selama jendela kegagalan.
Tingkat duplikasi — Persentase pesan duplikat selama failover dan replay serta dampaknya terhadap bisnis.
Waktu pemulihan backlog — Waktu yang dibutuhkan agar backlog Queue kembali ke level normal setelah failover.
Tingkat keberhasilan pemulihan client — Tingkat keberhasilan rekoneksi Connection, pembuatan ulang Channel, dan resubskripsi konsumen.
Distribusi koneksi — Setelah restart aplikasi, skala keluar, atau failover, trafik produksi dan konsumsi terus didistribusikan di beberapa Connection berumur panjang. Hindari penggunaan jangka panjang hanya satu Connection.