Keandalan di Azure Event Grid

Azure Event Grid adalah layanan olahpesan terkelola penuh yang memungkinkan komunikasi berbasis peristiwa antara layanan dan aplikasi. Ini umumnya digunakan untuk membangun arsitektur berbasis peristiwa dan mengintegrasikan layanan Azure dengan aplikasi kustom.

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 Event Grid tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, kegagalan zona ketersediaan, dan kegagalan di seluruh wilayah. Ini juga menyoroti informasi utama tentang perjanjian tingkat layanan (SLA) Event Grid.

Rekomendasi penyebaran produksi

Kerangka kerja Azure Well-Architected memberikan rekomendasi untuk keandalan, keamanan, biaya, operasi, dan performa. Untuk memahami bagaimana area ini saling memengaruhi dan berkontribusi pada solusi Event Grid yang andal, lihat praktik terbaik Arsitektur untuk Azure Event Grid.

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

Event Grid menyalurkan peristiwa dari penerbit ke konsumen. Ini digunakan oleh aplikasi pelanggan dan layanan Azure untuk memancarkan dan menggunakan peristiwa, seperti pemberitahuan saat sumber daya dibuat, diperbarui, atau dihapus.

Event Grid mendukung beberapa jenis sumber daya dan model penyebaran:

  • Topik adalah entitas utama yang menerima dan menyimpan peristiwa.

    Topik sistem dibuat secara otomatis oleh layanan Azure untuk memancarkan peristiwa untuk jenis sumber daya Azure tertentu. Topik kustom dibuat dan dikelola oleh Anda.

    Topik mampu mendukung pengiriman push dan pull.

  • Domain peristiwa mengelompokkan beberapa topik kustom di bawah satu titik akhir untuk menyederhanakan penerbitan peristiwa. Untuk informasi selengkapnya, lihat Memahami domain peristiwa untuk mengelola topik Event Grid.

  • Namespace digunakan dengan tingkat Standar, dan menyediakan kontainer untuk beberapa sumber daya Event Grid. Untuk informasi selengkapnya, lihat Konsep namespace Layanan Azure Event Grid.

Event Grid mendukung beberapa tingkatan, termasuk tingkat Dasar dan tingkat Standar. Tingkatan ini menyediakan kemampuan yang berbeda, dan berbeda dalam cara sumber daya disebarkan dan dikelola. Untuk informasi selengkapnya, lihat Memilih tingkat Event Grid yang tepat untuk solusi Anda.

Arsitektur fisik

Event Grid adalah layanan yang dikelola sepenuhnya. Microsoft mengelola infrastruktur yang mendasar, termasuk sumber daya komputasi dan penyimpanan. Di wilayah yang didukung, Event Grid secara otomatis mendistribusikan sumber daya di seluruh zona ketersediaan untuk menyediakan redundansi zona bawaan.

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.

Saat Anda menggunakan Event Grid, pertimbangkan praktik berikut untuk memastikan solusi Anda tahan terhadap kesalahan sementara:

  • Penerbit peristiwa. Saat aplikasi klien menerbitkan peristiwa ke Event Grid, aplikasi tersebut bertanggung jawab untuk menangani kegagalan sementara. Aplikasi harus menerapkan logika coba lagi saat mereka menerbitkan peristiwa. Untuk informasi selengkapnya, lihat Memecahkan masalah konektivitas sementara.

    Kami menyarankan agar Anda menggunakan SDK sarana data Event Grid, yang secara otomatis menyediakan penanganan kesalahan sementara.

  • Pengguna acara Event Grid mengirimkan peristiwa ke tujuan yang dikonfigurasi. Untuk koneksi keluar ini, Anda mengonfigurasi kebijakan percobaan ulang pada langganan peristiwa. Kebijakan ini menentukan seberapa sering dan berapa lama Event Grid mencoba kembali pengiriman ketika kegagalan terjadi, termasuk kesalahan sementara. Untuk informasi selengkapnya, lihat Pengiriman push pesan dan coba lagi dengan topik namespace.

  • Idempotensi. Ini adalah praktik yang baik untuk merancang arsitektur eventing Anda untuk idempotensi, yang berarti bahwa aplikasi Anda dapat menerima dan memproses event yang sama dengan aman beberapa kali. Misalnya, jika kesalahan sementara atau masalah lain terjadi saat aplikasi Anda memproses peristiwa, dengan pendekatan idempogen, aplikasi Anda dapat memproses ulang pesan dan memulihkan.

    Anda bertanggung jawab untuk merancang arsitektur dan aplikasi acara Anda untuk mendukung idempotensi. Untuk informasi umum, lihat Idempotensi.

  • Surat mati. Event Grid mendukung dead-lettering untuk peristiwa yang tidak dapat dikirimkan, yang membantu mempertahankan data selama kesalahan jangka panjang pada konsumen peristiwa. Untuk informasi selengkapnya, lihat Dead Lettering untuk langganan peristiwa pada topik namespace di Event Grid.

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.

