Keandalan di Azure Functions
Artikel ini menjelaskan dukungan keandalan di Azure Functions, dan mencakup ketahanan intra-regional dengan zona ketersediaan dan pemulihan lintas wilayah dan kelangsungan bisnis. Untuk gambaran umum yang lebih rinci tentang prinsip keandalan di Azure, lihat Keandalan Azure.
Dukungan zona ketersediaan untuk Azure Functions tersedia pada paket Premium (Elastic Premium) dan Dedicated (App Service). Artikel ini berfokus pada dukungan redundansi zona untuk paket Premium. Untuk redundansi zona pada paket Khusus, lihat Memigrasikan App Service ke dukungan zona ketersediaan.
Dukungan zona ketersediaan
Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.
Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.
Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Azure Functions mendukung penyebaran zona-redundan.
Saat Anda mengonfigurasi Functions sebagai zona redundan, platform secara otomatis menyebarkan instans aplikasi fungsi di tiga zona di wilayah yang dipilih.
Instans yang menyebar dengan penyebaran zona-redundan ditentukan di dalam aturan berikut, bahkan saat aplikasi menskalakan masuk dan keluar:
- Jumlah instans aplikasi fungsi minimum adalah tiga.
- Ketika Anda menentukan kapasitas yang lebih besar dari tiga, instans tersebar secara merata hanya ketika kapasitasnya adalah kelipatan 3.
- Untuk nilai kapasitas lebih dari 3*N, instans tambahan tersebar di satu atau dua zona yang tersisa.
Penting
Azure Functions dapat berjalan di platform Azure App Service. Di platform App Service, paket yang menghosting aplikasi fungsi paket Premium disebut sebagai paket Elastic Premium, dengan nama SKU seperti EP1. Jika Anda memilih untuk menjalankan aplikasi fungsi pada paket Premium, pastikan untuk membuat paket dengan nama SKU yang dimulai dengan "E", seperti EP1. Nama SKU paket App Service yang dimulai dengan "P", seperti P1V2 (paket Premium V2 Small), sebenarnya adalah paket hosting Khusus. Karena mereka berdedikasi dan bukan Premium Elastis, paket dengan nama SKU dimulai dengan "P" tidak akan menskalakan secara dinamis dan dapat meningkatkan biaya Anda.
Ketersediaan regional
Paket Premium zona-redundan tersedia di wilayah berikut:
| Amerika | Eropa | Timur Tengah | Afrika | 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 | Arab Saudi Utara | Tiongkok Utara 3 | |
| US Timur | Eropa Utara | Asia Timur | ||
| US Timur 2 | Norwegia Timur | Jepang Timur | ||
| US Tengah Selatan | Swedia Tengah | Asia Tenggara | ||
| US Barat 2 | Swiss Utara | |||
| AS Barat 3 | UK Selatan | |||
| Eropa Barat |
Prasyarat
Dukungan zona ketersediaan adalah properti dari paket Premium. Berikut persyaratan/batasan saat ini untuk mengaktifkan zona ketersediaan:
- Anda hanya dapat mengaktifkan zona ketersediaan saat membuat paket Premium untuk aplikasi fungsi. Anda tidak dapat mengonversi paket Premium yang ada untuk menggunakan zona ketersediaan.
- Anda harus menggunakan akun penyimpanan redundan zona (ZRS) untuk akun penyimpanan aplikasi fungsi Anda. Jika Anda menggunakan jenis akun penyimpanan yang berbeda, Functions dapat menunjukkan perilaku tak terduga selama pemadaman zona.
- Aplikasi Windows dan Linux didukung.
- Harus dihosting pada paket hosting Elastic Premium atau Dedicated. Untuk mempelajari cara menggunakan redundansi zona dengan paket Khusus, lihat Memigrasikan App Service ke dukungan zona ketersediaan.
- Dukungan zona ketersediaan saat ini tidak tersedia untuk aplikasi fungsi dalam paket Konsumsi.
- Aplikasi fungsi yang dihosting di paket Premium juga harus memiliki jumlah instans yang selalu siap minimum, yaitu tiga instans.
- Platform memberlakukan jumlah minimum di belakang layar ini jika Anda menentukan jumlah instans kurang dari tiga.
- Jika Anda tidak menggunakan paket Premium atau unit skala yang mendukung zona ketersediaan, berada di wilayah yang tidak didukung, atau tidak yakin, lihat panduan migrasi.
Harga
Tidak ada biaya tambahan yang terkait dengan mengaktifkan zona ketersediaan. Harga untuk paket Premium App Service zona redundan sama dengan paket Premium zona tunggal. Untuk setiap paket App Service yang Anda gunakan, Anda dikenakan biaya berdasarkan SKU yang Anda pilih, kapasitas yang Anda tentukan, dan instans apa pun yang Anda skalakan berdasarkan kriteria skala otomatis Anda. Jika Anda mengaktifkan zona ketersediaan tetapi menentukan kapasitas kurang dari tiga untuk paket App Service, platform memberlakukan jumlah instans minimum tiga untuk paket App Service tersebut dan menagih Anda untuk ketiga instans tersebut.
Membuat paket Premium dan aplikasi fungsi zona-redundan
Saat ini ada dua cara untuk menyebarkan paket Premium dan aplikasi fungsi zona redundan. Anda harus menggunakan portal Microsoft Azure atau templat ARM.
Di portal Azure, buka halaman Buat Aplikasi Fungsi. Untuk informasi selengkapnya tentang membuat aplikasi fungsi di portal, lihat Membuat aplikasi fungsi.
Pilih Functions Premium lalu pilih tombol Pilih . Artikel ini menjelaskan cara membuat aplikasi zona redundan dalam paket Premium. Redundansi zona saat ini tidak tersedia dalam paket Konsumsi. Untuk informasi tentang redundansi zona pada paket layanan aplikasi, lihat Keandalan di Azure App Service.
Pada halaman Buat Aplikasi Fungsi (Functions Premium), pada tab Dasar , masukkan pengaturan untuk aplikasi fungsi Anda. Beri perhatian khusus pada pengaturan dalam tabel berikut (juga disorot dalam cuplikan layar berikut), yang memiliki persyaratan khusus untuk redundansi zona.
Pengaturan Nilai yang disarankan Catatan untuk redundansi zona Wilayah Wilayah yang didukung pilihan Anda Wilayah tempat aplikasi fungsi baru dibuat. Anda harus memilih wilayah yang mendukung zona ketersediaan. Lihat daftar ketersediaan wilayah. Paket harga Salah satu paket Elastic Premium. Untuk informasi selengkapnya, lihat SKU instans yang tersedia. Artikel ini menjelaskan cara membuat aplikasi zona redundan dalam paket Premium. Redundansi zona saat ini tidak tersedia dalam paket Konsumsi. Untuk informasi tentang redundansi zona pada paket App Service, lihat Keandalan di Azure App Service. Zona redundansi Diaktifkan Pengaturan ini menentukan apakah aplikasi Anda redundan zona. Anda tidak akan dapat memilih Enabledkecuali Anda telah memilih wilayah yang mendukung redundansi zona, seperti yang dijelaskan sebelumnya.
Pada tab Penyimpanan , masukkan pengaturan untuk akun penyimpanan aplikasi fungsi Anda. Beri perhatian khusus pada pengaturan dalam tabel berikut, yang memiliki persyaratan khusus untuk redundansi zona.
Pengaturan Nilai yang disarankan Catatan untuk redundansi zona Akun penyimpanan Akun penyimpanan zona redundan Seperti yang dijelaskan di bagian prasyarat , sebaiknya gunakan akun penyimpanan redundan zona untuk aplikasi fungsi zona redundan Anda. Untuk proses pembuatan aplikasi fungsi lainnya, buat aplikasi fungsi Anda seperti biasa. Tidak ada pengaturan di sisa proses pembuatan yang memengaruhi redundansi zona.
Setelah paket zona-redundan dibuat dan disebarkan, aplikasi fungsi apa pun yang dihosting pada paket baru Anda dianggap zona-redundan.
Migrasi zona ketersediaan
Azure Function Apps saat ini tidak mendukung migrasi instans aplikasi fungsi yang ada di tempat. Untuk informasi tentang cara memigrasikan paket Premium multipenyewa publik dari zona non-ketersediaan ke dukungan zona ketersediaan, lihat Memigrasikan App Service ke dukungan zona ketersediaan.
Pengalaman zona tidak berfungsi
Semua instans aplikasi fungsi yang tersedia dari aplikasi fungsi zona-redundan diaktifkan dan memproses peristiwa. Saat zona tidak berfungsi, Functions mendeteksi instans yang hilang dan secara otomatis mencoba menemukan instans pengganti baru jika diperlukan. Perilaku skala elastis tetap berlaku. Namun, dalam skenario zona yang tidak berfungsi, tidak ada jaminan bahwa permintaan instans tambahan akan berhasil, karena pengisian kembali instans yang hilang terjadi berdasarkan upaya terbaik. Aplikasi yang disebarkan dalam paket Premium yang diaktifkan zona ketersediaan terus berjalan bahkan ketika zona lain di wilayah yang sama mengalami pemadaman. Namun, ada kemungkinan bahwa perilaku non-runtime masih dapat terpengaruh dari gangguan di zona ketersediaan lainnya. Perilaku yang terpengaruh ini mungkin mencakup penskalaan paket Premium, pembuatan aplikasi, konfigurasi aplikasi, dan penerbitan aplikasi. Redundansi zona untuk paket Premium hanya memastikan waktu aktif lanjutan untuk aplikasi yang disebarkan.
Saat mengalokasikan instans ke paket Premium zona redundan, Functions menggunakan penyeimbangan zona upaya terbaik yang ditawarkan oleh Azure Virtual Machine Scale Sets dasar. Paket Premium dianggap seimbang jika setiap zona memiliki jumlah VM yang sama (± 1 VM) di semua zona lain yang digunakan oleh paket Premium.
Pemulihan bencana lintas wilayah dan kelangsungan bisnis
Pemulihan bencana (DR) adalah tentang pemulihan dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.
Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.
Bagian ini menjelaskan beberapa strategi yang dapat Anda gunakan untuk menyebarkan Functions untuk memungkinkan pemulihan bencana.
Untuk pemulihan bencana untuk Durable Functions, lihat Pemulihan bencana dan distribusi geografis di Azure Durable Functions.
Pemulihan bencana multi-wilayah
Karena tidak ada redundansi bawaan yang tersedia, fungsi berjalan di aplikasi fungsi di wilayah Azure tertentu. Untuk menghindari kehilangan eksekusi selama pemadaman, Anda dapat secara berlebihan menerapkan fungsi yang sama untuk berfungsi aplikasi di beberapa wilayah. Untuk mempelajari lebih lanjut tentang penyebaran multi-wilayah, lihat panduan dalam aplikasi web multi-wilayah yang sangat tersedia.
Saat Anda menjalankan kode fungsi yang sama di beberapa wilayah, ada dua pola yang perlu dipertimbangkan, aktif-aktif dan aktif-pasif.
Pola aktif-aktif untuk fungsi pemicu HTTP
Dengan pola aktif-aktif, fungsi di kedua wilayah secara aktif berjalan dan memproses peristiwa, baik secara duplikat atau dalam rotasi. Disarankan agar Anda menggunakan pola aktif-aktif dalam kombinasi dengan Azure Front Door untuk fungsi yang dipicu HTTP penting Anda, yang dapat merutekan dan permintaan HTTP round-robin antara fungsi yang berjalan di beberapa wilayah. Front door juga dapat secara berkala memeriksa kesehatan setiap titik akhir. Ketika fungsi di satu wilayah berhenti merespons pemeriksaan kesehatan, Azure Front Door mengeluarkannya dari rotasi, dan hanya meneruskan lalu lintas ke fungsi sehat yang tersisa.
Penting
Meskipun, sangat disarankan agar Anda menggunakan pola aktif-pasif untuk fungsi pemicu non-HTTPS. Anda dapat membuat penyebaran aktif-aktif untuk fungsi yang dipicu non-HTTP. Namun, Anda perlu mempertimbangkan bagaimana kedua wilayah aktif berinteraksi atau berkoordinasi satu sama lain. Saat Anda menyebarkan aplikasi fungsi yang sama ke dalam dua wilayah dengan masing-masing memicu pada antrean Azure Service Bus yang sama, aplikasi fungsi akan bertindak sebagai konsumen yang saling mengurangi antrean. Meskipun ini berarti setiap pesan hanya diproses oleh salah satu instans, itu juga berarti masih ada satu titik kegagalan pada instans Bus Layanan tunggal.
Anda malah bisa menyebarkan dua antrian Azure Service Bus, dengan satu di wilayah utama, satu di wilayah sekunder. Dalam hal ini, Anda dapat memiliki dua aplikasi fungsi, dengan masing-masing menunjuk ke antrian Azure Service Bus aktif di wilayah mereka. Tantangan dengan topologi ini adalah bagaimana pesan antrian didistribusikan antara kedua wilayah. Seringkali ini mengakibatkan setiap penerbit berusaha menerbitkan pesan ke kedua wilayah, dan setiap pesan diproses oleh kedua aplikasi fungsi aktif. Selain menciptakan pola aktif/aktif yang diinginkan, cara ini juga menimbulkan tantangan lain berupa duplikasi komputasi dan kapan atau bagaimana data dikonsolidasikan.
Pola pasif aktif untuk fungsi pemicu non-HTTPS
Disarankan agar Anda menggunakan pola pasif aktif untuk fungsi yang dipicu berbasis peristiwa dan non-HTTP, seperti fungsi yang dipicu Bus Layanan dan Azure Event Hubs.
Untuk membuat redundansi untuk fungsi pemicu non-HTTP, gunakan pola pasif aktif. Dengan pola pasif aktif, fungsi berjalan secara aktif di wilayah yang menerima peristiwa; sementara fungsi yang sama di wilayah kedua tetap menganggur. Pola aktif-pasif menyediakan cara bagi hanya satu fungsi untuk memproses setiap pesan sambil menyediakan mekanisme untuk melakukan failover ke wilayah sekunder dalam bencana. Aplikasi fungsi bekerja dengan perilaku failover dari layanan mitra, seperti Pemulihan geo Azure Service Bus dan Pemulihan geo Azure Event Hubs.
Pertimbangkan contoh topologi menggunakan pemicu Azure Event Hubs. Dalam hal ini, pola aktif/pasif perlu melibatkan komponen berikut:
- Azure Event Hubs disebarkan ke wilayah utama dan sekunder.
- Bencana geografis diaktifkan untuk memasangkan hub peristiwa primer dan sekunder. Cara ini juga membuat alias yang dapat Anda gunakan untuk menyambungkan ke hub peristiwa dan beralih dari utama ke sekunder tanpa mengubah info koneksi.
- Aplikasi fungsi digunakan ke wilayah primer dan sekunder (failover), dengan aplikasi di wilayah sekunder pada dasarnya menganggur karena pesan tidak dikirim ke sana.
- Aplikasi fungsi memicu string koneksi langsung (non-alias) untuk hub peristiwa masing-masing.
- Penerbit ke hub peristiwa harus menerbitkan ke string koneksi alias.
Sebelum pengalihan kegagalan, penerbit yang mengirim ke alias bersama merutekan ke hub peristiwa utama. Aplikasi fungsi utama mendengarkan secara eksklusif ke hub peristiwa utama. Aplikasi fungsi sekunder adalah pasif dan diam. Segera setelah pengalihan kegagalan dimulai, penerbit yang mengirim ke alias bersama merutekan ke hub peristiwa sekunder. Aplikasi fungsi sekunder sekarang menjadi aktif dan mulai memicu secara otomatis. Pemindahan kegagalan yang efektif ke wilayah sekunder dapat dijalankan sepenuhnya dari hub peristiwa, dengan fungsi yang menjadi aktif hanya ketika hub peristiwa terkait aktif.
Baca lebih lanjut tentang informasi dan pertimbangan untuk pengalihan kegagalan dengan Azure Service Bus dan Azure Event Hubs.