Microsoft Fabric'da kısıtlama

Microsoft Fabric, iş yükleri kapasiteyi aştığında veya REST API istekleri sınırları aştığında hizmet performansını ve güvenilirliğini korumak için kısıtlama uygular. Bu makalede, hız sınırlamanın nasıl çalıştığı, HTTP 429 yanıtlarının nasıl yorumlanacağı ve Fabric API kotalarını etkili bir şekilde yöneten uygulamaların nasıl tasarlanacağı açıklanmaktadır.

API kota limitleri

Microsoft Fabric, REST API’leri için Birleşik Kota özelliğini sunuyor. Bu model kapsamında API istekleri, Kullanıcı veya Hizmet Sorumlusu başına uygulanan kimlik düzeyi kotalarına tabidir.

Amaç, otomasyon, CI/CD ve aracı odaklı senaryolar genelinde yönetilen API grupları için tutarlı ve öngörülebilir bir hız sınırlama deneyimi sunmaktır.

Daha önce her Microsoft Fabric REST API kendi bağımsız azaltma kurallarını zorunlu tutardı ve bu da genellikle uç noktalar arasında tutarsız davranışlara neden oldu. Sonuç olarak, özellikle birden çok API ile etkileşim kuran ve farklı sınırlara tabi olan otomasyon senaryoları için bir iş yükünün ne zaman kısıtlandığını tahmin etmek zor oldu.

API Kotası'nın kullanıma sunulmasıyla Fabric daha tutarlı, kimlik tabanlı bir yaklaşıma geçiyor. API tüketimi artık kimlik başına uygulanan birleşik bir kotaya tabidir ve Fabric API'ler arasında daha net ve tahmin edilebilir bir azaltma modeli sağlar. Ancak, bazı münferit API’ye özgü hız sınırlama limitlerinin, genel API kotasına ek olarak yine de geçerli olabileceğini unutmamak önemlidir.

Note

API Kotası yalnızca API isteklerini yönetmek ve kısıtlamak için vardır. Fabric işlem, depolama veya faturalama kapasitesini temsil etmez ve Fabric kapasite tüketiminizi veya maliyetinizi etkilemez.

Bir API referans sayfası bir kota belirtiyorsa, o uç noktaya özgü sınırı söz konusu API için esas alın. API referans sayfasında sayısal bir kota belirtilmiyorsa, Retry-After dikkate alarak, sınırlı yeniden denemeler uygulayarak ve ani istek patlamalarından kaçınarak uygulamanızı 429 yanıtlarını işleyecek şekilde tasarlayın.

Kota Modeli Nasıl Çalışır?

Kotaların nasıl aktığını gösteren hesaplama diyagramı.

Her kimliğe (bir kullanıcı veya hizmet sorumlusu) farklı API trafiği kategorilerini yöneten birden çok bağımsız kota demetleri atanır. Kimlik bir istek gönderdiğinde, istek kullanılan API kategorisi kotasına göre değerlendirilir.

Üç Birleşik Kota vardır:

  1. Platform API'leri için Birleşik Kota — Platform API'lerine özeldir.
  2. İş Zamanlayıcısı API'leri için birleşik kota — İş Zamanlayıcısı API'lerine ayrılmıştır.
  3. Uzun Süreli İşlemler API'leri için Birleşik Kota — Uzun Süreli İşlemler API'lerine ayrılmıştır.
Quota Sınır
Platform API'leri için Birleşik Kota 200 arama/dk
İş Zamanlayıcı API'leri için Birleşik Kota 200 arama/dk
Uzun Süreli İşlem API'leri için birleşik kota 200 arama/dk

Bu kotalar bağımsız olduğundan, bir kategorideki etkinlik başka bir kategorideki kotayı kullanmaz. Örneğin, hizmet sorumlusu, Kullanılabilir Platform API'leri için Birleşik Kotayı etkilemeden İş Zamanlayıcı API'leri için tam Birleşik Kotayı kullanabilir. Bu ayrım, özel API alanlarındaki yüksek hacimli iş yüklerinin genel API işlemlerini etkilememesini sağlar ve farklı istek türleri arasında daha öngörülebilir azaltma davranışı sağlar.