Sumber daya Event Grid bersifat redundan antar zona di wilayah yang mendukung zona ketersediaan. Redundansi zona berarti bahwa bahkan ketika zona ketersediaan bermasalah, sumber daya Event Grid Anda terus berfungsi dengan menggunakan infrastruktur di zona lain. Data peristiwa secara otomatis direplikasi di tiga zona ketersediaan untuk ketahanan intra-wilayah, dan Event Grid melakukan penyembuhan mandiri selama terjadi pemadaman di seluruh zona. Anda tidak perlu mengaktifkan atau mengonfigurasi kemampuan ini.

Diagram yang memperlihatkan sumber daya Event Grid zona-redundan di wilayah dengan tiga zona ketersediaan.

Persyaratan

Dukungan wilayah: Redundansi zona tersedia di semua wilayah Azure yang mendukung zona ketersediaan.

Biaya

Tidak ada biaya tambahan untuk redundansi zona. Anda tidak dapat mengaktifkan atau menonaktifkan fitur ini. Ini disertakan secara default di wilayah yang didukung.

Mengonfigurasi dukungan zona ketersediaan

Tidak diperlukan konfigurasi. Semua sumber daya Event Grid di wilayah yang didukung secara otomatis redundan zona.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang dapat diharapkan ketika sumber daya Event Grid memiliki redundansi zona dan semua zona berfungsi dengan baik.

  • Operasi lintas zona: Event Grid beroperasi dalam model aktif-aktif di seluruh zona ketersediaan. Koneksi klien secara otomatis diseimbangkan beban di seluruh zona, dan layanan merutekan operasi ke infrastruktur olahpesan yang tersedia terlepas dari zonanya.

  • Replikasi data lintas zona: Event Grid secara otomatis mereplikasi metadata dan data peristiwa di seluruh zona ketersediaan untuk menjaga ketahanan.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang dapat diharapkan ketika sumber daya Event Grid memiliki redundansi zona dan terjadi pemadaman di salah satu zona.

  • Deteksi dan respons: Event Grid secara otomatis mendeteksi kegagalan zona dan memulai failover ke zona sehat. Anda tidak perlu melakukan apa pun untuk memulai failover zona.
  • 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: Selama kegagalan zona, Event Grid mungkin menghilangkan permintaan aktif. Jika klien Anda menangani kesalahan sementara dengan tepat, seperti dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Kehilangan data yang diharapkan: Model redundansi zona Event Grid dirancang untuk memungkinkan ketahanan terhadap kegagalan zona dengan dampak minimal. Namun, selama kegagalan zona, beberapa kehilangan data dimungkinkan.

    Jika Anda perlu memastikan bahwa aplikasi Anda tidak kehilangan data selama kegagalan zona, Anda harus:

    • Rancang produsen dan konsumen acara Anda untuk mengikuti rekomendasi penanganan kesalahan sementara, termasuk percobaan ulang dan idempotensi.
    • Rencanakan durabilitas peristiwa di sumber atau di penyimpanan peristiwa yang tahan lama.

  • Waktu henti yang diharapkan: Kegagalan zona dapat menyebabkan beberapa detik waktu henti. Jika klien Anda menangani kesalahan sementara dengan tepat, seperti dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Pengalihan lalu lintas: Event Grid mendeteksi hilangnya zona dan secara otomatis mengalihkan permintaan baru ke infrastruktur di salah satu zona ketersediaan sehat.

