Keandalan dalam Azure Functions

Azure Functions adalah layanan komputasi berbasis peristiwa yang menjalankan blok kecil kode, atau fungsi, tanpa penyediaan atau manajemen infrastruktur eksplisit. Fungsi dapat merespons peristiwa seperti permintaan HTTP, timer, pesan antrean, dan perubahan dalam layanan Azure lainnya. Kemampuan ini membuat Functions sangat cocok untuk pemrosesan data, integrasi sistem, dan tugas latar belakang.

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 Functions 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 Functions (SLA).

Rekomendasi penyebaran produksi

Azure Well-Architected Framework memberikan rekomendasi dalam hal reliabilitas, keamanan, biaya, operasi, dan performa. Untuk mempelajari bagaimana area ini saling memengaruhi dan berkontribusi pada solusi Functions yang andal, lihat Praktik terbaik arsitektur untuk Functions.

Gambaran umum arsitektur keandalan

Saat Anda menyebarkan Functions, penting untuk membiasakan diri dengan konsep-konsep ini:

• Paket hosting: Paket mewakili lingkungan hosting untuk aplikasi fungsi Anda. Rencana menentukan sumber daya komputasi, model harga, dan perilaku penskalaan yang tersedia.

• Akun penyimpanan: Saat membuat aplikasi fungsi, Anda harus menentukan akun penyimpanan host. Akun penyimpanan mengelola berbagai aspek operasi internal aplikasi fungsi, termasuk penyimpanan kode fungsi, pencatatan, dan manajemen keserentakan (seperti penyewaan blob untuk tipe pemicu tertentu).

  Anda juga dapat menggunakan akun penyimpanan untuk penyebaran. Akun penyimpanan ini mungkin sama dengan akun penyimpanan host Anda atau akun penyimpanan yang berbeda.

  Penting

  Akun penyimpanan adalah bagian penting dari arsitektur keandalan Functions Anda. Konfigurasikan untuk memenuhi persyaratan ketahanan aplikasi fungsi Anda.

• Pemicu dan pengikatan: Pemicu dan pengikatan memungkinkan fungsi Anda merespons peristiwa, menerima data dari layanan lain, dan menulis data ke layanan lain.

• Fungsi tahan lama: Fungsi tahan lama adalah fitur Functions. Ini menyediakan fungsi stateful seperti orkestrasi yang berjalan lama dan entitas stateful.

  Saat Anda menggunakan fungsi tahan lama, Anda mengonfigurasi penyedia penyimpanan yang menyimpan status. Evaluasi karakteristik keandalan penyimpanan status yang Anda pilih dan konfigurasikan untuk memenuhi persyaratan ketahanan Anda.

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.

Pertimbangkan rekomendasi berikut untuk menangani kesalahan sementara di aplikasi fungsi Anda:

• Pemicu dan pengikatan: Platform Functions mencakup penanganan kesalahan sementara bawaan untuk pemicu dan pengikatan. Ketika kesalahan sementara terjadi saat pemicu yang didukung diaktifkan atau pengikatan yang didukung membaca atau menulis data, platform dapat secara otomatis mencoba kembali operasi. Perilaku coba lagi bawaan ini memastikan bahwa masalah konektivitas sementara atau gangguan layanan tidak mencegah fungsi Anda berjalan. Untuk informasi selengkapnya, lihat Penanganan dan percobaan ulang kesalahan Functions.

  Perlindungan ini hanya mencakup kesalahan sementara. Platform tidak mencoba kembali kegagalan persisten, seperti string koneksi yang salah dikonfigurasi atau sumber daya yang dihapus.

  Platform ini memperlakukan kegagalan persisten dan kegagalan sementara berulang sebagai kesalahan. Konfigurasikan pengelogan untuk mengambil informasi tentang kesalahan eksekusi fungsi. Untuk informasi selengkapnya, lihat Mengonfigurasi pemantauan untuk Functions.