API zorunlu kılma

API Kotası kimlik başına uygulanır, yani her kullanıcı, hizmet sorumlusu veya yönetilen kimlik kendi bağımsız kota ayırmasını alır. Kotalar hiçbir zaman kimlikler arasında paylaşılır ve tüm uygun Fabric API'leri bu kimlikle ilişkili ortak bir kota demetinden tüketir.

Sonuç olarak, bir kimliğin API kullanımı diğer kimlikleri etkilemez. Örneğin, yoğun kullanılan bir hizmet sorumlusu, diğer kullanıcıların veya uygulamaların kotalarını etkilemeden kendi API Kotasını tüketebilir.

Benzer şekilde, bir kimlik kota sınırına ulaşıp kısıtlanırsa, bu kısıtlama yalnızca o kimlik için geçerlidir; diğer kimlikler ise normal şekilde çalışmaya devam eder. Bu yalıtım, iş yükleri arasında daha öngörülebilir ve yönetilebilir API tüketimi sağlar.

Kota uygulama hiyerarşisi

Kota hiyerarşisinin kavramsal diyagramı.

Her API isteği bir kimlikle (kullanıcı hesabı veya hizmet sorumlusu) başlar. Bu kimlik bir Fabric API’sini çağırdığında, istek ilk olarak API başına değil, kimlik başına uygulanan paylaşılan API kotasından kapasite tüketir. Bu kota, tüm katılan API'ler arasında paylaşılan merkezi bir azaltma mekanizması işlevi görür ve tek bir kimliğin ayrılmış istek oranını aşamamasını sağlar.

İstek, paylaşılan API kotasına göre değerlendirildikten sonra, API’ye özgü hız sınırlama limitleri de uygulanır. Bu sınırlar paylaşılan kotadan bağımsızdır ve yalnızca belirli API'ler için mevcut olabilir. Sonuç olarak, bir isteğin başarılı bir şekilde işlenebilmesi için hem kimlik düzeyi API Kotasını hem de geçerli tek tek API sınırlarını karşılaması gerekir.

Pratik olarak, paylaşılan API Kotası API'ler arasında tutarlı bir azaltma deneyimi sağlarken, tek tek API sınırları ek koruma gerektiren belirli hizmetleri korumaya devam eder. Bu nedenle bir API çağrısı, kimlik paylaşılan kotasını tüketmiş veya belirli bir API uç noktası sınırına ulaşmış olduğundan kısıtlanabilir.

Temel kavramlar:

  • Kimlik tabanlı zorlama: Kota, her kullanıcı veya hizmet sorumlusu için ayrı olarak izlenir.
  • API'ler arasında paylaşılan: Farklı API'lere yapılan istekler, aynı API kota havuzunu tüketir.
  • Yalnızca azaltma: API Kotası istek oranlarını denetler, ancak yetkilendirmeyi veya izinleri etkilemez.
  • Çift uygulama: Her istek için hem paylaşılan API kotası hem de API'ye özgü limitler değerlendirilir.
  • En kısıtlayıcı sınır kazanır: Paylaşılan kota veya ilgili API'ye özgü sınır aşıldığında istek kısıtlanır.

Kota Nasıl Tüketilir?

Her API isteği, çağıran kimliğin API Kota demetinden kota kullanır. Bu kimlik tarafından yapılan tüm istekler, hangi API'nin çağrıldığı fark etmeksizin aynı paylaşılan kotaya doğru sayılır.

Kota Penceresi ve Yenileme

API kotası, sabit 60 saniyelik bir pencereyle uygulanır. Geçerli pencere sona erdiğinde kota demetinin tümü aynı anda yenilenir. Kota, bu süre boyunca kademeli olarak yenilenmez.

Note

Bir kimlik, pencerenin başında kotanın tamamını tüketirse, sonraki 60 saniyelik pencere başlayana kadar ek istekte bulunamaz.

Zaman Çizelgesi Örneği