Pemulihan Zona

Ketika zona yang terpengaruh pulih, Event Grid secara otomatis mengintegrasikannya kembali ke dalam layanan tanpa memerlukan tindakan pelanggan. Zona yang dipulihkan kemudian menerima koneksi baru dan memproses pesan bersama zona lain. Data yang direplikasi ke zona yang bertahan selama pemadaman tetap utuh, dan replikasi normal dilanjutkan di semua zona. Anda tidak perlu mengambil tindakan untuk pemulihan zona atau reintegrasi.

Uji kegagalan zona

Event Grid mengelola perutean lalu lintas, failover, dan pemulihan zona untuk kegagalan zona, sehingga Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan atau memberikan input lebih lanjut.

Ketahanan terhadap kegagalan di seluruh wilayah

Sumber daya Event Grid disebarkan ke dalam satu wilayah. Jika ada kegagalan di seluruh wilayah, sumber daya Event Grid Anda tidak tersedia.

Di wilayah Azure yang dipasangkan, Event Grid menyediakan pemulihan bencana geografis terbatas untuk metadata sumber daya Event Grid Anda. Anda juga dapat merancang dan membangun solusi multiregion Anda sendiri, yang dapat mendukung perencanaan pemulihan bencana Anda. Tabel berikut menunjukkan bagaimana jenis sumber daya Event Grid yang berbeda mendukung setiap model.

Sumber daya Event Grid Mendukung pemulihan bencana geografis Mendukung solusi kustom
Topik khusus Didukung Didukung
Topik sistem Diaktifkan secara otomatis Tidak didukung
Domain Didukung Didukung
Namespace Tidak didukung Didukung
Namespace rekan Tidak didukung Didukung

Pemulihan metadata bencana geo-geografis

Pemulihan bencana geografi mereplikasi metadata Event Grid ke wilayah berpasangan dari wilayah utama Anda bagi sumber daya yang didukung. Data peristiwa tidak direplikasi.

Pemulihan bencana geografis dirancang sebagai upaya terbaik dari Microsoft untuk menyediakan sistem cadangan selama gangguan regional yang serius dan tidak dimaksudkan untuk memberikan waktu pemulihan yang cepat atau dapat diprediksi. Failover yang diinisiasi Microsoft dilakukan oleh Microsoft dalam situasi yang jarang terjadi untuk melakukan fail over sumber daya Event Grid dari wilayah yang terpengaruh ke wilayah yang dipasangkan secara geografis yang terkait. Microsoft berhak menentukan kapan harus menggunakan opsi ini. Mekanisme ini tidak melibatkan persetujuan pelanggan sebelum lalu lintas beralih otomatis.

Penting

Microsoft memicu failover yang dikelola Microsoft. Kemungkinan akan terjadi setelah penundaan yang signifikan dan dilakukan seoptimal mungkin. Failover sumber daya Event Grid mungkin terjadi pada satu waktu yang berbeda dari waktu failover layanan Azure lainnya.

Jika Anda harus tahan terhadap pemadaman wilayah, pertimbangkan untuk menggunakan salah satu solusi multiregion kustom untuk ketahanan.

Anda dapat secara opsional menonaktifkan pemulihan bencana geografis dan menggunakan solusi multiregion kustom Anda sendiri yang memenuhi persyaratan Anda untuk pemilihan wilayah, waktu failover, dan banyak lagi. Saat Anda menonaktifkan pemulihan bencana geografis, Microsoft tidak mereplikasi data peristiwa apa pun ke wilayah lain.

Fitur ini tidak tersedia di wilayah yang tidak memiliki wilayah berpasangan.

Persyaratan

  • Dukungan wilayah: Pemulihan bencana geografis hanya tersedia di wilayah Azure yang memiliki wilayah berpasangan.

  • Jenis sumber daya: Topik dan domain kustom mendukung pemulihan bencana geografis. Topik sistem secara otomatis diaktifkan untuk pemulihan bencana geografis. Jenis sumber daya lainnya, seperti namespace dan namespace mitra, tidak didukung.