• Kode fungsi Anda: Dalam kode fungsi, Anda bertanggung jawab untuk menangani kesalahan sementara saat fungsi Anda memanggil layanan eksternal. Terapkan logika coba lagi, batas waktu, dan pola pemutus sirkuit yang sesuai untuk panggilan layanan eksternal yang dilakukan dalam kode fungsi Anda. Rancang fungsi Anda agar idempogen jika memungkinkan sehingga percobaan ulang tidak membuat efek samping duplikat.

• Klien: Aplikasi klien yang terhubung ke fungsi secara sinkron, seperti melalui koneksi HTTP, harus tahan terhadap kesalahan sementara.

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.

Paket konsumsi tidak mendukung zona ketersediaan. Jika redundansi zona adalah persyaratan untuk beban kerja Anda, pertimbangkan untuk menggunakan paket Konsumsi Flex, Premium, atau Khusus (Azure App Service) sebagai gantinya.

Paket Konsumsi Flex mendukung penyebaran zona redundan.

Paket premium mendukung penyebaran yang redundan zona.

Saat redundansi zona diaktifkan, platform secara otomatis menyebarkan instans paket Anda di semua zona ketersediaan di wilayah yang dipilih. Jika ada zona ketersediaan di wilayah yang mengalami masalah, fungsi Anda akan terus berjalan menggunakan instans di zona yang sehat.

Anda harus mengaktifkan penyimpanan zona-redundan (ZRS) pada akun penyimpanan host, yang memastikan bahwa penyimpanan tersebut juga tahan terhadap pemadaman zona.

Diagram menunjukkan tiga zona ketersediaan. Setiap zona berisi instance Functions. Akun ZRS mencakup ketiga zona ketersediaan.

Paket Dedicated (App Service) mendukung penerapan yang redundan zona. Saat redundansi zona diaktifkan, platform secara otomatis menyebarkan instans Anda di semua zona ketersediaan di wilayah yang dipilih. Anda mengonfigurasi redundansi zona pada rencana. Untuk informasi selengkapnya tentang cara Azure App Service menangani redundansi zona, lihat Reliability di App Service.

Paket Anda nonzonal atau regional ketika Anda tidak mengaktifkan redundansi zona. Platform ini dapat menempatkan instance paket di zona ketersediaan apa pun di wilayah yang sama atau di zona yang sama. Instans rencana tidak tangguh menghadapi kegagalan zona ketersediaan. Rencana Anda mungkin mengalami waktu henti selama terjadi pemadaman di zona apa pun di wilayah tersebut.

Persyaratan

• Dukungan wilayah: Anda dapat menyebarkan paket Konsumsi Fleksibel zona-redundan ke dalam sekumpulan wilayah tertentu. Anda dapat mengambil daftar wilayah yang didukung saat ini dengan menggunakan Azure CLI. Untuk informasi selengkapnya, lihat Menampilkan wilayah yang mendukung zona ketersediaan.

• Dukungan wilayah: Anda dapat menyebarkan paket Premium zona-redundan ke wilayah berikut.

  Americas	Eropa	Timur Tengah	Africa	Asia Pasifik
  Brasil Selatan	Prancis Tengah	Israel Tengah	Afrika Selatan Utara	Australia Timur
  Kanada Tengah	Jerman Barat Tengah	Qatar Tengah		India Tengah
  US Tengah	Italia Utara	UAE Utara		Tiongkok Utara 3
  US Timur	Eropa Utara			Asia Timur
  US Timur 2	Norwegia Timur			Jepang Timur
  US Tengah Selatan	Swedia Tengah			Asia Tenggara
  Barat AS 2	Swiss Utara
  Barat AS 3	UK Selatan
  	Eropa Barat

• Operating systems: Platform ini mendukung penyebaran paket zona-redundan Windows dan Linux.

• Jumlah instans minimum: Redundansi zona untuk paket Premium memerlukan minimal dua instans yang selalu siap.

• Akun penyimpanan host: Anda harus mengonfigurasi akun penyimpanan host default aplikasi fungsi Anda untuk menggunakan ZRS. Jika Anda menggunakan akun penyimpanan host yang tidak dikonfigurasi untuk ZRS, aplikasi Anda mungkin berperilaku tidak terduga selama pemadaman zona.

