Mendiagnosis dan memecahkan masalah pengecualian tingkat permintaan terlalu besar (429) dalam Azure Cosmos DB

BERLAKU UNTUK: API SQL

Artikel ini berisi penyebab dan solusi yang diketahui untuk berbagai kesalahan API SQL dengan kode status 429. Jika Anda menggunakan API untuk MongoDB, lihat artikel Memecahkan masalah umum pada API untuk MongoDB untuk mengetahui cara men-debug masalah dengan kode status 16500.

Pengecualian "Tingkat permintaan terlalu besar", yang juga dikenal sebagai kode kesalahan 429, menunjukkan bahwa permintaan Anda terhadap Azure Cosmos DB sedang dibatasi.

Saat menggunakan throughput yang tersedia, Anda menetapkan throughput yang diukur dalam unit permintaan per detik (RU/s) yang diperlukan untuk beban kerja Anda. Operasi database terhadap layanan, seperti membaca, menulis, dan meminta kueri, mengonsumsi sejumlah unit permintaan (RU). Pelajari lebih lanjut tentang unit permintaan.

Dalam detik tertentu, jika operasi mengonsumsi lebih dari unit permintaan yang disediakan, Azure Cosmos DB akan menghasilkan pengecualian 429. Setiap detik, jumlah unit permintaan yang tersedia untuk digunakan akan direset.

Sebelum mengambil tindakan untuk mengubah RU/s, Anda perlu memahami akar penyebab pembatasan jumlah permintaan dan mengatasi masalah yang mendasarinya.

Ada berbagai pesan kesalahan yang berhubungan dengan berbagai jenis pengecualian 429:

Tingkat permintaan terlalu besar

Ini adalah skenario yang paling umum. Skenario ini terjadi ketika unit permintaan yang dikonsumsi oleh operasi pada data melebihi jumlah RU/s yang disediakan.

Langkah 1: Periksa metrik untuk menentukan persentase permintaan dengan kesalahan 429

Munculnya pesan kesalahan 429 tidak selalu berarti ada masalah dengan database atau kontainer Anda.

Cara menyelidiki

Tentukan berapa persen permintaan Anda ke database atau kontainer Anda yang menghasilkan pesan kesalahan 429, dibandingkan dengan jumlah keseluruhan permintaan yang berhasil. Dari bilah akun Azure Cosmos DB Anda, buka Insights > Permintaan > Total Permintaan berdasarkan Kode Status. Lakukan pemfilteran ke database dan kontainer tertentu.

Secara default, SDK klien Azure Cosmos DB dan alat pengimpor data, seperti Azure Data Factory dam pustaka eksekutor massal, akan secara otomatis mencoba ulang permintaan saat mengalami kesalahan 429. Biasanya percobaan ulang tersebut dilakukan hingga 9 kali. Akibatnya, meskipun Anda mungkin melihat 429 dalam metrik, kesalahan ini bahkan mungkin belum ditampilkan di aplikasi Anda.

Bagan Total Permintaan menurut Kode Status yang memperlihatkan jumlah permintaan 429 dan 2xx.

Secara umum, untuk beban kerja produksi, jika Anda melihat antara 1-5% permintaan 429 dan latensi ujung ke ujung Anda dapat diterima, ini adalah tanda baik bahwa RU/s telah dimanfaatkan sepenuhnya. Tidak diperlukan tindakan. Jika tidak demikian, lihatlah langkah selanjutnya tentang pemecahan masalah.

Langkah 2: Tentukan apakah ada partisi panas

Partisi panas muncul ketika satu atau beberapa kunci partisi logis mengonsumsi jumlah yang tidak proporsional dari total RU/s akibat volume permintaan yang lebih tinggi. Ini dapat disebabkan oleh desain kunci partisi yang tidak mendistribusikan permintaan secara merata. Hal ini menyebabkan banyak permintaan diarahkan ke subset kecil partisi logis (yang berarti partisi fisik) yang menjadi "panas". Karena semua data untuk partisi logis berada pada satu partisi fisik dan total RU/s didistribusikan secara merata di semua partisi fisik, partisi panas dapat menyebabkan kesalahan 429 dan penggunaan throughput yang tidak efisien.

Berikut adalah beberapa contoh strategi pembuatan partisi yang menyebabkan partisi panas:

  • Anda memiliki kontainer yang menyimpan data perangkat IoT untuk beban kerja dominan tulis yang dipartisikan berdasarkan date. Semua data untuk satu tanggal akan berada pada partisi logis dan fisik yang sama. Karena semua data yang ditulis setiap hari memiliki tanggal yang sama, hal ini akan menghasilkan partisi panas setiap hari.
    • Sebaliknya, untuk skenario ini, kunci partisi seperti id (baik GUID ataupun id perangkat), atau kunci partisi sintetis yang menggabungkan id dan date akan menghasilkan kardinalitas nilai yang lebih tinggi dan distribusi volume permintaan yang lebih baik.
  • Anda memiliki skenario multi-penyewa dengan kontainer yang dipartisikan berdasarkan tenantId. Jika satu penyewa secara signifikan lebih aktif daripada yang lain, hal itu akan menghasilkan partisi panas. Misalnya, jika penyewa terbesar memiliki 100.000 pengguna, tetapi sebagian besar penyewa memiliki kurang dari 10 pengguna, Anda akan memiliki partisi panas saat dipartisikan berdasarkan tenantID.
    • Untuk skenario sebelumnya, pertimbangkan untuk memiliki kontainer khusus untuk penyewa terbesar, yang dipartisikan berdasarkan properti yang lebih terperinci seperti UserId.