Biaya

Tidak ada biaya tambahan untuk pemulihan bencana geografis.

Konfigurasikan dukungan multiregion

Di wilayah yang didukung, topik sistem secara otomatis dikonfigurasi untuk pemulihan bencana geografis. Untuk jenis sumber daya Event Grid lainnya:

  • Untuk mengaktifkan pemulihan bencana geografis: Perbarui konfigurasi untuk topik atau domain Anda dan pilih Lintas Geo (default).

  • Untuk menonaktifkan pemulihan bencana geografis: Perbarui konfigurasi untuk topik atau domain Anda dan pilih Regional.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika sumber daya Event Grid dikonfigurasi untuk pemulihan bencana geografis dan semua wilayah beroperasi.

  • Operasi lintas wilayah: Semua lalu lintas dirutekan ke wilayah utama.

  • Replikasi data lintas wilayah: Metadata direplikasi secara sinkron ke wilayah yang dipasangkan. Data peristiwa tidak direplikasi.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika sumber daya Event Grid dikonfigurasi untuk pemulihan bencana geografis dan ada pemadaman di wilayah utama.

  • Deteksi dan respons: Microsoft mendeteksi kegagalan wilayah dan menentukan apakah dan kapan memulai failover.
  • 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 aktif ke wilayah utama dihentikan. Aplikasi klien harus mencoba kembali permintaan ini setelah failover selesai.

  • Kehilangan data yang diharapkan:

    • Metadata. Event Grid mempertahankan metadata selama failover. Karena semua perubahan metadata direplikasi secara sinkron, tidak ada kehilangan metadata yang diharapkan.

    • Data peristiwa. Data peristiwa di wilayah utama tidak tersedia dan mungkin hilang jika wilayah tersebut tidak dapat dipulihkan.

      Setelah failover terjadi, data baru diproses dari region yang berpasangan. Peristiwa yang belum diproses dikirim dari wilayah utama segera setelah pemadaman diatasi. Jika pemulihan wilayah utama memerlukan waktu yang lebih lama daripada nilai time-to-live yang ditetapkan pada kejadian, data di wilayah utama kemungkinan besar akan dihilangkan. Untuk mengurangi kehilangan data ini, kami sarankan Anda mengonfigurasi tujuan surat mati untuk langganan peristiwa.

      Jika wilayah yang terpengaruh hilang dan tidak dapat dipulihkan, akan ada beberapa kehilangan data. Dalam skenario terbaik, konsumen menyesuaikan dengan kecepatan penerbitan dan hanya beberapa detik data yang hilang. Skenario terburuk terjadi ketika konsumen tidak secara aktif memproses peristiwa. Dengan waktu hidup maksimum 24 jam, kehilangan data bisa sebanyak 24 jam.

      Nota

      Event Grid tidak dapat menjamin retensi data selama pemadaman wilayah. Jika Anda memerlukan retensi terjamin, Anda perlu merancang aplikasi Anda untuk menyimpan data secara permanen di penyimpanan data lain.

  • Waktu henti yang diharapkan: Jumlah waktu henti tergantung pada tingkat keparahan pemadaman dan waktu yang diperlukan Microsoft untuk menilai dan memulai failover. Anda harus mengharapkan waktu henti setidaknya satu jam dan mungkin lebih lama.

    Event Grid mulai menerima lalu lintas untuk topik dan langganan, termasuk untuk operasi pembuatan, pembaruan, dan penghapusan, dalam waktu lima menit setelah failover dimulai.

  • Redistribusi: Setelah failover selesai, lalu lintas secara otomatis dirutekan ke wilayah sekunder.

Pemulihan wilayah

Microsoft mengelola pemulihan wilayah, dan proses pemulihan tergantung pada skenario pemadaman tertentu. Secara umum, failover diperlakukan sebagai operasi satu arah.

Pengujian untuk mendeteksi kegagalan wilayah

Event Grid mengelola perutean lalu lintas, failover, dan pemulihan untuk pemulihan bencana geografis. Anda tidak perlu memulai apa pun. Karena fitur ini dikelola sepenuhnya, Anda tidak perlu memvalidasi proses kegagalan wilayah.