• Akun penyimpanan kontainer penyebaran: Jika Anda menggunakan akun penyimpanan terpisah untuk kontainer penyebaran aplikasi, perbarui juga menjadi zona redundan.

Pertimbangan

Perilaku nonruntime: Redundansi zona hanya menjamin keberlangsungan operasional untuk aplikasi yang disebarkan. Gangguan zona ketersediaan mungkin memengaruhi beberapa aspek dari Functions, meskipun aplikasi tetap beroperasi dan melayani permintaan. Perilaku ini termasuk penskalaan rencana, pembuatan aplikasi, konfigurasi aplikasi, dan penerbitan aplikasi.

Distribusi instans di seluruh zona

Saat Anda mengonfigurasi aplikasi paket Konsumsi Flex sebagai zona redundan, platform secara otomatis menyebarkan instans paket di beberapa zona di wilayah yang dipilih, dengan aturan yang berbeda untuk instans yang selalu siap versus sesuai permintaan:

• Instans yang selalu siap didistribusikan di setidaknya dua zona dengan menggunakan distribusi round-robin.

  Untuk memastikan ketahanan zona, platform secara otomatis mempertahankan setidaknya dua instans yang selalu siap untuk setiap fungsi atau grup penskalaan per fungsi, terlepas dari konfigurasi yang selalu siap untuk aplikasi. Instans yang dibuat oleh platform dikelola oleh platform, ditagih sebagai instans yang selalu siap pakai, dan tidak mengubah pengaturan konfigurasi dari status selalu siap tersebut.

• Instance sesuai permintaan dihasilkan dari volume sumber peristiwa saat aplikasi berkembang melebihi jumlah instance yang selalu siap. Instans sesuai permintaan didistribusikan di seluruh zona ketersediaan berdasarkan upaya terbaik. Platform ini memprioritaskan peluasan skala yang lebih cepat daripada distribusi yang merata di seluruh zona. Platform mencoba untuk meratakan distribusi dari waktu ke waktu.

Saat Anda mengonfigurasi paket aplikasi fungsi Elastic Premium sebagai zona redundan, platform secara otomatis menyebarkan instans paket di beberapa zona di wilayah yang dipilih. Penyebaran instans mengikuti aturan ini, bahkan saat aplikasi menskalakan masuk dan keluar:

• Jumlah minimum instans aplikasi fungsi adalah dua.

• Ketika Anda menentukan kapasitas yang lebih besar dari jumlah zona, instans tersebar secara merata hanya ketika kapasitas adalah kelipatan dari jumlah zona.

• Untuk nilai kapasitas yang lebih besar dari jumlah zona yang dikalikan dengan jumlah instans, instans tambahan akan tersebar di seluruh zona yang tersisa.

Ketika Functions mengalokasikan instans ke paket Premium zona-redundan, ia menggunakan penyeimbangan zona dengan upaya terbaik, yang disediakan oleh Kumpulan Skala Komputer Virtual Azure yang mendasarinya. Azure mempertimbangkan paket Premium balanced ketika setiap zona memiliki jumlah komputer virtual (VM) yang sama dengan zona lain dalam paket, ditambah atau dikurangi satu VM.

Biaya

Anda tidak dikenakan biaya tambahan saat mengaktifkan redundansi zona. Harga untuk paket redundansi zona sama dengan paket zona tunggal. Namun, mengaktifkan redundansi zona memengaruhi jumlah minimum instans pada rencana Anda.

Saat Anda mengaktifkan zona ketersediaan di aplikasi dengan konfigurasi instans yang selalu siap kurang dari dua instans untuk setiap fungsi atau grup penskalaan per fungsi, platform secara otomatis membuat dua instans jenis yang selalu siap untuk setiap fungsi atau grup penskalaan per fungsi. Instans baru ini juga disebut sebagai instans yang selalu siap digunakan.

