Keandalan di Azure Notification Hubs

Azure Notification Hubs membantu Anda mengelola pemberitahuan push di beberapa sistem pemberitahuan platform (PNS), seperti Layanan Pemberitahuan Push Apple (APN), Firebase Cloud Messaging (FCM), dan Windows Push Notification Service (WNS).

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 Notification Hubs tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, kegagalan zona ketersediaan, kegagalan di seluruh wilayah, dan pemeliharaan layanan. Ini juga menjelaskan opsi pencadangan dan pemulihan dan informasi utama tentang perjanjian tingkat layanan (SLA) Notification Hubs.

Rekomendasi penyebaran produksi

Untuk beban kerja produksi, ikuti rekomendasi berikut:

• Gunakan tingkat Dasar atau Standar sehingga namespace Anda memenuhi syarat untuk SLA.

• Jika memungkinkan, gunakan penginstalan alih-alih pendaftaran dalam aplikasi perangkat.

• Gunakan SDK yang disediakan Microsoft untuk berinteraksi dengan Notification Hubs.

• Aktifkan redundansi zona.

• Untuk mengantisipasi gangguan di seluruh wilayah, aktifkan pemulihan bencana metadata ke wilayah Azure lain. Rencanakan cara mencadangkan dan memulihkan pendaftaran dan penginstalan perangkat.

Gambaran umum arsitektur keandalan

Azure Notification Hubs disusun berdasarkan namespace dan pusat notifikasi. Namespace adalah batas manajemen yang berisi satu atau beberapa hub. Hub mewakili titik akhir untuk aplikasi. Perangkat mendaftar dengan titik akhir tersebut dengan menggunakan pendaftaran atau penginstalan, yang memungkinkan layanan mengirim pemberitahuan push ke perangkat. Untuk informasi selengkapnya, lihat Manajemen pendaftaran.

Notification Hubs mengirimkan pemberitahuan push ke sistem pemberitahuan platform (PNS), seperti layanan Pemberitahuan Push Apple (APN) dan Firebase Cloud Messaging (FCM). Penyampaian notifikasi secara menyeluruh bergantung pada ketersediaan Notification Hubs dan perilaku penyedia PNS di hilir.

Untuk perencanaan keandalan, penting untuk membedakan antara jenis data berikut yang dikelola Notification Hubs:

• Metadata: Konfigurasi namespace dan hub, termasuk informasi koneksi dan konfigurasi pemulihan bencana.
• Data pendaftaran: Pendaftaran dan penginstalan perangkat yang memetakan pengguna dan perangkat ke tag dan templat.

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.

Notification Hubs secara otomatis menangani kesalahan sementara yang terjadi saat menyambungkan ke PNS. Namun, Anda bertanggung jawab untuk menangani kegagalan sementara saat perangkat layanan atau pengguna Berinteraksi dengan Notification Hubs. Kegagalan sementara dapat terjadi selama operasi pendaftaran, operasi pengiriman pemberitahuan, dan operasi manajemen. Ikuti panduan ini:

• Pendaftaran dan penginstalan: Aplikasi Anda pada perangkat harus mencoba kembali operasi pendaftaran dan penginstalan yang gagal karena kesalahan sementara. SDK yang disediakan Microsoft menangani percobaan ulang secara otomatis. Jika Anda tidak dapat menggunakan SDK yang disediakan, terapkan logika percobaan ulang dengan backoff eksponensial dan jitter, serta jadikan operasi pendaftaran idempoten jika memungkinkan.

  Membuat atau memperbarui instalasi bersifat idempoten, sehingga Anda dapat mencoba ulang operasi dengan aman. Jika memungkinkan, gunakan penginstalan alih-alih pendaftaran.

• Pemberitahuan mengirim dan operasi manajemen: Gunakan SDK yang disediakan Microsoft untuk mengirim pemberitahuan push dan melakukan operasi manajemen. SDK ini secara otomatis mencoba kembali ketika kesalahan sementara terjadi.

  Jika Anda tidak dapat menggunakan SDK yang disediakan, terapkan logika percobaan ulang dengan backoff eksponensial dan jitter, serta jadikan operasi pengiriman notifikasi bersifat idempoten jika memungkinkan.

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.

