Azure Cosmos DB istek oranı çok yüksek (429) özel durumlarını tanılama ve sorun giderme

  • Makale

UYGULANANLAR: NOSQL

Bu makale, NoSQL API'sine yönelik çeşitli 429 durum kodu hatalarının bilinen nedenlerini ve çözümlerini içerir. MongoDB API'sini kullanıyorsanız, 16500 durum kodunda hata ayıklama için MongoDB IÇIN API'de sık karşılaşılan sorunları giderme makalesine bakın.

Hata kodu 429 olarak da bilinen "İstek oranı çok büyük" özel durumu, Azure Cosmos DB'ye yönelik isteklerinizin hız sınırlaması olduğunu gösterir.

Sağlanan aktarım hızını kullandığınızda, iş yükünüz için gereken saniye başına istek birimleri (RU/sn) cinsinden ölçülen aktarım hızını ayarlarsınız. Okumalar, yazmalar ve sorgular gibi hizmete karşı veritabanı işlemleri bir miktar istek birimi (RU) tüketir. İstek birimleri hakkında daha fazla bilgi edinin.

Belirli bir saniyede, işlemler sağlanan istek birimlerinden daha fazlasını tüketirse Azure Cosmos DB 429 özel durumu döndürür. Her saniye, kullanılabilecek istek birimi sayısı sıfırlanır.

RU/sn'yi değiştirmek için bir eylem gerçekleştirmeden önce hız sınırlamasının kök nedenini anlamak ve temel sorunu çözmek önemlidir.

İpucu

Bu makaledeki kılavuz, sağlanan aktarım hızını kullanan veritabanları ve kapsayıcılar için geçerlidir; hem otomatik ölçeklendirme hem de el ile aktarım hızı.

Farklı 429 özel durum türlerine karşılık gelen farklı hata iletileri vardır:

İstek oranı büyük

Bu en yaygın senaryodur. Veriler üzerindeki işlemler tarafından kullanılan istek birimleri sağlanan RU/sn sayısını aştığında oluşur. El ile aktarım hızı kullanıyorsanız, sağlanan el ile aktarım hızından daha fazla RU/sn kullandığınızda bu durum oluşur. Otomatik ölçeklendirme kullanıyorsanız, sağlanan maksimum RU/sn'den daha fazlasını kullandığınızda bu durum oluşur. Örneğin, el ile 400 RU/sn aktarım hızıyla sağlanan bir kaynağınız varsa, tek bir saniyede 400'den fazla istek birimi kullandığınızda 429 görürsünüz. 4000 RU/sn (400 RU/sn - 4000 RU/sn arasında ölçeklendirilir) otomatik ölçeklendirme maksimum RU/sn ile sağlanan bir kaynağınız varsa, tek bir saniyede 4000'den fazla istek birimi kullandığınızda 429 yanıt görürsünüz.

İpucu

Tüm işlemler, kullandıkları kaynak sayısına göre ücretlendirilir. Bu ücretler istek birimleriyle ölçülür. Bu ücretler, , 412, 449vb. gibi 400uygulama hataları nedeniyle başarıyla tamamlanmayan istekleri içerir. Azaltmaya veya kullanıma bakarken, kullanımınızda bu işlemlerin artmasına neden olacak bir desenin değişip değişmediğini araştırmak iyi bir fikirdir. Özellikle etiketleri 412 veya 449 (gerçek çakışma) denetleyin.

Sağlanan aktarım hızı hakkında daha fazla bilgi için bkz. Azure Cosmos DB'de sağlanan aktarım hızı.

1. Adım: 429 hatasıyla isteklerin yüzdesini belirlemek için ölçümleri denetleyin

429 hata iletilerini görmek, veritabanınızda veya kapsayıcınızda bir sorun olduğu anlamına gelmez. El ile veya otomatik ölçeklendirme aktarım hızı kullandığınızda 429 yanıtın küçük bir yüzdesi normaldir ve sağladığınız RU/sn değerini en üst düzeye çıkardığınızın işaretidir.

Araştırma adımları

Veritabanınıza veya kapsayıcınıza yönelik isteklerinizin yüzde kaçının başarılı isteklerin toplam sayısına kıyasla 429 yanıta neden olduğunu belirleyin. Azure Cosmos DB hesabınızdan, Durum KodunaGöre İçgörü>İstekleri> Toplam İstekler'e gidin. Belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

Varsayılan olarak, Azure Cosmos DB istemci SDK'ları ve Azure Data Factory ve toplu yürütücü kitaplığı gibi veri içeri aktarma araçları istekleri 429'larda otomatik olarak yeniden dener. Genellikle en fazla dokuz kez yeniden denerler. Sonuç olarak ölçümlerde 429 yanıt görebilirsiniz ancak bu hatalar uygulamanıza döndürülmemiş bile olabilir.

