İş ölçümlerini kullanarak, karşıt Azure uygulamaları tasarlama

İş yükü kullanılabilirliği hedefleri

Uygulama veya önemli senaryolar için Hizmet Düzeyi Sözleşmesi (SLA), Hizmet Düzeyi Göstergeleri (SLI) ve Hizmet Düzeyi Hedefleri (SLI) gibi kullanılabilirlik hedefleri tanımlandı mı?

Müşteri kullanılabilirliği beklentilerini anlamak, uygulamanın genel operasyonlarını gözden geçirme açısından çok önemlidir. Örneğin, bir müşteri bir uygulama SLO's una ulaşmak için çabalarsa, uygulamanın gerektirilen doğal operasyonel etkinlik düzeyi, hedefin SLO's undan 99.999%99.9% çok daha yüksek olur.

Mimarinin iş gereksinimlerini karşılayarak karşılamayıp karşılama olmadığını belirlemek için çözümünüzle ilgili her iş yükü için kendi hedef SLA'larınızı tanımlayın.

Maliyeti ve karmaşıklığı göz önünde

Diğer her şey eşit, yüksek kullanılabilirlik daha iyidir. Ancak siz dokuzdan fazlası için çabalarken maliyet ve karmaşıklık da artıyor. Çalışma süresi, 99.99% aylık toplam kapalı kalma süresinin yaklaşık beş dakikası olarak ifade eder. Beş dokuza ulaşmak fazladan karmaşıklık ve maliyete değer mi? Bunun yanıtı iş gereksinimlerine bağlıdır.

SLA tanımlarken göz önüne alınacak diğer bazı noktalar şunlardır:

• Dört dokuz ( ) elde etmek için hatalardan kurtarmak 99.99% için el ile müdahaleye güvenesiniz. Uygulamanın kendi kendini tanılayabilmesi ve düzeltebilmesi gerekir.
• Dört dokuzdan fazla, kesintileri SLA'yı karşılayacak kadar hızlı bir şekilde algılamak zordur.
• SLA’nızın ölçüldüğü zaman penceresini düşünün. Bu pencere küçüldükçe tolerans da azalır. SLA'nızı saatlik veya günlük çalışma süresi açısından tanımlamak mantıklı değil.
• MTBF ve MTTR ölçümlerini düşünün. SLA'nız ne kadar yüksek olursa hizmet o kadar az sıklıkta kapatılabilir ve hizmetin kurtarılma oranı o kadar hızlı olur.
• Uygulamanın her parçasının kullanılabilirlik hedefleri için müşterilerinizden anlaşma elde edin ve belgelenin. Aksi takdirde, tasarımınız müşterilerin beklentilerini karşılamayabilir.

Bağımlılıkları tanımlama

İç ve dış bağımlılıkları belirlemek için bağımlılık eşleme alıştırmaları gerçekleştirin. Active Directory gibi güvenlik veya kimlikle ilgili bağımlılıklar ya da ödeme sağlayıcısı ya da e-posta mesajlaşma hizmeti gibi üçüncü taraf hizmetler buna örnek olarak verilmiştir.

Tek hata noktası veya performans sorunlarına neden olan dış bağımlılıklara özellikle dikkat etmek. Bir iş yükü çalışma süresi gerektiriyorsa ama SLA'sı olan bir hizmete bağlı ise, bu hizmet sistemde tek hata 99.99%99.9% noktası oamaz. Bir çözüm, hizmetin başarısız olduğu durumda bir geri dönüş yoluna sahip olmaktır. Alternatif olarak, bu hizmette bir hatadan kurtarmak için başka önlemler alın.

Aşağıdaki tabloda, çeşitli SLA düzeyleri için olası toplam kapalı kalma süreleri gösterilmektedir.

Kritik sistem akışlarını tanımlama

Kritik sistem akışlarını anlamak, genel operasyonel etkinliği değerlendirmek için çok önemlidir ve bir sistem durumu modelini uygulama için bilgilendirmek için kullanılmalıdır. Ayrıca uygulama alanlarının fazla mı yoksa az mı kullanılıyor olduğunu ve iş ihtiyaçlarını ve maliyet hedeflerini daha iyi karşılayacak şekilde ayarlanması gerektiğini de söyler.

Uygulamanın kritik alt sistemleri veya yolları, ilişkili iş senaryolarının ve işlevlerinin kritik öneme sahip olması nedeniyle kullanılabilirlik, kurtarma ve performansla ilgili daha yüksek beklentiye sahip olabilir. Bu, maliyetin bu yüksek ihtiyaçlardan etkilenecek olup olacağını anlamanıza da yardımcı olur.

Daha az kritik bileşenleri tanımlama

Uygulamanın daha az kritik olan bazı bileşenleri veya yolları kullanılabilirlik, kurtarma ve performansla ilgili daha düşük beklentilere sahip olabilir. Daha az kritik bileşenler, daha düşük performans ve kullanılabilirlik ile daha düşük SKUS'lar seçerek maliyetin azalmasına neden olabilir.

Kurtarma ölçümleri

Bir risk değerlendirmesi yaparak bu değerleri türetin ve kapalı kalma süresi ve veri kaybı maliyetini ve riskini anlamadan emin olun. Bunlar bir sistemin işlevsel olmayan gereksinimleridir ve iş gereksinimlerine göre dikte gereksinimlerini karşılamalıdır.

