Hedef ve işlevsel olmayan gereksinimler

  • Makale
  • Okumak için 11 dakika

Kullanılabilirlik hedefleri ve kurtarma hedefleri gibi hedef ve işlevsel olmayan gereksinimler, iş yüklerinizin çalışma süresini ve kapalı kalma süresini ölçmenize olanak tanır. Net bir şekilde tanımlanmış hedeflere sahip olmak, üzerinde çalışma ve ölçüm yapma amacına sahip olmak açısından çok önemlidir. Bu hedeflere ek olarak, güvenilirlik gereksinimlerini geliştirmek ve iş beklentilerini karşılamak için göz önünde bulundurmanız gereken birçok başka gereksinim vardır.

Uygulamalarınızda dayanıklılık (hatalardan kurtarma) ve kullanılabilirlik (önemli bir kapalı kalma süresi olmadan iyi durumda çalışıyor) oluşturma gereksinimlerin toplanmasıyla başlar. Örneğin, ne kadar kapalı kalma süresi kabul edilebilir? Olası kapalı kalma süresi işletmenize ne kadara mal olur? Müşterinizin kullanılabilirlik gereksinimleri nelerdir? Uygulamanızı yüksek oranda kullanılabilir hale getirmek için ne kadar yatırım yapıyorsunuz? Risk ve maliyet karşılaştırması nedir?

Önemli noktalar

  • İş yükleriniz için kabul edilebilir çalışma süresi düzeyini belirleyin.
  • İş yüklerinin ne kadar süreyle kullanılamayabileceğini ve olağanüstü durum sırasında ne kadar verinin kaybedilebileceğini belirleyin.
  • Dayanıklılığı ve kullanılabilirliği geliştirmek için uygulama ve veri platformu gereksinimlerini göz önünde bulundurun.
  • Azure hizmetleriyle bağlantı kullanılabilirliğini sağlayın ve güvenilirliği artırın.
  • İş yüklerinin genel uygulama durumunu değerlendirme.

Kullanılabilirlik hedefleri

Hizmet Düzeyi Sözleşmesi (SLA), uygulamanın performansı ve kullanılabilirliğiyle ilgili taahhüdü temsil eden bir kullanılabilirlik hedefidir. Güvenilirlik hedeflerini tanımlamak için sistem içindeki tek tek bileşenlerin SLA'sını anlamak önemlidir. Bağımlılıkların SLA'sını bilmek, bağımlılıkları yüksek oranda kullanılabilir hale getirirken ve uygun destek sözleşmeleriyle ek harcamalar için bir gerekçe de sağlar. Uygulama tarafından yararlanılan tüm bağımlılıklar için kullanılabilirlik hedefleri anlaşılmalı ve ideal olarak uygulama hedefleriyle uyumlu olmalıdır.

Kullanılabilirlik beklentilerinizi anlamak, uygulamanın genel işlemlerini gözden geçirmek için çok önemlidir. Örneğin, %99,999'lık bir uygulama Hizmet Düzeyi Hedefi'ne (SLO) ulaşmak için çabalıyorsanız, uygulama için gerekli olan işlemsel eylem düzeyi, hedefin %99,9 SLO olması durumundan çok daha yüksek olacaktır.

Uygulama kullanılabilirliğinin izlenmesi ve ölçülmesi, genel uygulama durumunun nitelenmesi ve tanımlanan hedeflere doğru ilerleme açısından çok önemlidir. Aşağıdakiler gibi önemli hedefleri ölçüp izlediğinize emin olun:

  • Ortalama Hatalar Arasındaki Süre (MTBF) — Belirli bir bileşenin hataları arasındaki ortalama süre.
  • Ortalama Kurtarma Süresi (MTTR): Bir hatadan sonra bileşeni geri yüklemek için geçen ortalama süre.

Kullanılabilirlik hedefleri için dikkat edilmesi gerekenler

Tüm kaldırılan bağımlılıklar için SLA'lar/SLO'lar/SLI'ler anlaşıldı mı?

Uygulama tarafından yararlanılan tüm bağımlılıklar için kullanılabilirlik hedefleri anlaşılmalı ve ideal olarak uygulama hedefleriyle uyumlu olmalıdır. Tüm kaldırılan bağımlılıklar için SLA'ların/SLO'ların/SLI'lerin anlaşılmış olduğundan emin olun.

Azure SLA'ları kullanılarak uygulama ve/veya anahtar senaryoları için bileşik SLA hesaplandı mı?

