Ölçeklenebilir bulut uygulamaları ve site güvenilirliği mühendisliği (SRE)

Bulut çözümünüzün başarısı güvenilirliğine bağlıdır. Güvenilirlik, sistemin belirtilen ortam koşullarında belirtilen süre içinde beklendiği gibi çalışma olasılığı olarak geniş bir şekilde tanımlanabilir. Site güvenilirlik mühendisliği (SRE), ölçeklenebilir ve son derece güvenilir yazılım sistemleri oluşturmaya yönelik bir dizi ilke ve uygulamadır. SRE, daha fazla güvenilirlik sağlamak için dijital hizmetlerin tasarımı sırasında giderek daha fazla kullanılmaktadır.

SRE stratejileri hakkında daha fazla bilgi için bkz . AZ-400: Site Güvenilirlik Mühendisliği (SRE) stratejisi geliştirme.

Olası kullanım örnekleri

Bu makaledeki kavramlar şunlar için geçerlidir:

• API tabanlı bulut hizmetleri.
• Genel kullanıma yönelik web uygulamaları.
• IoT tabanlı veya olay tabanlı iş yükleri.

Mimari

Bu mimarinin PowerPoint dosyasını indirin.

Burada göz önünde bulundurulan mimari, ölçeklenebilir bir API platformudur. Çözüm, Dynamics 365 ve Microsoft 365 gibi hizmet olarak yazılım (SaaS) çözümleri de dahil olmak üzere çeşitli veritabanlarını ve depolama hizmetlerini kullanan birden çok mikro hizmet içerir.

Bu makalede, diyagramda gösterilen blokları göstermek için üst düzey market ve e-ticaret kullanım örneklerini işleyen bir çözüm ele alınmaktadır. Kullanım örnekleri şunlardır:

• Ürüne göz atma.
• Kayıt ve oturum açma.
• Haber makaleleri gibi içerikleri görüntüleme.
• Sipariş ve abonelik yönetimi.

Web uygulamaları, mobil uygulamalar ve hatta hizmet uygulamaları gibi istemci uygulamaları, API platform hizmetlerini birleşik bir erişim yolu https://api.contoso.comaracılığıyla kullanır.

Bileşenler

• Azure Front Door , çözüme yönelik tüm istekler için güvenli, birleşik bir giriş noktası sağlar. Daha fazla bilgi için bkz . Yönlendirme mimarisine genel bakış.
• Azure API Management , yayımlanan tüm API'lerin üzerinde bir idare katmanı sağlar. Azure API Management ilkelerini kullanarak API katmanına erişim kısıtlamaları, önbelleğe alma ve veri dönüştürme gibi ek özellikler uygulayabilirsiniz. API Management, standart ve premium katmanlarda otomatik ölçeklendirmeyi destekler.
• Azure Kubernetes Service (AKS), açık kaynak Kubernetes kümelerinin Azure uygulamasıdır. Azure, barındırılan bir Kubernetes hizmeti olarak sistem durumu izleme ve bakım gibi kritik görevleri üstlenir. Kubernetes ana yöneticileri Azure tarafından yönetildiğinden yalnızca aracı düğümlerini yönetir ve korursunuz. Bu mimaride tüm mikro hizmetler AKS'de dağıtılır.
• Azure Uygulaması lication Gateway bir uygulama teslim denetleyicisi hizmetidir. Uygulama katmanı olan 7. katmanda çalışır ve çeşitli yük dengeleme özelliklerine sahiptir. Application Gateway Giriş Denetleyicisi (AGIC), Azure Kubernetes Service (AKS) müşterilerinin bulut yazılımını İnternet'te kullanıma sunmak için Azure'ın yerel Application Gateway L7 yük dengeleyicisini kullanmasını mümkün kılan bir Kubernetes uygulamasıdır. Otomatik ölçeklendirme ve bölge yedekliliği v2 SKU'da desteklenir.
• Azure Depolama, Azure Data Lake Depolama, Azure Cosmos DB ve Azure SQL hem yapılandırılmış hem de yapılandırılmamış içeriği depolayabilir. Azure Cosmos DB kapsayıcıları ve veritabanları, otomatik ölçeklendirme aktarım hızıyla oluşturulabilir.
• Microsoft Dynamics 365 , Microsoft'un müşteri hizmetleri, satış, pazarlama ve finans için çeşitli iş uygulamaları sağlayan bir hizmet olarak yazılım (SaaS) teklifidir. Bu mimaride Dynamics 365 öncelikle ürün kataloglarını yönetmek ve müşteri hizmetleri yönetimi için kullanılır. Ölçek birimleri Dynamics 365 uygulamalarına dayanıklılık sağlar.
• Microsoft 365 (eski adıyla Office 365), Office 365 SharePoint Online'da oluşturulmuş bir kurumsal içerik yönetim sistemi olarak kullanılır. Medya varlıkları ve belgeler gibi içerikleri oluşturmak, yönetmek ve yayımlamak için kullanılır.