Cara mengidentifikasi partisi panas

Untuk memverifikasi apakah ada partisi panas, buka Insights > Throughput > Konsumsi RU yang Dinormalisasi (%) Berdasarkan PartitionKeyRangeID. Lakukan pemfilteran ke database dan kontainer tertentu.

Setiap PartitionKeyRangeId dipetakan ke satu partisi fisik. Jika ada satu PartitionKeyRangeId yang memiliki konsumsi RU yang Dinormalisasi yang jauh lebih tinggi daripada yang lain (misalnya, satu partisi secara konsisten memiliki konsumsi 100%, tetapi yang lain memiliki konsumsi 30% atau kurang), hal ini bisa menjadi tanda partisi panas. Pelajari lebih lanjut mengenai metrik Konsumsi RU yang Dinormalisasi.

Bagan Konsumsi RU yang Dinormalisasi oleh PartitionKeyRangeId dengan partisi panas.

Untuk melihat kunci partisi logis mana yang paling banyak mengkonsumsi RU/s, gunakan Azure Diagnostic Logs. Kueri sampel ini menjumlah total unit permintaan yang dikonsumsi per detik pada setiap kunci partisi logis.

Penting

Pengaktifan log diagnostik menimbulkan biaya terpisah untuk layanan Analitik Log, yang ditagih berdasarkan volume data yang diserap. Sebaiknya Anda mengaktifkan log diagnostik untuk waktu yang terbatas saat melakukan debug dan mematikannya saat tidak lagi diperlukan. Lihat halaman harga untuk detailnya.

AzureDiagnostics
| where TimeGenerated >= ago(24hour)
| where Category == "PartitionKeyRUConsumption"
| where collectionName_s == "CollectionName" 
| where isnotempty(partitionKey_s)
// Sum total request units consumed by logical partition key for each second
| summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)
| order by sum_requestCharge_s desc

Output sampel ini menunjukkan bahwa dalam menit tertentu, kunci partisi logis dengan nilai "Contoso" dikonsumsi sekitar 12.000 RU/s, sementara kunci partisi logis dengan nilai "Fabrikam" dikonsumsi kurang dari 600 RU/s. Jika pola ini konsisten selama periode waktu saat pembatasan terjadi, pola ini akan menunjukkan adanya partisi panas.

Kunci partisi logis yang mengonsumsi unit permintaan per detik paling banyak.

Tip

Dalam beban kerja apa pun, volume permintaan di seluruh partisi logis pasti akan bervariasi. Anda harus menentukan apakah partisi panas disebabkan oleh kecondongan mendasar karena pemilihan kunci partisi (yang mungkin memerlukan pengubahan kunci) atau lonjakan sementara karena variasi alami dalam pola beban kerja.

Baca panduan tentang cara memilih kunci partisi yang baik.

Jika ada persentase tinggi dari permintaan yang jumlahnya dibatasi dan tidak ada partisi panas:

Jika ada persentase tinggi dari permintaan yang jumlahnya dibatasi dan ada partisi panas yang mendasarinya:

  • Untuk jangka panjang, demi mendapatkan biaya dan kinerja terbaik, pertimbangkan untuk mengubah kunci partisi. Kunci partisi tidak dapat diperbarui, sehingga ini diperlukan migrasi data ke kontainer baru dengan kunci partisi yang berbeda. Azure Cosmos DB mendukung alat migrasi data langsung untuk tujuan ini.
  • Untuk jangka pendek, Anda dapat meningkatkan RU/s untuk sementara guna memungkinkan lebih banyak throughput ke partisi panas. Hal ini tidak disarankan sebagai strategi jangka panjang karena akan menyebabkan kelebihan provisi RU/s dan biaya yang lebih tinggi.

Tip

Ketika Anda meningkatkan throughput, operasi peningkatan skala antara akan selesai secara instan atau memerlukan waktu hingga 5-6 jam untuk menyelesaikannya, tergantung pada jumlah RU/s yang ingin Anda tingkatkan skalanya. Jika Anda ingin mengetahui jumlah RU/s tertinggi yang dapat Anda tetapkan tanpa memicu operasi peningkatan skala yang asinkron (yang mengharuskan Azure Cosmos DB menyediakan lebih banyak partisi fisik), kalikan jumlah PartitionKeyRangeIds yang berbeda dengan 10.0000 RU/s. Misalnya, jika Anda memiliki 30.000 RU/s yang disediakan dan 5 partisi fisik (6.000 RU/s akan dialokasikan per partisi fisik), Anda dapat meningkatkannya menjadi 50.000 RU/s (10.000 RU/s per partisi fisik) dalam operasi peningkatan skala seketika. Peningkatan menjadi >50.000 RU/s akan membutuhkan operasi peningkatan asinkron.