Bileşik SLA, tüm uygulama bileşenlerinde ve bağımlılıklarında uçtan uca SLA'yı yakalar. Uygulama bileşenlerini barındıran Azure hizmetlerinin tek tek SLA'ları kullanılarak hesaplanır ve müşteri beklentileri ve hedefleriyle ilgili olarak tasarlanmış kullanılabilirlik için önemli bir gösterge sağlar. Kritik yollardaki tüm bileşenlerin ve bağımlılıkların bileşik SLA'sının anlaşılmış olduğundan emin olun. Daha fazla bilgi edinmek için bkz . Bileşik SLA'lar.

Not

Azure çözümünüz için bir SLA'ya sözleşmeye dayalı taahhütleriniz varsa, kod düzeyindeki sorunlar ve dağıtımların neden olduğu kesintilere uyum sağlamak için Azure bileşik SLA'sının üzerine ek izinler eklenmelidir. Bu durum genellikle göz ardı edilir ve müşteriler bileşik SLA'yı doğrudan müşterilerine iletmektedir.

Sistem olağanüstü durum kurtarma modunda çalışırken kullanılabilirlik hedefleri dikkate alınır mı?

Olağanüstü durum kurtarma modunda çalışırken kullanılabilirlik hedefleri uygulanabilir veya uygulanmayabilir. Bu, uygulamadan uygulamaya bağlıdır. Hedeflerin hata durumunda da geçerli olması gerekiyorsa, daha fazla kullanılabilirlik ve dayanıklılık elde etmek için bir N+1 modeli kullanılmalıdır. Bu senaryoda N, gerekli kullanılabilirliği sağlamak için gereken kapasitedir. Ayrıca, daha dayanıklı altyapı genellikle daha pahalı olduğundan bir maliyet de söz konusudur. Bunun işletme tarafından kabul edilmesi gerekir.

Kullanılabilirlik hedefleri karşılanmazsa bunun sonuçları ne olur?

SLA taahhütlerini yerine getirememekle ilişkili finansal ücretler gibi herhangi bir ceza var mı? Cezaları önlemek için ek önlemler kullanılabilir, ancak bu da altyapıyı çalıştırmak için ek maliyet getirir. Bunun dikkate alınması ve değerlendirilmesi gerekir. Kullanılabilirlik hedefleri karşılanmazsa sonuçları tam olarak anlaşılmalıdır. Bu, yük devretme olayının ne zaman başlatılacağını da bildirir.

Kurtarma hedefleri

Kurtarma hedefleri, iş yükünün ne kadar süreyle kullanılamayabileceğini ve olağanüstü durum sırasında ne kadar verinin kaybedilebileceğini belirler. Uygulama ve temel senaryolar için hedef raporları tanımlayın. Gereken hedef raporlar Kurtarma Süresi Hedefi (RTO) (bir olaydan sonra bir uygulamanın kullanılamaz durumda olduğu kabul edilebilir süre üst sınırı ve Kurtarma Noktası Hedefi (RPO) ) ise olağanüstü durum sırasında kabul edilebilir olan maksimum veri kaybı süresidir.

Kurtarma hedefleri bir sistemin işlevsel olmayan gereksinimleridir ve iş gereksinimlerine göre dikte edilmelidir. Kurtarma hedefleri, iş yükleri için gerekli RTO ve RPO hedeflerine uygun olarak tanımlanmalıdır.

Uygulama platformu gereksinimlerini karşılama

Azure uygulama platformu hizmetleri, uygulama güvenilirliğini desteklemek için dayanıklılık özellikleri sunar ancak bunlar yalnızca belirli bir SKU ve yapılandırma/dağıtımda uygulanabilir. Örneğin, SLA dağıtılan örneklerin sayısına veya etkinleştirilen belirli bir özelliğe bağlıdır. Kullanılan hizmetler için SLA'yı gözden geçirmeniz önerilir. Örneğin, Service Bus Premium SKU gürültülü komşu senaryolarını azaltmak için öngörülebilir gecikme süresi ve aktarım hızı sağlar. Ayrıca yük devretme amacıyla meta verileri otomatik olarak ölçeklendirme ve başka bir Service Bus örneğine çoğaltma olanağı sağlar.

Daha fazla bilgi edinmek için bkz. premium SKU Azure Service Bus.

Birden çok ve eşleştirilmiş bölge

Gereksinimlere göre bir uygulama platformu birden çok bölgeye dağıtılmalıdır. Bölgeleri kullanarak gereksinimlerin karşılanması daha ucuz ve daha az karmaşıktır. Tek bölgeli bölgeler arası kurulum tarafından verilen SLA'lar yetersizse veya kullanıcıların coğrafi olarak yayılması için gerekliyse bölgesel yalıtım ek bir ölçü olmalıdır.