Alternatifler

Bu çözüm yüksek oranda ölçeklenebilir bir mikro hizmet tabanlı mimari kullandığından işlem düzlemi için şu alternatifleri göz önünde bulundurun:

• Sunucusuz API hizmetleri için Azure İşlevleri
• Java tabanlı mikro hizmetler için Azure Spring Apps

Uygun güvenilirlik

Çözüm için gereken güvenilirlik derecesi, iş bağlamlarına bağlıdır. 14 saat açık olan ve bu süre içinde sistem kullanımı en üst düzeyde olan bir perakende satış mağazasının gereksinimleri, her saat sipariş kabul eden bir çevrimiçi işletmeden farklı gereksinimlere sahiptir. SRE uygulamaları uygun güvenilirlik düzeyine ulaşmak için uyarlanabilir.

Güvenilirlik, bir hizmet için hedef güvenilirlik düzeyini tanımlayan hizmet düzeyi hedefleri (hizmet düzeyi hedefleri (SLO)) kullanılarak tanımlanır ve ölçülür. Hedef düzeye ulaşmak, tüketicilerin memnun olduğunu güvence altına alır. SLO hedefleri, işletmenin taleplerine bağlı olarak gelişebilir veya değişebilir. Ancak hizmet sahipleri sorunları algılamak ve düzeltici eylemler uygulamak için sürekli olarak SLO'lara karşı güvenilirliği ölçmelidir. SLO'lar genellikle bir dönem içindeki başarı yüzdesi olarak tanımlanır.

Dikkat edilmesi gereken bir diğer önemli terim de , SLO'nun hesaplanmasında kullanılan ölçüm olan hizmet düzeyi göstergesidir (hizmet düzeyi göstergesi (SLI). SLI'ler, müşteri hizmeti tükettiğinde yakalanan verilerden türetilen içgörüleri temel alır. SLI'ler her zaman müşterinin bakış açısından ölçülür.

SLO'lar ve SLI'ler her zaman el ele gider ve genellikle yinelemeli bir şekilde tanımlanır. SLO'lar önemli iş hedeflerine göre yönlendirilirken, SLI'ler hizmeti uygularken ölçülebilecek öğeler tarafından yönlendirilir.

İzlenen ölçüm, SLI ve SLO arasındaki ilişki aşağıda gösterilir:

Bu, SLO'ları hesaplamak için SLI ölçümlerini tanımlama bölümünde daha ayrıntılı olarak açıklanmıştır.

Ölçek ve performans beklentilerini modelleme

Bir yazılım sistemi için performans genellikle bir eylemi belirli bir süre içinde yürütürken sistemin genel yanıt verme hızını ifade ederken, ölçeklenebilirlik sistemin performansı incitmeden artan kullanıcı yüklerini işleyebilmesidir.

Temel alınan kaynaklar yük artışını desteklemek üzere dinamik olarak kullanılabilir hale getirildiğinde sistem ölçeklenebilir olarak kabul edilir. Bulut uygulamalarının ölçek için tasarlanması gerekir ve trafik hacmini zaman zaman tahmin etmek zordur. Mevsimsel ani artışlar, özellikle bir hizmet birden çok kiracıya yönelik istekleri işlediğinde ölçek gereksinimlerini artırabilir.