Second 0   → Quota window begins. Bucket is full (300 requests available).
Second 1   → 300 requests are made. Bucket is exhausted.
             Additional requests receive HTTP 429 (Too Many Requests).

Seconds 2-59 → All additional requests continue to receive HTTP 429.
               No quota is restored during the window.

Second 60  → New quota window begins.
             Bucket is fully replenished (300 requests available).
             Requests are accepted again.

Pratik Etkileri

  • Pencerenin başında ani isteklere izin verilir, ancak bunu yapmak, söz konusu pencerenin geri kalanı için kimliği kısıtlanmış olarak bırakabilir.
  • İstekleri 60 saniyelik süre boyunca eşit şekilde dağıtmak, kısıtlanmayı önlemeye yardımcı olur.
  • Her zaman Retry-After yanıt başlığını dikkate alın. Kısıtlanmış bir isteği yeniden denemeden önce ne kadar bekleyeceğinizi gösterir.

API'ye göre hız sınırı ayrıntıları

Microsoft Fabric birleşik azaltma kategorileri ve paylaşılan kota kavramları sağlasa da, gerçek hız sınırları API'ye göre farklılık gösterebilir. Çağırdığınız API’ye özgü hız sınırlama limitleri bölümünü her zaman kontrol edin.

Note

Çağırdığınız API’ye özgü hız sınırlama limitleri bölümünü her zaman kontrol edin.

Hız sınırlama mesajı

Hız sınırlaması uygulandığında, Fabric 429 (Çok Fazla İstek) HTTP durum kodunu döndürür. Fabric, her biri yanıt gövdesinde farklı bir errorCode ile tanımlanan iki ayrı nedenle 429 durum kodu döndürür:

Hangi durumun gerçekleştiğini ve nasıl yanıt verileceğini belirlemek için yanıttaki errorCode değeri inceleyin.

Hız sınırı aşıldı (RequestBlocked)

Kullanıcı bir zaman penceresi sırasında önceden belirlenmiş sınırı aşan birçok istek gönderdiğinde Fabric kısa bir süre için bu kullanıcıdan gelen diğer istekleri kısıtlar.

Bu durumda, Fabric yanıtta HTTP üst bilgisi olan Retry-After bir HTTP durum kodu 429 (Çok fazla istek) döndürür ve çağrıyı yeniden denemeden önce çağıran uygulamanın kaç saniye beklemesi gerektiğini belirtir. Yanıt gövdesi şu RequestBlocked hata kodunu kullanır:

