Tanya Jawab Umum Azure App Configuration

App Configuration membantu pengembang mengelola pengaturan aplikasi dan mengontrol ketersediaan fitur. Ini bertujuan untuk menyederhanakan banyak tugas bekerja dengan data konfigurasi yang kompleks.

App Configuration mendukung:

• kumpulan nama hierarkis
• Pemberian label
• Kueri yang ekstensif
• Pengambilan batch
• Operasi manajemen khusus
• Antarmuka pengguna manajemen fitur

App Configuration melengkapi Key Vault, dan keduanya harus digunakan berdampingan di sebagian besar penyebaran aplikasi.

Meskipun App Configuration memberikan keamanan yang diperketat, Key Vault masih merupakan tempat terbaik untuk menyimpan rahasia aplikasi. Key Vault menyediakan enkripsi tingkat perangkat keras, kebijakan akses terperinci, dan operasi manajemen seperti rotasi sertifikat.

Anda dapat membuat nilai kunci App Configuration yang mereferensikan rahasia yang disimpan di Key Vault. Untuk informasi selengkapnya, lihat Menggunakan referensi Key Vault di aplikasi ASP.NET Core.

Ya. App Configuration selalu mengenkripsi semua data saat transit dan saat tidak aktif. Semua komunikasi jaringan melalui TLS 1.2 atau TLS 1.3. App Configuration mendukung enkripsi saat tidak aktif dengan kunci yang dikelola Microsoft atau kunci yang dikelola pelanggan.

Azure App Service memungkinkan Anda menentukan pengaturan aplikasi untuk setiap instans App Service. Pengaturan ini diteruskan sebagai variabel lingkungan ke kode aplikasi. Anda dapat mengaitkan pengaturan dengan slot penyebaran tertentu, jika Anda mau. Untuk informasi selengkapnya, lihat Mengonfigurasi pengaturan aplikasi.

Sebaliknya, Azure App Configuration memungkinkan Anda menentukan pengaturan yang dapat dibagikan di antara beberapa aplikasi. Ini termasuk aplikasi yang berjalan di App Service, serta platform lainnya. Kode aplikasi Anda mengakses pengaturan ini melalui penyedia konfigurasi untuk .NET dan Java, melalui Azure SDK, atau langsung melalui REST API.

Anda dapat menambahkan referensi ke data App Configuration Anda di pengaturan Aplikasi App Service. Anda juga dapat mengimpor dan mengekspor pengaturan antara App Service dan App Configuration. Kemampuan ini memungkinkan Anda dengan cepat menyiapkan penyimpanan App Configuration baru berdasarkan pengaturan App Service yang ada. Anda juga dapat berbagi konfigurasi dengan aplikasi yang ada yang bergantung pada pengaturan App Service.

Ada batas 10 KB untuk nilai kunci tunggal, termasuk atribut seperti label, tipe konten, tag, dan metadata lainnya. Tidak ada batasan jumlah kunci dan label selama ukuran totalnya di bawah batas penyimpanan.

Batas kunci-nilai ini harus cukup untuk satu pengaturan di sebagian besar aplikasi. Jika Anda menemukan bahwa pengaturan Anda lebih besar dari batas ini, Anda mungkin mempertimbangkan untuk menyimpan data Anda di tempat lain, dan menambahkan referensi data tersebut di App Configuration.

Untuk daftar lengkap batas, lihat Batas langganan dan layanan Azure.

Anda mengontrol siapa yang dapat mengakses App Configuration di tingkat penyimpanan. Gunakan penyimpanan terpisah untuk setiap lingkungan yang memerlukan izin berbeda. Pendekatan ini memberikan isolasi keamanan terbaik.

Jika Anda tidak memerlukan isolasi keamanan antar lingkungan, Anda dapat menggunakan label untuk membedakan antara nilai konfigurasi. Gunakan label untuk mengaktifkan konfigurasi yang berbeda untuk lingkungan yang berbeda memberikan contoh lengkap.

Lihat praktik terbaik.

Ada tiga tingkat harga: Gratis, Standar, dan Premium. Untuk informasi harga terperinci, lihat halaman harga App Configuration.

Semua tingkat App Configuration menawarkan fungsionalitas inti, termasuk pengaturan konfigurasi, bendera fitur, referensi Key Vault, rekam jepret konfigurasi, operasi manajemen dasar, metrik, dan log.

Berikut ini adalah pertimbangan untuk memilih tingkatan.