Bulut kaynaklarının yükü karşılamak için gerektiğinde ölçeği otomatik olarak artırıp azaltacak şekilde uygulamalar tasarlamak iyi bir uygulamadır. Temel olarak sistem, talebi karşılamak için kaynakları artımlı bir şekilde sağlayarak veya ayırarak iş yükü artışına uyum sağlamalıdır. Ölçeklenebilirlik yalnızca işlem örnekleriyle değil, veri depolama ve mesajlaşma altyapısı gibi diğer öğelerle de ilgilidir.

Bu makalede, iş yükü senaryolarının ölçek ve performans modellemesini gerçekleştirerek ve sonuçları kullanarak izleyicileri, SLI'leri ve SLO'ları tanımlayarak bulut uygulaması için uygun güvenilirliği nasıl sağlayabileceğiniz gösterilmektedir.

Dikkat edilmesi gereken noktalar

Ölçeklenebilir ve güvenilir uygulamalar oluşturmaya ilişkin yönergeler için Azure Well Architected Framework'ünGüvenilirlik ve Performans Verimliliği sütunlarına bakın.

Bu makalede, çözüm mimarisi ve tasarımında ince ayar yapmak için ölçeklenebilirlik ve performans modelleme tekniklerinin nasıl uygulanacağı incelenmektedir. Bu teknikler, en iyi kullanıcı deneyimi için işlem akışlarında yapılan değişiklikleri tanımlar. Teknik kararlarınızı çözümün işlevsel olmayan gereksinimlerine dayandırın. Süreç şu şekildedir:

• Ölçeklenebilirlik gereksinimlerini belirleyin.
• Beklenen yükü modelle.
• Kullanıcı senaryoları için SLI'leri ve SLO'ları tanımlayın.

Ölçeklenebilirlik gereksinimlerini yakalama

Şu en yüksek yük ölçümlerini varsayın:

