Simple Message Queue (SMQ, sebelumnya MNS) menawarkan migrasi data yang mulus dari layanan seperti AWS Simple Queue Service (SQS) atau AWS Simple Notification Service (SNS). Topik ini menjelaskan perbedaan antara SMQ, Amazon SQS, dan Amazon SNS berdasarkan fitur, batasan, dan SDK, serta memandu Anda melalui proses migrasi data dari Amazon SQS atau Amazon SNS ke SMQ.
Informasi latar belakang
SMQ, Amazon SQS, dan Amazon SNS memiliki kemampuan messaging yang serupa:
SMQ menyediakan model pesan berbasis antrian dan model pesan berbasis topik.
Amazon SQS menyediakan model pesan berbasis antrian.
Amazon SNS menyediakan model pesan berbasis topik.
Karena layanan-layanan tersebut tumpang tindih dalam fungsionalitasnya, migrasi dari Amazon SQS atau Amazon SNS ke SMQ bersifat langsung. Bagian-bagian berikut membantu Anda memahami perbedaannya dan merencanakan migrasi Anda.
Prasyarat
Sebelum memulai migrasi, pastikan Anda telah menyelesaikan hal-hal berikut:
Akun Alibaba Cloud dengan SMQ yang telah diaktifkan. Untuk informasi lebih lanjut, lihat Aktifkan SMQ dan otorisasi Pengguna RAM untuk mengakses SMQ.
Inventarisasi antrian Amazon SQS dan topik Amazon SNS yang ada, termasuk konfigurasinya (periode retensi, timeout visibilitas, pengaturan penundaan, titik akhir subscription, dan kebijakan retry).
Kredensial akses untuk lingkungan AWS dan lingkungan Alibaba Cloud Anda.
Pemahaman yang jelas mengenai produsen dan konsumen pesan saat ini, sehingga Anda dapat merencanakan strategi dual-read dan dual-write.
Pemetaan konsep
Tabel berikut memetakan konsep utama antara Amazon SQS/Amazon SNS dan SMQ. Meskipun banyak fitur yang setara secara fungsional, perhatikan perbedaan perilaku yang tercantum pada kolom ketiga.
| Konsep AWS | Setara di SMQ | Perbedaan perilaku |
|---|---|---|
| SQS Standard Queue | Antrian SMQ (model pesan berbasis antrian) | Keduanya mendukung status pesan Active, Inactive, Deleted, dan Expired. SMQ memiliki timeout visibilitas default 30 detik; Amazon SQS tidak menentukan nilai default. |
| SQS FIFO Queue | Antrian FIFO SMQ (sequencing) | Keduanya didukung. |
| SQS Dead-letter Queue | Dead-letter Queue SMQ | Keduanya didukung. |
| Topik SNS | Topik SMQ (model pesan berbasis topik) | Nama topik SMQ tidak case-sensitive (1–120 karakter). Nama topik Amazon SNS case-sensitive (3–64 karakter). |
| Topik FIFO SNS | Topik FIFO SMQ (sequencing) | Keduanya didukung. |
| Subscription SNS (kebijakan filter JSON) | Subscription SMQ (penyaringan berbasis tag) | Penyaringan data berbeda: SMQ menggunakan penyaringan berbasis tag. Amazon SNS menggunakan penyaringan berbasis kebijakan JSON. Anda perlu mengonversi logika filter selama migrasi. |
| Titik akhir subscription SNS (Antrian, HTTP, SMS, Email, Mobile push, Lambda) | Titik akhir subscription SMQ (Antrian, HTTP, Text message, Email, Mobile push, Function Compute) | Amazon SNS terintegrasi dengan AWS Lambda; SMQ terintegrasi dengan Function Compute. |
| Dead-letter Queue SNS | Dead-letter Queue SMQ (model topik) | Keduanya didukung. |
Perbandingan fitur
Tabel berikut membandingkan fitur-fitur SMQ, Amazon SQS, dan Amazon SNS berdasarkan model pesan berbasis antrian dan model pesan berbasis topik.
Model pesan berbasis antrian
| Fitur | SMQ | Amazon SQS |
|---|---|---|
| Siklus hidup pesan | Didukung. Mesin keadaan pesan memiliki status berikut: Active, Inactive, Deleted, dan Expired. | Didukung. Mesin keadaan pesan memiliki status berikut: Active, Inactive, Deleted, dan Expired. |
| Periode retensi kustom untuk pesan | Didukung | Didukung |
| Penundaan pesan (periode terjadwal) | Didukung | Didukung |
| Periode timeout visibilitas | Didukung | Didukung |
| Panjang maksimum pesan | Didukung | Didukung |
| Dead-letter queue | Didukung | Didukung |
| Antrian FIFO (sequencing) | Didukung | Didukung |
Model pesan berbasis topik
| Fitur | SMQ | Amazon SNS |
|---|---|---|
| Penyaringan data | Penyaringan data berbasis tag | Penyaringan data berbasis kebijakan JSON |
| Subscription antrian | Didukung | Didukung |
| Langganan HTTP | Didukung | Didukung |
| Subscription text message | Didukung | Didukung |
| Subscription email | Didukung | Didukung |
| Mobile push | Didukung | Didukung |
| Function Compute | Didukung | Didukung |
| Dead-letter queue | Didukung | Didukung |
| Topik FIFO (sequencing) | Didukung | Didukung |
Perbandingan batasan
Tinjau batasan-batasan ini secara cermat karena beberapa perbedaan dapat memengaruhi rencana migrasi Anda. Tabel-tabel berikut membandingkan batasan SMQ, Amazon SQS, dan Amazon SNS berdasarkan model messaging.
Batasan model pesan berbasis antrian
| Batas | SMQ | Amazon SQS |
|---|---|---|
| Penamaan antrian | Nama antrian case-sensitive. Setiap nama harus terdiri dari 1 hingga 120 karakter. | Nama antrian case-sensitive. Setiap nama harus terdiri dari 1 hingga 80 karakter. |
| Periode retensi pesan | 7 hari | 14 hari |
| Interval long polling | Nilai valid: 0 hingga 30. Nilai default: 15. Satuan: detik. | Nilai valid: 0 hingga 20. Satuan: detik. |
| Muatan pesan maksimum | 64 KB. Jika Anda ingin meningkatkan muatan pesan maksimum, ajukan tiket. | 256 KB |
| Periode timeout visibilitas | Nilai valid: 1 hingga 43200. Nilai default: 30. Satuan: detik. | Nilai valid: 1 hingga 43200. Satuan: detik. Tidak ada nilai default yang ditentukan. |
| ID antrian | Setiap nama antrian unik dalam satu Wilayah. Setiap ID pesan bersifat unik secara global. Nama setiap receipt handle adalah string kustom. | Setiap nama antrian unik dalam satu Wilayah. Setiap ID pesan bersifat unik secara global. Nama setiap receipt handle adalah string kustom. |
| Penundaan pesan | Parameter DelaySeconds menentukan penundaan pesan. Nilai valid: 0 hingga 604800. Satuan: detik. | Parameter DelaySeconds menentukan penundaan pesan. Nilai valid: 0 hingga 604800. Satuan: detik. |
| Jumlah maksimum pesan yang terakumulasi | Tidak terbatas | Tidak terbatas |
| Permintaan per detik (QPS) maksimum | Tidak ada batasan pada sumber daya antrian yang digunakan pengguna. QPS untuk messaging berbasis antrian dan berbasis topik dibatasi hingga 20.000 untuk setiap Akun Alibaba Cloud di setiap Wilayah. Untuk informasi lebih lanjut, lihat Kebijakan throttling. | Tidak terbatas |
Batasan model pesan berbasis topik
| Batas | SMQ | Amazon SNS |
|---|---|---|
| Nama topik | Setiap nama topik harus terdiri dari 1 hingga 120 karakter. Nama topik tidak case-sensitive. | Setiap nama topik harus terdiri dari 3 hingga 64 karakter. Nama topik case-sensitive. |
| Panjang pesan maksimum | 64 KB | 256 KB |
| Kebijakan Percobaan Ulang | Mode backoff: Sistem melakukan tiga kali retry. Interval antara dua retry berturut-turut berkisar antara 10 hingga 20 detik. Mode exponential decay: Sistem melakukan 176 kali retry hanya dalam satu hari. | Mode backoff: Sistem melakukan tiga kali percobaan ulang dengan interval 20 detik antara setiap percobaan berturut-turut. Mode exponential decay: Anda dapat mengubah jumlah percobaan ulang. |
| Jumlah maksimum subscription untuk satu topik | 100. Jika Anda ingin menambah batas ini, Anda dapat mengajukan tiket. | 12.500.000 |
| QPS maksimum | Tidak ada batasan pada sumber daya antrian yang digunakan pengguna. QPS untuk messaging berbasis antrian dan berbasis topik dibatasi hingga 20.000 untuk setiap Akun Alibaba Cloud di setiap Wilayah. Untuk informasi lebih lanjut, lihat Kebijakan throttling. | 300 QPS per topik atau 10 MB/detik. Sistem mulai menghitung ketika topik menerima kueri pertama. |
Perbedaan batasan utama dan solusi alternatif
Saat merencanakan migrasi Anda, perhatikan secara khusus perbedaan batasan signifikan berikut:
Muatan pesan maksimum (64 KB vs. 256 KB): SMQ memiliki muatan pesan maksimum default 64 KB, sedangkan Amazon SQS dan Amazon SNS mendukung hingga 256 KB. Jika beban kerja Anda saat ini mengirim pesan yang lebih besar dari 64 KB, Anda dapat mengajukan tiket untuk meminta batas yang lebih tinggi. Sebagai alternatif, Anda dapat menyimpan isi pesan besar di Alibaba Cloud OSS dan meneruskan referensi objek dalam pesan, mirip dengan pola Amazon SQS Extended Client Library. Untuk informasi lebih lanjut, lihat Transmisi pesan berukuran besar.
Jumlah maksimum subscription per topik (100 vs. 12.500.000): SMQ mendukung hingga 100 subscription per topik secara default, sedangkan Amazon SNS mendukung hingga 12.500.000. Jika topik Anda memiliki lebih dari 100 subscriber, Anda dapat mengajukan tiket untuk menaikkan batas tersebut.
Periode retensi pesan (7 hari vs. 14 hari): SMQ menyimpan pesan hingga 7 hari, sedangkan Amazon SQS menyimpan pesan hingga 14 hari. Pastikan konsumen Anda dapat memproses pesan dalam jendela 7 hari tersebut, atau sesuaikan pipeline pemrosesan Anda.
Mekanisme penyaringan data: SMQ menggunakan penyaringan data berbasis tag untuk subscription topik, sedangkan Amazon SNS menggunakan penyaringan berbasis kebijakan JSON. Anda perlu mendesain ulang logika filter Anda saat memigrasikan subscription.
Perbandingan SDK
Tabel berikut membandingkan SDK yang tersedia untuk SMQ, Amazon SQS, dan Amazon SNS.
| SDK | Alibaba Cloud SMQ | Amazon SQS | Amazon SNS |
|---|---|---|---|
| Operasi API | Referensi API | Referensi API | Referensi API |
| SDK HTTP | SDK untuk Java, SDK untuk Python, SDK untuk C#, SDK untuk PHP, SDK untuk C++, SDK untuk Go, dan SDK untuk JMS | SDK untuk Java, SDK untuk JavaScript, SDK untuk PHP, SDK untuk Python, SDK untuk Ruby, dan SDK untuk .NET | SDK untuk Java, SDK untuk JavaScript, SDK untuk PHP, SDK untuk Python, SDK untuk Ruby, dan SDK untuk .NET |
Proses migrasi
Untuk memastikan aplikasi Anda dimigrasikan dengan lancar dari Amazon SQS atau Amazon SNS ke SMQ, kami merekomendasikan agar Anda menyinkronkan antrian, topik, dan metadata subscription antar layanan. Kemudian, aktifkan strategi dual-read dan dual-write di sisi aplikasi untuk memigrasikan data. Gambar berikut menunjukkan proses migrasi data dari Amazon SQS ke SMQ.
Proses migrasi terdiri dari empat tahap. Untuk setiap tahap, kami menjelaskan tujuan, tindakan yang perlu Anda ambil, dan kriteria keluar sebelum beralih ke tahap berikutnya.
Tahap 1: Beban kerja yang ada memproduksi dan mengonsumsi pesan melalui Amazon SQS
Tujuan: Tetapkan garis dasar Anda dan siapkan sumber daya SMQ.
Tindakan:
Inventarisasi semua antrian Amazon SQS dan topik Amazon SNS di lingkungan AWS Anda. Catat konfigurasinya, termasuk periode retensi, timeout visibilitas, pengaturan penundaan, dan subscription.
Buat antrian dan topik yang sesuai di SMQ dengan konfigurasi setara. Perhatikan perbedaan batasan yang dijelaskan di atas (ukuran muatan pesan, batas subscription, periode retensi).
Sinkronkan metadata subscription. Konversi kebijakan filter JSON Amazon SNS ke filter berbasis tag SMQ jika berlaku.
Siapkan Pemantauan untuk lingkungan AWS dan SMQ agar Anda dapat membandingkan alur pesan selama migrasi.
Kriteria keluar: Antrian dan topik SMQ telah dibuat dan dikonfigurasi. Pemantauan telah diterapkan untuk kedua lingkungan.
Tahap 2: Layanan konsumen secara simultan mengonsumsi pesan dari Amazon SQS dan SMQ
Tujuan: Aktifkan dual-read sehingga konsumen memproses pesan dari kedua layanan.
Tindakan:
Perbarui aplikasi konsumen Anda untuk membaca dari antrian Amazon SQS dan SMQ (dual-read). Hal ini memastikan konsumen siap menangani pesan dari SMQ sebelum produsen beralih.
Validasi bahwa pesan yang dipublikasikan ke SMQ dikonsumsi dengan benar. Verifikasi kompatibilitas format pesan, perilaku acknowledgment, dan penanganan error.
Pantau lag konsumen dan tingkat error di kedua sisi untuk memastikan konsumsi SMQ stabil.
Kriteria keluar: Konsumen berhasil memproses pesan dari SMQ tanpa error selama periode yang berkelanjutan.
Tahap 3: Layanan produsen terhubung ke SMQ
Tujuan: Mengalihkan produsen untuk menulis ke SMQ sambil mempertahankan pembacaan ganda di sisi konsumen.
Tindakan:
Perbarui aplikasi produsen Anda untuk mempublikasikan pesan ke SMQ, bukan (atau selain) Amazon SQS.
Jika Anda menjalankan dual-write (menulis ke Amazon SQS dan SMQ secara bersamaan), pantau kedua alur pesan untuk memastikan pesan tiba dengan benar di SMQ.
Setelah produsen sepenuhnya beralih ke SMQ, Anda dapat menghentikan dual-write. Konsumen harus tetap menjalankan dual-read untuk mengosongkan pesan yang tersisa di Amazon SQS.
Kriteria keluar: Semua produsen berhasil mempublikasikan ke SMQ. Pengiriman pesan dikonfirmasi melalui Pemantauan.
Tahap 4: Layanan produsen diputus dari Amazon SQS setelah pesan yang ada dikonsumsi
Tujuan: Selesaikan migrasi dengan mendekomisioning sumber daya Amazon SQS/Amazon SNS.
Tindakan:
Tunggu hingga semua pesan yang tersisa di antrian Amazon SQS dikonsumsi. Pantau Kedalaman antrian untuk memastikannya mencapai nol.
Setelah tidak ada pesan yang tersisa, hapus logika dual-read dari aplikasi konsumen Anda sehingga hanya membaca dari SMQ.
Dekomisioning antrian Amazon SQS dan topik Amazon SNS di AWS.
Perbarui dokumentasi dan runbook Anda agar mencerminkan arsitektur berbasis SMQ yang baru.
Kriteria keluar: Semua sumber daya Amazon SQS/Amazon SNS telah didekomisioning. Semua produsen dan konsumen beroperasi secara eksklusif melalui SMQ.
Pengujian dan validasi
Sebelum dan selama migrasi, lakukan pengujian berikut untuk memastikan integritas data dan stabilitas aplikasi:
Pengujian fungsional: Kirim pesan uji melalui SMQ dan verifikasi bahwa konsumen menerima serta memprosesnya dengan benar. Konfirmasi bahwa atribut pesan, penundaan, dan timeout visibilitas berperilaku sesuai harapan.
Validasi filter: Jika Anda menggunakan penyaringan data, verifikasi bahwa filter berbasis tag SMQ menghasilkan hasil yang sama dengan filter kebijakan JSON Amazon SNS Anda.
Pengujian kinerja: Bandingkan throughput dan latensi pesan antara pengaturan Amazon SQS/Amazon SNS dan SMQ. Perhatikan batas QPS SMQ sebesar 20.000 per Akun Alibaba Cloud per Wilayah. Untuk informasi lebih lanjut, lihat Kebijakan throttling.
Pengujian dead-letter queue: Kirim sengaja pesan yang rusak atau tidak dapat diproses untuk memverifikasi bahwa dead-letter queue di SMQ menangkapnya dengan benar.
Pengujian perilaku retry: Verifikasi bahwa kebijakan retry (mode backoff dan mode exponential decay) memenuhi kebutuhan aplikasi Anda. Perhatikan perbedaan interval dan jumlah retry antara SMQ dan Amazon SNS.
Pemantauan dan Peringatan: Konfirmasi bahwa alat Pemantauan Anda menangkap metrik SMQ (jumlah pesan, lag konsumen, tingkat error) dengan benar dan bahwa Peringatan muncul sesuai harapan.
Kesiapan rollback: Selama Tahap 2 dan Tahap 3, pertahankan sumber daya Amazon SQS/Amazon SNS Anda aktif. Jika Anda mengalami masalah dengan SMQ, Anda dapat mengembalikan produsen ke Amazon SQS dan konsumen ke mode dual-read atau hanya Amazon SQS hingga masalah terselesaikan.