• Tujuan: Tingkat Gratis sangat cocok untuk mengevaluasi layanan di lingkungan non-produksi, memungkinkan Anda menjelajahi fitur-fiturnya tanpa biaya apa pun. Tingkat Standar disesuaikan untuk kasus penggunaan produksi volume menengah, memberikan keseimbangan performa dan efisiensi biaya. Untuk kebutuhan produksi volume tinggi atau tingkat perusahaan, tingkat Premium menawarkan tingkat performa dan skalabilitas tertinggi, memastikan aplikasi Anda berjalan dengan lancar bahkan di bawah beban berat.

• Sumber daya per langganan: Sumber daya terdiri dari satu penyimpanan konfigurasi. Setiap langganan dibatasi untuk satu penyimpanan konfigurasi per wilayah di tingkat Gratis. Langganan dapat memiliki jumlah penyimpanan konfigurasi yang tidak terbatas di tingkat Standar dan Premium.

• Penyimpanan per sumber daya: Di tingkat Gratis, setiap penyimpanan konfigurasi dibatasi hingga 10 MB penyimpanan reguler dan penyimpanan rekam jepret 10 MB. Di tingkat Standar, setiap penyimpanan konfigurasi dapat menggunakan penyimpanan reguler hingga 1 GB dan penyimpanan rekam jepret tambahan sebesar 1 GB. Di tingkat Premium, setiap penyimpanan konfigurasi dapat menggunakan penyimpanan reguler hingga 4 GB dan penyimpanan rekam jepret tambahan sebesar 4 GB.

• Riwayat revisi: App Configuration menyimpan riwayat semua perubahan yang dilakukan pada kunci. Di tingkat Gratis, riwayat ini disimpan selama tujuh hari. Di tingkat Standar dan Premium, riwayat ini disimpan selama 30 hari.

• Kuota permintaan: Toko tingkat gratis dibatasi hingga 1.000 permintaan per hari. Saat penyimpanan mencapai 1.000 permintaan, ini mengembalikan kode status HTTP 429 untuk semua permintaan hingga tengah malam UTC.

  Penyimpanan tingkat standar dibatasi hingga 30.000 permintaan per jam. Setelah kuota per jam habis, permintaan tambahan dapat mengembalikan kode status HTTP 429, menunjukkan terlalu banyak permintaan, hingga akhir jam. Karena permintaan yang dikirim berjumlah semakin banyak dan melebihi kuota, persentase yang lebih tinggi dari permintaan tersebut mungkin akan menampilkan kode status 429.

  Penyimpanan tingkat premium tidak memiliki batas kuota pada permintaan, memastikan bahwa akses ke toko tidak pernah diblokir.

• Throughput: Penyimpanan App Configuration di semua tingkatan memiliki jatah throughput. Permintaan yang melebihi jatah ini menerima respons kode status HTTP 429. Penyimpanan di tingkat Gratis tidak memiliki throughput yang dijamin.

  Penyimpanan di tingkat Standar memungkinkan laju eksekusi† hingga 300 permintaan per detik (RPS) untuk permintaan baca dan hingga 60 RPS untuk permintaan tulis.

  Penyimpanan di tingkat Premium memungkinkan tarif eksekusi† hingga 450 RPS untuk permintaan baca dan hingga 100 RPS untuk permintaan tulis.

  †Laju eksekusi biasanya diukur sebagai jumlah rata-rata permintaan yang ditangani oleh penyimpanan App Configuration tanpa pembatasan selama periode tertentu.

• Perjanjian tingkat layanan: Tingkat gratis tidak memiliki SLA. Tingkat Standar memiliki ketersediaan 99,9% dan ketersediaan 99,95% dengan replikasi geografis diaktifkan. Tingkat Premium memiliki ketersediaan 99,9% dan ketersediaan 99,99% dengan replikasi geografis diaktifkan.

• Fitur: Semua tingkatan mencakup fungsionalitas, termasuk enkripsi dengan kunci yang dikelola Microsoft, autentikasi melalui kunci akses atau ID Microsoft Entra, kontrol akses berbasis peran Azure (RBAC), identitas terkelola, tag layanan, dan redundansi zona ketersediaan. Tingkat Standar dan Premium menawarkan lebih banyak fungsi, termasuk dukungan Private Link, enkripsi dengan kunci yang dikelola pelanggan, perlindungan penghapusan sementara, dan kemampuan replikasi geografis.