Di wilayah yang mendukung zona ketersediaan, namespace Notification Hubs mendukung konfigurasi zona-redundan . Notification Hubs secara otomatis mengaktifkan redundansi zona untuk semua namespace di beberapa wilayah. Saat redundansi zona diaktifkan, Microsoft mereplikasi metadata dan data pendaftaran di semua zona ketersediaan di wilayah tersebut.

Diagram menunjukkan zona ketersediaan 1, 2, dan 3. Satu namespace Notification Hubs mencakup ketiga zona.

Requirements

• Dukungan wilayah:

  Notification Hubs secara otomatis mengaktifkan redundansi zona untuk semua namespace di wilayah berikut. Anda tidak dapat menonaktifkan redundansi zona di wilayah ini:

  Eropa	Timur Tengah	Africa	Asia Pasifik
  Prancis Tengah	Qatar Tengah	Afrika Selatan Utara	Tiongkok Utara 3
  Italia Utara			Korea Tengah
  Norwegia Timur
  Polandia Tengah
  Swedia Tengah
  Swiss Utara

  Di wilayah lain yang mendukung Notification Hubs dan memiliki zona ketersediaan, redundansi zona bersifat opsional. Anda hanya dapat mengaktifkannya saat membuat namespace.

• Dukungan untuk semua tingkat: Anda dapat menggunakan zona ketersediaan di semua tingkat Notification Hubs.

Cost

Redundansi zona dikenai biaya tambahan di luar biaya tier. Untuk informasi selengkapnya, lihat Harga Notification Hubs.

Mengonfigurasi dukungan zona ketersediaan

• Buat namespace zona-redundan baru: Proses untuk membuat namespace zona redundan baru bergantung pada wilayah yang Anda gunakan:

  • Di wilayah tempat Notification Hubs secara otomatis mengaktifkan redundansi zona, Anda tidak perlu mengonfigurasinya.

    Important

    Di wilayah ini, Notification Hubs selalu membuat namespace dengan redundansi zona diaktifkan, bahkan jika penyebaran berbasis kode, seperti file Bicep atau templat Azure Resource Manager, menentukan bahwa redundansi zona dinonaktifkan.

    Jika Anda tidak menginginkan namespace dengan redundansi zona, buat namespace tersebut di wilayah yang mendukung redundansi zona opsional.

  • Di wilayah di mana redundansi zona bersifat opsional, Anda hanya dapat mengaktifkannya saat membuat namespace. Untuk mempelajari cara menyiapkan namespace baru dengan redundansi zona, lihat Membuat hub pemberitahuan Azure di portal Azure.

• Buat zona namespace yang sudah ada menjadi redundan: Notification Hubs tidak mendukung migrasi namespace layanan yang ada ke dukungan zona ketersediaan di tempat. Anda perlu menyebarkan namespace baru dan memindahkan pendaftaran Anda ke namespace tersebut. Ikuti panduan dalam Memindahkan sumber daya antar wilayah Azure, yang juga berlaku jika Anda menyebarkan namespace baru di wilayah yang sama.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi namespace Notification Hubs untuk redundansi zona, dan semua zona beroperasi.

• Operasi lintas zona: Notification Hubs secara otomatis mendistribusikan dan melayani permintaan dengan menggunakan infrastruktur di zona mana pun di wilayah tersebut.

• Replikasi data lintas zona: Data pendaftaran dan metadata direplikasi secara sinkron di semua zona di wilayah yang ditentukan.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi namespace Notification Hubs untuk redundansi zona, dan ada pemadaman di salah satu zona.

• Deteksi dan respons: Microsoft mendeteksi kegagalan zona dan mengelola failover di wilayah tersebut. Anda tidak perlu memulai failover.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda 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: Operasi manajemen dalam penerbangan, pendaftaran perangkat, dan permintaan baru untuk mengirim pemberitahuan mungkin gagal selama failover. Aplikasi Anda harus mencoba kembali operasi yang gagal dengan mengikuti panduan penanganan kesalahan sementara.

• Kehilangan data yang diharapkan: Kehilangan data tidak diharapkan selama pemadaman zona tunggal karena Notification Hubs secara sinkron mereplikasi namespace dan konfigurasi hub dan data pendaftaran di seluruh zona ketersediaan.

  Replikasi ini bukan cadangan. Di bawah model tanggung jawab bersama, Anda bertanggung jawab untuk mencadangkan data pendaftaran dan penginstalan. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

