Daraltma deseni

Bir uygulama örneğinin, tek bir kiracının veya hizmetin tamamının kullanabileceği kaynakları sınırlayın. Bu, sistemin ani veya sürekli yük altında hizmet düzeyi hedeflerini (SLO) karşılamasını sağlar.

Bağlam ve sorun

Bulut uygulamasındaki yük, etkin kullanıcılara ve etkinliklerine göre zaman içinde değişir. İş saatleri içinde daha fazla kullanıcı oturum açar ve sistem her ayın sonunda hesaplama açısından pahalı analizler çalıştırır. Ani patlamalar da meydana gelir. İşleme talebi kullanılabilir kapasiteyi aşarsa sistem yavaşlar veya başarısız olur. Sistem üzerinde anlaşmaya varılmış bir hizmet düzeyi olduğunda, bu hata SLO'nun ihlaline neden olur.

Çeşitli stratejiler, uygulamanın iş hedeflerine bağlı olarak değişen yükü işler. Stratejilerden biri, sağlanan kaynakları geçerli taleple eşleştiren ve maliyeti denetleyen otomatik ölçeklendirmedir. Ancak yeni kaynakların sağlanması zaman alır ve maliyet ekler. Kapasite büyümesini veya bütçeyi aşan talep, kaynak açığı oluşturur.

Çözüm

Otomatik ölçeklendirmeye bir alternatif, kaynak kullanımına bir üst sınır koymak ve kullanım bu sınırı aştığında istekleri kısıtlamaktır. İş yükü kendi kaynak kullanımını izler ve kullanım eşiği aştığında bir veya daha fazla kullanıcıdan gelen istekleri kısıtlar. Sistem çalışmaya ve SLO'larını karşılamaya devam eder.

Hız sınırlama, tek bir kabul kararı değil, bir denetim döngüsüdür. Sistemin üç katmanda düşük gecikme süreli sinyallere ihtiyacı vardır: altyapı kullanımı, uygulama durumu ve sorumlu başına sayaçlar. Doyma düzeyini sürekli ölçer, net olarak tanımlanmış eşiklerde limitleri uygular ve trafik örüntüleri değiştikçe bu limitleri uyarlar. Aşırı yük, olgunlaşmış bir sistemin algılayıp toparlanabildiği normal bir çalışma durumudur. Hız sınırlama, iş yükünüze kendini koruma yetenekleri kazandırır.

Sistem çeşitli azaltma veya ilgili stratejiler uygulayabilir:

• Kimlik başına hız sınırları: Belirli bir zaman aralığında yapılandırılan oran sınırını zaten aşmış olan bir kullanıcıdan gelen istekleri reddedin. Bu strateji, sistemin her isteği bir principal ile ilişkilendirmesini ve kaynak kullanımını bu principal bazında ölçmesini gerektirir. Çok kiracılı iş yükleri için bkz. Her kiracının tüketimini ölçme.

• Düzgün özellik düşüşü: Gerekli özelliklerin yeterli kaynağa sahip olması için gerekli olmayan özellikleri kapatın veya düşürün. Bu strateji, kullanılabilirlik için yanıt eksiksizliğini takas eder. Örneğin, video akışı uygulaması daha düşük bir çözünürlüğe düşebilir.