• Biaya: Tidak ada biaya untuk menggunakan penyimpanan tingkat Gratis.

  Penyimpanan tingkat standar memiliki biaya penggunaan harian, yang mencakup 200.000 permintaan pertama setiap hari. Permintaan di luar alokasi harian ini dikenakan biaya kelebihan pemakaian.

  Penyimpanan tingkat premium juga memiliki biaya penggunaan harian dan menyertakan replika. 800.000 permintaan pertama untuk asal dan 800.000 permintaan pertama untuk replika setiap hari disertakan dalam biaya harian. Permintaan yang melebihi alokasi harian ini dikenakan biaya kelebihan pemakaian.

Anda dapat meningkatkan penyimpanan App Configuration kapan saja, misalnya, dari tingkat Gratis ke tingkat Standar atau Premium, atau dari tingkat Standar ke tingkat Premium.

Anda tidak dapat menurunkan tingkat penyimpanan App Configuration, misalnya, dari tingkat Premium ke tingkat Standar, atau dari tingkat Standar ke tingkat Gratis. Namun, Anda dapat membuat penyimpanan baru di tingkat yang diinginkan lalu mengimpor data konfigurasi ke penyimpanan tersebut.

Data pelanggan yang disimpan di App Configuration berada di wilayah tempat penyimpanan App Configuration pelanggan dibuat. Data pelanggan direplikasi ke wilayah lain hanya jika pelanggan mengaktifkan replikasi geografis untuk wilayah tersebut. Ini berlaku untuk semua wilayah yang tersedia. Pelanggan dapat memindahkan, menyalin, atau mengakses data mereka dari lokasi mana pun secara global.

Azure App Configuration mendukung replikasi geografis untuk meningkatkan ketahanan terhadap pemadaman wilayah.

Azure App Configuration mendukung Azure Availability Zone guna melindungi aplikasi dan data Anda dari kegagalan pusat data tunggal. Semua wilayah yang diaktifkan zona ketersediaan terdiri dari minimal tiga zona ketersediaan, di mana masing-masing adalah pusat data yang independen secara fisik. Untuk ketahanan, dukungan dalam App Configuration ini diaktifkan untuk semua pelanggan tanpa biaya tambahan. Berikut ini adalah wilayah dengan App Configuration sudah mengaktifkan dukungan Zona Ketersediaan. Untuk informasi selengkapnya, lihat Zona Wilayah dan Ketersediaan di Azure.

Berikut adalah wilayah di mana App Configuration sudah mengaktifkan dukungan Zona Ketersediaan.

Penyimpanan App Configuration memiliki kuota permintaan yang berbeda berdasarkan tingkatannya. Toko tingkat gratis dibatasi hingga 1.000 permintaan per hari, penyimpanan tingkat Standar hingga 30.000 permintaan per jam, dan penyimpanan tingkat Premium tidak memiliki batas permintaan, memastikan akses yang tidak terganggu.

Penyimpanan App Configuration memiliki tunjangan throughput berdasarkan tingkatnya. Penyimpanan tingkat gratis tidak memiliki throughput yang dijamin. Penyimpanan tingkat standar mendukung tingkat eksekusi hingga 300 permintaan per detik (RPS) untuk operasi baca dan hingga 60 RPS untuk operasi tulis. Penyimpanan tingkat premium mendukung tingkat eksekusi hingga 450 RPS untuk operasi baca dan hingga 100 RPS untuk operasi tulis.

Mari kita ambil contoh dan asumsikan Anda memiliki aplikasi dengan 1.000 pengaturan konfigurasi. Aplikasi Anda memuat semua pengaturan tersebut dari App Configuration saat startup. Setelah itu, ia memeriksa kunci sentinel untuk perubahan konfigurasi setiap 30 detik. Apakah Anda menjalankan Kubernetes, App Service, atau VM, mari kita asumsikan Anda memiliki 50 instans aplikasi yang berjalan secara bersamaan.

Pertama, mari kita perkirakan permintaan untuk pemantauan konfigurasi. Setiap instans aplikasi Anda mengirimkan satu permintaan untuk kunci sentinel ke App Configuration setiap 30 detik, sehingga mengirimkan permintaan 120 (=3600/30) dalam satu jam. Mengingat Anda memiliki 50 instans aplikasi, aplikasi Anda mengirimkan total permintaan 6.000 (=120x50) setiap jam untuk pemantauan konfigurasi. Perhatikan bahwa karena permintaan kunci sentinel sering dan sebagian besar tidak berubah, sebagian besar tidak dihitung terhadap batas kuota per jam penyimpanan† untuk penyimpanan tingkat Standar.

