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.

Batas 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 informasi selengkapnya, lihat langganan Azure dan batas layanan.

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 dua tingkatan harga:

• Tingkat gratis
• Tingkat standar

Jika Anda membuat toko sebelum pengenalan tingkat Standar, penyimpanan tersebut secara otomatis dipindahkan ke tingkat Gratis berdasarkan ketersediaan umum. Anda dapat memilih untuk meningkatkan ke tingkat Standar atau tetap di tingkat Gratis.

Anda tidak dapat menurunkan versi toko dari tingkat Standar ke tingkat Gratis. Anda dapat membuat toko baru di tingkat Gratis, lalu mengimpor data konfigurasi ke toko tersebut.

Kedua 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.

• Sumber daya per langganan: Sumber daya terdiri dari satu penyimpanan konfigurasi. Setiap langganan terbatas pada satu penyimpanan konfigurasi per wilayah di tingkat gratis. Langganan dapat memiliki jumlah penyimpanan konfigurasi yang tidak terbatas di tingkat standar.

• 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.

• Riwayat revisi: App Configuration menyimpan riwayat semua perubahan yang dilakukan pada kunci. Di tingkat gratis, riwayat ini disimpan selama tujuh hari. Di tingkat standar, 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 habis, permintaan mungkin kembali pada kode status HTTP 429 yang 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.

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

• Fitur: Kedua 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 menawarkan lebih banyak fungsi, termasuk dukungan Private Link, enkripsi dengan kunci yang dikelola pelanggan, perlindungan penghapusan sementara, dan kemampuan replikasi geografis.

• Biaya: Penyimpanan tingkat standar memiliki biaya penggunaan harian. 200.000 permintaan pertama setiap hari sudah termasuk dalam biaya harian. Ada juga akan dikenakan biaya tambahan untuk permintaan yang melewati alokasi harian. Tidak dikenakan biaya atas penggunaan penyimpanan tingkat gratis.

Anda dapat meningkatkan dari tingkat Gratis ke tingkat Standar kapan saja.

Anda tidak dapat menurunkan versi toko dari tingkat Standar ke tingkat Gratis. Anda dapat membuat toko baru di tingkat Gratis, lalu mengimpor data konfigurasi ke toko tersebut.

Data pelanggan yang disimpan di App Configuration berada di wilayah tempat penyimpanan App Configuration pelanggan dibuat. Data pelanggan akan 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 dengan Zona Ketersediaan yang aktif terdiri dari minimal 3 zona ketersediaan, di mana setiap wilayah merupakan 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 konfigurasi di tingkat Gratis dibatasi hingga 1.000 permintaan per hari. Penyimpanan konfigurasi di tingkat Standar mungkin mengalami pembatasan sementara saat tingkat permintaan melebihi 30.000 permintaan per jam.

Ketika sebuah penyimpanan mencapai batasnya di tingkat standar, penyimpanan tersebut dapat menampilkan kode status HTTP 429 untuk beberapa permintaan yang dilakukan hingga akhir jam. Header retry-after-ms dalam respons memberikan waktu tunggu yang disarankan (dalam milidetik) sebelum mencoba kembali permintaan.

Jika aplikasi Anda secara teratur mengalami respons kode status HTTP 429, pertimbangkan untuk mendesain ulang untuk mengurangi jumlah permintaan yang dibuat. Untuk informasi selengkapnya, lihat cara mengurangi permintaan yang dibuat ke App Configuration.

Anda akan menerima respons kode status HTTP 429 dalam keadaan berikut:

• Melebihi batas permintaan harian untuk penyimpanan di tingkat Gratis.
• Melebihi batas permintaan per jam untuk penyimpanan di tingkat standar.
• Pembatasan sesaat karena banyaknya jumlah permintaan†.
• Pembatasan sesaat karena penggunaan bandwidth yang berlebihan†.
• Mencoba membuat atau memodifikasi kunci saat kuota penyimpanan terlampaui.

Periksa isi respons 429 untuk alasan khusus mengapa permintaan gagal.

† Penyimpanan konfigurasi mungkin mengalami pembatasan sesaat jika menerima ledakan besar permintaan atau mentransfer volume data yang berlebihan. Klien App Configuration, seperti Azure SDK, pustaka penyedia konfigurasi, dan tugas Azure Pipelines, secara otomatis mencoba kembali permintaan yang dibatasi. Untuk setiap aplikasi yang menggunakan salah satu klien ini, atau klien khusus yang melakukan percobaan kembali pada permintaan yang dibatasi, pembatasan sesaat yang terjadi akan tidak terlihat.

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 berjalan di 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 akan mengirim satu permintaan untuk kunci sentinel ke App Configuration setiap 30 detik, sehingga akan mengirim 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 akan dihitung terhadap batas kuota per jam toko†.

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 diperlukan 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 akan menggunakan kuota per jam yang tersedia. Perbarui angka dalam contoh ini agar sesuai dengan penyiapan dan desain spesifik Anda sehingga Anda memiliki buffer yang cukup terhadap batas pembatasan per jam. Untuk informasi selengkapnya, lihat cara mengurangi permintaan yang dibuat ke App Configuration.

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

Semua penyimpanan App Configuration di tingkat standar telah secara otomatis mengaktifkan fitur penghapusan sementara. Saat penyimpanan App Configuration tingkat standar dihapus, nama tersebut dicadangkan selama 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 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 akan 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 akan 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 singletonIHttpContextAccessor. 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