Solusi multiregion kustom untuk ketahanan

Anda mungkin ingin menonaktifkan, atau tidak mengandalkan, failover yang dimulai Microsoft karena salah satu alasan berikut:

  • Anda memerlukan data peristiwa, bukan hanya metadata, untuk direplikasi di seluruh wilayah.

  • Anda perlu menjamin waktu atau pendekatan failover tertentu. Failover yang dimulai Microsoft dilakukan berdasarkan upaya terbaik.

  • Wilayah Anda tidak dipasangkan dengan wilayah Azure lain.

  • Pasangan wilayah di daerah Anda tidak memenuhi persyaratan domisili data dari organisasi Anda.

Untuk tingkat kontrol dan prediksi yang lebih tinggi, Anda dapat menerapkan arsitektur multiregion kustom. Pendekatan ini melibatkan penyebaran sumber daya Event Grid terpisah di beberapa wilayah dan mengelola failover di tingkat aplikasi. Saat menggunakan model ini, Anda bertanggung jawab untuk menyebarkan dan mengonfigurasi sumber daya dan menjaganya tetap sinkron di seluruh wilayah.

Pertimbangkan faktor-faktor berikut saat Anda merancang solusi multiregion:

  • Replikasi. Anda harus menerapkan proses kustom untuk mereplikasi sumber daya Event Grid Anda dan konfigurasinya antara wilayah utama dan sekunder. Ingatlah untuk mereplikasi identitas klien, sertifikat CA, grup klien, ruang topik, dan pengikatan izin, jika berlaku. Anda dapat memutuskan apakah akan menerapkan replikasi manual atau otomatis.

  • Pendekatan failover. Anda dapat memilih apakah akan membuat solusi aktif-aktif atau aktif-pasif.

    • Solusi aktif-aktif dapat dicapai dengan mereplikasi metadata dan menyeimbangkan beban di seluruh namespace.

    • Solusi pasif aktif dapat dicapai dengan mereplikasi metadata untuk menjaga namespace sekunder tetap siap sehingga, ketika namespace utama tidak tersedia, lalu lintas dapat diarahkan ke namespace sekunder.

  • Pemantauan kesehatan. Anda dapat menggunakan API kesehatan bawaan yang disediakan oleh Event Grid untuk memantau kesehatan topik.

    Aplikasi klien Anda harus mendeteksi kegagalan wilayah dan merutekan peristiwa ke wilayah lain yang sesuai.

    Atau, Anda dapat menerapkan layanan pramutamu yang mengarahkan klien ke titik akhir utama atau sekunder untuk topik atau namespace layanan mereka dengan melakukan pemeriksaan kesehatan pada titik akhir tersebut. Layanan pramutamu dapat menjadi aplikasi web yang direplikasi secara geografis dan terus dapat dijangkau melalui teknik atau layanan pengalihan DNS seperti Azure Traffic Manager.

Untuk informasi selengkapnya tentang satu pendekatan, termasuk contoh kode, lihat Implementasi failover sisi klien di Event Grid.

Pencadangan dan pemulihan

Event Grid terutama merupakan layanan perutean event dan tidak memiliki fitur pencadangan atau pemulihan bawaan.

Jika Anda perlu menerapkan kemampuan pencadangan, atau jika Anda memiliki kebutuhan retensi jangka panjang, kami sarankan Anda melakukan pengarsipan di aplikasi Anda. Untuk melakukannya, Anda harus membuat logika untuk merutekan atau menyalin peristiwa Anda ke penyimpanan yang tahan lama, seperti Azure Blob Storage, secara paralel dengan jalur pengiriman utama. Jika sistem hilir tidak tersedia, aplikasi Anda dapat menggunakan arsip untuk memutar ulang peristiwa.

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 diharapkan adanya waktu henti selama kegiatan pemeliharaan kecuali Anda sudah diberitahu melalui pemeliharaan terencana 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.

SLA untuk ketersediaan Event Grid mencakup penerbitan peristiwa.

Konten terkait

  • Last updated on