Daraltma deseni

Azure

Bir uygulama örneği, tek bir kiracı veya hizmetin tamamı tarafından kullanılan kaynakların tüketimini denetleyin. Bu, talep artışı kaynaklara aşırı yük getirse bile sistemin çalışmaya ve hizmet düzeyi hedeflerini (SLO) karşılamaya devam etmelerine olanak sağlayabilir.

Bağlam ve sorun

Bulut uygulamasındaki yük genellikle zaman içinde etkin kullanıcı sayısına veya gerçekleştirdikleri etkinlik türlerine göre değişir. Örneğin, iş saatlerinde daha fazla kullanıcı etkin olabilir veya sistemin her ay sonunda yoğun işlem yükü oluşturan analizler yapması gerekebilir. Beklenmeyen ve ani etkinlik artışları da olabilir. Sistemin işleme gereksinimleri kullanılabilir kaynakların kapasitesini aşarsa düşük performansla karşılaşır ve hatta başarısız olabilir. Sistem üzerinde anlaşılan bir hizmet düzeyini karşılaması gerekiyorsa, bu tür hatalar kabul edilemez olabilir.

Uygulamanın iş hedeflerine bağlı olarak bulutta değişen yükü işlemek için kullanabileceğimiz birçok strateji vardır. Stratejilerden biri, sağlanan kaynakları herhangi bir zamanda kullanıcı gereksinimleriyle eşleştirmek için otomatik ölçeklendirmeyi kullanmaktır. Bu çalıştırma maliyetlerini en iyi duruma getirirken tutarlı olarak kullanıcı talebini karşılama olasılığına sahiptir. Ancak, otomatik ölçeklendirme daha fazla kaynağın sağlanmasını tetikleyebilir, ancak bu sağlama hemen olmaz. Talep hızla artarsa, bir kaynak eksikliği yaşanan bir zaman penceresi olabilir.

Çözüm