• Kurtarma süresi hedefi (RTO), bir olaydan sonra bir uygulamanın kullanılamaz durumda olduğu kabul edilebilir en uzun süredir.
• Kurtarma noktası hedefi (RPO), olağanüstü durum sırasında kabul edilebilir maksimum veri kaybı süresidir.

Yüksek oranda kullanılabilir bir kurulumda herhangi bir kritik bileşenin MTTR değeri sistem RTO'suzu aşarsa, sistemdeki bir hata kabul edilemez bir iş kesintisi neden olabilir. Başka bir deyişle tanımlanan RTO içinde sistemi geri yüklemek mümkün olmaz.

Kullanılabilirlik ölçümleri

Yedekliliği planlamak ve müşteri SLA'larını belirlemek için bu ölçüleri kullanın.

• Ortalama kurtarma süresi (MTTR), bir hatadan sonra bileşeni geri yüklemek için gereken ortalama süredir.
• Hatalar arasındaki ortalama süre (MTBF), bir bileşenin kesintiler arasında makul bir süre bekleme süresidir.

Hizmet düzeyi sözleşmelerini anlama

Azure'da Hizmet Düzeyi Sözleşmesi Microsoft'un çalışma süresi ve bağlantı taahhütlerini açıklar. Belirli bir hizmetin SLA'sı 99.9% ise, hizmetin zaman içinde kullanılabilir 99.9% olmasını beklemelisiniz. Farklı hizmetlerin farklı SLA'ları vardır.

Azure SLA'sı, SLA'nın karşılanmazsa hizmet kredisi alma hükümlerinin yanı sıra her hizmetin belirli kullanılabilirlik tanımlarını da içerir. SLA’nın bu yönü bir yaptırım ilkesi görevini görür.

Tahmin Hizmet Düzeyi Sözleşmesi örnek, mimarinizin SLA'sı hesaplamayı gösterir.

Bileşik SLA'lar

Bileşik SLA'lar, her biri farklı kullanılabilirlik düzeylerine sahip bir uygulamayı destekleyen birden çok hizmeti içerir. Örneğin, App Service yazan bir web uygulaması Azure SQL Veritabanı. Yayım zamanında, bu Azure hizmetleri aşağıdaki SLA'lara sahip olur:

• App Service web uygulamaları = 99.95%
• SQL Veritabanı =99.99%

Bu uygulamadan bekleyebileceğiniz en uzun kapalı kalma süresi nedir? Hizmetlerin herhangi biri başarısız olursa tüm uygulama başarısız olur. Her hizmetin başarısız olma olasılığı bağımsızdır, dolayısıyla bu uygulama için bileşik SLA 99.95% × 99.99% = 99.94% değeridir. Bu, tek tek SLA'lardan daha düşüktür ve birden çok hizmetten hizmet alan bir uygulamanın daha fazla olası hata noktası olduğundan bu şaşırtıcı değildir.

Bağımsız geri dönüş yolları oluşturarak bileşik SLA'yı geliştirin. Örneğin, bir SQL Veritabanı kullanılamıyorsa, işlemleri daha sonra işlenecek bir kuyruğa alın.

Bu tasarımda uygulama, veritabanına bağlanamasa bile kullanılabilir durumda kalır. Ancak, veritabanı ve kuyruk aynı anda başarısız olursa uygulama da başarısız olur. Eşzamanlı hata için beklenen süre yüzdesi değeridir, bu nedenle bu birleşik yolun 0.0001 × 0.001 bileşik SLA'sı şöyledir:

• Veritabanı veya kuyruk =

Toplam bileşik SLA ise aşağıdaki gibidir:

• Web uygulaması ve (veritabanı veya kuyruk) =

Bu yaklaşımın bazında bazı trade'lar vardır. Uygulama mantığı daha karmaşıktır, kuyruk için ödeme yaparsınız ve veri tutarlılığı sorunlarını göz önünde bulundurmanız gerekir.

Çok bölgeli dağıtımları için SLA 'Lar

çok bölgeli dağıtımları için sla 'lar , uygulamayı birden fazla bölgede dağıtmaya yönelik yüksek kullanılabilirliğe sahip bir tekniktir ve uygulama bir bölgede başarısız olursa yük devretmek için Azure Traffic Manager kullanır.

Bir çok bölgeli dağıtımı için bileşik SLA aşağıdaki şekilde hesaplanır:

• N , tek bir bölgede dağıtılan uygulamanın bileşik SLA 'sı.
• R , uygulamanın dağıtıldığı bölge sayısıdır.

Uygulamanın tüm bölgelerde aynı anda başarısız olması beklenen şans ( (1 − N) ^ R ). Örneğin, tek bölgeli SLA 99.95% :

• İki bölgenin birleştirilmiş SLA 'Sı = (1 − (1 − 0.9995) \^ 2) = 99.999975%
• Dört bölgenin birleştirilmiş SLA 'Sı = (1 − (1 − 0.9995) \^ 4) = 99.999999%

Traffic Manager SLA da bir faktördür. Yük devretme, etkin-Pasif yapılandırmalarda anlık değildir ve bu da yük devretme sırasında kapalı kalma süresine yol açabilir. Bkz. Traffic Manager uç nokta izleme ve yük devretme.