Genel işlem platformu kullanılabilirliği ve uygulama dayanıklılığı için olağanüstü durum senaryolarına yanıt verebilme özelliği, birden çok bölgenin veya diğer dağıtım konumlarının kullanımına bağlıdır.

Aynı coğrafyada bulunan eşleştirilmiş bölgeleri kullanın ve Geo-Redundant Depolama (GRS) zaman uyumsuz çoğaltma gibi kurtarma amacıyla yerel çoğaltma özellikleri sağlayın. Planlı bakım durumunda, bir bölgede yapılan güncelleştirmeler yalnızca sırayla gerçekleştirilir. Daha fazla bilgi edinmek için bkz. Azure Eşleştirilmiş Bölgeleri ile iş sürekliliği.

Kullanılabilirlik Alanları ve kümeleri

Kullanılabilirlik Alanları yararlanabilen platform hizmetleri, belirli bir bölge içinde bölgesel bir şekilde veya birden çok bölgede alanlar arası yedekli bir yapılandırmada dağıtılır. Daha fazla bilgi edinmek için bkz. Kullanılabilirlik Alanları kullanarak yüksek kullanılabilirlik için çözümler oluşturma.

Kullanılabilirlik Kümesi (AS), Azure'a kapsanan sanal makine örneklerini bir Azure bölgesindeki birden çok hata ve güncelleştirme etki alanına dağıtması gerektiğini bildiren mantıksal bir yapıdır. Kullanılabilirlik Alanları (AZ), çoğaltma örneklerinin bir Azure bölgesindeki birden çok veri merkezine dağıtılabilmesini sağlayarak sanal makinelerin hata düzeyini fiziksel bir veri merkezine yükseltin. Bölgeler kümelere göre daha fazla dayanıklılık sağlarken, uygulamaların fiziksel ayrım ve bölgeler arası bant genişliği ücretleri dikkate alındığında bölgeler arasında son derece 'gevende' olduğu performans ve maliyet konusunda dikkat edilmesi gerekenler vardır. Sonuç olarak, Service Fabric ve Azure Kubernetes Service (AKS) gibi azure Sanal Makineler ve azure paas hizmetleri, bölge içinde uygulama dayanıklılığı sağlamak için AZ'lerden veya AS'lerden yararlanabilir. Daha fazla bilgi edinmek için bkz . Veri dayanıklılığı ile iş sürekliliği.

Kullanılabilirlik konusunda dikkat edilmesi gerekenler

Uygulama 2 veya daha fazla uygulama platformu düğümünde mi barındırılıyor?

Uygulama platformu güvenilirliğini sağlamak için, tek hata noktası olmadığından emin olmak için uygulamanın en az iki düğümde barındırılması çok önemlidir. İdeal olarak, işlem kullanılabilirliği için bir n+1 modeli uygulanmalıdır; burada n, uygulama kullanılabilirliğini ve performans gereksinimlerini desteklemek için gereken örnek sayısıdır.

Not

Sanal makineler ve ilişkili ilgili platform hizmetleri için sağlanan daha yüksek SLA'lar, bir Kullanılabilirlik Kümesine veya iki veya daha fazla Kullanılabilirlik Alanları dağıtılan en az iki çoğaltma düğümü gerektirir. Daha fazla bilgi edinmek için bkz. Sanal Makineler için SLA.

Bölge, bölge veya ağ kesintisi durumunda istemci trafiği uygulamaya nasıl yönlendirilir?

Büyük bir kesinti durumunda istemci trafiği, diğer bölgelerde veya bölgelerde kullanılabilir durumda kalan uygulama dağıtımlarına yönlendirilebilir olmalıdır. Sonuçta, uygulamanın iç ve/veya dış kullanıma yönelik olup olmadığına bağlı olarak, şirket içi bağlantı ve genel yük dengelemenin kullanılması gerekir. Azure Front Door, Azure Traffic Manager veya üçüncü taraf CDN'ler gibi hizmetler, sistem durumu yoklamaları aracılığıyla talep edilen uygulama durumu temelinde trafiği bölgeler arasında yönlendirebilir. Daha fazla bilgi için bkz. Traffic Manager uç nokta izleme.

Veri platformu gereksinimlerini karşılama

Veri ve depolama hizmetleri yüksek oranda kullanılabilir bir yapılandırmada/SKU'da çalıştırılmalıdır. Azure veri platformu hizmetleri, uygulama güvenilirliğini desteklemek için dayanıklılık özellikleri sunar ancak bunlar yalnızca belirli bir SKU'da uygulanabilir. Örnek olarak Azure SQL Veritabanı İş Açısından Kritik SKU'ları veya kullanılabilirlik alanlarına yayılmış üç zaman uyumlu çoğaltmaya sahip Azure Depolama Bölgesi Yedekli Depolama (ZRS) verilebilir.