{
    "errorCode": "RequestBlocked",
    "message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}

Bu hatayı aldığınızda, isteği yeniden denemeden önce üst bilgide Retry-After belirtilen süreyi bekleyin.

Aşağıdaki ekran görüntüsünde, kullanıcının aramayı yeniden denemeden önce 55 saniye beklemesini öneren bir yanıt örneği gösterilmektedir.

HTTP yanıt üst bilgisini gösteren ekran görüntüsü.

Kapasite sınırı aşıldı (CapacityLimitExceeded)

Fabric ayrıca kuruluşunuzun Fabric kapasitesi sınırlarını aştığında 429 (Çok fazla istek) HTTP durum kodu döndürür. Oran sınırlamasının aksine, bu kısıtlama belirli bir istemcinin yaptığı API çağrılarının sayısından kaynaklanmaz. Bunun yerine, kapasitenizde tüketilen işlem gücü (kapasite birimleri), satın alınan Fabric SKU’sunun sınırlarını aştığında ortaya çıkar. Yanıt gövdesi şu CapacityLimitExceeded hata kodunu kullanır:

{
    "errorCode": "CapacityLimitExceeded",
    "message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}

Bu hatayı aldığınızda isteği daha sonra yeniden deneyin. Bu kısıtlama, size özgü istek oranından ziyade kapasitenizde tüketilen toplam hesaplama kaynaklarına bağlı olduğundan, kapasitenin hesaplama kullanımı yeniden sınırları içine düşene kadar hemen yeniden denemenin başarılı olma olasılığı düşüktür. Bu hatayla sık sık karşılaşırsanız, Fabric kapasitenizin ölçeğini artırmayı veya genişletmeyi göz önünde bulundurun. Kapasite birimleri, SKU'lar ve Fabric kapasitenin nasıl tüketileceği hakkında daha fazla bilgi için bkz. Kapasite boyutunuzu planlama.

Dikkat edilmesi gerekenler ve sınırlamalar

Tüm Fabric yönetici ve çekirdek ortak API'leri hız sınırlamasına tabi tutulabilir.

Fabric REST API'lerini çağıran uygulamalar tasarlarken şu noktaları göz önünde bulundurun:

  • Çağıran kimliği ve çağrılan API için kotalar uygulanır. Ayrı kimliklerin aynı istek sayacını paylaşması gerekmez, ancak her çağıranın API için belgelenen sınırları izlemesi gerekir.
  • Birçok hız sınırı bir dakikalık pencereler üzerinden değerlendirilir. Sınırı aşarsanız, daha fazla istek göndermeden önce Retry-After değerini bekleyin.
  • Kapasite kısıtlaması, istek hızı kısıtlamasından farklıdır. CapacityLimitExceeded, isteği yapanın dakika başına API kotasını aştığını değil, Fabric kapasitesinin aşırı yüklü olduğunu belirtir.
  • Kapasite kısıtlama hatasını hemen yeniden denemek büyük olasılıkla başarılı olmaz. Sınırlanmış yeniden deneme ilkesi kullanın ve hata devam ederse kapasite kullanımını araştırın.
  • Yüksek hacimli entegrasyonlar için, mevcut olduğunda liste, toplu veya yığın işlemlerini tercih edin, sık değişmeyen meta verileri önbelleğe alın ve istekleri zamana eşit biçimde yayın.
  • Sayfalandırmayı destekleyen API'ler için baştan yinelenen geniş sorgular yapmak yerine devamlılık belirteçlerini kullanın.

Sık sorulan sorular

API kotası mı yoksa kapasite sınırına mı ulaştığımı nasıl bilebilirim?

429 yanıt gövdesindeki errorCode öğesini kontrol edin. RequestBlocked, istek oranının hizmetin kısıtlama sınırlarını aştığı anlamına gelir. CapacityLimitExceeded, Fabric kapasitesinde kullanılan işlem kaynaklarının satın alınan SKU limitlerini aştığı anlamına gelir.

Kotam ne zaman sıfırlanır?

Birçok Fabric REST API hız sınırı bir dakikalık pencereler üzerinden değerlendirilir. Yanıt bir Retry-After üstbilgi içeriyorsa, yeniden denemeden önce bu değeri kesin bekleme süresi olarak kullanın.

İstekte bulunmadan önce kalan API kotamı denetleyebiliyorum?

Fabric REST API yanıtları tüm API'ler için genel bir kalan kota sayacı sağlamaz. İstemcileri, 429 yanıtlarını algılayabilecek, Retry-After değerine uyacak ve hız sınırlaması uygulandığında istek hacmini azaltacak şekilde oluşturun.

Hızımın düşürülme olasılığını nasıl azaltabilirim?

Mümkün olduğunda toplu ve parti işlemlerini kullanın, çok sayıda tekil kaynak çağrısı yerine liste API’lerini tercih edin, sık erişilen meta verileri önbelleğe alın ve ani trafik artışlarından kaçının. Kalıcı kapasite azaltma için Microsoft Fabric Kapasite Ölçümleri uygulamasını kullanarak aşırı yüklenmiş kapasiteleri ve iş yüklerini belirleyin.

Her 429 yanıtını aynı şekilde yeniden denemeli miyim?

No. RequestBlocked için, Retry-After üst bilgisini bekleyin ve ardından sınırlı bir yeniden deneme ilkesiyle yeniden deneyin. CapacityLimitExceeded için, daha sonra üssel gecikmeyle yeniden deneyin ve sorun devam ederse kapasite kullanımını inceleyin.

İlgili içerik

  • Last updated on