• Yük dengeleme:Kuyruk kullanarak sorunsuz etkinlik hacmi. Çok kiracılı bir ortamda seviyeleme, her kiracının performansını düşürür. Kiracıların farklı hizmet düzeyi sözleşmeleri (SLA'lar) olduğunda, yüksek değerli kiracılara ait işleri hemen işleyin ve düşük öncelikli işleri, iş yığılması azalıncaya kadar bekletin. Öncelik Sırası desenini kullanarak veya her öncelik katmanı için ayrı uç noktaları kullanıma sunarak bu yaklaşımı uygulayın.

• Öncelik tabanlı erteleme: Düşük öncelikli uygulamalar veya kiracılar adına işlemleri erteleme. İşlemleri askıya alın veya sınırlayın ve kiracıya daha sonra yeniden denemesini bildiren bir özel durum döndürün.

• Giden hız sınırları: Dış bağımlılık başarısız olduğunda veya hata döndürdüğünde kendi giden çağrılarınızı sınırlayın. Logların dolup taşmasını önlemek ve sağlıksız bir bağımlı hizmete yönelik yeniden deneme maliyetlerinden kaçınmak için eşzamanlı istek sayısını azaltın. Bağımlılık kurtarıldıktan sonra normal istek akışını geri yükleyin. Örneğin, NServiceBus bu işlevi uygular.

Aşağıdaki grafikte, A, B ve C etiketli üç özellik kullanan bir uygulama için zaman içinde kaynak kullanımı (bellek, CPU, bant genişliği ve diğer faktörlerin birleşimi) gösterilmektedir. Özellik, belirli bir görev kümesini gerçekleştiren bir bileşen, karmaşık hesaplama yapan bir kod parçası veya bellek içi önbellek gibi bir hizmet sağlayan bir öğe gibi belirli bir işlevsellik alanıdır.

Çizgi grafik, x eksenindeki zamana göre y ekseninde kaynak kullanımını çizer. Özellik A, Özellik B ve Özellik C'yi temsil eden üç renkli çizgi, Özellik A'nın en düşük çizgisi, B Özelliğinin çizgisi ortada ve Özellik C'nin en yüksek çizgisiyle gösterilir. Grafiğin üst kısmına yakın düz bir yatay çizgi maksimum kapasiteyi, altındaki kesikli yatay çizgi ise kaynak kullanımının geçici sınırını belirtir. İki dikey kesikli çizgi, T1 ve T2 zamanlarını işaretler. T1'in öncesinde, üç özellik çizgisi de dalgalı olur ve Özellik C'nin çizgisi yükselir ve yumuşak sınırı geçer. T1'de Özellik B'nin çizgisi sıfıra düşer ve T2'ye kadar sıfırda kalır çünkü Özellik B, Özellik A ve Özellik C için kaynakları boşaltmak üzere askıya alınır. Özellik C'nin çizgisi T1 ile T2 arasındaki geçici sınırın altına geri dönerken Özellik A normal şekilde devam eder. T2'de Özellik B devam eder ve üç satır da yumuşak sınırın altında dalgalanmaya devam eder.

Grafik yığılmış bir alan grafiğidir. Özellik A'nın satırının altındaki alan, Özellik A'nın tükettiği kaynakları, Özellik A'ları ile Özellik B'nin satırları arasındaki alan B Özelliğinin tükettiği kaynakları ve Özellik B'leri ile Özellik C'nin satırları arasındaki alan C Özelliğinin tükettiği kaynakları gösterir. C özelliğinin satırı yığının en üstünde yer aldığından, zaman içindeki toplam sistem kaynağı kullanımını da gösterir.

Grafik, özelliklerin kontrollü biçimde işlev kaybetmesini gösterir. T1 zamanından hemen önce, toplam kaynak kullanımı eşiğe yaklaşır ve kullanılabilir kapasiteyi tüketme riski taşır. B özelliği, Özellik A veya Özellik C'den daha az kritik olduğundan sistem B Özelliğini kapatır ve kaynaklarını serbest bırakır. T1 ile T2 arasında Özellik A ve Özellik C normal şekilde devam eder. T2 zamanına göre, toplam kaynak kullanımı B Özelliğini yeniden açmak için yeterli miktarda düşer.

Uygulamaların yanıt vermeye devam etmesini ve SLA'ler içinde kalmasını sağlamak için otomatik ölçeklendirme, zarif bozulma ve kısıtlamayı birleştirebilirsiniz. Talebin yüksek kalmasını beklediğinizde, kısıtlama sistem yatay olarak ölçeklenirken kararlılığı korur. Ölçeklendirme tamamlandıktan sonra sistem tam işlevselliği geri kazanır.

Sonraki grafik, zaman içindeki toplam kaynak kullanımını ve kısıtlamanın otomatik ölçeklendirme ile diğer dengeleyici denetimlerle nasıl birlikte çalıştığını göstermektedir.

Çizgi grafik, x eksenindeki zamana göre y eksenindeki tüm uygulamalar için kaynak kullanımını çizer. İki yatay başvuru çizgisi, otomatik ölçeklendirmeden önce kaynak kullanımının geçici sınırını ve maksimum kapasiteyi işaretler. T2 zamanında başlayan daha yüksek bir yatay çizgi, otomatik ölçeklendirmeden sonra maksimum kapasiteyi işaretler. Kullanım çizgisi zaman içinde artar ve dalgalar. Otomatik ölçeklendirmenin başladığı nokta olan T1 anında yumuşak sınırı aşar. T1 ve T2 arasında, otomatik ölçeklendirme gerçekleşirken sistem kısıtlanır ve kullanım ön ölçeklendirme maksimum kapasitesinin altında kalır. T2 anında otomatik ölçeklendirme tamamlanır, kısıtlama hafifletilir ve kullanım eğrisi yukarı sıçrayarak yeni, daha yüksek maksimum kapasitenin altında dalgalanmaya devam eder.

T1 zamanında sistem yumuşak sınıra ulaşır ve ölçeği genişletmeye başlar. Yeni kaynaklar zamanında gelmezse talep mevcut kaynakları tüketebilir ve sistem başarısız olabilir. İstek sınırlama, kaynak kullanımını kesin sınırın altında tutmak için ölçek genişletme sırasında fazla istekleri reddeder, ardından yeni kapasite devreye girdikten sonra bu kısıtlamaları kaldırır.

Tip

Uç denetimleri ve Throttling deseni farklı sorunları ele alır. Azure DDoS Koruması ve web uygulaması güvenlik duvarı (WAF) hız sınırı kuralları gibi kenar denetimleri ağ sınırında çalışır ve uygulamanıza ulaşmadan önce hacimli veya kötü amaçlı trafiği bırakır. Kısıtlama deseni uygulamanız içinde çalışır ve meşru trafiği uygulama tarafından tanımlanan sınırlara göre düzenler. Her iki katmanı da birlikte kullanın. DDoS koruması, meşru bir kullanıcının hizmetinizi aşırı yüklemesini engellemez ve uygulama düzeyinde hız sınırlaması, hacimsel bir saldırıyı karşılamaz.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

• Kısıtlama kararlarını erken alın. Hız sınırlama, tüm sistemi etkileyen mimari bir karardır. Bunu sonradan eklemek pahalıya mal olur.

• Kısma sınırlarını, ilk olarak doygunluğa ulaşan bileşenle hizalayın.

  İstek oranı sınırlayıcı en tanıdık boyut olsa da gerçek performans sorunu genellikle eşzamanlı uçuş içi istekler, kuyruk derinliği, CPU veya bellek kullanımı ya da aşağı akış bağımlılığının kendi sınırlarıdır. Saniye başına istek sınırı, performans sorunu bir çıkış noktasında eşzamanlılık olan bir sistemi korumaz.

  Ağ geçidi, hizmet, bir bölüm veya aşağı akış bağımlılığı gibi hız sınırlamanın uygulandığı her sınırda, önce neyin doygunluğa ulaştığını belirleyin ve sınırı o boyuta göre ayarlayın. Fan-out noktalarında eşzamanlılığı sınırlayan koruma için, istek kısıtlamayı tamamlayan Bulkhead desenine bakın.

• Kasıtlı olarak bir sınırlama algoritması seçin. Bunu korumakta olduğunuz bileşenin toleransı ile eşleştirin.

  Algorithm	Davranış ve en iyi uyum
  Belirteç kovası	Yapılandırılan bir boyuta kadar ani artışları destekler ve sabit bir yeniden doldurma hızı uygular. Kısa ani artışları emmesi gereken ağ geçitleri için kullanın.
  Sızdıran kova	Sabit bir hızda yayar. Sabit giriş oranı gerektiren arka uçlar için kullanın.
  Sabit pencere	Uygulanması kolaydır, ancak pencere sınırlarında ardı ardına patlamalara izin verir.
  Kayan pencere	Daha fazla durum bilgisi gerektirme pahasına, sabit pencerelerin pencere sınırı sorununu yumuşatır.

• Sınırın kimi etkileyeceğine karar verin. Bölgesel bir ağ geçidi gibi kapsamı geniş bir noktada uygulanan hız sınırlaması, yükün büyük kısmına yalnızca birkaç kullanıcı neden olsa bile, birbiriyle ilgisiz birçok kullanıcıyı etkileyebilir.

• Bir sınır birden çok düğüme yayıldığında sayacın nerede yer aldığına karar verin. Yerel sayaçlar hızlıdır, ancak aynı istemci birden çok replikaya ulaştığında eksik sayım yapar. Redis gibi paylaşılan bir depodaki merkezi sayaç her isteği görür ancak her karara gecikme ekler. Küresel bir oranı yaklaşık olarak elde etmek için sınırı replikalar arasında bölüştürün ve düzenli aralıklarla mutabakat sağlayın.

• Kısıtlama kararlarını hızla alın. Sistem artan yükü algılamalı, tepki vermeli ve yük kolaylaştırıldıktan sonra normale dönmelidir. Bu süreç sürekli performans enstrümantasyonu gerektirir.

• Yükü çöküşün eşiğinde değil, proaktif olarak azaltın. Bir bileşen doygunluğa ulaştıktan sonra ancak reddetmeye başlayan bir hız sınırlayıcı, çağıranlar herhangi bir geri basınç görmeden önce gecikmenin aniden yükselmesine neden olur.

  Kullanım sabit sınıra yaklaştıkça artan istek kesirini reddetmeye başlayın. Erken reddetme, çağıranlara geri dönmeleri için sinyal gönderir ve ani sınırların genellikle tetiklediği gecikme daraltmasını önler. Ana tetikleyici olarak, SLO’nuza göre p99 gecikmesini kullanın. P99 zaten ihlal edilmişken ortalama kullanım sağlıklı görünebilir.

  İsteklerin değerini ayırt edebildiğiniz durumlarda, önce daha düşük değerli veya yeniden denenmesi daha uygun olan işleri eleyin. Daha fazla bilgi için bkz . Öncelik Sırası düzeni.

• İstemciye geçici bir reddin hız sınırlamadan kaynaklandığını belirten bir durum kodu döndür:

  • HTTP 429 (Çok Fazla İstek: Çağıran, tanımlı bir pencere üzerinden yapılandırılmış istek hızını aşıyor.
  • HTTP 503 (Hizmet Kullanılamıyor): Genellikle beklenmeyen bir yük artışı nedeniyle hizmet şu anda isteği işleyemiyor.

  İstemcinin yeniden deneme stratejisi seçebilmesi için bir Retry-After HTTP üst bilgisi ekleyin. Çağıranın tahmin etmek yerine kasıtlı olarak yeniden denemesi için yeterli bağlam döndürebilirsiniz. Örneğin, çağıranın aştığı sınırı adlandırın, etkilenen kapsamı netleştirin veya başarılı olacak bir hız önerin. Açıklanamayan reddetmeler arayanların uyum sağlamasına yardımcı olmaz.

• Aşırı yükleme sinyallerini emmek yerine bağımlılıklarınızdan yayma. Kendisine çağrı yapanlara hız sınırlaması uygulayan bir hizmet, kendi alt bağımlılıklarından aldığı hız sınırlama yanıtlarına da uymalıdır. Hizmetiniz, sessizce yeniden denemeler yaparak veya genel bir HTTP 500 (İç Sunucu Hatası) yanıtı döndürerek alt hizmetten gelen 429 ya da 503 yanıtını gizlerse, çağıranlar yavaşlayamaz, yeniden denemeler artar ve aşırı yük yukarı akışa doğru yayılır. Yeniden Deneme Fırtınası karşı deseni bu hata modunu açıklar. Tüm çağrı zincirinin yükü birlikte azaltabilmesi için geri basıncı üst çağıranlara iletin.

• Reddetme işlemini, önlediği işten daha ucuz hâle getirin. bir isteği reddetmek için yoğun kimlik doğrulaması, derin ayrıştırma veya karmaşık ilke değerlendirmesi gerekiyorsa reddedilen istekler yine de sistemi doygunluğa taşıyabilir. İstek işlem hattında mümkün olduğunca erken reddedin ve reddetme yolunun kendisini yük testi yapın.

• Kısıtlamanın otomatik ölçekleme için yeterince zaman kazandıramadığı durumlar için plan yapın. Talep, yeni kapasitenin devreye girme hızından daha hızlı artarsa, kapasitesi kısılmış bir sistem bile çökebilir. Bu sonuç kabul edilemez olduğunda, daha büyük kapasite yedekleri tutun ve daha agresif otomatik ölçeklendirme yapılandırın.

• Hız sınırlamanın yerine önbelleğe almayı kullanmayın. Önbellek, kaynak üzerindeki ortalama yükü düşürür ancak en yüksek yükü bağlamaz. Her önbellek kaçağı çıkış noktası üzerinden geçer ve yoğun trafik altında popüler bir anahtarın süresi dolduğunda, birçok arayan bu anahtarı doldurmak için yarışabilir. Normal yükü azaltmak ve en kötü durumu sınırlamak için önbelleğe alma ve hız sınırlama kullanın. Daha fazla bilgi için bkz.Cache-Aside düzeni.

• Genellikle eşit yürütme maliyetleri taşımadığından farklı işlemler için kaynak maliyetlerini normalleştirin. Örneğin, kısıtlama sınırları okuma işlemleri için daha yüksek, yazma işlemleri için ise daha düşük olabilir. İşlem başına maliyeti yoksaymak kapasiteyi tüketebilir ve bir saldırı vektörüne neden olabilir.

• Kısıtlama yapılandırmasını çalışma zamanında değiştirilebilir yapın. Anormal yük geldiğinde, dağıtım olmadan sınırları ayarlamanız gerekir. Dağıtımlar bir olay sırasında yavaş ve risklidir. Dış Yapılandırma Deposu düzeni, çalışma zamanında değiştirebilmeniz için yapılandırmayı dışlar.

• Statik sınırlar yerine uyarlamalı sınırları göz önünde bulundurun. Bazı hız sınırlama SDK’ları, sınırın bileşenlerin gerçek durumuna göre ayarlanması için gecikme veya kuyruk uzunluğu sinyallerine tepki verir. Uyarlamalı sınırlayıcıyı her zaman ayarlanmış maksimum değerle eşleştirin.

• İş yükü değiştikçe limitlerinizi yeniden değerlendirin. Uyarlamalı sınırlayıcılar, SLO değişiklikleri, bağımlılık kapasitesindeki değişiklikler veya işlem başına maliyetteki değişimler gibi her tür sapmayı izleyemez. Bu girdilere göre periyodik operatör incelemesi planlayın.

Bu desen ne zaman kullanılır?

Şu deseni kullanın:

• Bir sistemi SLO sınırları içinde tutmak için.

• Tek bir kiracının uygulama kaynaklarını tekeline almasını önlemek için.

• Ani etkinlik patlamalarını yönetmek için.

• Bir sistemin ihtiyaç duyduğu en yüksek kaynak düzeyini sınırlamak için.

• Şebeke karbon yoğunluğunun yüksek olduğu dönemlerde düşük değerli bilgi işlemi azaltmak için.

İş yükü tasarımı

Azure Well-Architected Framework sütunları kapsamında ele alınan hedefleri ve ilkeleri karşılamak için iş yükü tasarımında Kısma düzeninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.

Kolon	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur.	Arızalara yol açabilecek kaynak tükenmesini önlemeye yardımcı olmak için sınırları tasarlarsınız. Bu deseni, düzgün bir düşüş planında denetim mekanizması olarak da kullanabilirsiniz. - RE:07 Kendini koruma
Güvenlik tasarımı kararları, iş yükünüzün verilerinin ve sistemlerinin gizliliğini, bütünlüğünü ve kullanılabilirliğini sağlamaya yardımcı olur.	Sistemin otomatik olarak kötüye kullanılmasına neden olabilecek kaynak tükenmesini önlemeye yardımcı olacak sınırlar tasarlayabilirsiniz. - SE:06 Ağ denetimleri - SE:08 Güvenlik kaynaklarının güçlendirilmesi
Maliyet İyileştirme, iş yükünüzün yatırım getirisinisürdürmeye ve geliştirmeye odaklanır.	Uygulanan sınırlar maliyet modellemeyi bilgilendirebilir ve doğrudan uygulamanızın iş modeline bağlanabilir. Ayrıca, kaynak boyutlandırmaya hesaba katılabilmesi için kullanımın net üst sınırlarını da koyarlar. - CO:02 Maliyet modeli - CO:12 Ölçeklendirme maliyetleri
Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar.	Sistem yüksek talep altında olduğunda, bu desen performans sorunlarına yol açabilecek tıkanıklığı azaltmaya yardımcı olur. Gürültülü komşu senaryolarından proaktif olarak kaçınmak için de kullanabilirsiniz. - PE:02 Kapasite planlaması - PE:05 Ölçeklendirme ve bölümleme

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Example

Aşağıdaki diyagramda çok kiracılı bir sistemde kısıtlama gösterilmektedir.

Solda etiketlenmiş üç kullanıcı, çok kiracılı bir Surveys uygulamasının kiracılarını temsil eder: Adatum, Fabrikam ve Contoso. Her kullanıcı istekleri kiracıya özgü bir özel etki alanı üzerinden gönderir. Bu etki alanı, uygulamanın kiracıyı tanımlamak için kullandığı bir etki alanıdır. Adatum, surveys.adatum.com üzerinden saniyede 5 istek, Fabrikam surveys.fabrikam.com üzerinden saniyede 10 istek gönderir ve Contoso da surveys.contoso.com aracılığıyla saniyede 150 istek gönderir. Sağ tarafta, anket uygulaması web rolü her kiracı için saniye başına istek oranını ölçer. Adatum ve Fabrikam istek akışları uygulamaya geçer. Contoso istek akışı, oran kiracı başına limiti aştığı için “Hata: Kısıtlanmış yanıt” nedeniyle engellendi.

Birkaç kiracı kuruluştan kullanıcılar, anketleri doldurmak ve göndermek için bulutta barındırılan bir uygulamaya erişmektedir. Uygulama, her kiracının kullanıcılarının istek gönderme hızını izleyen izleme mekanizmaları içerir.

Bir kiracıdaki kullanıcıların diğer kiracılardaki kullanıcılar için yanıt hızını ve kullanılabilirliğini düşürmesini önlemek için uygulama, tek bir kiracının gönderebileceği saniye başına istek oranını sınırlar. Uygulama bu sınırı aşan istekleri engeller.

Sonraki adım

• İzleme sistemi tasarlamaya yönelik mimari stratejileri

İlgili kaynaklar

• Her kiracının tüketimini ölçün
• Azure'da otomatik ölçeklendirme
• Kuyruk Tabanlı Yük Dengeleme düzeni
• Öncelik Sırası düzeni
• Dış Yapılandırma Deposu şablonu