Bir uygulama örneği, tek bir kiracı veya hizmetin tamamı tarafından kullanılan kaynakların tüketimini denetleyin. Bu, istekteki artış kaynaklar üzerinde aşırı yüklemeye neden olduğunda bile sistemin çalışmaya ve hizmet düzeyi sözleşmelerini karşılamaya devam etmesine olanak sağlar.
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 kaynak kapasitesini aşıyorsa, sistem performansı düşer ve hatta sistem 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 var olan hizmet düzeyi sözleşmelerini (SLA' lar) karşılaması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ç azaltma 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 kaynaklar ile etkilenmeden çalışabilmesi için seçili temel olmayan hizmetleri devre dışı bırakma veya düzeyini düşürme. Ö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 bekletilerek kapsam yükü azaldığında 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.
Düşük öncelikli uygulama veya kiracılar 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 yanıtsız istek işlemeye 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.
Önceki şekilde işlemleri ertelemenin etkileri gösterilmektedir. T1 zamanından hemen önce, bu özellikleri kullanan tüm uygulamalar için ayrılan toplam kaynaklar bir eşiğe ulaşır (kaynak kullanımı sınırı). 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ı yanıt verir durumda ve SLA’lar dahilinde tutmaya yardımcı olmak için birleştirilebilir. Talebin yüksek kalması bekleniyorsa azaltma, sistemin ölçeği genişletilirken geçici bir çözüm sağlar. Bu noktada, sistemin tüm işlevselliği geri yüklenebilir.
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 azaltma gevşetilebilir.
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ı kısıtlamak ve kullanılan strateji bir 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ışı aniden gerçekleşirse ve uzun süreli olması beklenmiyorsa ölçeklendirme, çalıştırma maliyetlerine önemli ölçüde katabileceği için ölçeklendirme yerine yalnızca azaltma yapmak daha iyidir.
Azaltma, sistem otomatik ölçeklendirilirken geçici bir ölçü olarak kullanılıyorsa ve kaynak talepleri çok hızlı bir şekilde artıyorsa, azaltılmış 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, azaltma 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 azaltma davranışının dinamik yapılandırma değişikliği tercih 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 desen azaltma yapılandırmasının kullanılması dışlaştırılır ve dağıtımlar olmadan değiştirilebilir ve uygulanabilir.
Bu düzenin kullanılacağı durumlar
Bu düzeni kullanarak:
Bir sistemin hizmet düzeyi sözleşmelerini karşılamaya 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.
Etkinlik artışlarını işlemek 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.
İş yükü tasarımı
Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için azaltma düzeninin iş yükünün tasarımında 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 Sağlamlaştırma 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 sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.
Örnek
Son şekilde azaltmanın çok kiracılı bir sistemde nasıl uygulanabileceği gösterilmektedir. Her bir kiracı kuruluştan kullanıcılar anket doldurup göndermek üzere bulutta barındırılan bir uygulamaya erişir. Uygulama bu kullanıcıların istekleri uygulamaya gönderme hızını izleyen bir izleme 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 desen uygulanırken aşağıdaki yönergeler de uygun olabilir:
- İzleme 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 açıklanmalıdı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 kısıtlanacağını belirlerken yararlı olabilir.
- Otomatik Ölçeklendirme Kılavuzu. Kısıtlama, bit sistem otomatik ölçeklendirilirken bir ara önlem olarak veya sistemin otomatik ölçeklendirilmesi gereksinimini 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 ilgili olabilir:
- Kuyruk Tabanlı Yük Dengeleme düzeni. Kuyruk tabanlı yük dengeleme, kısıtlama uygulama için sık 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 için performansı azaltarak kuyruğa almayı kısıtlama stratejisinin bir parçası olarak kullanabilir.
- Dış Yapılandırma Deposu düzeni. Azaltma ilkelerinin merkezileştirilmesi ve dışlaştırılması, yeniden dağıtıma gerek kalmadan çalışma zamanında yapılandırmayı değiştirme olanağı sağlar. Hizmetler yapılandırma değişikliklerine abone olabilir ve böylece sistemi kararlı hale getirmek için yeni yapılandırmayı hemen uygulayabilir.