• API Platformunu kullanan tüketici sayısı: 1,5 milyon
• Saatlik etkin tüketiciler (1,5 milyonun yüzde 30'luk kısmı): 450.000
• Her etkinlik için yük yüzdesi:
  • Ürüne göz atma: yüzde 75
  • Profil oluşturma ve oturum açma dahil olmak üzere kayıt: yüzde 10
  • Siparişlerin ve aboneliklerin yönetimi: yüzde 10
  • İçerik görüntüleme: Yüzde 5

Yük, platform tarafından barındırılan API'ler için normal en yüksek yük altında aşağıdaki ölçek gereksinimlerini oluşturur:

• Ürün mikro hizmeti: saniyede yaklaşık 500 istek (RPS)
• Profil mikro hizmeti: yaklaşık 100 RPS
• Siparişler ve ödeme mikro hizmeti: yaklaşık 100 RPS
• İçerik mikro hizmeti: yaklaşık 50 RPS

Bu ölçek gereksinimleri, mevsimsel ve rastgele zirveleri ve pazarlama promosyonları gibi özel etkinlikler sırasındaki zirveleri dikkate almaz. Zirveler sırasında, bazı kullanıcı etkinlikleri için ölçek gereksinimi normal tepe yükünün 10 katına kadardır. Mikro hizmetler için tasarım seçimlerini yaparken bu kısıtlamaları ve beklentileri göz önünde bulundurun.

SLO'ları hesaplamak için SLI ölçümlerini tanımlama

SLI ölçümleri, bir hizmetin ne derece tatmin edici bir deneyim sağladığını gösterir ve iyi olayların toplam olaylara oranı olarak ifade edilebilir.

Bir API hizmeti için olaylar, telemetri veya işlenmiş veri olarak yürütme sırasında yakalanan uygulamaya özgü ölçümlere başvurur. Bu örnekte aşağıdaki SLI ölçümleri vardır:

SLI örnekleri şunlardır:

• (1.000 ms'den kısa sürede başarıyla tamamlanan istek sayısı) / (İstek sayısı)
• (Üç saniye içinde katalogda yayımlanan tüm ürünlerin döndüreceği arama sonuçlarının sayısı) / (Arama sayısı)

SLI'leri tanımladıktan sonra, bunları ölçmek için hangi olayların veya telemetrinin yakalandığını belirleyin. Örneğin, kullanılabilirliği ölçmek için, API hizmetinin bir isteği başarıyla işleyip işlemediğini belirtmek için olayları yakalarsınız. HTTP tabanlı hizmetler için başarı veya başarısızlık HTTP durum kodlarıyla gösterilir. API tasarımı ve uygulaması uygun kodları sağlamalıdır. Genel olarak, SLI ölçümleri API uygulaması için önemli bir giriştir.

Bulut tabanlı sistemler için, kaynaklar için kullanılabilen tanılama ve izleme desteğini kullanarak ölçümlerin bazılarını alabilirsiniz. Azure İzleyici, bulut hizmetlerinizden telemetri verilerini toplamak, analiz etmek ve üzerinde hareket etmek için kapsamlı bir çözümdür. SLI gereksinimlerinize bağlı olarak, ölçümleri hesaplamak için daha fazla izleme verisi yakalanabilir.

Yüzdebirlik dağıtımları kullanma

Bazı SLI'ler yüzdebirlik dağıtım tekniği kullanılarak hesaplanır. Ortalama veya ortanca dağılımlar gibi diğer teknikleri çarpıtabilen aykırı değerler varsa bu daha iyi sonuçlar verir.

Örneğin ölçümün API isteklerinin gecikme süresi olduğunu ve en iyi performans için üç saniyenin eşik olduğunu düşünün. Bir saatlik API isteklerinin sıralanmış yanıt süreleri, birkaç isteğin üç saniyeden uzun sürdüğünü ve çoğu yanıtın eşik sınırı içinde alındığını gösterir. Bu, sistemin beklenen davranışıdır.

Yüzdebirlik dağılımı, aralıklı sorunların neden olduğu aykırı değerleri dışlamaya yöneliktir. Örneğin, uygun hizmet yanıtları 90. veya 95. yüzdebirlik dilimdeyse, SLO'nun karşılandığı kabul edilir.

Uygun ölçüm dönemlerini seçin

SLO tanımlamak için ölçüm süresi çok önemlidir. Sonuçların kullanıcı deneyimi için anlamlı olması için boşta kalma değil etkinliği yakalaması gerekir. Bu pencere, SLI ölçümünü nasıl izlemek ve hesaplamak istediğinize bağlı olarak beş dakika ile 24 saat arasında olabilir.

Performans idaresi süreci oluşturma

Api'nin performansı kullanımdan kaldırılana veya kullanımdan kaldırılana kadar api'nin başlangıcından yönetilmelidir. İşletmeyi etkileyen büyük bir kesintiye neden olmadan önce performans sorunlarının algılandığından ve düzeltildiğinden emin olmak için sağlam bir idare süreci uygulanmalıdır.

Performans idaresinin öğeleri şunlardır:

• Performans Hedefleri: İş senaryoları için hedefli performans SLO'larını tanımlayın.
• Performans Modelleme: İş açısından kritik iş akışlarını ve işlemleri tanımlayın ve performansla ilgili etkileri anlamak için modelleme gerçekleştirin. Daha doğru tahminler için bu bilgileri ayrıntılı bir düzeyde yakalayın.
• Tasarım Yönergeleri: Performans tasarımı yönergelerini hazırlayın ve uygun iş akışı değişikliklerini önerin. Ekiplerin bu yönergeleri anladığınızdan emin olun.
• Yönergeleri Uygulama: Ölçümleri yakalamak için izleme dahil olmak üzere çözüm bileşenleri için performans tasarımı yönergeleri uygulayın. Performans tasarımı gözden geçirmeleri gerçekleştirin. Farklı ekipler için mimari kapsamı öğelerini kullanarak bunların tümünü izlemek kritik önem taşır.
• Performans Testi: Platform durumuyla ilgili ölçümleri yakalamak için yük profili dağıtımına uygun yük ve stres testi gerçekleştirin. Ayrıca, çözüm altyapısı gereksinimlerini karşılaştırmak için sınırlı bir yük için bu testleri gerçekleştirebilirsiniz.
• Performans Sorunu Analizi: Çeşitli bileşenlerdeki performans sorunlarını belirlemek, analiz etmek ve kaldırmak için kod incelemesini ve kod incelemelerini kullanın. En yüksek yükleri desteklemek için gereken yatay veya dikey ölçeklendirme geliştirmelerini belirleyin.
• Sürekli İzleme: DevOps işlemlerinin bir parçası olarak sürekli izleme ve uyarı altyapısı oluşturun. Yanıt süreleri karşılaştırmalarla karşılaştırıldığında önemli ölçüde azaldığında ilgili ekiplere bildirildiğinden emin olun.
• Performans İdaresi: Performans SLO'larını sürdürmek için iyi tanımlanmış süreçler ve ekiplerden oluşan bir performans idaresi oluşturun. Derleme yükseltmeleri nedeniyle herhangi bir düşüşü önlemek için her sürümden sonra uyumluluğu izleyin. Çözüm yükseltmelerini belirlemek için artan yükleri değerlendirmek için düzenli aralıklarla incelemeler yapın.

Aşamalı detaylandırma sürecinin bir parçası olarak çözüm geliştirme sürecinde adımları yinelediğinden emin olun.

Kapsamınızdaki performans hedeflerini ve beklentilerini izleme

Ulaşıldıklarından emin olmak için performans hedeflerinizi izleyin. İzlenmek için ayrıntılı ve ayrıntılı kullanıcı hikayeleri yakalayın. Bu, geliştirme ekiplerinin performans idaresi etkinliklerini yüksek öncelikli hale getirmelerine yardımcı olur.

Hedef çözüm için aspirasyonel SLO'lar oluşturma

Api platformu çözümü için dikkate alınması gereken örnek aspirational SLO'lar aşağıda verilmiştir:

• Bir gün içinde bir saniye içinde tüm OKUMA isteklerinin yüzde 95'ini yanıtlar.
• Bir gün içindeki tüm CREATE ve UPDATE isteklerinin yüzde 95'ini üç saniye içinde yanıtlar.
• Beş saniye içinde bir gün içindeki tüm isteklerin yüzde 99'unun hatasız yanıt verir.
• Bir gün içindeki tüm isteklerin yüzde 99,9'una beş dakika içinde başarıyla yanıt verir.
• En yoğun bir saatlik zaman penceresi hatası sırasında isteklerin yüzde birinden azı dışarı.

SLO'lar belirli uygulama gereksinimlerine göre uyarlanabilir. Ancak, güvenilirlik sağlamak için netliğe sahip olmak için yeterince ayrıntılı olmak kritik önem taşır.

Günlüklerden alınan verileri temel alan ilk SLO'ları ölçme

İzleme günlükleri, API hizmeti kullanımda olduğunda otomatik olarak oluşturulur. Bir haftalık verilerin aşağıdakileri gösterdiğini varsayın:

• İstekler: 123.456
• Başarılı istekler: 123.204
• 90. yüzdebirlik gecikme süresi: 497 ms
• 95. yüzdebirlik gecikme süresi: 870 ms
• 99. yüzdebirlik gecikme süresi: 1.024 ms

Bu veriler aşağıdaki ilk SLI'leri oluşturur:

• Kullanılabilirlik = (123.204 / 123.456) = yüzde 99,8
• Gecikme süresi = isteklerin en az yüzde 90'ının 500 ms içinde sunulduğu
• Gecikme süresi = isteklerin yaklaşık yüzde 98'i 1000 ms içinde servis edildi

Planlama sırasında istek gecikme süresi SLO hedefinin, isteklerin yüzde 90'ının 500 ms içinde işlendiğini ve bir hafta içinde yüzde 99 başarı oranına sahip olduğunu varsayalım. Günlük verileriyle SLO hedefinin karşılanıp karşılanmadığını kolayca belirleyebilirsiniz. Bu tür bir analizi birkaç hafta boyunca yaparsanız SLO uyumluluğuyla ilgili eğilimleri görmeye başlayabilirsiniz.

Teknik risk azaltma kılavuzu

Ölçeklenebilirlik ve performans risklerini azaltmak için aşağıdaki önerilen uygulamalar denetim listesini kullanın:

• Ölçek ve performans için tasarım.
  • Mevsimsellik ve zirveler de dahil olmak üzere her kullanıcı senaryosu ve iş yükü için ölçek gereksinimlerini yakaladığınızı unutmayın.
  • Sistem kısıtlamalarını ve performans sorunlarını belirlemek için performans modellemesi gerçekleştirme
• Teknik borcu yönetme.
  • Performans ölçümlerinin kapsamlı izlemesini yapın.
  • Geliştirme hazırlama ortamınızda örneğin 50 ila 100 RPS olmak üzere çeşitli kullanıcı yüklemeleriyle K6.io, Karate ve JMeter gibi araçları çalıştırmak için betikleri kullanmayı göz önünde bulundurun. Bu, tasarım ve uygulama sorunlarını algılamak için günlüklerde bilgi sağlar.
  • Derleme sonlarını algılamak için otomatik test betiklerini sürekli dağıtım (CD) işlemlerinizin bir parçası olarak tümleştirin.
• Üretim anlayışına sahip olun.
  • Otomatik ölçeklendirme eşiklerini sistem durumu istatistiklerinde gösterildiği gibi ayarlayın.
  • Dikey yerine yatay ölçeklendirme tekniklerini tercih edin.
  • Mevsimselliği işlemek için ölçeklendirme konusunda proaktif olun.
  • Halka tabanlı dağıtımı tercih edin.
  • Deneme yapmak için hata bütçelerini kullanın.

Fiyatlandırma

Güvenilirlik, performans verimliliği ve maliyet iyileştirmesi el eledir. Mimaride kullanılan Azure hizmetleri, değişen kullanıcı yüklerini karşılamak için otomatik ölçeklendirme yaptıkları için maliyetlerin azaltılmasına yardımcı olur.

AKS için başlangıçta düğüm havuzu için standart boyutlu VM'lerle başlayabilirsiniz. Daha sonra geliştirme veya üretim kullanımı sırasında kaynak gereksinimlerini izleyebilir ve buna göre ayarlayabilirsiniz.

Maliyet iyileştirme, Microsoft Azure İyi Tasarlanmış Çerçeve'nin bir dayanağıdır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış. Azure ürünlerinin ve yapılandırmalarının maliyetini tahmin etmek için Fiyatlandırma hesaplayıcısını kullanın.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

• Subhajit Chatterjee | Baş Yazılım Mühendisi

Sonraki adımlar

• Azure belgeleri
• Microsoft Azure İyi Tasarlanmış Çerçeve
• Mikro hizmetler mimarisi stili
• Ölçeği genişletmek için tasarlama
• Uygulamanız için bir Azure işlem hizmeti seçme
• Tasarım ve uygulama desenleri
• Azure Kubernetes Service'te mikro hizmetler mimarisi
• Azure Front Door nedir?
• API Yönetimi hakkında
• Application Gateway Giriş Denetleyicisi nedir?
• Azure Kubernetes Service
• Otomatik ölçeklendirme ve Alanlar arası yedekli Application Gateway v2
• Azure Kubernetes Service (AKS) ile bir kümeyi uygulama taleplerini karşılayacak şekilde otomatik olarak ölçeklendirme
• Otomatik ölçeklendirme aktarım hızıyla Azure Cosmos DB kapsayıcıları ve veritabanları oluşturma
• Microsoft Dynamics 365 belgeleri
• Microsoft 365 belgeleri
• Site güvenilirliği mühendisliği belgeleri
• AZ-400: Site Güvenilirlik Mühendisliği (SRE) stratejisi geliştirme

İlgili kaynaklar

• Alanlar arası yedekli temel web uygulaması
• Azure'da web uygulaması izleme