Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure Web PubSub Service adalah layanan olahpesan real time yang dikelola sepenuhnya yang memungkinkan komunikasi dua arah antara server dan klien dengan menggunakan protokol WebSocket. Satu sumber daya Web PubSub dapat menangani skala hingga satu juta koneksi WebSocket secara bersamaan. Layanan ini mendukung beberapa pola pengiriman pesan, termasuk penyiaran dari server ke klien, pengiriman pesan ke kelompok yang dinamai, publikasi/berlangganan dari klien ke klien, dan streaming token AI.
Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.
Artikel ini menjelaskan cara membuat layanan Azure Web PubSub tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, kegagalan zona ketersediaan, dan kegagalan di seluruh wilayah. Ini juga menjelaskan bagaimana layanan menangani pemeliharaan dan menyoroti informasi utama tentang perjanjian tingkat layanan (SLA) Azure Web PubSub Service.
Rekomendasi implementasi produksi untuk keandalan
Untuk beban kerja produksi, ikuti rekomendasi berikut:
- Gunakan tingkat Premium. Tingkat premium tahan terhadap kegagalan zona ketersediaan di wilayah yang didukung, dan memungkinkan Anda mengonfigurasi replikasi geografis.
- Gunakan SDK Klien Azure Web PubSub saat membangun aplikasi klien, atau ikuti panduan penanganan kesalahan sementara dengan menyambungkan kembali dengan aman. Failover zona, failover wilayah, dan kesalahan sementara semuanya memutuskan koneksi aktif.
- Aktifkan replikasi geografis untuk melindungi dari kegagalan di seluruh wilayah. Ukuran setiap replika dengan unit yang cukup untuk menangani beban lalu lintas penuh yang diharapkan selama peristiwa failover.
Gambaran umum arsitektur keandalan
Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.
Arsitektur logika
Sumber daya yang Anda buat adalah sumber daya Web PubSub. Anda mengonfigurasi sumber daya dengan sejumlah unit, yang mewakili kapasitas sumber daya, termasuk jumlah maksimum koneksi bersamaan. Untuk informasi selengkapnya, lihat Panduan Kinerja untuk Azure Web PubSub Service.
Sumber daya Web PubSub memiliki titik akhir unik global yang mirip dengan contoso.webpubsub.azure.com. Klien membuat koneksi WebSocket ke titik akhir ini. Server aplikasi terhubung ke titik akhir yang sama untuk mengirim pesan dan menerima peristiwa dari klien.
Untuk informasi selengkapnya, lihat layanan internal Azure Web PubSub.
Arsitektur fisik
Azure Web PubSub Service mengelola status koneksi WebSocket dan perutean pesan di sekumpulan sumber daya komputasi. Microsoft mengelola infrastruktur yang mendasar. Anda tidak secara langsung melihat atau berinteraksi dengan VM individual yang digunakan layanan, atau komponen infrastruktur lainnya.
Ketahanan terhadap kesalahan sementara
Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.
Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.
WebSocket adalah protokol koneksi berumur panjang. Peristiwa jaringan sementara, restart infrastruktur back-end, dan operasi pemeliharaan layanan dapat menyebabkan putusnya koneksi aktif. Koneksi ulang dasar memulihkan koneksi, tetapi tanpa logika tambahan, klien kehilangan pesan yang sedang dalam penerbangan atau diantrekan selama pemadaman.
Azure Web PubSub Service mengatasi masalah ini melalui subprotokel yang dapat diandalkan yang berada di atas koneksi WebSocket mentah. Subprotokola melacak urutan pesan dan status koneksi sehingga, ketika koneksi terputus, klien bernegosiasi ulang dengan layanan dan melanjutkan dari tempat koneksi ditinggalkan.
Biasanya tidak ada kehilangan pesan setelah koneksi terputus dan tersambung kembali. Namun, ada beberapa situasi di mana kehilangan pesan mungkin terjadi. Misalnya, jika klien terputus selama lebih dari satu menit dan kemudian terhubung kembali dengan ID koneksi yang sama, operasi koneksi ulang menunjukkan status kegagalan untuk menunjukkan kehilangan pesan mungkin terjadi.
Untuk memanfaatkan subprotokola yang andal, ikuti rekomendasi berikut:
Jika memungkinkan, gunakan SDK klien Azure Web PubSub. SDK mengimplementasikan subprotokola yang andal secara otomatis. Tidak diperlukan konfigurasi tambahan. Untuk informasi selengkapnya, lihat:
- SDK sisi klien Web PubSub untuk JavaScript
- perpustakaan klien Azure Web PubSub untuk .NET
- perpustakaan klien Azure Web PubSub untuk Python
- Azure perpustakaan klien WebPubSub untuk Java
Jika Anda tidak dapat menggunakan SDK, terapkan salah satu subprotokola yang andal langsung di kode klien WebSocket Anda. Untuk spesifikasi lengkap dan panduan implementasi, lihat Membuat klien WebSocket yang andal.
Ketahanan terhadap kegagalan zona ketersediaan
Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.
Azure Web PubSub Service mendukung penyebaran yang redundan di zona ketika Anda menggunakan tingkat Premium. Saat Anda membuat atau meningkatkan sumber daya Web PubSub tingkat Premium di wilayah yang mendukung zona ketersediaan, redundansi zona diaktifkan secara otomatis. Layanan ini mendistribusikan infrastrukturnya di beberapa zona ketersediaan di wilayah tersebut. Jika satu zona gagal, layanan merutekan lalu lintas ke infrastruktur di zona sehat.
Persyaratan
Dukungan wilayah: Redundansi zona didukung di sebagian besar wilayah di mana kedua kondisi ini berlaku:
- Azure Web PubSub Service tersedia. Untuk daftar wilayah tempat layanan tersedia, lihat Ketersediaan Produk menurut Wilayah.
- Wilayah ini mendukung zona ketersediaan. Untuk daftar wilayah dengan zona ketersediaan, lihat daftar wilayah Azure.
Namun, Jepang Barat saat ini tidak mendukung redundansi zona untuk Azure Web PubSub.
Tier: Redundansi zona tersedia di tingkat Premium.
Biaya
Redundansi zona tidak menambahkan biaya, dan Anda membayar tarif tingkat Premium standar. Untuk informasi selengkapnya, lihat harga layanan Azure Web PubSub.
Mengonfigurasi dukungan zona ketersediaan
Redundansi zona tidak memerlukan konfigurasi selain memilih tingkat Premium. Ini secara otomatis diaktifkan dalam kedua kasus ini:
Buat sumber daya zona redundan yang baru untuk Web PubSub. Pilih SKU tingkat Premium saat Anda membuat sumber daya. Untuk informasi selengkapnya, lihat Buat sumber daya Azure Web PubSub.
Tingkatkan sumber daya yang ada ke tingkat Premium. Redundansi zona diaktifkan secara otomatis saat Anda meningkatkan sumber daya yang ada ke SKU tingkat Premium. Peningkatan dari Standar ke Premium tidak menyebabkan waktu henti layanan. Untuk informasi selengkapnya, lihat Skalakan instans Layanan Azure Web PubSub.
Perilaku ketika semua zona sehat
Bagian ini menjelaskan hal yang dapat Anda harapkan ketika Anda mengonfigurasi sumber daya Azure Web PubSub untuk redundansi zona dan ketika semua zona ketersediaan berfungsi.
Cross-zone operation: Azure Web PubSub Service secara otomatis mengelola bagaimana koneksi dan operasi didistribusikan di seluruh zona ketersediaan. Infrastruktur di beberapa zona memproses lalu lintas dalam model aktif-aktif. Anda tidak perlu mengonfigurasi apa pun untuk memanfaatkan perilaku ini. Layanan merutekan pesan antar instans di seluruh zona secara otomatis, sehingga pesan yang dikirim oleh klien dalam satu zona dikirimkan ke klien yang terhubung di zona lain.
Replikasi data lintas zona: Azure Web PubSub Service tidak mempertahankan data pelanggan. Layanan ini mempertahankan metadata sesi, seperti status koneksi dan informasi urutan pesan untuk koneksi aktif. Metadata ini direplikasi secara sinkron di seluruh zona ketersediaan.
Perilaku selama kegagalan zona
Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi sumber daya Azure Web PubSub untuk redundansi zona dan ada pemadaman di salah satu zona ketersediaan.
- Detection and response: Platform Layanan Azure Web PubSub bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan. Anda tidak perlu mengambil tindakan apa pun untuk memulai failover zona.
- Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.
Permintaan aktif: Selama kegagalan zona, koneksi WebSocket aktif ke infrastruktur di zona yang terpengaruh dihilangkan. Jika klien Anda menangani kesalahan sementara dengan tepat, seperti dengan menyambungkan kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.
Expected data loss: Azure Web PubSub Service tidak mempertahankan pesan, sehingga kegagalan zona tidak diharapkan menyebabkan kehilangan data dalam layanan Azure Web PubSub. Namun, koneksi aktif apa pun akan terputus selama kejadian penurunan zona, sehingga data apa pun yang sedang secara aktif dikirimkan mungkin hilang.
Jika penerbit menggunakan SDK Klien Azure Web PubSub atau menerapkan subprotokola yang andal, pesan mereka diakui oleh layanan setelah layanan menerimanya. Saat sebuah pesan diakui, pesan tersebut direplikasi di semua zona ketersediaan, sehingga jika zona penerbit mengalami kegagalan, pesan tidak akan hilang. Namun, jika pelanggan tidak menerima pesan sebelum dihilangkan, pelanggan mungkin tidak menerima pesan.
Waktu henti yang diharapkan: Koneksi ulang koneksi aktif yang terputus biasanya memakan waktu beberapa detik. Klien yang menerapkan koneksi ulang logika mengalami gangguan minimal.
Redistribution: Azure Web PubSub Service mendeteksi hilangnya zona dan secara otomatis mendistribusikan ulang lalu lintas di seluruh zona sehat. Anda tidak perlu mengambil tindakan apa pun.
Pemulihan Zona
Ketika zona ketersediaan pulih, Azure Web PubSub Service secara otomatis mengintegrasikannya kembali ke dalam topologi layanan aktif. Anda tidak perlu mengambil tindakan apa pun untuk pemulihan zona.
Setelah zona pulih, koneksi baru mungkin diarahkan ke infrastruktur di zona yang dipulihkan. Setiap koneksi yang sudah ada tidak akan dipindahkan atau diseimbangkan kembali ke zona yang telah dipulihkan, melainkan akan secara bertahap diseimbangkan kembali seiring koneksi tersebut hilang dan terhubung kembali dari waktu ke waktu. Ketidakseimbangan koneksi di seluruh zona tidak berdampak pada beban kerja Anda.
Uji kegagalan zona
Azure Web PubSub Service mengelola perutean lalu lintas, failover, dan pemulihan zona secara otomatis untuk sumber daya tingkat Premium yang memiliki redundansi zona. Anda tidak perlu memulai apa pun. Karena redundansi zona dikelola sepenuhnya, Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan.
Ketahanan terhadap kegagalan di seluruh wilayah
Azure Web PubSub Service adalah layanan satu wilayah. Jika wilayah menjadi tidak dapat diakses, sumber daya Web PubSub Anda juga tidak dapat diakses.
Untuk melindungi aplikasi Anda dari kegagalan di seluruh wilayah, Anda dapat menggunakan replikasi geografis, yang tersedia di tingkat Premium. Atau, Anda dapat membangun solusi multiregion kustom dengan menyebarkan beberapa sumber daya Web PubSub di berbagai wilayah.
Replikasi lokasi geografis
Replikasi geografis memungkinkan Anda menambahkan replicas sumber daya Web PubSub Anda di wilayah Azure lainnya. Semua replika berbagi satu titik akhir (contoso.webpubsub.azure.com). Di balik titik akhir ini, Azure Traffic Manager memanfaatkan perutean berbasis DNS untuk mengarahkan setiap klien ke replika regional terdekat yang sehat. Jika suatu wilayah gagal, Traffic Manager mendeteksi kegagalan melalui pemeriksaan kesehatan dan berhenti mengarahkan klien ke replika tersebut. Koneksi klien baru secara otomatis dirutekan ke replika sehat terdekat.
Wilayah tempat Anda membuat sumber daya Web PubSub disebut wilayah utama, dan replikanya adalah replika utama. Sarana kontrol sumber daya utama mengelola konfigurasi sumber daya Web PubSub Anda.
Persyaratan
- Region support: Anda dapat menambahkan replika di wilayah mana pun di mana Azure Web PubSub Service tersedia.
- Tier: Anda harus menggunakan tingkat Premium untuk mengaktifkan replikasi geografis.
- Batas replika: Setiap sumber daya Web PubSub utama mendukung hingga delapan replika.
Pertimbangan
Pewarisan konfigurasi: Replika mewarisi sebagian besar pengaturan konfigurasi dari sumber daya utama. Pengaturan tertentu harus dikonfigurasi secara terpisah pada setiap replika. Untuk daftar lengkap pengaturan yang tidak diwariskan, lihat Geo-replication di Azure Web PubSub.
Perubahan konfigurasi: Sarana kontrol utama, di wilayah utama, memproses perubahan konfigurasi apa pun pada sumber daya Web PubSub. Jika sarana kontrol utama tidak tersedia, Anda tidak akan dapat memperbarui konfigurasi sumber daya, meskipun replika yang ada akan terus memproses lalu lintas data tanpa gangguan.
Biaya
Setiap replika ditagih secara terpisah berdasarkan jumlah unit dan volume pesan keluarnya sendiri. Jika pesan ditransfer antara replika lalu dikirimkan ke klien atau server di wilayah lain, pesan akan ditagih sebagai pesan keluar. Untuk informasi selengkapnya, lihat harga layanan Azure Web PubSub.
Mengonfigurasi replikasi geografis
Untuk menambahkan atau menghapus replika ke sumber daya Web PubSub, lihat Geo-replikasi di Azure Web PubSub.
Perencanaan dan manajemen kapasitas
Setiap replika menangani lalu lintas secara independen. Selama failover regional, para klien dari wilayah yang mengalami kegagalan terhubung kembali ke replika sehat terdekat. Untuk memastikan bahwa replika yang bertahan memiliki kapasitas yang cukup untuk menyerap beban tambahan ini, konfigurasikan setiap replika dengan unit yang dapat menangani lalu lintas beban kerja yang diharapkan penuh, bukan hanya bagian yang biasanya berfungsi.
Atau, aktifkan penskalaan otomatis pada setiap replika sehingga unit dapat menskalakan secara otomatis sebagai respons terhadap beban yang lebih tinggi. Autoscaling terus berfungsi saat replika sekunder tidak tersedia, tetapi autoscaling tidak berfungsi jika pesawat kendali utama tidak tersedia. Untuk informasi selengkapnya tentang penskalaan otomatis, lihat Unit skala layanan Azure Web PubSub secara otomatis.
Untuk panduan umum tentang provisi berlebihan sebagai strategi, lihat Mengelola kapasitas dengan provisi berlebih.
Perilaku ketika semua wilayah sehat
Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi Layanan Azure Web PubSub untuk replikasi geografis dan semua wilayah beroperasi.
Cross-region operation: Azure Traffic Manager merutekan setiap klien ke replika regional sehat terdekat. Klien di area geografis yang berbeda mungkin terhubung ke replika yang berbeda. Layanan Web PubSub menyinkronkan pesan di seluruh replika sehingga klien yang terhubung ke replika apa pun dapat berkomunikasi satu sama lain.
Replikasi data lintas wilayah: Ketika pesan dikirim ke replika, layanan secara sinkron mentransfer pesan tersebut ke replika lain sehingga klien yang terhubung ke tempat lain dapat menerimanya. Overhead sinkronisasi minimal untuk pola pengiriman pesan yang paling umum, seperti broadcast ke kelompok besar atau pengiriman pesan ke satu koneksi. Mengirim pesan ke grup kecil (kurang dari 10 anggota) mungkin menghasilkan sinkronisasi dengan overhead yang sedikit lebih tinggi.
Azure Web PubSub Service tidak menyimpan pesan; hanya pengiriman aktif yang disinkronkan di seluruh replika.
Perilaku selama kegagalan wilayah
Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi Layanan Azure Web PubSub untuk replikasi geografis dan ada pemadaman di salah satu wilayah replika.
- Deteksi dan respons: Layanan Web PubSub bertanggung jawab untuk mendeteksi kegagalan di suatu wilayah dan secara otomatis mengalihkan rute lalu lintas masuk ke replika di salah satu wilayah lain yang Anda konfigurasi.
Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:
Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah.
Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.
Permintaan aktif: Koneksi WebSocket aktif ke replika di wilayah yang mengalami kegagalan diputus. Klien harus terhubung kembali setelah replika gagal.
Perkiraan kehilangan data: Layanan Azure Web PubSub tidak menyimpan pesan. Pesan yang sedang transit ke klien di wilayah yang gagal pada saat kegagalan mungkin hilang. Tidak ada kehilangan data persisten yang diharapkan karena layanan tidak menyimpan data pelanggan.
Expected downtime: Azure Traffic Manager melakukan pemeriksaan kesehatan terhadap setiap replika. Ketika pemadaman wilayah menyebabkan replika gagal dalam pemeriksaan kesehatannya, Traffic Manager menghapus titik akhir replika tersebut dari hasil resolusi DNS-nya. Setelah menghapus titik akhir, TTL DNS 90 detik harus berlalu sebelum klien melihat catatan DNS yang diperbarui. Secara total, transisi biasanya memakan waktu beberapa menit. Klien yang dirancang dengan baik yang menerapkan logika koneksi ulang dapat melanjutkan operasi normal setelah menyambungkan kembali ke replika yang sehat.
Jika sarana kontrol utama tidak tersedia, Anda tidak dapat membuat perubahan apa pun pada konfigurasi sumber daya Web PubSub atau replikanya. Namun, koneksi WebSocket terus berfungsi dalam replika yang sehat.
Redistribution: Azure Traffic Manager mengarahkan permintaan masuk ke replika yang sehat. Namun, jika klien mencoba untuk terhubung kembali sebelum Azure Traffic Manager telah mendeteksi failover replika dan entri DNS yang diperbarui telah disebarkan ke klien, upaya koneksi ulang klien mungkin terus menargetkan wilayah yang tidak tersedia dan bisa gagal.
Setelah pembaruan DNS tersebar, para klien yang menghubungkan kembali secara otomatis dirutekan ke replika sehat terdekat.
Pemulihan wilayah
Ketika wilayah yang mengalami kegagalan pulih, pemeriksaan kesehatan koneksi Traffic Manager mendeteksi replika yang dipulihkan dan menyertakan titik akhirnya dalam resolusi DNS lagi. Klien-klien yang saat ini terhubung ke replika lain tidak terpengaruh dan tetap terhubung hingga mereka memutuskan koneksi. Koneksi baru kembali dirutekan ke replika di wilayah yang dipulihkan ketika replika tersebut adalah yang terdekat dan sehat.
Pengujian untuk mendeteksi kegagalan wilayah
Untuk mensimulasikan failover wilayah dan menguji perilaku koneksi ulang aplikasi klien, Anda dapat menonaktifkan titik akhir replika. Tindakan ini menyebabkan Traffic Manager berhenti mengarahkan lalu lintas ke replika tersebut, yang memungkinkan Anda mengamati bagaimana klien Anda berperilaku ketika replika yang mereka hubungi tidak tersedia. Untuk langkah-langkah mendetail, lihat Menonaktifkan atau mengaktifkan titik akhir replika.
Solusi multiregion kustom untuk ketahanan
Jika Anda memerlukan ketahanan lintas wilayah tetapi tidak menggunakan replikasi geografis, Anda dapat menyebarkan dan mengelola sumber daya Web PubSub terpisah di beberapa wilayah dan menerapkan logika failover Anda sendiri di server aplikasi Anda. Pendekatan ini lebih kompleks daripada replikasi geografis dan tidak mendukung failover zero-downtime untuk konektivitas klien-ke-klien. Untuk gambaran umum arsitektur terperinci, pola failover, dan panduan pengujian, lihat Ketahanan dan Pemulihan Bencana di Layanan Azure Web PubSub.
Pencadangan dan pemulihan
Azure Web PubSub Service adalah layanan olah pesan stateless. Tidak menyimpan pesan pelanggan dan tidak memiliki fitur pencadangan atau pemulihan.
Untuk melindungi konfigurasi sumber daya Anda, tentukan sumber daya Web PubSub Anda menggunakan infrastruktur sebagai kode (seperti templat Bicep atau ARM) dan simpan definisi tersebut dalam kontrol sumber. Jika Anda perlu membuat ulang sumber daya, sebarkan ulang dari konfigurasi yang disimpan.
Ketahanan terhadap pemeliharaan layanan
Microsoft secara teratur menerapkan pembaruan layanan dan melakukan pemeliharaan lainnya. Platform Azure menangani aktivitas ini secara otomatis, memastikan bahwa pemeliharaan mulus dan transparan bagi Anda. Tidak ada downtime yang diharapkan selama peristiwa pemeliharaan kecuali Anda menerima pemberitahuan tentang pemeliharaan terencana melalui Azure Service Health.
Perjanjian tingkat layanan
Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.