Jika Anda mengaktifkan zona ketersediaan pada paket yang memiliki kurang dari dua instans, platform memberlakukan jumlah instans minimum dua untuk paket tersebut, dan Anda dikenakan biaya untuk kedua instans.

Untuk detail harga lengkap, lihat Harga Functions.

Mengonfigurasi dukungan zona ketersediaan

• Buat rencana Functions zona redundan baru. Anda dapat mengaktifkan redundansi zona saat membuat rencana baru. Untuk informasi selengkapnya, lihat Membuat aplikasi fungsi zona redundan.

• Aktifkan redundansi zona pada rencana yang sudah ada. Anda dapat mengaktifkan atau menonaktifkan zona ketersediaan untuk paket Elastic Premium yang ada. Paket Elastic Premium memiliki perilaku kapasitas khusus yang berbeda dari paket Dedicated (App Service) dan memerlukan langkah-langkah konfigurasi tambahan. Untuk langkah-langkah mendetail, lihat Mengaktifkan redundansi zona pada paket yang sudah ada.

• Buat rencana Functions redundan zona baru. Anda dapat mengaktifkan redundansi zona saat membuat rencana baru. Untuk informasi selengkapnya, lihat Membuat aplikasi fungsi zona-redundan.

• Aktifkan redundansi zona pada paket yang ada. Untuk paket Premium, Anda hanya dapat mengaktifkan redundansi zona selama pembuatan paket. Anda tidak dapat mengonversi paket Premium yang ada menjadi zone-redundant. Sebagai gantinya, migrasikan aplikasi Anda dengan membuat penyebaran berdampingan pada aplikasi paket Premium baru. Untuk informasi selengkapnya, lihat Aktifkan redundansi zona pada paket yang sudah ada.

Perencanaan dan manajemen kapasitas

Aplikasi fungsi dengan redundansi zona terus berjalan meskipun terjadi pemadaman di zona wilayah tersebut.

Selama pemadaman zona, Functions mendeteksi instans yang hilang dan secara otomatis mencoba menemukan atau membuat instans pengganti di zona sehat. Platform melakukan proses ini berdasarkan upaya terbaik dan tidak menjamin keberhasilan. Jika beban kerja Anda memerlukan sejumlah instans tertentu untuk mempertahankan tingkat layanan yang diharapkan, pertimbangkan untuk menyediakan jumlah instans yang selalu siap secara berlebihan . Provisi berlebih memungkinkan solusi mentolerir kehilangan kapasitas dan terus berfungsi tanpa mengurangi performa. Untuk informasi selengkapnya, lihat Mengelola kapasitas dengan pengalokasian berlebih.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang dapat diharapkan ketika rencana memiliki redundansi zona, akun penyimpanan host menggunakan ZRS, dan semua zona ketersediaan beroperasi.

• Operasi lintas zona: Saat Anda mengonfigurasi redundansi zona pada Functions, permintaan secara otomatis tersebar di setiap instans di setiap zona ketersediaan. Permintaan mungkin ditujukan ke instans mana pun di zona ketersediaan mana pun.

• Replikasi data lintas zona: Functions adalah layanan komputasi stateless, sehingga tidak ada data untuk direplikasi antar zona. Platform mereplikasi konfigurasi di seluruh zona secara otomatis.

  Jika akun penyimpanan host Anda menggunakan ZRS, Azure Storage secara sinkron mereplikasi datanya di beberapa zona ketersediaan.

  Untuk fungsi tahan lama, tinjau penyedia penyimpanan Anda untuk mempelajari caranya mereplikasi data di seluruh zona.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika rencana memiliki redundansi zona, akun penyimpanan host menggunakan ZRS, dan pemadaman zona ketersediaan terjadi.

• Deteksi dan respons: Platform Functions bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan. Anda tidak perlu 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: Ketika zona ketersediaan tidak tersedia, permintaan yang sedang berlangsung yang terhubung ke instans di zona ketersediaan yang rusak dihentikan dan harus dicoba kembali. Pastikan aplikasi Anda disiapkan dengan mengikuti panduan penanganan kesalahan sementara.