Alternatif bir strateji, uygulamaların kaynakları yalnızca belirli bir sınıra kadar kullanmasına izin verip bu sınıra ulaşıldığında kısıtlamaktır. Sistem, kullanım eşiği aştığında bir veya daha fazla kullanıcıdan gelen istekleri kısıtlayabilmek için kaynakları nasıl kullandığını izlemelidir. Bu, sistemin çalışmaya devam etmesi ve hizmet düzeyi hedeflerine (SLO' lar) uymasını sağlar. Kaynak kullanımını izleme hakkında daha fazla bilgi için bkz. İzleme ve Telemetri Kılavuzu.

Sistem, aşağıdakiler dahil birkaç kısıtlama stratejisi uygulayabilir:

• Sistem API’lerine belirli bir süre boyunca saniyede n kereden fazla erişen tek bir kullanıcıdan gelen istekleri reddetme. Bu, sistemin bir uygulamayı çalıştıran her kiracı veya kullanıcı için kaynak kullanımını ölçmesini gerektirir. Daha fazla bilgi için bkz. Hizmet Ölçümü Kılavuzu.

• Temel hizmetlerin yeterli kaynaklarla etkilenmeden çalışabilmesi için seçili gereksiz hizmetleri devre dışı bırakma veya işlevselliğini azaltma. Örneğin uygulama video çıkışının akışını yapıyorsa, daha düşük bir çözünürlüğe geçiş yapabilir.

• Etkinlik hacmini düzenlemek için yük dengeleme kullanma ( bu yaklaşım Kuyruk Tabanlı Yük Dengeleme düzeni bölümünde daha ayrıntılı bir şekilde ele alınmıştır). Çok kiracılı bir ortamda bu yaklaşım her kiracının performansını düşürür. Sistemin farklı SLA’lara sahip bir kiracı karışımını desteklemesi gerekiyorsa, yüksek değerli kiracılar için iş hemen gerçekleştirilebilir. Diğer kiracılar için istekler, iş yükü azaldığında bekletilebilir ve işlenebilir. Öncelik Sırası düzeni, farklı hizmet düzeyleri/öncelikleri için farklı uç noktaları ortaya çıkarmak gibi bu yaklaşımın uygulanmasına yardımcı olmak için kullanılabilir.

• Daha düşük öncelikli uygulama veya kiracı adına gerçekleştirilen işlemleri erteleme. Bu işlemler kiracıya sistemin meşgul olduğunu ve işlerin daha sonra yeniden denenmesi gerektiğini bildiren bir özel durum oluşturularak askıya alınabilir veya sınırlandırılabilir.

• Kullanılamayabilecek veya hata döndürebilecek bazı üçüncü taraf hizmetleriyle tümleştirme yaparken dikkatli olmanız gerekir. Günlüklerin gereksiz yere hatalarla dolmaması için işlenen eşzamanlı isteklerin sayısını azaltın. Ayrıca, üçüncü taraf hizmet nedeniyle başarısız olacak isteklerin işlenmesini gereksiz bir şekilde yeniden denemekle ilişkili maliyetlerden de kaçınabilirsiniz. Ardından, istekler başarıyla işlendiğinde, normal kısıtlamasız istek işleme sürecine geri dönün. Bu işlevi uygulayan kitaplıklardan biri NServiceBus'tır.

Şekilde, üç özellik kullanan uygulamalar için zamana karşı kaynak kullanımı (bellek, CPU, bant genişliği ve diğer etkenlerin birleşimi) için bir alan gösterilmektedir. Özellik, belirli bir görev kümesini gerçekleştiren bir bileşen, karmaşık bir hesaplama gerçekleştiren bir kod parçası veya bellek için önbellek gibi bir hizmet sağlayan bir öğe gibi bir işlev alanıdır. Bu özellikler A, B ve C olarak etiketlenmiştir.

Bir özellik için çizginin hemen altındaki alan, uygulamalar bu özelliği çağırdığında kullanılan kaynakları gösterir. Örneğin, Özellik A için çizginin altındaki alan Özellik A’yı kullanan uygulamalar tarafından kullanılan kaynakları ve Özellik A ile Özellik B için çizgilerin arasındaki alan ise Özellik B’yi çağıran uygulamalar tarafından kullanılan kaynakları gösterir. Her özellik için alanların toplamı sistem için toplam kaynak kullanımını gösterir.

İşlemleri ertelemenin etkileri önceki şekilde gösterilmektedir. T1 zamanından hemen önce, bu özellikleri kullanan tüm uygulamalara ayrılan toplam kaynaklar eşiğe ulaşır. Bu eşik, kaynak kullanımı sınırını temsil eder. Bu noktada, uygulamaların kullanılabilir kaynakları tüketme tehlikesi vardır. Sistemde, Özellik B Özellik A veya Özellik C’den daha az kritik olduğundan geçici olarak devre dışı bırakılır ve kullandığı kaynaklar serbest bırakılır. T1 ve T2 zamanları arasında, Özellik A ve Özellik C’yi kullanan uygulamalar normal olarak çalışmaya devam eder. Sonuç olarak, T2 zamanında Özellik B’yi etkinleştirmek için yeterli kapasite olana kadar bu iki özelliğin kaynak kullanımı azaltılır.

Otomatik ölçeklendirme ve kısıtlama yaklaşımları, uygulamaların yanıt verme yeteneğini korumasına ve SLA’lara uygun kalmasına yardımcı olmak için birleştirilebilir. Talebin yüksek kalması bekleniyorsa, kısıtlama, sistem ölçeklendirilirken geçici bir çözüm sağlar. Bu noktada, sistemin tam işlevselliğinin geri yüklenmesi mümkün olur.

Sonraki şekilde, bir sistemde zamana karşı çalışan tüm uygulamalar tarafından genel kaynak kullanımı gösterilmekte ve kısıtlamanın otomatik ölçeklemeyle nasıl birleştirileceği açıklanmaktadır.

T1 zamanında, kaynak kullanımı yumuşak sınırını belirten eşiğe ulaşılmıştır. Bu noktada sistem ölçeği genişletmeye başlayabilir. Ancak, yeni kaynaklar yeterince hızlı bir şekilde kullanılabilir duruma gelmezse, mevcut kaynaklar tükenebilir ve sistem başarısız olabilir. Bunun gerçekleşmesini önlemek için, sistem daha önce açıklandığı şekilde geçici olarak kısıtlanır. Otomatik ölçeklendirme tamamlandığında ve ek kaynaklar kullanılabilir olduğunda, sınırlama hafifletilebilir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacağınıza karar verirken aşağıdaki noktaları dikkate almalısınız:

• Bir uygulamayı ve kullanılacak stratejiyi azaltma, sistemin tüm tasarımını etkileyen mimari bir karardır. Bir sistem uygulandıktan sonra kısıtlama eklemek kolay olmadığından, kısıtlama uygulama tasarım sürecinin ilk zamanlarında değerlendirilmelidir.

• Kısıtlama hızlı bir şekilde gerçekleştirilmelidir. Sistemin bir etkinlik artışını algılaması ve buna uygun şekilde tepki vermesi gerekir. Sistemin ayrıca yük azaldıktan sonra hızlı bir şekilde özgün durumuna dönebilmesi gerekir. Bu, uygun performans verilerinin sürekli olarak yakalanması ve izlenmesini gerektirir.

• Bir hizmetin bir kullanıcı isteğini geçici olarak reddetmesi gerekiyorsa, istemci uygulamasının bir isteğe hizmet vermeyi reddetme nedeninin azaltmadan kaynaklandığını anlaması için 429 ("Çok fazla istek") ve 503 ("Sunucu Çok Meşgul") gibi belirli bir hata kodunu döndürmesi gerekir.

  • HTTP 429, çağıran uygulamanın bir zaman penceresinde çok fazla istek gönderdiğini ve önceden belirlenmiş bir sınırı aştığını gösterir.
  • HTTP 503, hizmetin isteği işlemeye hazır olmadığını gösterir. Bunun yaygın nedeni, hizmetin beklenenden daha fazla geçici yük artışıyla karşılaşmasıdır.

İstemci uygulaması isteği yeniden denemeden önce bir süre bekleyebilir. Retry-After İstemcinin yeniden deneme stratejisini seçmesini desteklemek için bir HTTP üst bilgisi eklenmelidir.

• Bir sistem otomatik olarak ölçeklendirilirken kısıtlama geçici bir önlem olarak kullanılabilir. Bazı durumlarda, bir etkinlik artışının ani olması ve sürmesi beklenmemesi durumunda ölçeklendirme yerine azaltma yapmak daha iyidir çünkü ölçeklendirme, çalıştırma maliyetlerine önemli ölçüde eklenebilir.

• Kısıtlama, sistem otomatik ölçeklendirilirken geçici bir önlem olarak kullanılıyorsa ve kaynak talepleri çok hızlı bir şekilde artıyorsa, kısıtlanmış modda çalışırken bile sistem çalışmaya devam edemeyebilir. Bu kabul edilebilir değilse, daha geniş kapasite yedekleri tutmayı ve daha agresif otomatik ölçeklendirme yapılandırmayı göz önünde bulundurun.

• Genellikle eşit yürütme maliyetleri taşımadıkları için farklı işlemler için kaynak maliyetlerini normalleştirin. Örneğin, hız sınırlama sınırları okuma işlemleri için daha düşük ve yazma işlemleri için daha yüksek olabilir. Bir işlemin maliyeti dikkate alınmaması, kapasitenin tükenmesine ve olası bir saldırı vektörünün ortaya alınmasına neden olabilir.

• Çalışma zamanında kısıtlama davranışının dinamik olarak yapılandırılması arzu edilir. Bir sistem uygulanan yapılandırmanın işleyemediği anormal bir yükle karşılaşıyorsa, sistemi kararlı hale getirmek ve geçerli trafiğe ayak uydurmak için azaltma sınırlarının artması veya azalması gerekebilir. Bu noktada pahalı, riskli ve yavaş dağıtımlar tercih edilmez. Dış Yapılandırma Deposu deseni sınırlama yapılandırmasının dışsallaştırılmasını sağlar ve dağıtımlar olmadan değiştirilebilir ve uygulanabilir.

Bu düzenin kullanılacağı durumlar

Bu deseni kullan:

• Bir sistemin hizmet düzeyi hedeflerine (SLO) uymaya devam ettiğinden emin olmak için.

• Tek bir kiracının bir uygulama tarafından sağlanan kaynakların tamamını kullanmasını önlemek için.

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

• Bir sistemin çalışır duruma kalması için gereken en fazla kaynak düzeylerini sınırlandırarak sistemin maliyetini en iyi duruma getirmeye yardımcı olma.

• Enerji şebekesindeki yüksek karbon yoğunluğu dönemlerinde düşük değerli işlem işlemeyi azaltmak.

İş yükü tasarımı

Bir mimar, iş yükünün tasarımında Azure Well-Architected Framework sütunları kapsamındaki hedefleri ve ilkeleri ele almak için Throttling deseninin nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Yapı Taşı	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma gelmesini sağlamaya 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üçlendirme kaynakları
Maliyet İyileştirme, iş yükünüzün yatırım getirisini sürdürmeye ve geliştirmeye odaklanır.	Uygulanan sınırlar maliyet modellemeyi bilgilendirebilir ve hatta uygulamanızın iş modeline doğrudan 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

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer temel bileşenlerin hedeflerine karşı herhangi bir tavizi göz önünde bulundurun.

Örnek

Son şekil, sınırlamanın çoklu kiracı bir sistemde nasıl uygulanabileceğini göstermektedir. Her bir kiracı kuruluştan kullanıcılar anket doldurup göndermek üzere bulutta barındırılan bir uygulamaya erişir. Uygulama, kullanıcıların uygulamaya istek gönderme hızını izleyen araçlar içerir.

Bir kiracıdan gelen kullanıcıların diğer tüm kullanıcılar için uygulamanın yanıt verme becerisini veya kullanılabilirliğini etkilemesini önlemek için, herhangi bir kiracının gönderebildiği kullanıcı başına saniyede istek sayısına yönelik bir sınır uygulanır. Uygulama bu sınırı aşan istekleri engeller.

Sonraki adımlar

Bu düzeni uygularken aşağıdaki yönergeler de yararlı olabilir:

• Enstrümantasyon ve Telemetri Kılavuzu. Kısıtlama bir hizmetin ne kadar yoğun olarak kullanıldığı hakkında bilgi toplamaya bağlıdır. Özel izleme bilgilerini oluşturma ve yakalama yöntemleri açıklanmaktadır.
• Hizmet Ölçümü Kılavuzu. Nasıl kullanıldıklarını anlamak için hizmetlerin kullanımını ölçmeyi açıklar. Bu bilgiler, bir hizmetin nasıl kontrol edileceğini belirlerken yararlı olabilir.
• Otomatik Ölçeklendirme Kılavuzu. Kısıtlama, bir sistemin otomatik ölçeklendirilirken geçici bir önlem olarak veya sistemin otomatik ölçeklendirilmesine olan gereksinimi ortadan kaldırmak için kullanılabilir. Otomatik ölçeklendirme stratejileri hakkında bilgiler içerir.

İlgili kaynaklar

Bu desen uygulanırken aşağıdaki desenler de uygun olabilir:

• Kuyruk Tabanlı Yük Dengeleme düzeni. Kuyruk tabanlı yük dengeleme, kısıtlamayı uygulamak için yaygın olarak kullanılan bir mekanizmadır. Kuyruk, bir uygulama tarafından gönderilen isteklerin hizmete teslim edilme hızını düzenlemeye yardımcı olan bir arabellek olarak çalışabilir.
• Öncelikli Kuyruk düzeni. Sistemler, kritik veya yüksek değerli uygulamalar için performansı korurken, daha az önemli uygulamaların performansını azaltmak amacıyla önceliklendirilmiş kuyruklamayı daraltıcı stratejinin bir parçası olarak kullanabilir.
• Harici Yapılandırma Deposu Deseni. Sınırlama ilkelerinin merkezileştirilmesi ve dışa aktarılması, yeniden dağıtmaya gerek kalmadan çalışma zamanında yapılandırmayı değiştirme imkanı sağlar. Hizmetler, bir sistemi kararlı hale getirmek için yeni yapılandırmayı hemen uygulayan yapılandırma değişikliklerine abone olabilir.

Bir uygulama örneği, tek bir kiracı veya hizmetin tamamı tarafından kullanılan kaynakların tüketimini denetleyin. Bu, talep artışı kaynaklara aşırı yük getirse bile sistemin çalışmaya ve hizmet düzeyi hedeflerini (SLO) karşılamaya devam etmelerine olanak sağlayabilir.

Bağlam ve sorun

Bulut uygulamasındaki yük genellikle zaman içinde etkin kullanıcı sayısına veya gerçekleştirdikleri etkinlik türlerine göre değişir. Örneğin, iş saatlerinde daha fazla kullanıcı etkin olabilir veya sistemin her ay sonunda yoğun işlem yükü oluşturan analizler yapması gerekebilir. Beklenmeyen ve ani etkinlik artışları da olabilir. Sistemin işleme gereksinimleri kullanılabilir kaynakların kapasitesini aşarsa düşük performansla karşılaşır ve hatta başarısız olabilir. Sistem üzerinde anlaşılan bir hizmet düzeyini karşılaması gerekiyorsa, bu tür hatalar kabul edilemez olabilir.

Uygulamanın iş hedeflerine bağlı olarak bulutta değişen yükü işlemek için kullanabileceğimiz birçok strateji vardır. Stratejilerden biri, sağlanan kaynakları herhangi bir zamanda kullanıcı gereksinimleriyle eşleştirmek için otomatik ölçeklendirmeyi kullanmaktır. Bu çalıştırma maliyetlerini en iyi duruma getirirken tutarlı olarak kullanıcı talebini karşılama olasılığına sahiptir. Ancak, otomatik ölçeklendirme daha fazla kaynağın sağlanmasını tetikleyebilir, ancak bu sağlama hemen olmaz. Talep hızla artarsa, bir kaynak eksikliği yaşanan bir zaman penceresi olabilir.

Çözüm

Alternatif bir strateji, uygulamaların kaynakları yalnızca belirli bir sınıra kadar kullanmasına izin verip bu sınıra ulaşıldığında kısıtlamaktır. Sistem, kullanım eşiği aştığında bir veya daha fazla kullanıcıdan gelen istekleri kısıtlayabilmek için kaynakları nasıl kullandığını izlemelidir. Bu, sistemin çalışmaya devam etmesi ve hizmet düzeyi hedeflerine (SLO' lar) uymasını sağlar. Kaynak kullanımını izleme hakkında daha fazla bilgi için bkz. İzleme ve Telemetri Kılavuzu.

Sistem, aşağıdakiler dahil birkaç kısıtlama stratejisi uygulayabilir:

• Sistem API’lerine belirli bir süre boyunca saniyede n kereden fazla erişen tek bir kullanıcıdan gelen istekleri reddetme. Bu, sistemin bir uygulamayı çalıştıran her kiracı veya kullanıcı için kaynak kullanımını ölçmesini gerektirir. Daha fazla bilgi için bkz. Hizmet Ölçümü Kılavuzu.

• Temel hizmetlerin yeterli kaynaklarla etkilenmeden çalışabilmesi için seçili gereksiz hizmetleri devre dışı bırakma veya işlevselliğini azaltma. Örneğin uygulama video çıkışının akışını yapıyorsa, daha düşük bir çözünürlüğe geçiş yapabilir.

• Etkinlik hacmini düzenlemek için yük dengeleme kullanma ( bu yaklaşım Kuyruk Tabanlı Yük Dengeleme düzeni bölümünde daha ayrıntılı bir şekilde ele alınmıştır). Çok kiracılı bir ortamda bu yaklaşım her kiracının performansını düşürür. Sistemin farklı SLA’lara sahip bir kiracı karışımını desteklemesi gerekiyorsa, yüksek değerli kiracılar için iş hemen gerçekleştirilebilir. Diğer kiracılar için istekler, iş yükü azaldığında bekletilebilir ve işlenebilir. Öncelik Sırası düzeni, farklı hizmet düzeyleri/öncelikleri için farklı uç noktaları ortaya çıkarmak gibi bu yaklaşımın uygulanmasına yardımcı olmak için kullanılabilir.

• Daha düşük öncelikli uygulama veya kiracı adına gerçekleştirilen işlemleri erteleme. Bu işlemler kiracıya sistemin meşgul olduğunu ve işlerin daha sonra yeniden denenmesi gerektiğini bildiren bir özel durum oluşturularak askıya alınabilir veya sınırlandırılabilir.

• Kullanılamayabilecek veya hata döndürebilecek bazı üçüncü taraf hizmetleriyle tümleştirme yaparken dikkatli olmanız gerekir. Günlüklerin gereksiz yere hatalarla dolmaması için işlenen eşzamanlı isteklerin sayısını azaltın. Ayrıca, üçüncü taraf hizmet nedeniyle başarısız olacak isteklerin işlenmesini gereksiz bir şekilde yeniden denemekle ilişkili maliyetlerden de kaçınabilirsiniz. Ardından, istekler başarıyla işlendiğinde, normal kısıtlamasız istek işleme sürecine geri dönün. Bu işlevi uygulayan kitaplıklardan biri NServiceBus'tır.

Şekilde, üç özellik kullanan uygulamalar için zamana karşı kaynak kullanımı (bellek, CPU, bant genişliği ve diğer etkenlerin birleşimi) için bir alan gösterilmektedir. Özellik, belirli bir görev kümesini gerçekleştiren bir bileşen, karmaşık bir hesaplama gerçekleştiren bir kod parçası veya bellek için önbellek gibi bir hizmet sağlayan bir öğe gibi bir işlev alanıdır. Bu özellikler A, B ve C olarak etiketlenmiştir.

Bir özellik için çizginin hemen altındaki alan, uygulamalar bu özelliği çağırdığında kullanılan kaynakları gösterir. Örneğin, Özellik A için çizginin altındaki alan Özellik A’yı kullanan uygulamalar tarafından kullanılan kaynakları ve Özellik A ile Özellik B için çizgilerin arasındaki alan ise Özellik B’yi çağıran uygulamalar tarafından kullanılan kaynakları gösterir. Her özellik için alanların toplamı sistem için toplam kaynak kullanımını gösterir.

İşlemleri ertelemenin etkileri önceki şekilde gösterilmektedir. T1 zamanından hemen önce, bu özellikleri kullanan tüm uygulamalara ayrılan toplam kaynaklar eşiğe ulaşır. Bu eşik, kaynak kullanımı sınırını temsil eder. Bu noktada, uygulamaların kullanılabilir kaynakları tüketme tehlikesi vardır. Sistemde, Özellik B Özellik A veya Özellik C’den daha az kritik olduğundan geçici olarak devre dışı bırakılır ve kullandığı kaynaklar serbest bırakılır. T1 ve T2 zamanları arasında, Özellik A ve Özellik C’yi kullanan uygulamalar normal olarak çalışmaya devam eder. Sonuç olarak, T2 zamanında Özellik B’yi etkinleştirmek için yeterli kapasite olana kadar bu iki özelliğin kaynak kullanımı azaltılır.

Otomatik ölçeklendirme ve kısıtlama yaklaşımları, uygulamaların yanıt verme yeteneğini korumasına ve SLA’lara uygun kalmasına yardımcı olmak için birleştirilebilir. Talebin yüksek kalması bekleniyorsa, kısıtlama, sistem ölçeklendirilirken geçici bir çözüm sağlar. Bu noktada, sistemin tam işlevselliğinin geri yüklenmesi mümkün olur.

Sonraki şekilde, bir sistemde zamana karşı çalışan tüm uygulamalar tarafından genel kaynak kullanımı gösterilmekte ve kısıtlamanın otomatik ölçeklemeyle nasıl birleştirileceği açıklanmaktadır.

T1 zamanında, kaynak kullanımı yumuşak sınırını belirten eşiğe ulaşılmıştır. Bu noktada sistem ölçeği genişletmeye başlayabilir. Ancak, yeni kaynaklar yeterince hızlı bir şekilde kullanılabilir duruma gelmezse, mevcut kaynaklar tükenebilir ve sistem başarısız olabilir. Bunun gerçekleşmesini önlemek için, sistem daha önce açıklandığı şekilde geçici olarak kısıtlanır. Otomatik ölçeklendirme tamamlandığında ve ek kaynaklar kullanılabilir olduğunda, sınırlama hafifletilebilir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacağınıza karar verirken aşağıdaki noktaları dikkate almalısınız:

• Bir uygulamayı ve kullanılacak stratejiyi azaltma, sistemin tüm tasarımını etkileyen mimari bir karardır. Bir sistem uygulandıktan sonra kısıtlama eklemek kolay olmadığından, kısıtlama uygulama tasarım sürecinin ilk zamanlarında değerlendirilmelidir.

• Kısıtlama hızlı bir şekilde gerçekleştirilmelidir. Sistemin bir etkinlik artışını algılaması ve buna uygun şekilde tepki vermesi gerekir. Sistemin ayrıca yük azaldıktan sonra hızlı bir şekilde özgün durumuna dönebilmesi gerekir. Bu, uygun performans verilerinin sürekli olarak yakalanması ve izlenmesini gerektirir.

• Bir hizmetin bir kullanıcı isteğini geçici olarak reddetmesi gerekiyorsa, istemci uygulamasının bir isteğe hizmet vermeyi reddetme nedeninin azaltmadan kaynaklandığını anlaması için 429 ("Çok fazla istek") ve 503 ("Sunucu Çok Meşgul") gibi belirli bir hata kodunu döndürmesi gerekir.

  • HTTP 429, çağıran uygulamanın bir zaman penceresinde çok fazla istek gönderdiğini ve önceden belirlenmiş bir sınırı aştığını gösterir.
  • HTTP 503, hizmetin isteği işlemeye hazır olmadığını gösterir. Bunun yaygın nedeni, hizmetin beklenenden daha fazla geçici yük artışıyla karşılaşmasıdır.

İstemci uygulaması isteği yeniden denemeden önce bir süre bekleyebilir. Retry-After İstemcinin yeniden deneme stratejisini seçmesini desteklemek için bir HTTP üst bilgisi eklenmelidir.

• Bir sistem otomatik olarak ölçeklendirilirken kısıtlama geçici bir önlem olarak kullanılabilir. Bazı durumlarda, bir etkinlik artışının ani olması ve sürmesi beklenmemesi durumunda ölçeklendirme yerine azaltma yapmak daha iyidir çünkü ölçeklendirme, çalıştırma maliyetlerine önemli ölçüde eklenebilir.

• Kısıtlama, sistem otomatik ölçeklendirilirken geçici bir önlem olarak kullanılıyorsa ve kaynak talepleri çok hızlı bir şekilde artıyorsa, kısıtlanmış modda çalışırken bile sistem çalışmaya devam edemeyebilir. Bu kabul edilebilir değilse, daha geniş kapasite yedekleri tutmayı ve daha agresif otomatik ölçeklendirme yapılandırmayı göz önünde bulundurun.

• Genellikle eşit yürütme maliyetleri taşımadıkları için farklı işlemler için kaynak maliyetlerini normalleştirin. Örneğin, hız sınırlama sınırları okuma işlemleri için daha düşük ve yazma işlemleri için daha yüksek olabilir. Bir işlemin maliyeti dikkate alınmaması, kapasitenin tükenmesine ve olası bir saldırı vektörünün ortaya alınmasına neden olabilir.

• Çalışma zamanında kısıtlama davranışının dinamik olarak yapılandırılması arzu edilir. Bir sistem uygulanan yapılandırmanın işleyemediği anormal bir yükle karşılaşıyorsa, sistemi kararlı hale getirmek ve geçerli trafiğe ayak uydurmak için azaltma sınırlarının artması veya azalması gerekebilir. Bu noktada pahalı, riskli ve yavaş dağıtımlar tercih edilmez. Dış Yapılandırma Deposu deseni sınırlama yapılandırmasının dışsallaştırılmasını sağlar ve dağıtımlar olmadan değiştirilebilir ve uygulanabilir.

Bu düzenin kullanılacağı durumlar

Bu deseni kullan:

• Bir sistemin hizmet düzeyi hedeflerine (SLO) uymaya devam ettiğinden emin olmak için.

• Tek bir kiracının bir uygulama tarafından sağlanan kaynakların tamamını kullanmasını önlemek için.

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

• Bir sistemin çalışır duruma kalması için gereken en fazla kaynak düzeylerini sınırlandırarak sistemin maliyetini en iyi duruma getirmeye yardımcı olma.

• Enerji şebekesindeki yüksek karbon yoğunluğu dönemlerinde düşük değerli işlem işlemeyi azaltmak.

İş yükü tasarımı

Bir mimar, iş yükünün tasarımında Azure Well-Architected Framework sütunları kapsamındaki hedefleri ve ilkeleri ele almak için Throttling deseninin nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Yapı Taşı	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma gelmesini sağlamaya 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üçlendirme kaynakları
Maliyet İyileştirme, iş yükünüzün yatırım getirisini sürdürmeye ve geliştirmeye odaklanır.	Uygulanan sınırlar maliyet modellemeyi bilgilendirebilir ve hatta uygulamanızın iş modeline doğrudan 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

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer temel bileşenlerin hedeflerine karşı herhangi bir tavizi göz önünde bulundurun.

Örnek

Son şekil, sınırlamanın çoklu kiracı bir sistemde nasıl uygulanabileceğini göstermektedir. Her bir kiracı kuruluştan kullanıcılar anket doldurup göndermek üzere bulutta barındırılan bir uygulamaya erişir. Uygulama, kullanıcıların uygulamaya istek gönderme hızını izleyen araçlar içerir.

Bir kiracıdan gelen kullanıcıların diğer tüm kullanıcılar için uygulamanın yanıt verme becerisini veya kullanılabilirliğini etkilemesini önlemek için, herhangi bir kiracının gönderebildiği kullanıcı başına saniyede istek sayısına yönelik bir sınır uygulanır. Uygulama bu sınırı aşan istekleri engeller.

Sonraki adımlar

Bu düzeni uygularken aşağıdaki yönergeler de yararlı olabilir:

• Enstrümantasyon ve Telemetri Kılavuzu. Kısıtlama bir hizmetin ne kadar yoğun olarak kullanıldığı hakkında bilgi toplamaya bağlıdır. Özel izleme bilgilerini oluşturma ve yakalama yöntemleri açıklanmaktadır.
• Hizmet Ölçümü Kılavuzu. Nasıl kullanıldıklarını anlamak için hizmetlerin kullanımını ölçmeyi açıklar. Bu bilgiler, bir hizmetin nasıl kontrol edileceğini belirlerken yararlı olabilir.
• Otomatik Ölçeklendirme Kılavuzu. Kısıtlama, bir sistemin otomatik ölçeklendirilirken geçici bir önlem olarak veya sistemin otomatik ölçeklendirilmesine olan gereksinimi ortadan kaldırmak için kullanılabilir. Otomatik ölçeklendirme stratejileri hakkında bilgiler içerir.

İlgili kaynaklar

Bu desen uygulanırken aşağıdaki desenler de uygun olabilir:

• Kuyruk Tabanlı Yük Dengeleme düzeni. Kuyruk tabanlı yük dengeleme, kısıtlamayı uygulamak için yaygın olarak kullanılan bir mekanizmadır. Kuyruk, bir uygulama tarafından gönderilen isteklerin hizmete teslim edilme hızını düzenlemeye yardımcı olan bir arabellek olarak çalışabilir.
• Öncelikli Kuyruk düzeni. Sistemler, kritik veya yüksek değerli uygulamalar için performansı korurken, daha az önemli uygulamaların performansını azaltmak amacıyla önceliklendirilmiş kuyruklamayı daraltıcı stratejinin bir parçası olarak kullanabilir.
• Harici Yapılandırma Deposu Deseni. Sınırlama ilkelerinin merkezileştirilmesi ve dışa aktarılması, yeniden dağıtmaya gerek kalmadan çalışma zamanında yapılandırmayı değiştirme imkanı sağlar. Hizmetler, bir sistemi kararlı hale getirmek için yeni yapılandırmayı hemen uygulayan yapılandırma değişikliklerine abone olabilir.