ApsaraMQ for RocketMQ:Seri 5.x Serverless

Manfaat

ApsaraMQ for RocketMQ instans Serverless menawarkan skalabilitas resource yang fleksibel dan mampu memenuhi kebutuhan resource di berbagai tahap pertumbuhan bisnis. Manfaat utamanya meliputi hal-hal berikut:

• Kompatibilitas langsung dengan versi open source. Hal ini memungkinkan Anda fokus pada aplikasi bisnis tanpa perlu khawatir tentang ukuran atau stabilitas resource instans Serverless. Pengembang dapat berkonsentrasi pada pengembangan kode bisnis inti, sehingga mengurangi biaya operasi dan maintenance (O&M) perusahaan.

• Elastic scaling otomatis. Instans Serverless menerapkan kebijakan penyesuaian resource secara dinamis dengan otomatis menskalakan kapasitas berdasarkan traffic layanan real-time. Perusahaan tidak perlu memperkirakan atau mengonfigurasi tipe instans sebelumnya.

• Bayar sesuai penggunaan berdasarkan pemakaian aktual. Biaya dihitung berdasarkan penggunaan resource Anda, seperti message, resource topic, network traffic, dan penyimpanan. Biaya diselesaikan per jam sesuai penggunaan resource, sehingga benar-benar menerapkan penagihan pay-as-you-go yang membantu menghemat biaya.

Kemampuan Elastisitas

Kemampuan elastisitas dibagi menjadi elastisitas tanpa loss dan elastisitas adaptif, tergantung pada apakah proses scaling memengaruhi permintaan pengiriman atau penerimaan message oleh klien:

• Elastisitas tanpa loss: Selama elastic scaling, permintaan pengiriman dan penerimaan message tetap bebas error dan tidak terpengaruh. Ambang batas rate limiting awal merupakan ambang batas rate limiting elastisitas tanpa loss.

• Elastisitas adaptif: Setelah melebihi ambang batas rate limiting elastisitas tanpa loss, sisi server menerapkan aturan elastisitas adaptif lebih lanjut berdasarkan traffic layanan. Selama scale-out, traffic layanan dikenai rate limiting. Setelah scale-out, ambang batas rate limiting meningkat.

  • Ukuran langkah scale-out dan scale-in bervariasi tergantung pada tipe instans terjadwal:

    • Untuk mode kapasitas kumulatif, ukuran langkah sekitar 25.000 TPS.

    • Untuk mode kapasitas terjadwal dan elastis, ukuran langkah kira-kira sebesar ukuran tipe instans terjadwal.

  • Setiap operasi scale-out memerlukan waktu beberapa menit. Tipe instans terjadwal yang lebih besar memerlukan waktu lebih lama.

  • Sistem memeriksa traffic instans dalam jendela waktu sekitar 10 menit. Jika traffic instans menurun, operasi scale-in akan dilakukan. Setiap operasi scale-in mengurangi kapasitas sebesar satu langkah.

Alokasi TPS terjadwal

Secara default, TPS terjadwal dialokasikan secara merata antara pengiriman dan konsumsi message (masing-masing 50%). Rasio ini tidak dapat disesuaikan secara otomatis. Untuk mengubah rasio tersebut, Anda harus mengonfigurasi persentase terjadwal secara manual.

Contoh: Jika TPS terjadwal adalah 2.000 dan rasio kirim-konsumsi adalah 50:50, maka batas TPS untuk pengiriman dan konsumsi message masing-masing adalah 1.000.

Kemampuan Seri

Ambang batas rate limiting elastisitas tanpa loss dihitung sebagai berikut:

• Rumus: Ambang batas rate limiting elastisitas tanpa loss = Tipe instans terjadwal + Kemampuan elastisitas tanpa loss.

• Dibagikan:

  • Kumulatif: Ambang batas rate limiting elastisitas tanpa loss = Tipe instans terjadwal (0) + Kemampuan elastisitas tanpa loss (50.000) = 50.000.

  • Terjadwal dan Elastis: Ambang batas rate limiting elastisitas tanpa loss = Tipe instans terjadwal (1x) + Kemampuan elastisitas tanpa loss (2x tipe instans terjadwal) = Tipe instans terjadwal × 3.

• Eksklusif:

  • Terjadwal dan Elastis: Ambang batas rate limiting elastisitas tanpa loss = Tipe instans terjadwal (1x) + Kemampuan elastisitas tanpa loss (0,5x tipe instans terjadwal) = Tipe instans terjadwal × 1,5.

Dampak Peningkatan atau Penurunan terhadap Ambang Batas Rate Limiting

