Pertimbangan penyimpanan untuk Azure Functions
Azure Functions memerlukan akun Azure Storage saat Anda membuat instans aplikasi fungsi. Layanan penyimpanan berikut dapat digunakan oleh aplikasi fungsi Anda:
| Layanan penyimpanan | Penggunaan fungsi |
|---|---|
| Azure Blob Storage | Pertahankan status pengikatan dan kuncifungsi 1. Digunakan secara default untuk hub tugas di Durable Functions. Dapat digunakan untuk menyimpan kode aplikasi fungsi untuk build jarak jauh Konsumsi Linux atau sebagai bagian dari penyebaran URL paket eksternal. |
| Azure Files2 | Berbagi file yang digunakan untuk menyimpan dan menjalankan kode aplikasi fungsi Anda dalam Rencana Konsumsi dan Rencana Premium. |
| Azure Queue storage | Digunakan secara default untuk hub tugas di Durable Functions. Digunakan untuk kegagalan dan penanganan coba lagi dalam pemicu Azure Functions tertentu. Digunakan untuk pelacakan objek oleh pemicu penyimpanan Blob. |
| Azure Table Storage | Digunakan secara default untuk hub tugas di Durable Functions. |
1 Penyimpanan Blob adalah penyimpanan default untuk kunci fungsi, tetapi Anda dapat mengonfigurasi penyimpanan alternatif.
2 Azure Files disiapkan secara default, tetapi Anda dapat membuat aplikasi tanpa Azure Files dalam kondisi tertentu.
Pertimbangan penting
Anda harus sangat mempertimbangkan fakta-fakta berikut mengenai akun penyimpanan yang digunakan oleh aplikasi fungsi Anda:
Saat aplikasi fungsi Anda dihosting pada paket Konsumsi atau paket Premium, kode fungsi dan file konfigurasi Anda disimpan di Azure Files di akun penyimpanan yang ditautkan. Saat Anda menghapus akun penyimpanan ini, konten akan dihapus dan tidak dapat dipulihkan. Untuk informasi selengkapnya, lihat Akun penyimpanan telah dihapus
Data penting, seperti kode fungsi, kunci akses, dan data terkait layanan penting lainnya, dapat disimpan di akun penyimpanan. Anda harus mengelola akses dengan hati-hati ke akun penyimpanan yang digunakan oleh aplikasi fungsi dengan cara berikut:
Audit dan batasi akses aplikasi dan pengguna ke akun penyimpanan berdasarkan model hak istimewa paling sedikit. Izin ke akun penyimpanan dapat berasal dari tindakan data dalam peran yang ditetapkan atau melalui izin untuk melakukan operasi listKeys.
Pantau aktivitas sarana kontrol (seperti mengambil kunci) dan operasi sarana data (seperti menulis ke blob) di akun penyimpanan Anda. Pertimbangkan untuk mempertahankan log penyimpanan di lokasi selain Azure Storage. Untuk informasi selengkapnya, lihat Log penyimpanan.
Persyaratan akun penyimpanan
Akun penyimpanan yang dibuat sebagai bagian dari alur pembuatan aplikasi fungsi di portal Azure dijamin berfungsi dengan aplikasi fungsi baru. Saat Anda memilih untuk menggunakan akun penyimpanan yang ada, daftar yang disediakan tidak menyertakan akun penyimpanan tertentu yang tidak didukung. Pembatasan berikut berlaku untuk akun penyimpanan yang digunakan oleh aplikasi fungsi Anda, jadi Anda harus memastikan akun penyimpanan yang ada memenuhi persyaratan berikut:
Jenis akun harus mendukung penyimpanan Blob, Antrean, dan Tabel. Beberapa akun penyimpanan tidak mendukung antrean dan tabel. Akun-akun ini termasuk akun penyimpanan khusus blob dan Azure Premium Storage. Untuk mempelajari jenis akun penyimpanan selengkapnya, lihat ringkasan akun penyimpanan.
Anda tidak dapat menggunakan akun penyimpanan yang sudah diamankan dengan menggunakan firewall atau jaringan privat virtual saat membuat aplikasi fungsi di portal Azure. Namun, portal saat ini tidak memfilter akun penyimpanan aman ini. Untuk mempelajari cara menggunakan akun penyimpanan aman dengan aplikasi fungsi Anda, lihat Cara menggunakan akun penyimpanan aman dengan Azure Functions.
Anda tidak dapat menggunakan akun penyimpanan aman dengan aplikasi fungsi yang dihosting dalam paket Konsumsi.
Saat membuat aplikasi fungsi di portal, Anda hanya diizinkan untuk memilih akun penyimpanan yang ada di wilayah yang sama dengan aplikasi fungsi yang Anda buat. Ini adalah pengoptimalan performa dan bukan batasan yang ketat. Untuk mempelajari selengkapnya, lihat Lokasi akun penyimpanan.
Saat membuat aplikasi fungsi Anda pada paket dengan dukungan zona ketersediaan diaktifkan, hanya akun penyimpanan zona redundan yang didukung.
Anda dapat membuat aplikasi fungsi dalam paket Elastic Premium atau Dedicated (App Service) menggunakan otomatisasi penyebaran. Namun, Anda harus menyertakan konfigurasi jaringan tertentu dalam templat ARM atau file Bicep Anda. Saat Anda tidak menyertakan pengaturan dan sumber daya ini, penyebaran otomatis Anda mungkin gagal dalam validasi. Untuk informasi selengkapnya, lihat Penyebaran aman.
Panduan akun penyimpanan
Setiap aplikasi fungsi memerlukan akun penyimpanan untuk beroperasi. Saat akun tersebut dihapus, aplikasi fungsi Anda tidak akan berjalan. Untuk memecahkan masalah terkait penyimpanan, lihat Cara memecahkan masalah terkait penyimpanan. Pertimbangan lain berikut berlaku untuk akun Storage yang digunakan oleh aplikasi fungsi.
Lokasi akun penyimpanan
Agar performanya maksimal, aplikasi fungsi Anda harus menggunakan akun penyimpanan di wilayah yang sama, untuk mengurangi latensi. Portal Microsoft Azure memberlakukan praktik terbaik ini. Jika karena alasan tertentu Anda perlu menggunakan akun penyimpanan di wilayah yang berbeda dari aplikasi fungsi, Anda harus membuat aplikasi fungsi di luar portal.
Akun penyimpanan harus dapat diakses oleh aplikasi fungsi. Jika Anda perlu menggunakan akun penyimpanan aman, pertimbangkan untuk membatasi akun penyimpanan Anda ke jaringan virtual.
Pengaturan koneksi akun penyimpanan
Secara default, aplikasi fungsi mengonfigurasi AzureWebJobsStorage koneksi sebagai string koneksi yang disimpan di pengaturan aplikasi AzureWebJobsStorage, tetapi Anda juga dapat mengonfigurasi AzureWebJobsStorage untuk menggunakan koneksi berbasis identitas tanpa rahasia.
Aplikasi fungsi yang berjalan dalam paket Konsumsi (khusus Windows) atau paket Elastic Premium (Windows atau Linux) dapat menggunakan Azure Files untuk menyimpan gambar yang diperlukan untuk mengaktifkan penskalaan dinamis. Untuk paket ini, atur string koneksi untuk akun penyimpanan di pengaturan WEBSITE_CONTENTAZUREFILECONNECTIONSTRING dan nama berbagi file di pengaturan WEBSITE_CONTENTSHARE. Ini biasanya akun yang sama yang digunakan untuk AzureWebJobsStorage. Anda juga dapat membuat aplikasi fungsi yang tidak menggunakan Azure Files, tetapi penskalakan mungkin terbatas.
Catatan
Akun penyimpanan string koneksi harus diperbarui saat Anda meregenerasi kunci penyimpanan. Baca selengkapnya tentang manajemen kunci penyimpanan di sini.
Akun penyimpanan bersama
Beberapa aplikasi fungsi dapat berbagi akun penyimpanan yang sama tanpa ditemui masalah. Misalnya, di Visual Studio Anda dapat mengembangkan beberapa aplikasi menggunakan emulator penyimpanan Azurite. Dalam hal ini, emulator bertindak seperti satu akun penyimpanan. Akun penyimpanan yang sama dengan yang digunakan oleh aplikasi fungsi Anda juga dapat digunakan untuk menyimpan data aplikasi Anda. Namun, pendekatan ini tidak selalu merupakan ide yang baik dalam lingkungan produksi.
Anda mungkin perlu menggunakan akun penyimpanan terpisah untuk menghindari tabrakan ID host.
Pertimbangan kebijakan manajemen siklus hidup
Anda tidak boleh menerapkan kebijakan manajemen siklus hidup ke akun Blob Storage yang digunakan oleh aplikasi fungsi Anda. Functions menggunakan penyimpanan Blob untuk mempertahankan informasi penting, seperti kunci akses fungsi, dan kebijakan dapat menghapus blob (seperti kunci) yang diperlukan oleh host Functions. Jika Anda harus menggunakan kebijakan, kecualikan kontainer yang digunakan oleh Functions, yang diawali dengan azure-webjobs atau scm.
Log penyimpanan
Karena kode fungsi dan kunci mungkin bertahan di akun penyimpanan, pengelogan aktivitas terhadap akun penyimpanan adalah cara yang baik untuk memantau akses yang tidak sah. Log sumber daya Azure Monitor dapat digunakan untuk melacak peristiwa terhadap bidang data penyimpanan. Lihat Memantau Azure Storage untuk detail tentang cara mengonfigurasi dan memeriksa log ini.
Log aktivitas Azure Monitor memperlihatkan peristiwa sarana kontrol, termasuk operasi listKeys. Namun, Anda juga harus mengonfigurasi log sumber daya untuk akun penyimpanan guna melacak penggunaan kunci berikutnya atau operasi data plane berbasis identitas lainnya. Anda harus memiliki setidaknya kategori log StorageWrite yang diaktifkan untuk dapat mengidentifikasi modifikasi pada data di luar operasi Fungsi normal.
Untuk membatasi dampak potensial dari izin penyimpanan yang dilingkup secara luas, pertimbangkan untuk menggunakan tujuan nonstorage untuk log ini, seperti Analitik Log. Untuk informasi selengkapnya, lihat Memantau Azure Blob Storage.
Mengoptimalkan kinerja penyimpanan
Untuk memaksimalkan kinerja, gunakan akun penyimpanan terpisah untuk setiap aplikasi fungsi. Ini sangat penting ketika Anda memiliki fungsi Durable Functions atau Event Hub yang dipicu, yang keduanya menghasilkan volume transaksi penyimpanan yang tinggi. Saat logika aplikasi Anda berinteraksi dengan Azure Storage, baik secara langsung (menggunakan SDK Penyimpanan) atau melalui salah satu pengikatan penyimpanan, Anda harus menggunakan akun penyimpanan khusus. Misalnya, jika Anda memiliki fungsi yang dipicu Event Hub yang menulis beberapa data ke penyimpanan blob, gunakan dua akun penyimpanan—satu untuk aplikasi fungsi dan satu lagi untuk blob yang disimpan oleh fungsi.
Bekerja dengan blob
Skenario utama untuk Functions adalah pemrosesan file file dalam kontainer blob, seperti untuk pemrosesan gambar atau analisis sentimen. Untuk mempelajari selengkapnya, lihat Memproses unggahan file.
Pemicu pada kontainer blob
Ada beberapa cara untuk menjalankan kode fungsi Anda berdasarkan perubahan pada blob dalam kontainer penyimpanan. Gunakan tabel berikut untuk menentukan pemicu fungsi mana yang paling sesuai dengan kebutuhan Anda:
| Pertimbangan | Penyimpanan blob (polling) | Penyimpanan blob (berbasis peristiwa) | Antrean Penyimpanan | Event Grid |
|---|---|---|---|---|
| Latensi | Tinggi (hingga 10 menit) | Kurang Penting | Medium | Kurang Penting |
| Batas Akun penyimpanan | Akun khusus blob tidak didukung¹ | tujuan umum v1 tidak didukung | tidak ada | tujuan umum v1 tidak didukung |
| Versi ekstensi | Mana pun | Storage v5.x+ | Apa pun | Apa pun |
| Memproses blob yang ada | Ya | No | No | Tidak |
| Filter | Pola nama blob | Filter peristiwa | n/a | Filter peristiwa |
| Memerlukan langganan peristiwa | Tidak | Ya | No | Ya |
| Mendukung skala tinggi² | Tidak | Ya | Ya | Ya |
| Deskripsi | Perilaku pemicu default, yang bergantung pada polling kontainer untuk pembaruan. Untuk informasi selengkapnya, lihat contoh dalam referensi pemicu penyimpanan Blob. | Mengonsumsi peristiwa penyimpanan blob dari langganan peristiwa. Memerlukan nilai parameter Source dari EventGrid. Untuk informasi selengkapnya, lihat Tutorial: Memicu Azure Functions pada kontainer blob menggunakan langganan peristiwa. |
String nama blob ditambahkan secara manual ke antrean penyimpanan saat blob ditambahkan ke kontainer. Nilai ini diteruskan langsung oleh pemicu penyimpanan Antrean ke pengikatan input penyimpanan Blob pada fungsi yang sama. | Memberikan fleksibilitas pemicu pada beberapa peristiwa selain yang berasal dari kontainer penyimpanan. Gunakan ketika perlu juga memiliki peristiwa nonstorage yang memicu fungsi Anda. Untuk informasi selengkapnya, lihat Cara menggunakan pemicu dan pengikatan Event Grid di Azure Functions. |
1 Pengikatan input dan output penyimpanan Blob mendukung akun khusus blob.
2 Skala tinggi dapat didefinisikan secara longgar sebagai kontainer yang memiliki lebih dari 100.000 blob di dalamnya atau akun penyimpanan yang memiliki lebih dari 100 pembaruan blob per detik.
Enkripsi data penyimpanan
Azure Storage mengenkripsi semua data di akun penyimpanan ketika tidak aktif. Untuk informasi lebih lanjut, lihat Enkripsi Azure Storage untuk data tidak aktif.
Secara default, data dienkripsi dengan kunci yang dikelola Microsoft. Untuk kontrol tambahan atas kunci enkripsi, Anda dapat menyediakan kunci yang dikelola pelanggan untuk digunakan pada enkripsi blob dan data file. Kunci ini harus ada di Azure Key Vault for Functions untuk dapat mengakses akun penyimpanan. Untuk mempelajari lebih lanjut, lihat Enkripsi ketika tidak aktif menggunakan kunci yang dikelola pelanggan.
Residensi data dalam wilayah
Jika semua data pelanggan harus tetap berada dalam satu wilayah, akun penyimpanan yang terkait dengan aplikasi fungsi harus satu dengan redundansi wilayah. Akun penyimpanan yang berlebihan di wilayah juga harus digunakan dengan Azure Durable Functions.
Data pelanggan lainnya yang dikelola platform hanya disimpan di wilayah ini saat hosting di Lingkungan Layanan Aplikasi (ASE) yang seimbang secara internal. Untuk mempelajari lebih lanjut, lihat Redundansi zona ASE.
Pertimbangan ID Host
Functions menggunakan nilai ID host sebagai cara untuk mengidentifikasi aplikasi fungsi tertentu secara unik dalam artefak yang disimpan. Secara default, ID ini dibuat secara otomatis dari nama aplikasi fungsi, dipotong menjadi 32 karakter pertama. ID ini kemudian digunakan saat menyimpan korelasi per aplikasi dan melacak informasi di akun penyimpanan yang ditautkan. Ketika Anda memiliki aplikasi fungsi dengan nama yang lebih panjang dari 32 karakter dan ketika 32 karakter pertama identik, pemotongan ini dapat menghasilkan nilai ID host duplikat. Saat dua aplikasi fungsi dengan ID host yang identik menggunakan akun penyimpanan yang sama, Anda mendapatkan tabrakan ID host karena data yang disimpan tidak dapat ditautkan secara unik ke aplikasi fungsi yang benar.
Catatan
Jenis tabrakan ID host yang sama ini dapat terjadi antara aplikasi fungsi di slot produksi dan aplikasi fungsi yang sama di slot penahapan, saat kedua slot menggunakan akun penyimpanan yang sama.
Dimulai dengan runtime Functions versi 3.x, tabrakan ID host terdeteksi dan peringatan dicatat. Dalam versi 4.x, kesalahan dicatat dan host dihentikan, mengakibatkan kegagalan keras. Detail selengkapnya tentang tabrakan ID host dapat ditemukan dalam masalah ini.
Menghindari tabrakan ID host
Anda dapat menggunakan strategi berikut untuk menghindari tabrakan ID host:
- Gunakan akun penyimpanan terpisah untuk setiap aplikasi fungsi atau slot yang terlibat dalam tabrakan.
- Ganti nama salah satu aplikasi fungsi Anda menjadi nilai yang panjangnya kurang dari 32 karakter, yang mengubah ID host komputasi untuk aplikasi dan menghapus tabrakan.
- Atur ID host eksplisit untuk satu atau beberapa aplikasi yang bertabrakan. Untuk mempelajari selengkapnya, lihat Penimpaan ID Host.
Penting
Mengubah akun penyimpanan yang terkait dengan aplikasi fungsi yang ada atau mengubah ID host aplikasi dapat memengaruhi perilaku fungsi yang ada. Misalnya, pemicu penyimpanan Blob melacak apakah blob individual diproses dengan menulis tanda terima di bawah jalur ID host tertentu di penyimpanan. Ketika ID host berubah atau Anda menunjuk ke akun penyimpanan baru, blob yang diproses sebelumnya dapat diproses ulang.
Mengambil alih ID host
Anda dapat secara eksplisit mengatur ID host tertentu untuk aplikasi fungsi Anda di pengaturan aplikasi dengan menggunakan pengaturan AzureFunctionsWebHost__hostid. Untuk informasi selengkapnya, lihat AzureFunctionsWebHost__hostid.
Ketika tabrakan terjadi di antara slot, Anda harus mengatur ID host tertentu untuk setiap slot, termasuk slot produksi. Anda juga harus menandai pengaturan ini sebagai pengaturan penyebaran sehingga tidak ditukar. Untuk mempelajari cara membuat pengaturan aplikasi, lihat Bekerja dengan pengaturan aplikasi.
Kluster yang mendukung Azure Arc
Saat aplikasi fungsi Anda disebarkan ke kluster Kubernetes dengan dukungan Azure Arc, akun penyimpanan mungkin tidak diperlukan oleh aplikasi fungsi Anda. Dalam hal ini, akun penyimpanan hanya diperlukan oleh Functions saat aplikasi fungsi Anda menggunakan pemicu yang memerlukan penyimpanan. Tabel berikut menunjukkan pemicu mana yang mungkin memerlukan akun penyimpanan dan mana yang tidak.
| Tidak diperlukan | mungkin memerlukan penyimpanan |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Bus Layanan |
• Azure SQL • Penyimpanan blob • Event Grid • Pusat Aktivitas • IoT Hub • Penyimpanan antrean • SendGrid • SignalR • Penyimpanan tabel • Timer • Twilio |
Untuk membuat aplikasi fungsi pada kluster Kubernetes dengan dukungan Azure Arc tanpa penyimpanan, Anda harus menggunakan perintah Azure CLI buat az functionapp. Versi Azure CLI harus menyertakan versi 0.1.7 atau versi yang lebih baru dari ekstensi appservice-kube. Gunakan perintah az --version untuk memverifikasi bahwa ekstensi telah diinstal dan merupakan versi yang benar.
Membuat sumber daya aplikasi fungsi Anda menggunakan metode selain Azure CLI memerlukan akun penyimpanan yang sudah ada. Jika Anda berencana menggunakan pemicu apa pun yang memerlukan akun penyimpanan, Anda harus membuat akun sebelum membuat aplikasi fungsi.
Membuat aplikasi tanpa Azure Files
Azure Files disiapkan secara default untuk paket Konsumsi Elastic Premium dan non-Linux untuk berfungsi sebagai sistem file bersama dalam skenario skala tinggi. Sistem file digunakan oleh platform untuk beberapa fitur seperti streaming log, tetapi terutama memastikan konsistensi payload fungsi yang disebarkan. Saat aplikasi disebarkan menggunakan URL paket eksternal, konten aplikasi disajikan dari sistem file baca-saja terpisah. Artinya, Anda dapat membuat aplikasi fungsi tanpa Azure Files. Jika Anda membuat aplikasi fungsi dengan Azure Files, sistem file yang dapat ditulisi masih disediakan. Namun, sistem file ini mungkin tidak tersedia untuk semua instans aplikasi fungsi.
Saat Azure Files tidak digunakan, Anda harus memenuhi persyaratan berikut:
- Anda harus menyebarkan dari URL paket eksternal.
- Aplikasi Anda tidak dapat mengandalkan sistem file bersama yang dapat ditulis.
- Aplikasi tidak dapat menggunakan runtime Functions versi 1.x.
- Log pengalaman streaming di klien seperti portal Microsoft Azure default ke log sistem file. Anda sebaiknya mengandalkan log Application Insights.
Jika hal di atas diperhitungkan dengan benar, Anda dapat membuat aplikasi tanpa Azure Files. Membuat aplikasi fungsi tanpa menentukan pengaturan aplikasi WEBSITE_CONTENTAZUREFILECONNECTIONSTRING dan WEBSITE_CONTENTSHARE. Anda dapat menghindari pengaturan ini dengan menghasilkan templat ARM untuk penyebaran standar, menghapus dua pengaturan, lalu menyebarkan templat.
Karena Functions menggunakan Azure Files selama bagian dari proses peluasan skala dinamis, penskalaan dapat dibatasi saat berjalan tanpa Azure Files pada paket Konsumsi dan Elastic Premium.
Kaitkan pembagian file
Fungsi ini saat ini hanya tersedia untuk operasi Linux.
Anda dapat memasang berbagi Azure Files yang ada ke aplikasi fungsi Linux Anda. Dengan memasang berbagi ke aplikasi fungsi Linux, Anda dapat memanfaatkan model pembelajaran mesin atau data lain yang ada dalam fungsi Anda. Anda dapat menggunakan perintah berikut untuk memasang pembagian yang ada ke aplikasi fungsi Linux Anda.
az webapp config storage-account add
Dalam perintah ini, share-name adalah nama berbagi Azure Files yang ada, dan custom-id dapat menjadi string apa pun yang khusus menentukan pembagian file saat dipasang ke aplikasi fungsi. mount-path juga merupakan jalur tempat pembagian diakses di aplikasi fungsi Anda. mount-path harus dalam format /dir-name, dan tidak dapat dimulai dengan /home.
Untuk contoh lengkapnya, lihat skrip di Membuat aplikasi fungsi Python dan memasang berbagi Azure Files.
Saat ini, hanya storage-type dari AzureFiles yang didukung. Anda hanya dapat memasang lima pembagian ke aplikasi fungsi tertentu. Memasang berbagi file dapat meningkatkan waktu mulai dingin setidaknya 200-300 ms, atau bahkan lebih ketika akun penyimpanan berada di wilayah yang berbeda.
Pembagian file tersedia untuk kode fungsi Anda pada mount-path yang ditentukan. Misalnya, ketika mount-path adalah /path/to/mount, Anda dapat mengakses direktori target berdasarkan API sistem file, seperti dalam contoh Python berikut:
import os
...
files_in_share = os.listdir("/path/to/mount")
Langkah berikutnya
Pelajari selengkapnya tentang opsi hosting Azure Functions.