• Potensi kehilangan data: Kegagalan zona tidak diharapkan menyebabkan kehilangan data karena Functions adalah layanan tanpa status.

  Jika akun penyimpanan host Anda menggunakan ZRS, Storage memastikan tidak ada kehilangan data dari kegagalan zona.

  Untuk fungsi tahan lama, tinjau penyedia penyimpanan Anda untuk mempelajari apakah kehilangan data dimungkinkan selama kegagalan zona.

• Waktu henti yang diharapkan: Selama pemadaman zona, koneksi mungkin mengalami gangguan singkat yang biasanya berlangsung beberapa detik saat lalu lintas didistribusikan ulang. Pastikan aplikasi Anda disiapkan dengan mengikuti panduan penanganan kesalahan sementara.

• Pengalihan lalu lintas: Functions mendeteksi instans yang hilang dari zona tersebut dan mencoba menemukan instans pengganti baru. Setelah Functions menemukan penggantian, Functions mendistribusikan lalu lintas di seluruh instans baru sesuai kebutuhan.

  Penting

  Azure tidak menjamin bahwa permintaan untuk lebih banyak instans berhasil dalam skenario penurunan zona. Platform ini mencoba mengisi ulang instans yang hilang berdasarkan upaya terbaik. Jika Anda memerlukan kapasitas yang dijamin selama kegagalan zona ketersediaan, buat dan konfigurasikan rencana Anda untuk memperhitungkan kehilangan zona dengan menyediakan kapasitas secara berlebihan.

• Perilaku non-runtime: Aplikasi dalam paket aplikasi fungsi zona-redundan tetap berjalan dan menyediakan layanan lalu lintas meskipun zona ketersediaan mengalami pemadaman. Namun, perilaku nonruntime mungkin terpengaruh selama pemadaman zona ketersediaan. Perilaku ini termasuk penskalaan aplikasi fungsi, pembuatan aplikasi, konfigurasi aplikasi, dan penerbitan aplikasi.

Pemulihan Zona

Saat zona ketersediaan pulih, Functions secara otomatis memulihkan instans di zona ketersediaan, menghapus instans sementara yang dibuat di zona ketersediaan lain, dan mengalihkan lalu lintas antara instans Anda seperti biasa.

Uji kegagalan zona

Platform Functions mengelola perutean lalu lintas, failover, dan pemulihan zona untuk sumber daya zona redundan. Anda tidak perlu memulai apa pun. Azure sepenuhnya mengelola fitur ini, sehingga Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan.

Ketahanan terhadap kegagalan di seluruh wilayah

Functions adalah layanan yang tersedia di satu wilayah. Jika wilayah menjadi tidak tersedia, sumber daya Functions Anda juga tidak tersedia.

Solusi multi-wilayah kustom untuk ketahanan

Untuk menghindari gangguan pada layanan Anda selama pemadaman di seluruh wilayah, Anda dapat menyebarkan fungsi yang sama secara berlebihan untuk memfungsikan aplikasi di beberapa wilayah.

Anda bertanggung jawab untuk:

• Menyebarkan aplikasi fungsi ke beberapa wilayah.

• Mengelola distribusi lalu lintas antar wilayah.

• Menerapkan mekanisme failover.

• Memastikan konsistensi data di seluruh wilayah (jika berlaku).

• Memantau dan mengelola penyebaran lintas wilayah.

Saat Anda menjalankan kode fungsi yang sama di beberapa wilayah, pertimbangkan pola aktif-aktif dan pasif . Bagian berikut memperkenalkan pola-pola ini tetapi tidak memberikan panduan terperinci atau langkah-langkah konfigurasi.

Pola aktif-aktif untuk fungsi pemicu HTTP