Setelah melakukan peningkatan atau penurunan tipe instans terjadwal, ambang batas rate limiting instans dihitung sebagai: MAX(current rate limiting threshold, lossless elasticity rate limiting threshold after upgrade or downgrade). Nilai ini merepresentasikan nilai yang lebih besar antara ambang batas rate limiting saat ini dan ambang batas rate limiting elastisitas tanpa loss setelah peningkatan atau penurunan.

Arsitektur Instans Serverless

ApsaraMQ for RocketMQ instans Serverless 5.x menggunakan isolasi resource multi-tenant, sehingga memastikan bahwa operasi bisnis antar instans tidak saling mengganggu.

ApsaraMQ for RocketMQ mengemas semua komponen teknis ke dalam container. Dengan memanfaatkan sifat scalable dari cloud, sistem secara fleksibel mengalokasikan resource komputasi, penyimpanan, dan jaringan di lapisan bawah.

Oleh karena itu, instans Serverless ApsaraMQ for RocketMQ dapat merespons secara cepat terhadap perubahan kebutuhan resource dari setiap tenant, mencapai elastic scaling yang mulus dalam mode Serverless, serta secara fleksibel dan akurat memenuhi kebutuhan bisnis Anda.

Batasan

Instans Serverless saat ini hanya mendukung wilayah berikut: Tiongkok (Hangzhou), Tiongkok (Shanghai), Tiongkok (Beijing), Tiongkok (Zhangjiakou), Tiongkok (Shenzhen), Tiongkok (Chengdu), Singapura, Jerman (Frankfurt), dan AS (Virginia). Wilayah lain akan tersedia secara bertahap.

Akses jaringan

Untuk berkomunikasi dalam VPC yang sama, Anda harus mengaktifkan PrivateLink untuk instans Serverless. Arsitektur jaringan instans Serverless bergantung pada PrivateLink untuk mengimplementasikan komunikasi jaringan pribadi yang aman dan stabil.

Dukungan protokol

Instans Serverless hanya mendukung koneksi protokol TCP. Akses API HTTP melalui jaringan publik tidak didukung.

Penagihan

Untuk aturan penagihan spesifik instans Serverless, lihat Penagihan Instans Serverless.

FAQ

Apakah konsol instans Serverless ApsaraMQ for RocketMQ mendukung pengiriman ordered message atau message dengan atribut kustom?

Fitur Quick Experience pada konsol instans Serverless saat ini hanya mendukung pengiriman message normal. Menetapkan atribut kustom yang ditentukan pengguna tidak didukung. Jika Anda perlu mengirim ordered message atau message dengan atribut kustom, gunakan SDK sebagai gantinya.

Apakah peningkatan ke LiteTopic (lightweight topic) memengaruhi fungsi topic normal yang sudah ada?

Menambahkan tag version_capability:lite-topic tidak memengaruhi fungsi topic normal yang sudah ada. Lightweight topic berdampingan dengan topic normal sebagai container sekunder. Jenis topic yang ada (message normal, terurut, dan transaksional) serta logika konsumsi tetap tidak berubah. Peningkatan ini hanya menambahkan fitur khusus lightweight topic, seperti pembuatan dinamis, kedaluwarsa otomatis, dan konsumsi terurut berbasis single-queue.

Manakah yang lebih hemat biaya untuk pengembangan dan debugging: ApsaraMQ for RocketMQ 4.x atau 5.x Serverless?

(Direkomendasikan) Gunakan 5.x Serverless. Edisi Standar ApsaraMQ for RocketMQ 4.x ditagih berdasarkan penggunaan resource topic dan panggilan API. ApsaraMQ for RocketMQ 5.x mendukung penagihan pay-as-you-go dengan Serverless dan TPS elastis. Penyimpanan dan komputasi ditagih berdasarkan penggunaan aktual, sehingga menghindari pemborosan resource. Arsitektur elastis juga lebih cocok untuk skenario dengan traffic yang fluktuatif, sehingga mengurangi biaya jangka panjang.

Bagaimana saya dapat mengontrol biaya saat migrasi dari AWS SQS ke ApsaraMQ for RocketMQ Serverless?

Untuk mencapai biaya yang sebanding dengan AWS SQS, gunakan instans standar. Jika Anda menggunakan instans Serverless, sesuaikan aplikasi Anda agar menggunakan gRPC SDK, gunakan akses jaringan pribadi untuk menghindari biaya Internet traffic, dan pertahankan ukuran message pada atau di bawah 4 KB.

Kapan instans Serverless akan mendukung penampilan data client online?

Instans Serverless ApsaraMQ for RocketMQ dijadwalkan menyelesaikan peningkatan terpadu bulan ini (sebelum tanggal 25) untuk mendukung penampilan data client online. Pengguna akan diberi tahu satu minggu sebelum peningkatan dilakukan.