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.
Di Azure Functions, instans aplikasi fungsi tunggal memungkinkan beberapa peristiwa diproses secara bersamaan. Karena ini berjalan pada instans komputasi yang sama, mereka berbagi memori, CPU, dan sumber daya koneksi. Dalam paket hosting tertentu, permintaan tinggi pada instans tertentu menyebabkan host Functions secara otomatis membuat instans baru untuk menangani peningkatan beban. Dalam rencana skala dinamis ini, ada tradeoff antara perilaku konkurensi dan penskalaan. Untuk memberikan kontrol lebih besar atas cara aplikasi Anda berjalan, Functions menyediakan cara bagi Anda untuk mengelola jumlah eksekusi bersamaan.
Functions menyediakan dua cara utama untuk mengelola konkurensi:
- Konkurensi per instans yang tetap: Anda dapat mengonfigurasi batasan tingkat host pada konkurensi yang spesifik untuk setiap pemicu. Model ini adalah perilaku konkurensi default untuk Functions.
- Konkurensi dinamis: Untuk jenis pemicu tertentu, host Functions dapat secara otomatis menentukan tingkat konkurensi terbaik untuk pemicu tersebut di aplikasi fungsi Anda. Anda harus ikut serta dalam model konkurensi ini.
Artikel ini menjelaskan perilaku konkurensi pemicu berbasis peristiwa di Functions dan bagaimana perilaku ini memengaruhi penskalaan dalam rencana dinamis. Ini juga membandingkan model konkurensi tetap per instans dan dinamis.
Penskalaan versus konkurensi
Untuk fungsi yang menggunakan pemicu berbasis peristiwa atau merespons permintaan HTTP, Anda dapat dengan cepat mencapai batas eksekusi bersamaan selama periode permintaan tinggi. Selama periode tersebut, Anda harus dapat menskalakan aplikasi fungsi Anda dengan menambahkan instance untuk menghindari backlog dalam memproses permintaan yang masuk. Cara kami menskalakan aplikasi Anda tergantung pada paket hosting Anda:
| Jenis skala | Paket hosting | Deskripsi |
|---|---|---|
| Penskalakan dinamis (berbasis peristiwa) |
Konsumsi Konsumsi Fleksibel Premium |
Dalam rencana skala dinamis, host menskalakan jumlah instans aplikasi fungsi ke atas atau ke bawah berdasarkan jumlah peristiwa masuk. Untuk informasi selengkapnya, lihat Penskalaan berbasis peristiwa di Azure Functions. |
| Pengaturan ukuran manual | Paket Khusus (App Service) | Saat Anda menghosting aplikasi fungsi Anda dalam paket Dedicated, Anda harus mengonfigurasi instans Anda secara manual selama periode beban tinggi atau menyiapkan skema penskalaan otomatis. |
Sebelum penskalaan mungkin terjadi, aplikasi fungsi Anda mencoba menangani peningkatan beban dengan menangani beberapa pemanggilan jenis yang sama dalam satu instans. Akibatnya, eksekusi bersamaan ini pada instans tertentu berdampak langsung pada keputusan skala. Misalnya, ketika aplikasi dalam rencana skala dinamis mencapai batas konkurensi, aplikasi mungkin perlu menskalakan untuk mengikuti permintaan yang masuk.
Keseimbangan skala versus konkurensi yang coba Anda capai di aplikasi bergantung pada di mana hambatan mungkin terjadi: dalam pemrosesan (batasan proses intensif CPU) atau dalam layanan hilir (batasan berbasis I/O).
Diperbaiki konkurensi per instansi
Secara bawaan, sebagian besar pemicu mendukung konfigurasi model konkurensi tetap per instans melalui penskalaan berbasis target. Dalam model ini, setiap jenis pemicu memiliki batas konkurensi per instans.
Anda dapat mengambil alih nilai default konkurensi untuk sebagian besar pemicu dengan mengatur konkurensi per instans tertentu untuk jenis pemicu tersebut. Untuk banyak pemicu, Anda mengonfigurasi pengaturan konkurensi dalam file host.json. Misalnya, pemicu Azure Service Bus menyediakan pengaturan MaxConcurrentCalls dan MaxConcurrentSessions di host.json. Pengaturan ini bekerja sama untuk mengontrol jumlah maksimum pesan yang diproses setiap aplikasi fungsi secara bersamaan pada setiap instans.
Dalam skenario penskalaan berbasis target tertentu, seperti saat Anda menggunakan pemicu Apache Kafka atau Azure Cosmos DB, konfigurasi konkurensi ada dalam deklarasi fungsi, bukan dalam file host.json . Jenis pemicu lainnya memiliki mekanisme bawaan untuk pemanggilan penyeimbangan beban di seluruh instans. Misalnya, Azure Event Hubs dan Azure Cosmos DB keduanya menggunakan skema berbasis partisi.
Untuk jenis pemicu yang mendukung konfigurasi konkurensi, pengaturan konkurensi diterapkan ke semua instans yang sedang berjalan. Dengan cara ini, Anda dapat mengontrol konkurensi maksimum untuk fungsi Anda pada setiap instans. Misalnya, ketika fungsi Anda memerlukan banyak CPU atau sumber daya, Anda dapat memilih untuk membatasi konkurensi agar instans tetap berfungsi dengan baik. Dalam hal ini, Anda dapat mengandalkan penskalakan untuk menangani peningkatan beban. Demikian pula, ketika fungsi Anda membuat permintaan ke layanan hilir yang sedang dibatasi, Anda juga harus mempertimbangkan untuk membatasi konkurensi untuk menghindari kelebihan beban layanan hilir.
Konkurensi pemicu HTTP
Hanya berlaku untuk paket Konsumsi Flex
Konkurensi pemicu HTTP adalah jenis khusus konkurensi per instans tetap. Dalam konkurensi pemicu HTTP, konkurensi bawaan juga bergantung pada ukuran instans.
Paket Konsumsi Flex menskalakan semua fungsi pemicu HTTP bersama-sama sebagai grup. Untuk informasi selengkapnya, lihat Penskalaan per fungsi.
Tabel berikut menunjukkan pengaturan konkurensi default untuk pemicu HTTP pada instans tertentu, berdasarkan ukuran memori instans yang dikonfigurasi:
| Ukuran instans (MB) | Konkurensi default* |
|---|---|
| 512 | 4 |
| 2,048 | 16 |
| 4,096 | 32 |
*Di aplikasi Python, semua ukuran instans menggunakan tingkat konkurensi pemicu HTTP satu secara default.
Nilai default ini harus bekerja dengan baik untuk sebagian besar kasus, dan Anda dapat memulainya. Pertimbangkan bahwa pada sejumlah permintaan HTTP tertentu, meningkatkan nilai konkurensi HTTP mengurangi jumlah instans yang diperlukan untuk menangani permintaan HTTP. Demikian juga, mengurangi nilai konkurensi HTTP memerlukan lebih banyak instans untuk menangani beban yang sama.
Jika Anda perlu menyempurnakan konkurensi HTTP, Anda dapat melakukannya dengan menggunakan Azure CLI. Untuk informasi selengkapnya, lihat Mengatur batas konkurensi HTTP.
Nilai konkurensi default dalam tabel sebelumnya hanya berlaku saat Anda tidak mengatur pengaturan konkurensi HTTP Anda sendiri. Saat Anda tidak secara eksplisit mengatur pengaturan konkurensi HTTP, konkurensi default meningkat seperti yang ditunjukkan dalam tabel saat Anda mengubah ukuran instans. Setelah Anda secara khusus menetapkan nilai konkurensi HTTP, nilai tersebut dipertahankan meskipun ada perubahan dalam ukuran instans.
Menentukan konkurensi per instans tetap yang optimal
Pengaturan konfigurasi konkurensi per instans memberi Anda kemampuan untuk mengendalikan perilaku pemicu tertentu, seperti pembatasan fungsi Anda. Tetapi mungkin sulit untuk menentukan nilai optimal untuk pengaturan ini. Umumnya, Anda harus sampai pada nilai yang dapat diterima oleh proses berulang pengujian beban. Bahkan setelah Anda menentukan sekumpulan nilai yang berfungsi untuk profil beban tertentu, jumlah peristiwa yang tiba dari layanan terhubung Anda dapat berubah dari hari ke hari. Varianbilitas ini dapat menyebabkan aplikasi Anda berjalan dengan nilai suboptimal. Misalnya, aplikasi fungsi Anda mungkin memproses beban pesan berat pada hari terakhir dalam seminggu, yang mengharuskan Anda untuk membatasi tingkat bersamaan. Namun, selama sisa minggu, payload pesan mungkin lebih ringan, yang berarti Anda dapat menggunakan tingkat keserentakan yang lebih tinggi.
Idealnya, sistem harus memungkinkan instans untuk memproses pekerjaan sebanyak yang mereka bisa sambil menjaga setiap instans tetap sehat dan latensi rendah. Konkurensi dinamis dirancang untuk tujuan tersebut.
Konkurensi dinamis
Functions menyediakan model konkurensi dinamis yang menyederhanakan konfigurasi konkurensi untuk semua aplikasi fungsi yang berjalan dalam paket yang sama.
Catatan
Konkurensi dinamis saat ini hanya didukung untuk pemicu Azure Blob Storage, Azure Queue Storage, dan Service Bus. Selain itu, Anda harus menggunakan versi ekstensi yang tercantum dalam dukungan Ekstensi, nanti di artikel ini.
Keuntungan
Konkurensi dinamis memberikan manfaat berikut:
- Konfigurasi yang disederhanakan: Anda tidak lagi harus menentukan pengaturan konkurensi per pemicu secara manual. Sistem mempelajari nilai optimal untuk beban kerja Anda dari waktu ke waktu.
- Penyesuaian dinamis: Konkurensi disesuaikan naik atau turun secara dinamis secara real-time, yang memungkinkan sistem beradaptasi dengan perubahan pola beban dari waktu ke waktu.
- Perlindungan kesehatan instans: Runtime membatasi konkurensi pada tingkat yang dapat ditangani oleh instans aplikasi fungsi dengan nyaman. Batas ini melindungi aplikasi dari kelebihan beban dengan mengambil lebih banyak pekerjaan daripada yang seharusnya.
- Throughput yang ditingkatkan: Throughput keseluruhan ditingkatkan, karena instans individu tidak mengambil lebih banyak pekerjaan daripada yang dapat mereka proses dengan cepat. Sebagai hasilnya, beban kerja diseimbangkan lebih efektif antar instans. Untuk fungsi yang dapat menangani beban yang lebih tinggi, throughput yang lebih tinggi dapat diperoleh dengan meningkatkan konkurensi ke nilai di atas konfigurasi default.
Konfigurasi konkurensi dinamis
Anda dapat mengaktifkan konkurensi dinamis di tingkat host dalam file host.json . Saat diaktifkan, tingkat konkurensi ekstensi pengikatan apa pun yang mendukung fitur ini disesuaikan secara otomatis sesuai kebutuhan. Dalam kasus ini, pengaturan konkurensi dinamis mengambil alih pengaturan konkurensi yang dikonfigurasi secara manual.
Secara default, konkurensi dinamis dinonaktifkan. Saat Anda mengaktifkan konkurensi dinamis, konkurensi dimulai pada tingkat satu untuk setiap fungsi. Tingkat konkurensi dikonfigurasi hingga nilai optimal, yang ditentukan oleh host.
Anda dapat mengaktifkan konkurensi dinamis di aplikasi fungsi Anda dengan menambahkan pengaturan berikut ke file host.json Anda:
{
"version": "2.0",
"concurrency": {
"dynamicConcurrencyEnabled": true,
"snapshotPersistenceEnabled": true
}
}
Ketika snapshotPersistenceEnabled adalah true, yang merupakan nilai default, nilai konkurensi yang telah dipelajari disimpan secara berkala ke dalam penyimpanan. Instans baru dimulai dari nilai-nilai tersebut alih-alih dimulai dari tingkat satu dan harus mengulangi pembelajaran.
Pengelola konkurensi
Di balik layar, saat konkurensi dinamis diaktifkan, proses manajer konkurensi berjalan di latar belakang. Pengelola ini terus memantau metrik kesehatan instans, seperti penggunaan CPU dan alur, dan mengubah pembatasan sesuai kebutuhan. Ketika satu atau beberapa throttle diaktifkan, keserentakan fungsi disesuaikan ke bawah hingga host berfungsi dengan baik lagi. Ketika pengaturan batas dimatikan, konkurensi dapat meningkat. Berbagai heuristik digunakan untuk menyesuaikan konkurensi ke atas atau ke bawah secara cerdas sesuai kebutuhan berdasarkan pembatasan ini. Seiring waktu, konkurensi untuk setiap fungsi distabilkan pada tingkat tertentu. Karena dapat memakan waktu untuk menentukan nilai konkurensi optimal, gunakan konkurensi dinamis hanya jika nilai suboptimal dapat diterima untuk solusi Anda pada awalnya atau setelah periode tidak aktif.
Tingkat konkurensi dikelola untuk setiap fungsi individu. Secara khusus, sistem menyeimbangkan antara fungsi intensif sumber daya yang membutuhkan tingkat konkurensi yang rendah dan fungsi yang lebih ringan yang dapat menangani konkurensi yang lebih tinggi. Keseimbangan konkurensi untuk setiap fungsi membantu menjaga kesehatan keseluruhan instans aplikasi fungsi.
Saat konkurensi dinamis diaktifkan, Anda menemukan keputusan konkurensi dinamis di log Anda. Misalnya, entri log ditambahkan ketika berbagai pembatasan diaktifkan, dan setiap kali konkurensi disesuaikan ke atas atau ke bawah untuk setiap fungsi. Log ini ditulis di bawah kategori log Host.Concurrency dalam tabel jejak .
Dukungan ekstensi
Konkurensi dinamis diaktifkan untuk aplikasi fungsi di tingkat host, dan ekstensi apa pun yang mendukung konkurensi dinamis berjalan dalam mode tersebut. Konkurensi dinamis membutuhkan kolaborasi antara host dan ekstensi pemicu individu. Hanya versi terdaftar dari ekstensi berikut yang mendukung konkurensi dinamis.
| Ekstensi | Versi | Deskripsi |
|---|---|---|
| Penyimpanan Antrian | Versi 5.x (Ekstensi penyimpanan) | Pemicu Queue Storage memiliki loop polling pesan tersendiri. Saat Anda menggunakan konfigurasi per instans tetap, opsi konfigurasi BatchSize dan NewBatchThreshold mengatur konkurensi. Saat Anda menggunakan konkurensi dinamis, nilai konfigurasi tersebut diabaikan. Konkurensi dinamis diintegrasikan ke dalam perulangan pesan, sehingga jumlah pesan yang diambil per iterasi disesuaikan secara dinamis. Saat pengendalian aliran diaktifkan, host kelebihan beban. Pemrosesan pesan dijeda hingga pembatasan dimatikan. Ketika pengendali dimatikan, konkurensi meningkat. |
| Penyimpanan Blob | Versi 5.x (Ekstensi penyimpanan) | Secara internal, pemicu Blob Storage menggunakan infrastruktur yang sama dengan yang digunakan pemicu Queue Storage. Ketika blob baru atau yang diperbarui perlu diproses, pesan ditulis ke antrian kendali yang dikelola oleh platform. Antrean tersebut diproses dengan menggunakan logika yang sama yang digunakan untuk pemicu Queue Storage. Ketika konkurensi dinamis diaktifkan, konkurensi untuk pemrosesan antrean kontrol tersebut dikelola secara dinamis. |
| Bus Servis | Versi 5.x | Pemicu Azure Service Bus saat ini mendukung tiga model eksekusi. Konkurensi dinamis memengaruhi model eksekusi ini dengan cara berikut:MaxConcurrentCalls adalah opsi konfigurasi yang mengatur konkurensi. Saat Anda menggunakan konkurensi dinamis, nilai konfigurasi tersebut diabaikan, dan konkurensi disesuaikan secara dinamis.MaxConcurrentSessions pengaturan mengatur konkurensi. Ketika kompetensi dinamis diaktifkan, nilai MaxConcurrentSessions akan diabaikan, dan jumlah sesi yang diproses oleh setiap instans disesuaikan secara dinamis.MaxMessageCount. Karena pemanggilan batch bersifat serial, konkurensi untuk fungsi yang dipicu batch Anda selalu satu, dan konkurensi dinamis tidak berlaku. |
Langkah berikutnya
Untuk informasi selengkapnya, lihat sumber daya berikut: