Azure Blob Depolama'daki Yoğun Bölümler: algılama, izleme ve azaltma

Azure Blob Depolama, ölçeklenebilir performans sağlamak için verileri bölümler arasında dağıtır. Trafik tek bir bölüme yoğunlaştığında, o bölüm bir dar boğaz haline gelebilir; bu duruma sıcak bölüm denir. Bu makale, sıcak bölümlerin ne olduğunu, Azure İzleyici metrikleri ve kaynak kayıtları aracılığıyla nasıl tanınacağını ve yükü daha eşit dağıtmak ve throttling hatalarını azaltmak için hangi adımları atabileceğinizi açıklıyor.

Sıcak bölümleri anlama

Azure Blob Depolama, performansı ve verimliliği ölçeklendirmek için verileri otomatik olarak bölümler arasında dağıtır. Tek bir bölüm diğer bölümlerden çok daha fazla trafik aldığında, sıcak bir bölüm haline gelir. Sıcak bölüm, çok sayıda okuma, yazma veya güncelleme isteği aynı bölüme gittiğinde oluşur ve bu da hizmetin iş yükünü etkili bir şekilde dengeleme yeteneğini sınırlar. Sonuç olarak, istekler iş yükü yeniden dağıtılana veya erişim deseni optimize edilene kadar artan gecikme, kısıtlama ve zaman aşımı hataları yaşar. Trafiği birden fazla bölüm arasında yaymak yerine küçük bir veri alt kümesine yoğunlaştıran bölümleme veya adlandırma şemaları genellikle sıcak bölümlere neden olur.

Sıcak bölmelerin belirtileri ve etkisi

Bir depolama bölümü aşırı yoğunlaştığında, artık istekleri eskisi kadar verimli işleyemez. Bölüm ölçeklenebilirlik sınırlarına yaklaştıkça, Azure Depolama hizmeti korumak ve diğer iş yükleri için güvenilirliği korumak amacıyla talepleri yavaşlatmaya başlar. İstemci uygulamaları artan gecikme, azalmış veri verimliliği ve geçici istek hataları yaşar.

Sıcak bir bölünmenin yaygın belirtileri şunlardır:

  • HTTP 503 (Sunucu Yoğunluğu) yanıtları, bölümün geçici olarak daha fazla isteği kabul edemediğini gösterir.
  • HTTP 500 (İşlem Zaman Aşımı) yanıtları, bölüm yoğun yük altındayken isteklerin tamamlanmasının çok uzun sürmesi durumunda oluşur.
  • Artan istek gecikmesi, sonuçta başarılı olan istekler için bile.
  • İstemcilerin otomatik yeniden denemeleri, çok sayıda istemci aynı anda yeniden deneme yaparsa trafiği daha da artırabilir ve performans sorunlarının daha uzun sürmesine neden olabilir.
  • Düşük veri verimliliği, yani uygulamanın yeterli genel depolama hesabı kapasitesine rağmen saniyede beklenenden daha az işlem işlemesi.

Sıcak bölümler genellikle trafiği tek bir bölüme yoğunlaştıran erişim kalıplarından kaynaklanır. Yaygın örnekler arasında ardışık blob isimleri, sadece ekleme için kullanılan iş yükleri ve tek bir bölüme orantısız miktarda trafik gönderen bölüm anahtarı tasarımları bulunur. İş yükü eşit şekilde dağıtılmadığında, etkilenen bölüm depolama hesabının geri kalanından önce sınırlarına ulaşır ve bu da uygulama performansını etkileyen bir darboğaz oluşturur.

Birçok uygulamada, sıcak bölümlemenin ilk göstergesi, artan gecikme, artan tekrar deneme oranları ve yüksek talep dönemlerinde artan 503 veya 500 hata sayısının birleşimidir.

Azure İzleyici metrikleri ve kaynak logları kullanarak throttling hatalarını tespit edin

Azure Depolama, bir iş yükü depolama hesabının veya bölümün ölçeklenebilirlik hedeflerini aştığında isteği kısıtlar. Genellikle kısıtlamayı HTTP 503 (Sunucu Meşgul) veya 500 (İşlem Zaman Aşımı) yanıtları olarak görürsünüz. Azure Depolama istemci kitaplıkları, kısıtlamaya uğrayan istekleri genellikle otomatik olarak yeniden dener; bu nedenle izleme, kısıtlamayı uygulama performansını önemli ölçüde etkilemeden önce saptamak için kritik öneme sahiptir.

Kısıtlama hatalarını belirlemek için Azure İzleyici ölçümlerini kullanın

Kısıtlamayı tespit etmek için bir depolama hesabının Azure İzleyici metriklerini analiz edin. İşlemler metriği, ResponseType boyutu ile birleştiğinde, depolama taleplerinin sonucuna görünürlük sağlar ve throttling ile ilgili hataları tespit etmenize yardımcı olur.

Hız sınırlamayı belirlemeye yönelik metrikler

Aşağıdaki Azure İzleyici metrikleri throttling araştırmalarında faydalıdır:

Metric Purpose
İşlemler Depolama servisi tarafından işlenen istek sayısını ölçür. Kısıtlanmış istekleri belirlemek için ResponseType boyutunu kullanın.
Kullanılabilirlik Başarılı taleplerin yüzdesini gösterir. Kullanılabilirlikteki bir azalma, kısıtlama veya diğer istek başarısızlıklarını gösterebilir.
Başarı E2E Gecikme Süresi Ağ ve istemci tarafı işleme dahil olmak üzere uçtan uca istek gecikmesini ölçür. Artışlar, hız sınırlaması nedeniyle yapılan yeniden deneme girişimlerini gösterebilir.
Başarı Sunucu Gecikme Süresi Depolama hizmetinin talepleri işlemesi için gereken süreyi ölçür. Bu metriği E2E gecikmesi ile karşılaştırmak, hizmet tarafı gecikmelerini istemci denemelerinden ayırt etmeye yardımcı olabilir.

Yaygın bir kısıtlama örüntüsü, gecikmedeki artışa kısıtlamayla ilgili yanıt türlerindeki artışın ve kullanılabilirlikteki azalmanın eşlik etmesidir.

Throttling'i tanımlamak için ResponseType boyutunu kullanın

ResponseType boyutu, Azure İzleyici ölçümlerinde hız sınırlama durumlarını belirlemek için temel araçtır. İlgili değerler şunlardır:

ResponseType değeri Description
ServerBusyError Depolama servisi, ölçeklenebilirlik hedefinin aşılması nedeniyle HTTP 503 döndürdü.
ClientThrottlingError İstek, depolama servisine ulaşmadan önce kısıtlandı.
ClientAccountRequestThrottlingError Hesap düzeyinde talep oranı sınırları aşıldı.
ClientAccountBandwidthThrottlingError Hesap bant genişliği sınırları aşıldı.
KısıtlamaylaBaşarı Talep başlangıçta kısıtlandı ancak denemelerden sonra başarıya ulaştı.

Bu değerleri zaman içinde takip etmek, geçici throttling artışlarını ve sürdürülebilir ölçeklenebilirlik sorunlarını tespit etmenize yardımcı olabilir.

Throttling'in kaynağını belirlemek için boyutları kullanın

Azure İzleyici metrik boyutları, kısıtlamaya neden olan iş yükünü belirlemeye yardımcı olabilir:

Dimension Purpose
ResponseType Belirli bir throttling veya hata durumunu belirler.
ApiName Throttling uygulanan işlemi tanımlar; örneğin PutBlob, GetBlob veya ListBlobs.
GeoType Coğrafi yedekli depolama hesaplarında birincil ve ikincil uç noktalara giden trafiği ayırt eder.
Kimlik Doğrulaması Hız sınırlamanın belirli bir kimlik doğrulama yöntemiyle ilişkili olup olmadığını belirlemeye yardımcı olur.

Örneğin, kısıtlama esas olarak PutBlob işlemlerinde meydana geliyorsa, iş yükü yazma ağırlıklı olabilir. Belirli bir API operasyonu yüksek throttling oranları gösteriyorsa, optimizasyon çabaları tüm uygulamaya değil, o operasyona odaklanabilir.

Azure İzleyici kaynak günlüklerini analiz edin

Metrikler throttling’in varlığını belirlese de Azure İzleyici kaynak günlükleri, kök nedeni belirlemeye yardımcı olabilecek istek düzeyinde ayrıntılar sağlar. Kaynak kayıtları, hem başarılı hem de başarısız istekleri yakalar; bunlara kısıtlama, zaman aşımı, yetkilendirme ve ağla ilgili hatalar dahildir.

Azure Blob Depolama için, kayıtlar kaynak logları Log Analytics workspace'e gönderildikten sonra StorageBlobLogs tablosunda mevcuttur.

Kısıtlama olayları için kaynak günlüklerini sorgulayın

Bu sorguları çalıştırmadan önce, kaynak günlüklerinin bir Log Analytics çalışma alanına gönderildiğinden emin olun.

Yaygın hız sınırlaması durum kodlarını döndüren istekleri belirlemek için Kusto Sorgu Dili’ni (KQL) kullanın:

StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

