Panduan pembatasan Azure Key Vault

  • Artikel

Throttling adalah proses yang Anda mulai yang membatasi jumlah panggilan bersamaan ke layanan Azure untuk mencegah penggunaan sumber daya yang berlebihan. Azure Key Vault (AKV) dirancang untuk menangani permintaan dalam jumlah besar. Jika permintaan yang luar biasa terjadi, pembatasan permintaan klien Anda membantu menjaga kinerja dan keandalan layanan AKV yang optimal.

Batas pembatasan bervariasi berdasarkan skenario. Misalnya, jika Anda melakukan penulisan dalam volume besar, kemungkinan untuk pembatasan lebih tinggi daripada jika Anda hanya melakukan bacaan.

Bagaimana Key Vault menangani batasannya?

Batas layanan di Vault Utama mencegah penyalahgunaan sumber daya dan memastikan kualitas layanan untuk semua klien Vault Utama. Ketika ambang batas layanan terlampaui, Key Vault membatasi permintaan lebih lanjut dari klien tersebut, mengembalikan kode status HTTP 429 (Terlalu banyak permintaan), dan permintaan gagal. Permintaan gagal yang mengembalikan 429 tidak dihitung dalam batas throttle yang dilacak oleh Key Vault.

Key Vault awalnya dirancang untuk menyimpan dan mengambil rahasia Anda pada waktu penyebaran. Dunia telah berevolusi, dan Key Vault digunakan pada waktu run-time untuk menyimpan dan mengambil rahasia, dan seringkali aplikasi dan layanan ingin menggunakan Key Vault seperti database. Batas saat ini tidak mendukung tingkat throughput tinggi.

Vault Kunci awalnya dibuat dengan batas yang ditentukan dalam batas layanan Vault Kunci Azure. Untuk memaksimalkan rasio throughput Key Vault Kunci, simak beberapa rekomendasi panduan/praktik terbaik untuk memaksimalkan throughput Anda:

  1. Pastikan Anda memiliki pembatasan di tempat. Klien harus mematuhi kebijakan back-off eksponensial untuk 429 dan memastikan Anda melakukan percobaan ulang sesuai panduan di bawah ini.
  2. Bagi lalu lintas Vault Utama Anda di antara beberapa kubah dan wilayah yang berbeda. Gunakan kubah terpisah untuk setiap domain keamanan/ketersediaan. Jika Anda memiliki lima aplikasi, masing-masing di dua wilayah, maka kami merekomendasikan 10 kubah yang masing-masing berisi rahasia unik untuk aplikasi dan wilayah. Batas seluruh langganan untuk semua jenis transaksi adalah lima kali batas brankas utama individual. Misalnya, transaksi HSM-lain per langganan dibatasi hingga 5.000 transaksi dalam 10 detik per langganan. Pertimbangkan untuk menyimpan rahasia dalam layanan atau aplikasi Anda untuk mengurangi RPS langsung ke brankas utama dan/atau menangani lalu lintas berbasis burst. Anda juga dapat membagi lalu lintas di antara berbagai wilayah untuk meminimalkan latensi dan menggunakan langganan/kubah yang berbeda. Jangan mengirim lebih dari batas langganan ke layanan Vault Utama dalam satu wilayah Azure.
  3. Singgahan rahasia yang Anda ambil dari Vault Kunci Azure dalam memori, dan gunakan kembali dari memori jika memungkinkan. Baca ulang dari Azure Key Vault hanya ketika salinan singgahan berhenti berfungsi (misalnya karena diputar di sumber).
  4. Key Vault dirancang untuk rahasia layanan Anda sendiri. Jika Anda menyimpan rahasia pelanggan Anda (terutama untuk skenario penyimpanan kunci throughput tinggi), pertimbangkan untuk menempatkan kunci di database atau akun penyimpanan dengan enkripsi, dan hanya menyimpan kunci utama di Azure Key Vault.
  5. Mengenkripsi, membungkus, dan memverifikasi operasi kunci publik dapat dilakukan tanpa akses ke Key Vault, yang tidak hanya mengurangi risiko pembatasan, tetapi juga meningkatkan keandalan (selama Anda menyimpan materi kunci publik dengan benar).
  6. Jika Anda menggunakan Key Vault untuk menyimpan kredensial untuk layanan, periksa apakah layanan tersebut mendukung autentikasi Microsoft Entra untuk mengautentikasi secara langsung. Ini mengurangi beban pada Key Vault, meningkatkan keandalan dan menyederhanakan kode Anda karena Key Vault sekarang dapat menggunakan token Microsoft Entra. Banyak layanan telah beralih menggunakan Microsoft Entra auth. Lihat daftar saat ini di Layanan yang mendukung identitas terkelola untuk sumber daya Azure.
  7. Pertimbangkan untuk mengejutkan beban/penyebaran Anda dalam jangka waktu yang lebih lama untuk tetap berada di bawah batas RPS saat ini.
  8. Jika aplikasi Anda terdiri dari beberapa simpul yang perlu membaca rahasia yang sama, maka pertimbangkan untuk menggunakan pola fan-out, di mana satu entitas membaca rahasia dari Key Vault, dan penggemar ke semua simpul. Cache rahasia yang diambil hanya dalam memori.

Cara membatasi aplikasi Anda sebagai respons terhadap batas layanan

Berikut ini adalah praktik terbaik yang harus Anda terapkan saat layanan Anda dibatasi:

  • Mengurangi jumlah operasi per permintaan.
  • Mengurangi frekuensi permintaan.
  • Hindari pengambilan segera.
    • Semua permintaan bertambah terhadap batas penggunaan Anda.

Saat Anda menerapkan penanganan kesalahan aplikasi, gunakan kode kesalahan HTTP 429 untuk mendeteksi kebutuhan throttling pihak klien. Jika permintaan gagal lagi dengan kode kesalahan HTTP 429, Anda masih mengalami batas layanan Azure. Terus gunakan metode throttling sisi klien yang direkomendasikan, coba lagi permintaan sampai berhasil.

Berikut adalah kode yang mengimplementasikan backoff eksponensial:

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

Menggunakan kode ini dalam aplikasi klien C# sangat mudah.

Pada kode galat HTTP 429, mulai membatasi klien Anda menggunakan pendekatan backoff eksponensial:

  1. Tunggu 1 detik, coba lagi permintaan
  2. Jika masih dibatasi, tunggu 2 detik, coba lagi permintaan
  3. Jika masih dibatasi, tunggu 4 detik, coba lagi permintaan
  4. Jika masih dibatasi, tunggu 8 detik, coba lagi permintaan
  5. Jika tetap terbatas, tunggu 16 detik, coba lagi permintaan

Pada titik ini, Anda seharusnya tidak mendapatkan kode respons HTTP 429.

Baca juga

Untuk orientasi throttling yang lebih dalam di Microsoft Cloud, lihat Pola Throttling.