Veri tutarlılığı

Veri türleri, veri tutarlılığı gereksinimlerine göre kategorilere ayrılmış olmalıdır. Güçlü veya nihai tutarlılık gibi veri tutarlılığı gereksinimleri, tüm veri türleri için anlaşılmalı ve veri gruplandırma ve kategorilere ayırmayı bilgilendirmenin yanı sıra uygulama güvenilirlik hedeflerini karşılamak için hangi veri çoğaltma/eşitleme stratejilerinin dikkate alınabileceği konusunda bilgi verilmelidir.

CAP teorem, dağıtılmış bir veri deposunun aynı anda ikiden fazla garanti sağlamanın mümkün olmadığını kanıtlar:

  • Tutarlı -lık: Her okuma en son yazma veya hata alır.
  • Kullanılabilir -lik: Her istek, en son yazma işlemini içerdiği garanti edilmeden hata olmayan bir yanıt alır.
  • Bölüm toleransı: Bir sistem, düğümler arasında ağ tarafından bırakılan veya geciken rastgele işlem sayısına rağmen çalışmaya devam eder.

Uygulama gereksinimleri bağlamında bu garantilerden hangisinin en önemli olduğunu belirlemek kritik önem taşır.

Çoğaltma ve Yedeklilik

Verilerin bölgeler veya eşleştirilmiş bölgeler arasında çoğaltılması, hata senaryolarının etkisini sınırlamak için uygulama kullanılabilirliği hedeflerini destekler. Veri bozulması durumlarının yanı sıra hata senaryolarından kurtarılırken yedekten verileri geri yükleyebilme özelliği çok önemlidir. Bölgesel ve bölgesel hata senaryoları için yeterli yedeklilik ve kullanılabilirlik sağlamak için yedeklemelerin bölgeler ve/veya bölgeler arasında depolanması gerekir.

Tutarlı bir uygulama durumu sağlamak için veri geri yükleme işlemini tanımlayın ve test edin. Veri geri yükleme işleminin düzenli olarak test edilebilmesi, operasyonel mükemmelliği ve uygulama için tanımlanan kurtarma hedeflerine uygun olarak verileri kurtarma becerisine olan güveni teşvik eder.

Bölge, bölge veya ağ kesintisi durumunda uygulama trafiğinizin veri kaynaklarına nasıl yönlendirilmiş olduğunu düşünün. Büyük bir hata olayı durumunda uygulama trafiğini veri kaynaklarına yönlendirmek için kullanılan yöntemi anlamak, yük devretme işlemlerinin kurtarma hedeflerini karşılayıp karşılamayacağını belirlemek için kritik öneme sahiptir. Birçok Azure veri platformu hizmeti, Azure Cosmos DB Otomatik Yük Devretme veya Azure SQL Veritabanı Etkin Coğrafi Çoğaltma gibi önemli hataları işlemek için yerel güvenilirlik özellikleri sunar.

Not

Azure Depolama RA-GRS ve Azure SQL DB Active Geo-Replication gibi bazı özellikler, bazı hata senaryolarında alternatif uç noktalara uygulama tarafı yük devretme gerektirir, bu nedenle bu senaryoları işlemek için uygulama mantığı geliştirilmelidir.

Ağ ve bağlantı gereksinimleri

Bağlantı kullanılabilirliğini sağlamak ve Azure hizmetleriyle güvenilirliği artırmak için bu yönergeleri göz önünde bulundurun.