Durum Koduna Göre Toplam İstek sayısı grafiği, 429 ve 2xx istek sayısını gösterir.

Genel olarak, bir üretim iş yükü için 429 yanıt içeren isteklerin %1-5'ini görüyorsanız ve uçtan uca gecikmeniz kabul edilebilirse bu, RU/sn'lerin tam olarak kullanıldığına ilişkin iyi durumda bir işarettir. İşlem yapmanız gerekmez. Aksi takdirde, sonraki sorun giderme adımlarına geçin.

Önemli

Bu %1-5 aralığı, hesap bölümlerinizin eşit olarak dağıtıldığını varsayar. Bölümleriniz eşit dağıtılmadıysa, sorun bölümünüz büyük miktarda 429 hatası döndürebilir ve genel oran düşük olabilir.

Otomatik ölçeklendirme kullanıyorsanız, RU/sn en yüksek RU/sn'ye ölçeklendirilmemiş olsa bile veritabanınızda veya kapsayıcınızda 429 yanıt görebilirsiniz. Açıklama için İstek oranı otomatik ölçeklendirme ile büyük bölümüne bakın.

Sık sorulan sorulardan biri şudur: "Azure İzleyici ölçümlerinde neden 429 yanıt görüyorum, ancak kendi uygulama izlememde yok?" Azure İzleyici Ölçümleri 429 yanıtınız olduğunu gösteriyorsa ancak kendi uygulamanızda hiç yanıt görmediyseniz, bunun nedeni varsayılan olarak Azure Cosmos DB istemci SDK'ları automatically retried internally on the 429 responses ve isteğin sonraki yeniden denemelerde başarılı olmasıdır. Sonuç olarak, 429 durum kodu uygulamaya döndürülmüyor. Bu gibi durumlarda, 429 yanıtın genel oranı genellikle en düşük düzeydedir ve genel oranın %1-5 arasında olduğu ve uçtan uca gecikme süresinin uygulamanız için kabul edilebilir olduğu varsayıldığında güvenli bir şekilde yoksayılabilir.

2. Adım: Sık erişimli bölüm olup olmadığını belirleme

Sık erişimli bölüm, bir veya birkaç mantıksal bölüm anahtarı daha yüksek istek hacmi nedeniyle toplam RU/sn'nin orantısız bir miktarını tükettiğinde ortaya çıkar. Bunun nedeni istekleri eşit olarak dağıtmayan bir bölüm anahtarı tasarımı olabilir. Birçok isteğin "sık" duruma gelen küçük bir mantıksal (fiziksel) bölüm alt kümesine yönlendirilmesiyle sonuçlanır. Mantıksal bölümün tüm verileri tek bir fiziksel bölümde bulunduğundan ve toplam RU/sn fiziksel bölümler arasında eşit olarak dağıtıldığı için, sık erişimli bölüm 429 yanıta ve aktarım hızının verimsiz kullanımına yol açabilir.

Sık erişimli bölümlere yol açan bölümleme stratejilerine bazı örnekler aşağıda verilmiştir:

  • tarafından datebölümlenmiş yoğun yazma iş yükü için IoT cihaz verilerini depolayan bir kapsayıcınız var. Tek bir tarihe ilişkin tüm veriler aynı mantıksal ve fiziksel bölümde yer alır. Her gün yazılan tüm veriler aynı tarihe sahip olduğundan, bu durum her gün sık erişimli bölüme neden olur.
    • Bunun yerine, bu senaryo için gibi id bir bölüm anahtarı (GUID veya cihaz kimliği) veya yapay bir bölüm anahtarı birleştirilerek iddate değerlerin daha yüksek kardinalitesi ve istek biriminin daha iyi dağıtılması sağlanmıştır.
  • tarafından bölümlenmiş tenantIdbir kapsayıcı ile çok kiracılı bir senaryonuz var. Bir kiracı diğerlerinden çok daha etkinse, sık erişimli bölümle sonuçlanır. Örneğin, en büyük kiracı 100.000 kullanıcıya sahipse ancak çoğu kiracının 10'dan az kullanıcısı varsa, tarafından tenantIDbölümlendiğinde sık erişimli bir bölüme sahip olursunuz.
    • Önceki bu senaryoda, gibi daha ayrıntılı bir özellik UserIdtarafından bölümlenmiş en büyük kiracı için ayrılmış bir kapsayıcıya sahip olmayı göz önünde bulundurun.