Langkah 3: Tentukan permintaan apa yang menghasilkan kesalahan 429

Cara menyelidiki permintaan yang memiliki kesalahan 429

Gunakan Azure Diagnostic Logs untuk mengidentifikasi permintaan mana yang menghasilkan kesalahan 429 dan berapa banyak RU yang dikonsumsi. Sampel kueri ini diagregasi pada tingkat menit.

Penting

Pengaktifan log diagnostik menimbulkan biaya terpisah untuk layanan Analitik Log yang ditagih berdasarkan volume data yang diserap. Sebaiknya Anda mengaktifkan log diagnostik untuk waktu yang terbatas saat melakukan debug dan mematikannya saat tidak lagi diperlukan. Lihat halaman harga untuk detailnya.

AzureDiagnostics
| where TimeGenerated >= ago(24h)
| where Category == "DataPlaneRequests"
| summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, bin(TimeGenerated, 1min)
| extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations 
| extend fractionOf429s = 1.0 * throttledOperations / totalOperations
| order by fractionOf429s desc

Misalnya, output sampel ini menunjukkan bahwa setiap menit, 30% permintaan Buat Dokumen dibatasi, dengan setiap permintaan mengonsumsi rata-rata 17 RU. Permintaan dengan 429 di Log Diagnostik.

429 pada permintaan buat, ganti, atau upsert dokumen
  • Secara default, dalam API SQL, semua properti diindeks secara default. Setel kebijakan pengindeksan agar hanya mengindeks properti yang diperlukan. Ini akan menurunkan Unit Permintaan yang diperlukan per operasi pembuatan dokumen, sehingga akan mengurangi kemungkinan melihat 429 atau memungkinkan Anda untuk mencapai operasi yang lebih tinggi per detik untuk jumlah ketersediaan RU/s yang sama.
429 pada permintaan kueri dokumen
429 pada eksekusi prosedur tersimpan
  • Prosedur tersimpan ditujukan untuk operasi yang memerlukan transaksi tulis di seluruh nilai kunci partisi. Tidak disarankan untuk menggunakan prosedur tersimpan untuk operasi baca atau kueri dalam jumlah besar. Untuk kinerja terbaik, operasi baca atau kueri ini harus dilakukan pada sisi klien dengan menggunakan SDK Cosmos.

Pembatasan pada permintaan metadata

Pembatasan jumlah permintaan metadata dapat terjadi ketika Anda melakukan operasi metadata dalam volume tinggi pada database dan/atau kontainer. Operasi metadata antara lain:

  • Membuat, membaca, memperbarui, atau menghapus kontainer atau database
  • Melihat daftar database atau kontainer di akun Cosmos
  • Mengajukan kueri untuk penawaran untuk melihat throughput yang disediakan saat ini

Ada batas RU yang tersimpan dalam sistem untuk operasi ini, sehingga peningkatan RU/s yang disediakan pada database atau kontainer tidak akan berdampak apa pun dan tidak disarankan. Lihat batasan pada operasi metadata.

Cara menyelidiki

Buka Insights > Sistem > Permintaan Metadata Berdasarkan Kode Status. Lakukan pemfilteran ke database dan kontainer tertentu jika diinginkan.

Bagan permintaan metadata berdasarkan kode status di Insights.

  • Jika aplikasi Anda perlu melakukan operasi metadata, pertimbangkan untuk menerapkan kebijakan backoff untuk mengirim permintaan ini dalam jumlah yang lebih rendah.

  • Gunakan instans klien Cosmos DB statis. Saat DocumentClient atau CosmosClient diinisialisasi, SDK Cosmos DB mengambil metadata tentang akun, termasuk informasi tentang tingkat konsistensi, database, kontainer, partisi, dan penawaran. Inisialisasi ini dapat menggunakan sejumlah besar RU, dan tidak untuk digunakan secara berkala. Gunakan satu instans DocumentClient dan gunakan untuk masa pakai aplikasi Anda.

  • Simpan nama database dan kontainer di cache. Ambil nama database dan kontainer Anda dari konfigurasi atau simpan nama tersebut di cache saat memulai. Panggilan seperti ReadDatabaseAsync/ReadDocumentCollectionAsync atau CreateDatabaseQuery/CreateDocumentCollectionQuery akan menghasilkan panggilan metadata ke layanan, yang mengonsumsi dari batas RU yang tersimpan dalam sistem. Operasi ini tidak boleh dilakukan terlalu sering.

Pembatasan jumlah permintaan karena kesalahan layanan sementara

Kesalahan 429 ini dihasilkan ketika permintaan menemui kesalahan layanan sementara. Peningkatan RU/s pada database atau kontainer tidak akan memiliki pengaruh apa pun dan tidak direkomendasikan.

Coba lagi permintaannya. Jika kesalahan berlanjut selama beberapa menit, ajukan tiket dukungan dari portal Microsoft Azure.

Langkah berikutnya