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

  • Artikel

BERLAKU UNTUK: NoSQL

Artikel ini berisi penyebab dan solusi yang diketahui untuk berbagai kesalahan kode status 429 untuk API untuk NoSQL. 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 baca, tulis, dan kueri menggunakan beberapa jumlah 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.

Tip

Panduan dalam artikel ini berlaku untuk database dan kontainer yang menggunakan throughput yang diprovisikan - baik throughput skala otomatis maupun manual.

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. Jika Anda menggunakan throughput manual, skenario ini terjadi ketika Anda telah menggunakan lebih banyak RU/s daripada throughput manual yang diprovisikan. Jika Anda menggunakan skala otomatis, skenario terjadi ketika Anda telah menggunakan lebih banyak RU/s maksimum yang diprovisikan. Misalnya, jika Anda memiliki sumber daya yang disediakan dengan throughput manual 400 RU/dtk, Anda akan melihat 429 saat mengonsumsi lebih dari 400 unit permintaan dalam satu detik. Jika Anda memiliki sumber daya yang disediakan dengan RU/dtk maks skala otomatis 4000 RU/dtk (skala antara 400 RU/dtk - 4000 RU/dtk), Anda akan melihat 429 respons saat Anda menggunakan lebih dari 4000 unit permintaan dalam satu detik.

Tip

Semua operasi dibebankan berdasarkan jumlah sumber daya yang mereka konsumsi. Biaya ini diukur dalam unit permintaan. Biaya ini termasuk permintaan yang tidak berhasil diselesaikan karena kesalahan aplikasi seperti 400, 412, 449, dll. Saat melihat pembatasan atau penggunaan, ada baiknya untuk menyelidiki apakah beberapa pola telah berubah dalam penggunaan Anda yang akan mengakibatkan peningkatan operasi ini. Secara khusus, periksa tag 412 atau 449 (konflik aktual).

Untuk informasi selengkapnya tentang throughput yang disediakan, lihat throughput yang disediakan di Azure Cosmos DB.

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

Melihat pesan kesalahan 429 tidak selalu berarti ada masalah dengan database atau kontainer Anda. Persentase kecil dari 429 respons normal baik Anda menggunakan throughput manual atau skala otomatis, dan merupakan tanda bahwa Anda memaksimalkan RU/s yang telah Anda provisikan.

Cara menyelidiki

Tentukan berapa persen permintaan Anda ke database atau kontainer Anda yang menghasilkan 429 respons, dibandingkan dengan jumlah keseluruhan permintaan yang berhasil. Dari akun Azure Cosmos DB Anda, navigasikan kePermintaan>Wawasan>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 sembilan kali. Akibatnya, meskipun Anda mungkin melihat 429 respons dalam metrik, kesalahan ini bahkan mungkin belum dikembalikan ke 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 dengan respons 429, dan latensi ujung ke ujung Anda dapat diterima, ini adalah tanda sehat bahwa RU/dtk sedang digunakan sepenuhnya. Tidak diperlukan tindakan. Jika tidak demikian, lihatlah langkah selanjutnya tentang pemecahan masalah.

Penting

Rentang 1-5% ini mengasumsikan bahwa partisi akun Anda didistribusikan secara merata. Jika partisi Anda tidak didistribusikan secara merata, partisi masalah Anda dapat mengembalikan sejumlah besar kesalahan 429 sementara tingkat keseluruhan mungkin rendah.

Jika Anda menggunakan skala otomatis, Dimungkinkan untuk melihat 429 respons pada database atau kontainer Anda, bahkan jika RU/s tidak diskalakan ke RU/dtk maksimum. Lihat bagian Tingkat permintaan besar dengan skala otomatis untuk mendapatkan penjelasan.

Salah satu pertanyaan umum yang muncul adalah, "Mengapa saya melihat 429 respons dalam metrik Azure Monitor, tetapi tidak ada dalam pemantauan aplikasi saya sendiri?" Jika Metrik Azure Monitor menunjukkan bahwa Anda memiliki 429 respons, tetapi Anda belum melihat apa pun di aplikasi Anda sendiri, ini karena secara default, SDK automatically retried internally on the 429 responses klien Azure Cosmos DB dan permintaan berhasil dalam percobaan ulang berikutnya. Akibatnya, kode status 429 tidak dikembalikan ke aplikasi. Dalam kasus ini, tingkat keseluruhan respons 429 biasanya minimal dan dapat diabaikan dengan aman, dengan asumsi tingkat keseluruhan antara 1-5% dan latensi ujung ke ujung dapat diterima oleh aplikasi Anda.

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. Ini mengakibatkan banyak permintaan diarahkan ke subset kecil dari partisi logis (yang menyiratkan partisi fisik) yang menjadi "panas." Karena semua data untuk partisi logis berada pada satu partisi fisik dan total RU/dtk didistribusikan secara merata di antara partisi fisik, partisi panas dapat menyebabkan 429 respons 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 maupun 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 jauh lebih aktif dibandingkan yang lain, hal itu akan mengakibatkan 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 dipartisi oleh 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 dibandingkan yang lain (misalnya, satu partisi secara konsisten memiliki konsumsi 100%, tetapi yang lain memiliki konsumsi 30% atau kurang), hal ini bisa menjadi indikasi 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 menonaktifkannya saat tidak lagi diperlukan. Lihat halaman harga untuk detailnya.

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge 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.
  • Jangka pendek, Anda dapat meningkatkan RU/dtk sumber daya secara keseluruhan untuk 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.
  • Jangka pendek, Anda dapat menggunakan redistribusi throughput di seluruh fitur partisi (pratinjau) untuk menetapkan lebih banyak RU ke partisi fisik yang panas. Ini direkomendasikan hanya ketika partisi fisik panas dapat diprediksi dan konsisten.

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. Pelajari lebih lanjut dalam praktik terbaik terkait menskalakan throughput (RU) yang diprovisikan.