Kedua, mari kita perkirakan permintaan untuk pemuatan/pemuatan ulang konfigurasi. Aplikasi Anda memuat semua pengaturan saat startup atau setiap kali perubahan kunci sentinel terdeteksi. Setiap permintaan ke App Configuration dapat mengambil hingga 100 nilai kunci, sehingga dibutuhkan 10 permintaan (=1000/100) untuk memuat semua pengaturan. Mengingat Anda memiliki 50 instans aplikasi, Anda mengirim total permintaan 500 (=10x50) saat aplikasi Anda memulai ulang atau memuat ulang konfigurasinya.

Akhirnya, mari kita satukan. Dengan asumsi Anda memperbarui kunci sentinel dua kali dalam satu jam, penyimpanan App Configuration Anda dengan demikian akan menerima total permintaan 7.000 (=6.000+500x2) untuk jam tersebut. Perhatikan bahwa dari permintaan ini, hanya sekitar 1.000 permintaan (=500x2) yang menggunakan kuota per jam yang tersedia untuk penyimpanan tingkat Standar. Perbarui angka dalam contoh ini agar sesuai dengan penyiapan dan desain spesifik Anda sehingga Anda memiliki buffer yang cukup terhadap batas kuota per jam.

† Penyimpanan tingkat gratis tidak sering memiliki permintaan berulang yang dikecualikan dari batas hariannya.

Aplikasi Anda mungkin menerima respons kode status HTTP 429 dalam keadaan berikut:

• Melebihi kuota permintaan harian untuk toko di tingkat Gratis.
• Melebihi kuota permintaan per jam untuk penyimpanan di tingkat Standar.
• Melebihi jatah throughput untuk penyimpanan di tingkat mana pun.
• Melebihi jatah bandwidth untuk penyimpanan di tingkat mana pun.
• Mencoba membuat atau mengubah nilai kunci saat kuota penyimpanan terlampaui.

Periksa isi respons 429 untuk alasan khusus mengapa permintaan gagal. Anda juga dapat mengumpulkan log untuk penyimpanan App Configuration di Azure Monitor dan menyiapkan pemberitahuan untuk metrik Permintaan Penggunaan Kuota.

Menerima respons kode status HTTP 429 sesaat biasanya tidak membahayakan, karena klien App Configuration menanganinya dengan anggun. Namun, jika aplikasi Anda secara teratur mengalami respons kode status HTTP 429, pertimbangkan opsi berikut:

• Tingkatkan penyimpanan Anda ke tingkat Premium: Tingkat ini tidak memiliki batas kuota pada permintaan dan telah meningkatkan kuota penyimpanan dan jatah throughput yang lebih tinggi.
• Gunakan Penyedia App Configuration: Penyedia memiliki kemampuan coba lagi dan penembolokan bawaan bersama dengan banyak fitur ketahanan lainnya. Pastikan untuk memperbarui ke versi terbaru penyedia untuk semua penyempurnaan terbaru.
• Gunakan SDK App Configuration jika aplikasi Anda perlu mengirim permintaan tulis. Meskipun SDK mungkin tidak kaya fitur sebagai penyedia, SDK secara otomatis mencoba kembali pada respons kode status HTTP 429 dan kesalahan sementara lainnya.
• Sertakan logika coba lagi di klien kustom jika Anda tidak dapat menggunakan Penyedia App Configuration atau SDK. Header retry-after-ms dalam respons menyediakan waktu tunggu yang disarankan (dalam milidetik) sebelum mencoba kembali permintaan.
• Mendistribusikan permintaan di beberapa instans klien: Ini membantu mencapai throughput maksimum dari penyimpanan App Configuration Anda.
• Mengurangi permintaan yang dibuat ke App Configuration: Ikuti panduan untuk meminimalkan jumlah permintaan.
• Meningkatkan ketahanan aplikasi Anda: Pertimbangkan untuk mengintegrasikan replikasi geografis untuk memungkinkan failover dan penyeimbangan beban. Periksa praktik terbaik untuk membangun aplikasi yang sangat tangguh.