Dalam pola aktif-aktif, fungsi di kedua wilayah secara aktif menjalankan dan memproses peristiwa, baik secara duplikat atau dalam rotasi. Gunakan pola aktif-aktif dalam kombinasi dengan Azure Front Door untuk fungsi penting yang dipicu HTTP Anda, yang dapat merutekan permintaan HTTP secara round-robin antar fungsi yang berjalan di beberapa region. Azure Front Door juga dapat secara berkala memeriksa kesehatan setiap titik akhir. Jika fungsi di satu wilayah berhenti merespons pemeriksaan kesehatan, Azure Front Door menghapusnya dari rotasi dan hanya meneruskan lalu lintas ke fungsi sehat yang tersisa.

Diagram menunjukkan Azure Front Door di bagian atas. Dua wilayah muncul di bawah ini: wilayah utama di sebelah kiri dan wilayah sekunder di sebelah kanan. Setiap wilayah berisi aplikasi Functions dan database. Panah menunjuk dari Azure Front Door ke kedua aplikasi fungsi. Panah menunjuk dari setiap aplikasi fungsi ke database masing-masing.

Pola pasif aktif untuk fungsi pemicu non-HTTP

Untuk fungsi berbasis peristiwa yang tidak dipicu HTTP (seperti pemicu Azure Service Bus dan Azure Event Hubs), gunakan pola pasif aktif. Dalam pola aktif-pasif, instans fungsi berjalan di wilayah yang menerima peristiwa, sementara instans di wilayah sekunder tetap menganggur. Pola ini memastikan bahwa hanya satu fungsi yang memproses setiap pesan, yang membantu menjaga konsistensi data. Ini juga menyediakan cara untuk melakukan failover ke wilayah sekunder selama bencana seperti pemadaman wilayah.

Pertimbangkan failover aplikasi fungsi bersama dengan perilaku failover layanan lainnya yang Anda gunakan, seperti:

• Bus Layanan replikasi geografis dan pemulihan bencana geografis
• Replikasi geografis Azure Event Hubs dan pemulihan bencana geografis

Pertimbangkan contoh topologi yang menggunakan pemicu Event Hubs, di mana namespace Event Hubs Anda dikonfigurasi untuk pemulihan bencana geografis. Dalam hal ini, pola pasif aktif memerlukan komponen berikut:

• Namespace layanan Azure Event Hubs disebarkan ke wilayah utama dan sekunder.

• Pemulihan bencana geografis diaktifkan untuk memasangkan hub peristiwa primer dan sekunder. Konfigurasi ini juga membuat alias yang dapat Anda gunakan untuk menyambungkan ke namespace Layanan Pusat Aktivitas dan mengalihkan alias dari primer ke sekunder tanpa perubahan pada info koneksi.

• Aplikasi fungsi disebarkan ke wilayah utama dan sekunder. Aplikasi di wilayah sekunder tetap menganggur karena tidak menerima pesan.

• Setiap perangkat pemicu aplikasi fungsi menggunakan direct (nonalias) string koneksi untuk setiap namespace pada Azure Event Hubs.

• Penerbit pada namespace Event Hubs memublikasikan ke alias string koneksi.

Diagram menunjukkan wilayah utama di sebelah kiri dan wilayah sekunder di sebelah kanan. Wilayah utama berisi namespace layanan Azure Event Hubs aktif, aplikasi fungsi, dan database. Wilayah sekunder berisi Event Hubs namespace pasif, aplikasi fungsi, dan database. Sebuah panah menunjuk dari alias ke pemulihan bencana geografis Event Hubs, yang menghubungkan namespace Event Hubs primer dan sekunder. Panah mengarah dari setiap hub acara ke aplikasi fungsi masing-masing. Panah menunjuk dari setiap aplikasi fungsional ke database yang sesuai.

Sebelum failover, penerbit yang mengirimkan peristiwa ke alias bersama mengarahkan lalu lintas ke hub peristiwa utama. Aplikasi fungsi utama mendengarkan secara eksklusif ke hub peristiwa utama. Aplikasi fungsi sekunder tetap pasif dan menganggur.