• Waktu henti yang diharapkan: Gangguan layanan singkat dimungkinkan saat Microsoft mengalihkan lalu lintas. Ikuti panduan penanganan kesalahan sementara untuk menyiapkan aplikasi Anda untuk gangguan ini.

• Redistribusi: Layanan ini secara otomatis mengalihkan permintaan ke zona sehat.

Pemulihan Zona

Ketika zona yang terpengaruh pulih, Anda tidak perlu mengambil tindakan apa pun. Microsoft memulihkan dan menyeimbangkan kembali infrastruktur Notification Hubs untuk menggunakan zona yang dipulihkan.

Uji kegagalan zona

Anda tidak dapat memicu failover zona Notification Hubs secara langsung. Untuk menguji perilaku beban kerja Anda, jalankan pengujian ketahanan untuk percobaan ulang, idempotensi, dan kegagalan dependensi di lingkungan nonproduksi. Anda juga dapat menggunakan Azure Chaos Studio untuk menguji komponen aplikasi di sekitarnya.

Ketahanan terhadap kegagalan di seluruh wilayah

Notification Hubs menyediakan pemulihan bencana metadata dengan mereplikasi metadata namespace di seluruh wilayah, tetapi tidak mereplikasi data pendaftaran perangkat. Kemampuan ini memerlukan intervensi manual selama pemadaman wilayah dan melibatkan beberapa waktu henti untuk hub pemberitahuan Anda.

Jika Anda perlu mengurangi waktu henti dan intervensi manual selama failover, pertimbangkan untuk menggunakan solusi multiregion kustom.

pemulihan bencana geografis metadata yang dikelola Microsoft

Notification Hubs mendukung pemulihan bencana metadata yang dikelola Microsoft ke wilayah Azure sekunder. Jika wilayah utama Anda memiliki wilayah berpasangan, Anda dapat memilih wilayah berpasangan tersebut. Terlepas dari status penyandingan wilayah utama, Anda juga dapat memilih wilayah sekunder dari daftar wilayah pemulihan fleksibel. Notification Hubs kemudian mereplikasi metadata namespace, seperti nama namespace, string koneksi, dan informasi penting lainnya.

Aplikasi klien terhubung melalui titik akhir namespace ke namespace utama di wilayah utama. Namespace utama berisi metadata dan pendaftaran. Notification Hubs hanya mereplikasi metadata ke namespace sekunder di wilayah sekunder; data pendaftaran tidak direplikasi.

Important

Pemulihan bencana geografis metadata tidak mereplikasi data pendaftaran. Jika skenario pemulihan bencana dipicu, data pendaftaran dan penginstalan dapat hilang. Anda bertanggung jawab untuk menerapkan solusi untuk mengisi ulang data pendaftaran di hub Anda setelah pemulihan.

Microsoft bertanggung jawab untuk mendeklarasikan bencana dan memulai failover. Ketika itu terjadi, Microsoft membuat namespace baru di wilayah sekunder. Karena menggunakan metadata dari wilayah utama, aplikasi dapat terhubung ke namespace tersebut dengan menggunakan nama namespace, string koneksi, dan nama hub yang ada.

Wilayah utama dan namespace-nya tidak tersedia, dan replikasi metadata dari wilayah utama telah berhenti. Aplikasi klien terus menggunakan titik akhir namespace, yang terhubung ke namespace sekunder di wilayah sekunder. Namespace sekunder berisi metadata yang direplikasi, tetapi tidak berisi pendaftaran dari namespace utama.

Requirements

• Dukungan wilayah: Dalam wilayah Azure berpasangan, namespace Anda dapat menggunakan wilayah yang dipasangkan Azure sebagai wilayah sekunder.

  Jika namespace Anda berada di wilayah yang tidak berpasangan, atau jika Anda ingin mereplikasi data ke wilayah lain, Anda dapat memilih salah satu wilayah pemulihan fleksibel berikut sebagai wilayah sekunder:

  Americas	Eropa	Africa	Asia Pasifik
  Brasil Selatan	Eropa Utara	Afrika Selatan Utara	Australia Timur
  Barat AS 2			Asia Tenggara

• Dukungan tingkat: Opsi pemulihan bencana metadata tersedia di semua tingkat Notification Hubs.