Langkah 3: Tentukan permintaan apa yang mengembalikan 429 respons

Cara menyelidiki permintaan dengan 429 respons

Gunakan Log Diagnostik Azure untuk mengidentifikasi permintaan mana yang mengembalikan 429 respons dan berapa banyak RU yang mereka konsumsi. 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.

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, 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.

Menggunakan perencana kapasitas Azure Cosmos DB

Anda dapat memanfaatkan perencana kapasitas Azure Cosmos DB untuk memahami throughput yang diprovisikan mana yang paling cocok berdasarkan beban kerja Anda (volume dan jenis operasi serta ukuran dokumen). Anda dapat menyesuaikan perhitungan lebih lanjut dengan menyediakan data sampel untuk mendapatkan estimasi yang lebih akurat.

429 respons pada permintaan dokumen buat, ganti, atau upsert
  • Secara default, dalam API untuk NoSQL, semua properti diindeks secara default. Setel kebijakan pengindeksan agar hanya mengindeks properti yang diperlukan. Ini akan menurunkan Unit Permintaan yang diperlukan per membuat operasi dokumen, yang akan mengurangi kemungkinan melihat 429 respons atau memungkinkan Anda untuk mencapai operasi yang lebih tinggi per detik untuk jumlah RU/s yang disediakan yang sama.
429 respons pada permintaan dokumen kueri
429 respons tentang menjalankan 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 performa terbaik, operasi baca atau kueri ini harus dilakukan di sisi klien, menggunakan Azure Cosmos DB SDK.

Tingkat permintaan besar dengan skala otomatis

Semua panduan dalam artikel ini berlaku untuk throughput manual dan skala otomatis.

Saat menggunakan skala otomatis, pertanyaan umum yang muncul adalah, "Apakah masih mungkin untuk melihat 429 respons dengan skala otomatis?"

Ya. Ada dua skenario utama yang bisa terjadi.

Skenario 1: Jika keseluruhan RU/s yang digunakan melebihi RU/s maksimal dari database atau kontainer, layanan akan membatasi permintaan sebagaimana mestinya. Hal ini sama seperti melebihi throughput yang diprovisikan dari database atau kontainer secara keseluruhan.

Skenario 2: Jika ada partisi panas, yaitu, nilai kunci partisi logis yang memiliki jumlah permintaan yang jauh lebih tinggi dibandingkan dengan nilai kunci partisi lainnya, dimungkinkan bagi partisi fisik yang mendasarinya melebihi anggaran RU/dtk. Sebagai praktik terbaik, untuk menghindari partisi panas, pilih kunci partisi yang baik yang menghasilkan distribusi yang seimbang pada penyimpanan dan throughput. Ini mirip dengan ketika ada partisi panas saat menggunakan throughput manual.

Misalnya, jika Anda memilih opsi throughput 20.000 RU/s maksimum dan memiliki penyimpanan 200 GB, dengan empat partisi fisik, setiap partisi fisik dapat diskalakan secara otomatis hingga 5.000 RU/s. Jika ada partisi panas pada kunci partisi logis tertentu, Anda akan melihat 429 respons ketika partisi fisik dasar yang berada di melebihi 5000 RU/dtk, yaitu, melebihi 100% pemanfaatan yang dinormalisasi.

Ikuti panduan di Langkah 1, Langkah 2, dan Langkah 3 untuk men-debug skenario ini.

Pertanyaan umum lain yang muncul adalah, Mengapa konsumsi RU yang dinormalisasinya 100%, tetapi skala otomatis tidak diskalakan ke RU/s maksimumnya?

Ini biasanya terjadi untuk beban kerja yang memiliki lonjakan penggunaan sementara atau lonjakan yang terputus-putus. Saat Anda menggunakan skala otomatis, Azure Cosmos DB hanya menskalakan RU ke throughput maksimum ketika konsumsi RU yang dinormalisasi adalah 100% untuk periode waktu berkelanjutan yang berkelanjutan dalam interval 5 detik. Hal ini dilakukan untuk memastikan logika penskalaan hemat bagi pengguna, karena memastikan bahwa lonjakan tunggal dan sesaat tidak menyebabkan penskalaan yang tidak diperlukan dan biaya yang lebih tinggi. Ketika ada lonjakan sesaat, sistem biasanya menskalakan hingga nilai yang lebih tinggi dibandingkan dengan yang sebelumnya diskalakan ke RU/s, tetapi lebih rendah dari RU/s maksimumnya. Pelajari selengkapnya cara menafsirkan metrik konsumsi RU yang dinormalisasi dengan skala otomatis.

Pembatasan pada permintaan metadata

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

  • Membuat, membaca, memperbarui, atau menghapus kontainer atau database
  • Mencantumkan database atau kontainer di akun Azure Cosmos DB
  • 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 Batas Layanan Sarana Kontrol.

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 Azure Cosmos DB statis. Ketika DocumentClient atau CosmosClient diinisialisasi, Azure Cosmos DB SDK 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