Saat failover dimulai, penerbit yang mengirimkan peristiwa ke alias bersama dialihkan ke event hub sekunder. Aplikasi fungsi sekunder menjadi aktif dan memicu secara otomatis. Hub peristiwa dapat mendorong seluruh proses failover, dan setiap aplikasi fungsi hanya berjalan saat hub peristiwa yang sesuai aktif.

Fungsi tahan lama

Untuk pemulihan bencana multi-wilayah untuk fungsi durable, lihat Pemulihan bencana dan geodistribusi dalam fungsi Azure durable.

Ketahanan terhadap pemeliharaan layanan

Fungsi melakukan peningkatan layanan reguler dan tugas pemeliharaan lainnya.

• Ketahanan kesalahan sementara: Selama pemeliharaan layanan, instans yang menjalankan aplikasi fungsi Anda mungkin memulai ulang atau mengalami gangguan sementara. Pastikan aplikasi klien yang berinteraksi dengan aplikasi fungsi Anda tahan terhadap kesalahan sementara.

• Aktifkan redundansi zona: Saat mengaktifkan redundansi zona pada paket, Anda juga meningkatkan ketahanan selama pembaruan platform. Menyebarkan beberapa instans dalam paket Anda dan mengaktifkan redundansi zona untuk paket Anda menambahkan lapisan ketahanan tambahan jika instans atau zona menjadi tidak sehat selama peningkatan.

• Instans sementara tambahan: Untuk mempertahankan kapasitas yang diharapkan selama peningkatan, platform secara otomatis menambahkan instans tambahan paket selama proses peningkatan.

• Aktifkan redundansi zona: Saat mengaktifkan redundansi zona pada paket, Anda juga meningkatkan ketahanan selama pembaruan platform. Domain pembaruan terdiri dari kumpulan VM yang offline selama pembaruan, dan dipetakan ke zona ketersediaan. Menyebarkan beberapa instans dalam paket Anda dan mengaktifkan redundansi zona untuk paket Anda menambahkan lapisan ketahanan tambahan jika instans atau zona menjadi tidak sehat selama peningkatan.

• Lingkungan App Service: Jika Anda menghosting aplikasi fungsi di Lingkungan App Service, Anda dapat menyesuaikan siklus peningkatan. Jika Anda harus memvalidasi efek peningkatan pada beban kerja Anda, aktifkan peningkatan manual. Gunakan pendekatan ini untuk memvalidasi dan menguji instans nonproduksi sebelum Anda menerapkan peningkatan ke instans produksi Anda.

  Untuk informasi selengkapnya tentang preferensi pemeliharaan, lihat Preferensi peningkatan untuk pemeliharaan terencana di App Service Environment.

Ketahanan terhadap penyebaran aplikasi

Penyebaran aplikasi memperkenalkan risiko masalah di lingkungan produksi. Bersiaplah untuk mengembalikan pembaruan jika menyebabkan masalah. Kontrol bagaimana pembaruan diluncurkan untuk mengurangi gangguan dari mulai ulang aplikasi.

Paket Konsumsi Flex mendukung strategi pembaruan situs, yang menyediakan beberapa cara untuk menyebarkan pembaruan aplikasi Anda. Strategi ini termasuk pembaruan bergulir untuk penyebaran tanpa waktu henti.

Deployment slots Functions memungkinkan aplikasi fungsi Anda untuk menyebar tanpa downtime. Gunakan slot penyebaran untuk meminimalkan efek penyebaran dan perubahan konfigurasi bagi pengguna Anda. Slot penyebaran juga mengurangi kemungkinan aplikasi Anda diluncurkan ulang. Mulai ulang aplikasi menyebabkan kesalahan sementara.

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.

Functions menyediakan SLA ketersediaan yang berbeda untuk paket Konsumsi dan untuk jenis paket lainnya.

Konten terkait

• Pemulihan bencana dan distribusi geo dalam Fungsi Azure Durable
• Buat Azure Front Door
• Pertimbangan kegagalan Event Hubs
• Strategi arsitektur untuk cara menggunakan zona dan wilayah ketersediaan
• Keandalan di Azure