Bağlantı

  • Trafiği ve/veya yük devretmeyi bölgeler arasında dağıtmak için kullanılan genel yük dengeleyiciyi kullanın. Azure Front Door, Azure Traffic Manager veya üçüncü taraf CDN hizmetleri, gelen istekleri birden çok bölgede dağıtılan dış kullanıma yönelik uygulama uç noktalarına yönlendirmek için kullanılabilir. Traffic Manager'ın DNS tabanlı bir yük dengeleyici olduğunu, bu nedenle yük devretmenin DNS yayılımının gerçekleşmesini beklemesi gerektiğini unutmayın. DNS kayıtları için yeterince düşük bir TTL (Yaşam Süresi) değeri kullanılmalıdır, ancak tüm ISS'ler bunu kabul etmeyebilir. Saydam yük devretme gerektiren uygulama senaryoları için Azure Front Door kullanılmalıdır. Daha fazla bilgi edinmek için bkz. Azure Traffic Manager ve Azure Front Door yönlendirme mimarisinikullanarak Olağanüstü Durum Kurtarma.

  • Şirket içi ağlar arası bağlantı (ExpressRoute veya VPN) için farklı konumlardan yedekli bağlantılar olduğundan emin olun. Tek hata noktası olmadığından emin olmak için iki veya daha fazla Azure bölgesinde ve eşleme konumunda en az iki yedekli bağlantı kurulmalıdır. Etkin/etkin yük paylaşımlı yapılandırma, yol çeşitliliği sağlar ve ağ bağlantısı yollarının kullanılabilirliğini teşvik eder. Daha fazla bilgi edinmek için bkz. Ağlar arası bağlantı.

  • Bağlantının alternatif yollar üzerinden kullanılabilir olduğundan emin olmak için hata yolunun benzetimini oluşturun. Bağlantının ve işletim verimliliğinin doğrulanması için bağlantı yolunun diğer bağlantı yollarında başarısız olup olmadığının test edilmesi gerekir. ExpressRoute için bir yedekleme yolu olarak Siteden Siteye VPN bağlantısının kullanılması, şirket içi ve dışı bağlantı için ek bir ağ dayanıklılığı katmanı sağlar. Daha fazla bilgi edinmek için bkz. ExpressRoute özel eşlemesi için yedek olarak siteden siteye VPN kullanma.

  • Veri yolundan (şirket içi ve Azure) tüm hata noktalarını ortadan kaldırın. İster Azure'da ister şirket içi bir veri merkezinde dağıtılan tek örnekli Ağ Sanal Gereçleri (NVA) önemli bağlantı riski oluşturur. Daha fazla bilgi edinmek için bkz. Yüksek oranda kullanılabilir ağ sanal gereçlerini dağıtma.

Bölge kullanan hizmetler

  • ExpressRoute/VPN alanlar arası yedekli Sanal Ağ Ağ Geçitlerini kullanın. Alanlar arası yedekli sanal ağ geçitleri, güvenilirliği artırmak ve bir bölgedeki veri merkezini etkileyen hata senaryoları sırasında kullanılabilirliği sağlamak için ağ geçidi örneklerini Kullanılabilirlik Alanları arasında dağıtır. Daha fazla bilgi edinmek için bkz. Alanlar arası yedekli Sanal Ağ Ağ Geçitleri.

  • Kullanılırsa, alanlar arası yedekli bir yapılandırmada dağıtılan Azure Application Gateway v2'yi dağıtın. Azure Application Gateway v2, bölge içindeki bir veri merkezini etkileyen hata senaryoları sırasında güvenilirlik ve kullanılabilirliği artırmak amacıyla ağ geçidi örneklerini bölgeler arasında dağıtmak için alanlar arası yedekli bir yapılandırmada dağıtılabilir. Daha fazla bilgi edinmek için bkz. Alanlar arası yedekli Application Gateway v2.

  • Kullanılabilirlik Alanları genelinde trafiğin yükünü dengelemek için Azure Load Balancer Standard kullanın. Azure Load Balancer Standard, trafiği Kullanılabilirlik Alanları arasında dağıtmaya duyarlıdır. Ayrıca, güvenilirliği artırmak ve bölge içindeki bir veri merkezini etkileyen hata senaryoları sırasında kullanılabilirliği sağlamak için alanlar arası yedekli bir yapılandırmada yapılandırılabilir. Daha fazla bilgi edinmek için bkz. Standart Load Balancer ve Kullanılabilirlik Alanları.

  • Azure Load Balancer/Azure Uygulaması Ağ Geçitleri için sistem durumu yoklamalarını yapılandırın. Sistem durumu yoklamaları, Azure Load Balancer'ların trafiğin iyi durumda olmayan örneklere gönderilmesini önlemek için arka uç uç uç noktalarının sistem durumunu değerlendirmesine olanak tanır. Daha fazla bilgi edinmek için bkz. sistem durumu yoklamalarını Load Balancer.

  • Sistem durumu yoklamalarıyla kritik uygulama bağımlılıklarını değerlendirme. Bağımlılık hataları nedeniyle istekleri başarıyla işleyemeyen arka uç örneklerine trafik gönderilmemesi için özel sistem durumu yoklamaları, aşağı akış bileşenleri ve API'ler ve veri depoları gibi bağımlı hizmetler de dahil olmak üzere genel uygulama durumunu değerlendirmek için kullanılmalıdır. Daha fazla bilgi edinmek için bkz. Sistem Durumu Uç Noktası İzleme Düzeni.

Sonraki adım

Uygulama tasarımı

Ana makaleye Geri dön: Tasarım