Hızı sınırlandırılan istekleri oluşturan iş yükünü belirlemek için bu sorguyu sonuçları işlem, kimlik doğrulama türü, çağıran IP adresi veya uygulama kimliğine göre gruplandıracak şekilde genişletin. Kaynak günlükleri, özellikle kısıtlamanın belirli bir uygulama, işlem veya zaman dilimi içinde yoğunlaşıp yoğunlaşmadığını belirlemek için yararlıdır.

Throttling için uyarı koşulları

Aşağıdakiler için Azure İzleyici uyarıları oluşturun:

  • ServerBusyError işlemlerinin sürekli ortaya çıkması.
  • Throttling ile ilgili ResponseType değerlerindeki artışlar.
  • Kullanılabilirlik metriğinin kabul edilebilir eşiğin altına düşmesi.
  • Kısıtlama olaylarıyla ilişkili gecikme artışları.
  • Depolama ölçeklenebilirlik sınırlarına yaklaşan ani istek hacmi artışları.
  1. İşlemler metriğini izleyin ve sonuçları ResponseType'a göre bölürün.
  2. ServerBusyError ve ClientThrottlingError gibi kısıtlama ile ilgili yanıt türlerindeki artışları arayın.
  3. Etkilenen işlemleri belirlemek için ApiName boyutunu kullanın.
  4. Throttling olaylarını Erişilebilirlik, Başarı E2E Gecikmesi ve Başarı Sunucusu Gecikmesi değişiklikleriyle ilişkilendirin.
  5. Hangi isteklerin, işlemlerin veya uygulamaların kısılmış trafik oluşturduğunu belirlemek için Azure İzleyici kaynak günlüklerini kullanın.
  6. Kullanıcıları etkilemeden önce kısıtlama sorunlarının tespit edilmesini sağlamak için uyarıları yapılandırın.

Azure İzleyici metriklerini, boyutlarını ve kaynak kayıtlarını birleştirerek, throttling koşullarını hızla tespit edebilir, aşırı talebin kaynağını tespit edebilir ve uygulama performansı düşmeden önce düzeltici önlemler alabilirsiniz.

Sıcak bölümlemelerin etkisini azaltın

Sıcak bölümleri önlemek için, istekleri bölümler arasında eşit şekilde dağıtın ve kısıtlama uygulandığında uygulamaların uygun şekilde yanıt vermesini sağlayın.

Verimli bölümleme ve adlandırma şemaları kullanın

Bölüm anahtarlarını, blob isimlerini ve diğer tanımlayıcıları isteklerin birden fazla bölüm arasında dağıtılması için tasarlayın. Çoğu isteği aynı bölüme yönlendiren ardışık veya sadece ekleyici adlandırma kalıplarından kaçının. Bkz. Blob bölümlerini ve adlandırma şemalarını optimize et.

Tekrar denemeler için üstel geri dönüş kullanın

İstekler sınırlandırılırsa ve 503 (Sunucu Meşgul) veya 500 (İşlem Zaman Aşımı) hataları alınırsa, istekleri üstel geri çekilme stratejisi kullanarak yeniden deneyin. Bu yaklaşım, etkilenen bölüm üzerindeki baskıyı azaltır ve Azure Depolama'a yükü yeniden dengelemek veya geçici talep artışlarından kurtulmak için zaman tanır.

Üstel geri çekilme yeniden deneme davranışı, Azure Depolama istemci kitaplıkları, SDK’lar veya REST API’lerini kullanarak Azure Depolama’a erişen özel uygulamalar için en çok geçerlidir. Birçok Microsoft hizmetleri, yönetilen uygulama ve üçüncü taraf istemcisi zaten uygun yeniden deneme mantığı uygular, bu yüzden ekstra bir şey yapılandırmanıza gerek olmayabilir. Özel bir uygulama geliştiriyorsanız, yeniden deneme politikalarının Azure Depolama'ın en iyi uygulamalarına göre etkinleştirildiğinden ve yapılandırıldığından emin olun. Şu makalelerden birine bakın:

İstek sesindeki ani artışlardan kaçının

Yeni bir iş yükü tanıtılırken, performans testleri yapılırken veya büyük miktarda veri işlenirken talep oranlarını hemen zirve trafik yaratmak yerine kademeli olarak artırın. Azure Depolama, talep değiştikçe bölümler arasındaki yükü otomatik olarak dengeler; ancak ani trafik artışları geçici olarak bir bölümü aşırı yükleyebilir ve hizmet uyum sağlama fırsatı bulana kadar isteklerin kısıtlanmasına neden olabilir.

Sonraki Adımlar

Detaylı uygulama rehberliği için bkz:

  • Last updated on