Cost

Notification Hubs tidak mengenakan biaya tambahan untuk mengonfigurasi atau menggunakan pemulihan bencana geografis metadata. Namun, Anda membayar bandwidth lintas wilayah yang digunakan untuk mereplikasi metadata. Untuk detail harga, lihat Harga Bandwidth dan Harga Notification Hubs.

Konfigurasikan dukungan multiregion

• Aktifkan pemulihan bencana geografis metadata untuk namespace baru: Ikuti prosedur di Membuat hub pemberitahuan Azure di portal Azure. Pilih konfigurasi pemulihan bencana saat Anda membuat namespace.

• Aktifkan atau nonaktifkan pemulihan bencana geografis metadata untuk namespace yang ada: Ikuti prosedur dalam Mengaktifkan pemulihan bencana untuk namespace Azure Notification Hubs yang ada.

• Cadangkan data pendaftaran perangkat Anda: Lihat Mengekspor dan mengimpor pendaftaran Azure Notification Hubs secara massal.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi namespace Notification Hubs untuk pemulihan bencana geografis metadata, dan wilayah utama dan sekunder Anda beroperasi.

• Operasi lintas wilayah: Wilayah utama melayani semua permintaan. Wilayah sekunder tidak melayani permintaan kecuali terjadi failover.

• Replikasi data lintas wilayah: Metadata, seperti nama namespace, konfigurasi hub, string koneksi, dan informasi penting lainnya, direplikasi secara asinkron di seluruh wilayah. Data pendaftaran tidak direplikasi. Anda bertanggung jawab untuk mengekspornya secara teratur untuk mempertahankan cadangan.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi namespace Notification Hubs untuk pemulihan bencana geografis metadata, dan ada pemadaman di wilayah utama.

• Deteksi dan respons: Microsoft bertanggung jawab untuk mendeteksi kegagalan wilayah dan memutuskan apakah akan memicu failover ke wilayah sekunder yang dikonfigurasi.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Permintaan yang sedang diproses ke namespace di wilayah utama mungkin gagal saat wilayah tersebut tidak aktif. Klien harus mencoba kembali operasi setelah failover selesai.

• Kehilangan data yang diharapkan: Metadata dipertahankan. Data pendaftaran tidak dicadangkan otomatis, tetapi Anda dapat mencadangkannya sendiri. Untuk informasi selengkapnya, lihat Mengekspor dan mengimpor pendaftaran Azure Notification Hubs secara massal. Jika tidak, data pendaftaran tidak tersedia hingga wilayah utama pulih.

• Perkiraan waktu henti: Microsoft memerlukan waktu untuk memulai failover metadata dan agar proses failover selesai. Meskipun waktunya dapat bervariasi, umumnya dibutuhkan beberapa jam.

  Setelah failover selesai, Anda bertanggung jawab untuk memulihkan cadangan data pendaftaran apa pun.

• Redistribusi: Setelah failover, permintaan dirutekan ke namespace di wilayah sekunder yang menggunakan data hasil replikasi dari wilayah utama. Setelah failover selesai, klien terhubung ke namespace di wilayah sekunder secara otomatis.

Pemulihan wilayah

Jika wilayah utama telah pulih, pengalihan kembali ke namespace utama di wilayah utama mungkin dapat dilakukan. Namespace utama akan menyimpan data pendaftaran dari sebelum pemadaman. Ini akan menjadi proses manual dan Microsoft akan berkomunikasi dengan Anda untuk menjelaskan cara kerjanya.

Setelah wilayah utama pulih, Anda perlu:

• Validasikan status namespace Anda dan datanya.
• Tentukan apakah akan menyinkronkan perubahan data pendaftaran terbaru dari wilayah sekunder kembali ke wilayah utama.

Pengujian untuk mendeteksi kegagalan wilayah

Anda tidak dapat memulai geo-failover. Namun, Anda harus menguji prosedur pemulihan bencana Anda sendiri. Pastikan bahwa registrasi sudah dicadangkan dan Anda dapat memulihkannya ke namespace yang baru.

Solusi multiregion kustom untuk ketahanan