Semua penyimpanan App Configuration di tingkat Standar dan Premium telah secara otomatis mengaktifkan fitur penghapusan sementara. Saat penyimpanan App Configuration tingkat Standar atau Premium dihapus, namanya dicadangkan untuk periode retensi. Untuk membuat ulang penyimpanan dengan nama yang sama sebelum periode retensi berakhir, Anda perlu hapus menyeluruh penyimpanan yang dihapus sementara terlebih dahulu, asalkan penyimpanan tidak mengaktifkan perlindungan penghapusan menyeluruh. Jika perlindungan penghapusan menyeluruh diaktifkan, Anda harus menunggu periode retensi selesai. Menggunakan fungsi penghapusan atau mengatur periode retensi yang lebih pendek jika Anda sering perlu membuat ulang penyimpanan dengan nama yang sama. Alur kerja yang memerlukan pembuatan ulang penyimpanan dengan nama yang sama harus memungkinkan selama satu jam antara menghapus menyeluruh penyimpanan konfigurasi dan melakukan pembuatan berikutnya. Rekomendasi ini diberlakukan karena setelah pembersihan diminta pembersihan aktual sumber daya penyimpanan konfigurasi dilakukan secara asinkron, membutuhkan sedikit waktu tambahan untuk menyelesaikannya. Untuk menghindari kebutuhan menunggu, alur kerja yang membuat penyimpanan konfigurasi sementara disarankan untuk menggunakan nama unik.

Semua penyimpanan App Configuration di tingkat Standar dan Premium mendukung fitur penghapusan sementara, yang tidak dapat dinonaktifkan. Anda dapat memulihkan penyimpanan yang dihapus dalam periode retensinya. Ikuti instruksi ini untuk memulihkan penyimpanan App Configuration yang dihapus secara keliru.

Ya. Meskipun Anda dapat mengelola tanda fitur dan referensi Key Vault di App Configuration melalui portal Azure atau CLI, Anda juga dapat membuat dan memperbaruinya secara terprogram menggunakan SDK App Configuration. Oleh karena itu, Anda dapat menulis portal manajemen yang disesuaikan atau mengelolanya di CI/CD Anda secara terprogram. Bendera fitur dan API referensi Key Vault tersedia di SDK dari semua bahasa yang didukung. Lihat link sampel untuk contoh dalam setiap bahasa yang didukung.

Mengevaluasi dan menggunakan tanda fitur dalam aplikasi Anda memerlukan penyedia App Configuration dan pustaka manajemen fitur, yang tersedia di .NET dan Java Spring. Lihat bagian Manajemen fitur di bawah Mulai Cepat dan Tutorial untuk informasi selengkapnya.

Profil Spring menyediakan cara untuk memisahkan bagian aplikasi Anda, termasuk konfigurasi, dan membuatnya hanya tersedia di lingkungan tertentu atau ketika pustaka tertentu digunakan.

Anda disarankan untuk mengatur label nilai kunci agar sesuai dengan profil Spring Anda. Secara default, pustaka penyedia App Configuration Spring memuat nilai kunci dengan label yang cocok dengan profil Spring aktif saat ini (${spring.profiles.active}) jika filter label tidak diatur secara eksplisit. Jika tidak ada kumpulan profil Spring aktif, nilai kunci dengan "tanpa label" akan dimuat.

Misalnya, dengan profil dev dan prod, Anda membuat nilai kunci yang sesuai dengan label berikut.

Ketika profil Spring diatur ke dev, nilainya config.message adalah Hello from dev. Ketika profil Spring diatur ke prod, nilainya config.message adalah Hello from prod.

Perilaku default ini dapat diganti dengan mengatur filter label dalam file bootstrap Anda. Pustaka penyedia Spring memuat nilai kunci dengan label yang ditentukan terlepas dari profil Spring aktif.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Untuk memilih label lain dan profil Spring Anda, Anda dapat menggunakan filter label seperti ',${spring.profiles.active}', yang akan memilih semua kunci tanpa label dan yang cocok dengan profil Spring Anda. Label paling kanan lebih diprioritaskan ketika kunci duplikat ditemukan.

Dimulai dengan versi 3.1.0, Microsoft.FeatureManagement pustaka memungkinkan menjalankan layanan manajemen fitur, termasuk filter fitur, sebagai layanan terlingkup dalam aplikasi .NET berbasis injeksi dependensi. Untuk memanfaatkan fitur ini, Anda cukup mengganti AddFeatureManagement panggilan dalam kode Anda dengan AddScopedFeatureManagement, seperti yang ditunjukkan dalam cuplikan kode berikut:

services.AddScopedFeatureManagement();

Filter fitur dapat mengevaluasi bendera fitur berdasarkan properti Permintaan HTTP. Ini biasanya dilakukan dengan memeriksa HttpContext melalui pola singleton IHttpContextAccessor . Namun, pola ini tidak berfungsi untuk aplikasi server Blazor di mana layanan tercakup harus digunakan sebagai gantinya. Dalam hal ini, AddScopedFeatureManagement metode harus digunakan.

Berlangganan repo pengumuman GitHub kami.

Anda dapat menghubungi kami langsung di GitHub.

• Tentang Azure App Configuration