Sık erişimli bölümü tanımlama

Sık erişimli bölüm olup olmadığını doğrulamak için İçgörü aktarım>hızı>Normalleştirilmiş RU Tüketimi (%) By PartitionKeyRangeID bölümüne gidin. Belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

Her PartitionKeyRangeId bir fiziksel bölüme eşler. Normalleştirilmiş RU tüketimi diğerlerinden çok daha yüksek olan bir PartitionKeyRangeId varsa (örneğin, biri tutarlı olarak %100'de, diğerleri ise %30 veya daha azsa), bu sık erişimli bölümün işareti olabilir. Normalleştirilmiş RU Tüketimi ölçümü hakkında daha fazla bilgi edinin.

Sık erişimli bölüme sahip PartitionKeyRangeId grafiği tarafından normalleştirilmiş RU Tüketimi.

En çok RU/sn kullanan mantıksal bölüm anahtarlarını görmek için Azure Tanılama Günlükleri'ni kullanın. Bu örnek sorgu, her mantıksal bölüm anahtarında saniyede tüketilen toplam istek birimlerini özetler.

Önemli

Tanılama günlüklerinin etkinleştirilmesi Log Analytics hizmeti için ayrı bir ücretlendirilir ve bu ücret alınan veri hacmine göre faturalandırılır. Tanılama günlüklerini hata ayıklama için sınırlı bir süre boyunca açmanız ve artık gerekli olmadığında kapatmanız önerilir. Ayrıntılar için fiyatlandırma sayfasına bakın.

 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

Bu örnek çıktı, belirli bir dakika içinde "Contoso" değerine sahip mantıksal bölüm anahtarının yaklaşık 12.000 RU/sn tüketildiğini, "Fabrikam" değerine sahip mantıksal bölüm anahtarının ise 600 RU/sn'den az tüketildiğini gösterir. Bu desen, hız sınırlamanın gerçekleştiği zaman aralığında tutarlıysa, bu bir sık erişimli bölüm olduğunu gösterir.

Saniyede en fazla istek birimini kullanan mantıksal bölüm anahtarları.

İpucu

Herhangi bir iş yükünde, mantıksal bölümler arasında istek hacminde doğal bir değişim olacaktır. Sık erişimli bölümün, bölüm anahtarı seçiminden kaynaklanan temel bir dengesizlikten mi (anahtarın değiştirilmesini gerektirebilir) yoksa iş yükü desenlerindeki doğal değişim nedeniyle geçici bir ani artıştan mı kaynaklandığına karar vermelisiniz.

İyi bir bölüm anahtarı seçme yönergelerini gözden geçirin.

Hız sınırlı isteklerin yüzdesi yüksekse ve sık erişimli bölüm yoksa:

Hız sınırına sahip isteklerin yüzdesi yüksekse ve temel alınan bir sık erişimli bölüm varsa:

  • En iyi maliyet ve performans için uzun vadeli bölüm anahtarını değiştirmeyi göz önünde bulundurun. Bölüm anahtarı yerinde güncelleştirilemez, bu nedenle verilerin farklı bir bölüm anahtarına sahip yeni bir kapsayıcıya geçirilmesi gerekir. Azure Cosmos DB bu amaçla bir dinamik veri geçiş aracını destekler.
  • Kısa vadeli olarak, sık erişimli bölüme daha fazla aktarım hızı sağlamak için kaynağın genel RU/sn değerini geçici olarak artırabilirsiniz. Ru/sn'nin fazla sağlanmasına ve maliyetin daha yüksek olmasına yol açtığı için bu uzun vadeli bir strateji olarak önerilmez.
  • Kısa vadeli olarak, sık erişimli fiziksel bölüme daha fazla RU/sn atamak için bölümler arasında aktarım hızı yeniden dağıtma özelliğini (önizleme) kullanabilirsiniz. Bu yalnızca sık erişimli fiziksel bölüm tahmin edilebilir ve tutarlı olduğunda önerilir.

İpucu

Aktarım hızını artırdığınızda, ölçeği artırmak istediğiniz RU/sn sayısına bağlı olarak ölçeği artırma işlemi anında tamamlanır veya tamamlanması 5-6 saate kadar sürebilir. Zaman uyumsuz ölçeklendirme işlemini tetiklemeden ayarlayabileceğiniz en yüksek RU/sn sayısını bilmek istiyorsanız (azure cosmos DB'nin daha fazla fiziksel bölüm sağlaması gerekir), ayrı PartitionKeyRangeId sayısını 10.0000 RU/sn ile çarpın. Örneğin, sağlanan 30.000 RU/sn ve 5 fiziksel bölümünüz (fiziksel bölüm başına 6000 RU/sn) varsa, anlık ölçeklendirme işleminde 50.000 RU/sn'ye (fiziksel bölüm başına 10.000 RU/sn) artırabilirsiniz. 50.000 RU/sn'ye çıkılması >zaman uyumsuz bir ölçeklendirme işlemi gerektirir. Sağlanan aktarım hızını (RU/sn) ölçeklendirmeye yönelik en iyi yöntemler hakkında daha fazla bilgi edinin.

3. Adım: Hangi isteklerin 429 yanıt döndüreceğini belirleme

429 yanıtla istekleri araştırma

Hangi isteklerin 429 yanıt döndürüp kaç RU tükettiğini belirlemek için Azure Tanılama Günlüklerini kullanın. Bu örnek sorgu dakika düzeyinde toplanır.

Önemli

Tanılama günlüklerinin etkinleştirilmesi, alınan veri hacmine göre faturalandırılan Log Analytics hizmeti için ayrı bir ücretlendirilir. Tanılama günlüklerini hata ayıklama için sınırlı bir süre boyunca açmanız ve artık gerekli olmadığında kapatmanız önerilir. Ayrıntılar için fiyatlandırma sayfasına bakın.

 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

Örneğin, bu örnek çıktı, Belge Oluşturma isteklerinin her dakikasının %30'unun hız sınırlaması olduğunu ve her isteğin ortalama 17 RU tükettiğini gösterir. Tanılama Günlüklerinde 429 ile istekler.

Azure Cosmos DB kapasite planlayıcısını kullanma

İş yükünüz (işlem hacmi ve türü ve belgelerin boyutu) temelinde en iyi sağlanan aktarım hızını anlamak için Azure Cosmos DB kapasite planlayıcısını kullanabilirsiniz. Daha doğru bir tahmin elde etmek için örnek veriler sağlayarak hesaplamaları daha da özelleştirebilirsiniz.

Belge istekleri oluşturma, değiştirme veya upsert'te 429 yanıt
  • Varsayılan olarak, NoSQL API'sinde tüm özellikler varsayılan olarak dizine eklenir. Dizin oluşturma ilkesini yalnızca gereken özellikleri dizine almak için ayarlayın. Bu, belge oluşturma işlemi başına gereken İstek Birimlerini azaltır ve bu da 429 yanıt görme olasılığını azaltır veya sağlanan RU/sn miktarı için saniyede daha yüksek işlemler gerçekleştirmenize olanak tanır.
Sorgu belgesi isteklerinde 429 yanıt
Saklı yordamları yürütürken 429 yanıt
  • Saklı yordamlar , bir bölüm anahtarı değeri boyunca yazma işlemleri gerektiren işlemlere yöneliktir. Çok sayıda okuma veya sorgu işlemi için saklı yordamların kullanılması önerilmez. En iyi performans için bu okuma veya sorgu işlemleri, Azure Cosmos DB SDK'ları kullanılarak istemci tarafında yapılmalıdır.

İstek oranı otomatik ölçeklendirme ile büyük

Bu makaledeki tüm yönergeler hem el ile hem de otomatik ölçeklendirme aktarım hızı için geçerlidir.

Otomatik ölçeklendirme kullanılırken sık sorulan bir soru şudur: "Otomatik ölçeklendirme ile 429 yanıt görmek hala mümkün mü?"

Evet. Bunun gerçekleşebileceği iki ana senaryo vardır.

Senaryo 1: Genel olarak tüketilen RU/sn veritabanı veya kapsayıcının maksimum RU/sn değerini aştığında, hizmet istekleri buna göre kısıtlar. Bu, bir veritabanı veya kapsayıcının genel el ile sağlanan aktarım hızını aşmaya benzer.

Senaryo 2: Sık erişimli bir bölüm varsa, yani diğer bölüm anahtarı değerlerine kıyasla orantısız olarak daha yüksek istek miktarına sahip mantıksal bölüm anahtarı değeri varsa, temel alınan fiziksel bölümün RU/sn bütçesini aşması mümkündür. Sık erişimli bölümlerle karşılaşmamak için kullanabileceğiniz en iyi yöntemlerden biri, depolama ve işlem hızı konusunda eşit dağıtım sağlayan iyi bir bölüm anahtarı seçmektir. Bu, el ile aktarım hızı kullanılırken sık erişimli bölüm olmasına benzer.

Örneğin, 20.000 RU/sn maksimum aktarım hızı seçeneğini belirtirseniz ve dört fiziksel bölüme sahip 200 GB depolama alanına sahipseniz, her fiziksel bölüm 5000 RU/sn'ye kadar otomatik olarak ölçeklendirilebilir. Belirli bir mantıksal bölüm anahtarında sık erişimli bölüm varsa, içinde bulunduğu temel alınan fiziksel bölüm 5000 RU/sn'yi aştığında, yani %100 normalleştirilmiş kullanımı aştığında 429 yanıt görürsünüz.

Bu senaryolarda hata ayıklamak için 1. Adım, Adım 2 ve 3. Adım'daki yönergeleri izleyin.

Ortaya çıkan bir diğer yaygın soru, Neden normalleştirilmiş RU tüketimi %100'dür, ancak otomatik ölçeklendirme en yüksek RU/sn'ye ölçeklendirilmediyse?

Bu durum genellikle geçici veya aralıklı kullanım artışları olan iş yükleri için oluşur. Otomatik ölçeklendirmeyi kullandığınızda Azure Cosmos DB, 5 saniyelik bir aralıkta sürekli ve sürekli bir süre için normalleştirilmiş RU tüketimi %100 olduğunda RU/sn'yi yalnızca maksimum aktarım hızına ölçeklendirir. Bu, ölçeklendirme mantığının kullanıcıya uygun maliyetli olmasını sağlamak için yapılır, bu sayede tek, anlık ani artışlar gereksiz ölçeklendirmeye ve daha yüksek maliyete yol açmaz. Anlık ani artışlar olduğunda, sistem genellikle daha önce RU/sn olarak ölçeklendirilenden daha yüksek ancak maksimum RU/sn'den daha düşük bir değere kadar ölçeklendirilir. Otomatik ölçeklendirme ile normalleştirilmiş RU tüketimi ölçümünü yorumlama hakkında daha fazla bilgi edinin.

Meta veri isteklerinde hız sınırlama

Meta veri hızı sınırlaması, veritabanlarında ve/veya kapsayıcılarda yüksek hacimli meta veri işlemleri gerçekleştirdiğinizde oluşabilir. Meta veri işlemleri şunları içerir:

  • Kapsayıcı veya veritabanı oluşturma, okuma, güncelleştirme veya silme
  • Azure Cosmos DB hesabındaki veritabanlarını veya kapsayıcıları listeleme
  • Geçerli sağlanan aktarım hızını görmek için teklifleri sorgulama

Bu işlemler için sistem tarafından ayrılmış bir RU sınırı vardır, bu nedenle veritabanı veya kapsayıcının sağlanan RU/sn'lerini artırmanın hiçbir etkisi olmaz ve önerilmez. Bkz. Denetim Düzlemi Hizmet Sınırları.

Araştırma adımları

Durum Koduna Göre İçgörüler>Sistem>Meta Veri İstekleri'ne gidin. İsterseniz belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

İçgörüler'de durum kodu grafiğine göre meta veri istekleri.

  • Uygulamanızın meta veri işlemleri gerçekleştirmesi gerekiyorsa, bu istekleri daha düşük bir hızda göndermek için bir geri alma ilkesi uygulamayı göz önünde bulundurun.

  • Statik Azure Cosmos DB istemci örneklerini kullanın. DocumentClient veya CosmosClient başlatıldığında, Azure Cosmos DB SDK'sı tutarlılık düzeyi, veritabanları, kapsayıcılar, bölümler ve teklifler hakkında bilgiler de dahil olmak üzere hesap hakkındaki meta verileri getirir. Bu başlatma işlemi çok sayıda RU kullanabileceğinden seyrek gerçekleştirilmelidir. Tek bir DocumentClient örneğini, uygulamanızın yaşam ömrü boyunca kullanın.

  • Veritabanlarının ve kapsayıcıların adlarını önbelleğe alın. Yapılandırmadan veritabanlarınızın ve kapsayıcılarınızın adlarını alın veya başlangıçta önbelleğe alın. ReadDatabaseAsync/ReadDocumentCollectionAsync veya CreateDatabaseQuery/CreateDocumentCollectionQuery gibi çağrılar, sisteme ayrılmış RU sınırından kullanan hizmete meta veri çağrılarına neden olur. Bu işlemler seyrek gerçekleştirilmelidir.

Geçici hizmet hatası nedeniyle hız sınırlaması

İstek geçici bir hizmet hatasıyla karşılaştığında bu 429 hatası döndürülür. Veritabanı veya kapsayıcı üzerinde RU/sn'nin artırılmasının hiçbir etkisi olmaz ve önerilmez.

İsteği yeniden deneyin. Hata birkaç dakika boyunca devam ederse Azure portal bir destek bileti oluşturun.

Sonraki adımlar