pemulihan bencana geografis metadata yang dikelola Microsoft hanya mereplikasi metadata. Fitur ini dapat memulihkan metadata tersebut ke namespace layanan sekunder, tetapi Anda bertanggung jawab untuk mengimpor pendaftaran perangkat ke namespace tersebut sehingga aplikasi Anda dapat terus beroperasi. Pendekatan ini memerlukan intervensi manual selama bencana dan melibatkan waktu henti.

Jika tujuan pemulihan Anda memerlukan lebih sedikit waktu henti atau intervensi manual, Anda dapat menerapkan solusi multiregion aktif-aktif kustom. Sebarkan namespace Notification Hubs kedua ke wilayah Azure lain sebelumnya.

Nota

Bagian ini menyediakan panduan dasar untuk merancang jenis solusi ini. Anda bertanggung jawab untuk merancang, menerapkan, menguji, menyebarkan, mengalihkan, dan mengelola solusi.

• Failover: Karena namespace kedua adalah sumber daya yang berfungsi, Anda dapat menerapkan logika untuk mendeteksi kegagalan wilayah dan beralih ke namespace tersebut.

• Sinkronisasi: Untuk menjaga hub pemberitahuan kedua tetap sinkron dengan hub pemberitahuan utama, gunakan salah satu opsi berikut:

  • Untuk penginstalan: Gunakan backend aplikasi yang secara bersamaan membuat dan memperbarui penginstalan di kedua hub pemberitahuan. Penginstalan memungkinkan Anda menentukan pengidentifikasi perangkat unik Anda sendiri, yang mendukung skenario replikasi ini. Untuk informasi selengkapnya, lihat sampel RedundantHub.

  • Untuk pendaftaran: Gunakan backend aplikasi yang secara teratur mengekspor pendaftaran dari hub pemberitahuan utama sebagai cadangan dan mengimpornya secara massal ke hub pemberitahuan sekunder. Untuk informasi selengkapnya, lihat Mengekspor dan mengimpor pendaftaran Azure Notification Hubs secara massal.

  Atau, jika Anda tidak memiliki backend, konfigurasikan aplikasi Anda untuk membuat penginstalan di kedua hub saat aplikasi dimulai pada perangkat target. Perangkat membuat pendaftaran baru di kedua pusat notifikasi. Akhirnya hub pemberitahuan sekunder memiliki semua perangkat aktif yang terdaftar.

• Pendaftaran dan penginstalan yang kedaluwarsa: Hub pemberitahuan sekunder mungkin memiliki pendaftaran dan penginstalan yang kedaluwarsa. Saat notifikasi push dikirim ke handle yang kedaluwarsa, Notification Hubs secara otomatis membersihkan catatan pendaftaran atau penginstalan yang terkait pada hub notifikasi, berdasarkan respons yang diterima dari server PNS. Anda dapat membersihkan catatan kedaluwarsa dari solusi cadangan pilihan Anda dengan menambahkan logika kustom yang memproses umpan balik dari setiap pengiriman dan menghapus pendaftaran dan penginstalan yang kedaluwarsa.

• Aplikasi yang tidak dibuka: Ada periode waktu di mana perangkat dengan aplikasi yang tidak dibuka tidak menerima pemberitahuan.

• Biaya: Jika Anda menggunakan hub sekunder Anda sendiri untuk melindungi data pendaftaran, hub tersebut dikenakan biaya layanan normal. Demikian pula, jika Anda menyebarkan sumber daya Azure lain ke wilayah sekunder Anda untuk mendukung pemulihan Anda, Anda membayarnya dengan tarif layanan normal.

Pencadangan dan pemulihan

Notification Hubs tidak menyediakan satu fitur pencadangan dan pemulihan bawaan untuk semua data yang disimpan di namespace Anda. Anda bertanggung jawab untuk menggabungkan pendekatan berikut:

• Gunakan infrastruktur sebagai kode (IaC), seperti Bicep, untuk menentukan namespace, hub, dan konfigurasi kebijakan Anda. Simpan definisi tersebut dalam kontrol sumber sehingga Anda dapat menyebarkan ulang sumber daya jika diperlukan.
• Buat cadangan data pendaftaran perangkat Anda dengan mengekspor pendaftaran Azure Notification Hubs secara massal.

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.

Untuk Notification Hubs, SLA ketersediaan berlaku untuk namespace yang menggunakan tingkat Basic dan Standard.

Konten terkait

• Keandalan di Azure