Azure'da görev açısından kritik iş yüklerinin uygulama tasarımı

Bir uygulama tasarlarken hem işlevsel hem de işlevsel olmayan uygulama gereksinimleri kritik önem taşır. Bu tasarım alanı, uygulamanızı hatalara karşı dayanıklı hale getirmenize yardımcı olabilecek mimari desenlerini ve ölçeklendirme stratejilerini açıklar.

Önemli

Bu makale, Azure İyi Tasarlanmış Çerçeve'nin görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız, Görev Açısından Kritik İş Yükü Nedir? ile başlamanızı öneririz.

Ölçek birimi mimarisi

Bir çözümün tüm işlevsel yönleri, talepteki değişiklikleri karşılayacak şekilde ölçeklenebilmeli ve ideal olarak yüke yanıt verirken otomatik ölçeklendirme gerçekleştirebilmelidir. Bölümleme aracılığıyla uçtan uca ölçeklenebilirliği iyileştirmek ve ayrıca kapasite ekleme ve kaldırma sürecini standartlaştırmak için ölçek birimi mimarisi kullanmanızı öneririz. Ölçek birimi, bağımsız olarak ölçeklendirilebilen mantıksal bir birim veya işlevdir. Bir birim kod bileşenlerinden, uygulama barındırma platformlarından, ilgili bileşenleri kapsayan dağıtım damgalarından ve hatta çok kiracılı gereksinimleri desteklemek için aboneliklerden oluşabilir.

Tek tek kaynakların ve uygulamanın tamamının ölçek sınırlarını ele alması nedeniyle bu yaklaşımı öneririz. Bir ölçek birimi tek bir birim olarak dağıtılabildiği için karmaşık dağıtım ve güncelleştirme senaryolarına yardımcı olur. Ayrıca, kullanıcı trafiğini üniteye yönlendirmeden önce bir ünitedeki bileşenlerin belirli sürümlerini test edebilir ve doğrulayabilirsiniz.

Görev açısından kritik uygulamanızın çevrimiçi bir ürün kataloğu olduğunu varsayalım. Ürün açıklamalarını ve derecelendirmelerini işlemek için bir kullanıcı akışına sahiptir. Akış, açıklamaları ve derecelendirmeleri ve OAuth uç noktası, veri deposu ve ileti kuyrukları gibi destekleyici bileşenleri almak ve göndermek için API'leri kullanır. Durum bilgisi olmayan API uç noktaları, isteğe bağlı değişikliklere uyum sağlaması gereken ayrıntılı işlevsel birimleri temsil eder. Temel alınan uygulama platformunun da uygun şekilde ölçeklenebilmesi gerekir. Performans sorunlarını önlemek için aşağı akış bileşenlerinin ve bağımlılıklarının da uygun bir dereceye ölçeklendirilmesi gerekir. Ayrı ölçek birimleri olarak bağımsız olarak veya tek bir mantıksal birimin parçası olarak birlikte ölçeklendirilebilirler.

Örnek ölçek birimleri

Aşağıdaki görüntüde ölçek birimleri için olası kapsamlar gösterilmektedir. Kapsamlar mikro hizmet podlarından küme düğümlerine ve bölgesel dağıtım damgalarına kadar değişir.

Ölçek birimleri için birden çok kapsamı gösteren diyagram.

Tasarımla ilgili dikkat edilecek noktalar

• Kapsam. Ölçek biriminin kapsamı, ölçek birimleri ile bileşenleri arasındaki ilişki bir kapasite modeline göre tanımlanmalıdır. Performans için işlevsel olmayan gereksinimleri dikkate alın.

• Ölçek sınırları. Azure aboneliği ölçek sınırları ve kotalarının uygulama tasarımı, teknoloji seçenekleri ve ölçek birimlerinin tanımı üzerinde bir ilgisi olabilir. Ölçek birimleri, bir hizmetin ölçek sınırlarını atlamanıza yardımcı olabilir. Örneğin, bir ünitedeki AKS kümesinde yalnızca 1.000 düğüm varsa, bu sınırı 2.000 düğüme yükseltmek için iki birim kullanabilirsiniz.

• Beklenen yük. Çekirdek ölçek gereksinimlerini bilgilendirmek için her kullanıcı akışı için istek sayısını, beklenen en yüksek istek oranını (saniye başına istek sayısı) ve günlük/haftalık/mevsimsel trafik desenlerini kullanın. Ayrıca hem trafik hem de veri hacmi için beklenen büyüme desenlerini de dikkate alır.

• Kabul edilebilir düşük performans. Yüksek yanıt süresine sahip düşürülmüş bir hizmetin yük altında kabul edilebilir olup olmadığını belirleyin. Gerekli kapasiteyi modellerken, yükün altında çözümün gerekli performansı kritik bir faktördür.

• İşlevsel olmayan gereksinimler. Teknik ve iş senaryolarında dayanıklılık, kullanılabilirlik, gecikme süresi, kapasite ve gözlemlenebilirlik konusunda dikkat edilmesi gereken önemli noktalar vardır. Bu gereksinimleri anahtar uçtan uca kullanıcı akışları bağlamında analiz edin. Tasarım, karar alma ve teknoloji seçimlerinde kullanıcı akışı düzeyinde göreli esnekliğe sahip olursunuz.

Tasarım önerileri

• Ölçek biriminin kapsamını ve ölçeklendirilecek birimi tetikleyecek sınırları tanımlayın.

• Tüm uygulama bileşenlerinin bağımsız olarak veya diğer ilgili bileşenleri içeren bir ölçek biriminin parçası olarak ölçeklenebilmesini sağlayın.

• Kapasite modeline ve işlevsel olmayan gereksinimlere göre ölçek birimleri arasındaki ilişkiyi tanımlayın.

• Bölgesel uygulama kaynaklarının sağlanmasını, yönetilmesini ve çalışmasını heterojen ama birbirine bağımlı bir ölçek biriminde birleştirmek için bölgesel dağıtım damgası tanımlayın. Yük arttıkça, çözümü yatay olarak ölçeklendirmek için aynı Azure bölgesinde veya farklı bölgelerde ek damgalar dağıtılabilir.

• Ölçek birimi olarak bir Azure aboneliği kullanın, böylece tek bir abonelik içindeki ölçek sınırları ölçeklenebilirliği kısıtlamaz. Bu yaklaşım, önemli trafik hacmine sahip yüksek ölçekli uygulama senaryoları için geçerlidir.

• Hizmette düşüşü önlemek için yeterli kapasitenin en yoğun zamanlarda sağlandığından emin olmak için tanımlanan trafik desenleri etrafında gerekli kapasiteyi modelleyin. Alternatif olarak yoğun olmayan saatlerde kapasiteyi iyileştirin.

• Trafikteki doğal varyasyonların hizmette kabul edilemez bir düşüşe neden olmadığından emin olmak için ölçek genişletme ve ölçek küçültme işlemlerini yaparken gereken süreyi ölçün. Ölçeklendirme işlemi sürelerini operasyonel ölçüm olarak izleyin.

Not

Azure iniş bölgesinde dağıtım yaparken, iniş bölgesi aboneliğinin net bir yönetim sınırı sağlamak ve Gürültülü Komşu antipattern'ından kaçınmak için uygulamaya ayrılmış olduğundan emin olun.

Genel dağıtım

Yüksek oranda dağıtılmış herhangi bir ortamda hata oluşmasını önlemek mümkün değildir. Bu bölümde, birçok hata senaryolarını azaltmaya yönelik stratejiler sağlanır. Uygulamanın bölgesel ve bölge hatalarına dayanabilmesi gerekir. Yükün tüm bölgeler arasında dağıtılması için etkin/etkin bir modelde dağıtılması gerekir.

Görev açısından kritik uygulamalarda hataları planlama ve dayanıklılığı en üst düzeye çıkarma hakkında genel bir bakış elde etmek için bu videoyu izleyin:

Tasarımla ilgili dikkat edilecek noktalar

• Yedeklilik. Uygulamanızın birden çok bölgeye dağıtılması gerekir. Ayrıca, bir bölgede, veri merkezi düzeyinde hataya dayanıklılık sağlamak için kullanılabilirlik alanlarını kullanmanızı şiddetle öneririz. Kullanılabilirlik alanları, kullanılabilirlik alanları arasında 2 milisaniyeden kısa bir gecikme süresi çevresine sahiptir. Bölgeler arasında sık iletişim kuran iş yükleri için bu gecikme süresi, bölgeler arası veri aktarımı için bir performans cezasına neden olabilir.

• Aktif/aktif model. Kullanılabilirliği en üst düzeye çıkardığından ve daha yüksek bileşik hizmet düzeyi sözleşmesi (SLA) sağladığından etkin/etkin dağıtım stratejisi önerilir. Ancak, birçok uygulama senaryosu için veri eşitleme ve tutarlılık ile ilgili zorluklara neden olabilir. Artan maliyet ve mühendislik çalışmalarının dengelerini göz önünde bulundurarak veri platformu düzeyindeki zorlukları ele alın.

  Birden çok bulut sağlayıcısı arasında etkin/etkin dağıtım, tek bir bulut sağlayıcısındaki genel kaynaklara bağımlılığı azaltmanın bir yoludur. Ancak, çoklu bulut etkin/etkin dağıtım stratejisi, CI/CD sürecine önemli bir karmaşıklık getirir. Ayrıca, bulut sağlayıcıları arasındaki kaynak belirtimleri ve özellikleri arasındaki farklar göz önünde bulundurulduğunda, her bulut için özel dağıtım damgaları gerekir.

• Coğrafi dağılım. İş yükünün coğrafi veri yerleşimi, veri koruması ve veri saklama için uyumluluk gereksinimleri olabilir. Verilerin bulunması gereken belirli bölgeler olup olmadığını veya kaynakların dağıtılması gerekip gerekmediğini göz önünde bulundurun.

• Kaynak iste. Kullanıcıların veya bağımlı sistemlerin coğrafi yakınlığı ve yoğunluğu, tasarım kararlarını küresel dağıtım hakkında bilgilendirmelidir.

• Bağlantı. İş yüküne kullanıcılar veya dış sistemler tarafından nasıl erişileceği tasarımınızı etkiler. Uygulamanın genel İnternet üzerinden mi yoksa VPN veya Azure ExpressRoute devreleri kullanan özel ağlar üzerinden mi kullanılabilir olduğunu düşünün.

Platform düzeyinde tasarım önerileri ve yapılandırma seçenekleri için bkz . Uygulama platformu: Genel dağıtım.

Gevşek bir şekilde bağlanmış olay odaklı mimari

Bağlama, iyi tanımlanmış arabirimler aracılığıyla hizmetler arası iletişim sağlar. Gevşek bağlantı, bir uygulama bileşeninin bağımsız olarak çalışmasına olanak tanır. Mikroservisler mimari stili, görev-önemli gereksinimlerle tutarlıdır. Basamaklı hataları önleyerek yüksek kullanılabilirliği kolaylaştırır.

Gevşek bağlantı için, olay odaklı tasarımı uygulamanızı şiddetle öneririz. Bir aracı kullanarak eşzamansız mesaj işleme, dayanıklılığı artırabilir.

Zaman uyumsuz, olay odaklı iletişimi gösteren diyagram.

Bazı senaryolarda uygulamalar, iş hedeflerine bağlı olarak gevşek ve sıkı bağlamayı birleştirebilir.

Tasarımla ilgili dikkat edilecek noktalar

• Çalışma zamanı bağımlılıkları. Gevşek olarak bağlanmış hizmetler aynı işlem platformunu, programlama dilini, çalışma zamanını veya işletim sistemini kullanacak şekilde kısıtlanmamış olmalıdır.

• Ölçeklendirme. Hizmetlerin bağımsız olarak ölçeklendirilebilmesi gerekir. Altyapı ve platform kaynaklarının kullanımını iyileştirin.

• Hata toleransı. Hatalar ayrı olarak işlenmeli ve istemci işlemlerini etkilememelidir.

• İşlem bütünlüğü. Ayrı hizmetlerde gerçekleşen veri oluşturma ve kalıcılığın etkisini göz önünde bulundurun.

• Dağıtılmış izleme. Uçtan uca izleme karmaşık düzenleme gerektirebilir.

Tasarım önerileri

• Mikro hizmet sınırlarını kritik kullanıcı akışlarıyla hizalayın.

• Sürdürülebilir ölçek ve en uygun performansı desteklemek için mümkün olduğunda olay odaklı zaman uyumsuz iletişimi kullanın.

• Her iletinin doğru şekilde işlenmesini garanti etmek için tutarlılığı sağlamak amacıyla Giden Kutusu ve İşlem Oturumu gibi desenleri kullanın.

Uygulama kodunda dayanıklılık desenleri ve hata işleme

Görev açısından kritik bir uygulama, mümkün olduğunca çok hata senaryosunu ele almak için dayanıklı olacak şekilde tasarlanmalıdır. Bu dayanıklılık, hizmet kullanılabilirliğini ve güvenilirliğini en üst düzeye çıkarır. Uygulama, Geri Çekilmeli Yeniden Denemeler ve Devre Kesici gibi tasarım desenlerini kullanarak uygulayabileceğiniz kendi kendini iyileştirme yeteneklerine sahip olmalıdır.

Uygulama mantığında tam olarak azaltılamayan geçici olmayan hatalar için sistem durumu modelinin ve işlem sarmalayıcılarının düzeltici eylem gerçekleştirmesi gerekir. Uygulama kodu, sistem durumu modelini bilgilendirmek ve gerektiğinde sonraki sorun giderme veya kök neden analizini kolaylaştırmak için uygun izleme ve günlüğe kaydetmeyi içermelidir. Dağıtılmış izleme uygulamanız, bir hata meydana geldiğinde korelasyon kimliğini içeren kapsamlı bir hata iletisi sağlamak için gereklidir.

Application Insights gibi araçlar, uygulama izlerini sorgulamanıza, ilişkilendirmenize ve görselleştirmenize yardımcı olabilir.

Tasarımla ilgili dikkat edilecek noktalar

• Uygun yapılandırmalar. Geçici sorunların art arda hatalara neden olması sık karşılaşılan bir durum değildir. Örneğin, uygun geri alma olmadan yeniden deneme, bir hizmet kısıtlandığında sorunu daha da büyütüyor. Yeniden deneme gecikmelerini doğrusal olarak dağıtabilir veya artan gecikmelerle sıklığını azaltmak için katlanarak artırabilirsiniz.

• Sağlık göstergeleri. Uygulama bileşenlerinin sağlık durumunu almak için dış çözümlerin yoklayabileceği sağlık uç noktalarını kullanarak uygulama kodundaki işlevsel kontrolleri açığa çıkarabilirsiniz.

Tasarım önerileri

Dayanıklı uygulamalar için bazı yaygın yazılım mühendisliği desenleri şunlardır:

Desen	Özet
Kuyruk Tabanlı Yük Dengeleme	Tutarlı yük düzeylerini sağlamak için tüketicilerle istenen kaynaklar arasında bir arabellek sağlar. Tüketici istekleri kuyruğa alınırken, bir çalışan süreci bu istekleri, çalışanın belirlediği hızda ve istenen kaynağın işleme kapasitesine göre işler. Tüketiciler isteklerine yanıt bekliyorsa, ayrı bir yanıt mekanizması uygulamanız gerekir. En önemli etkinliklerin önce gerçekleştirilmesi için öncelikli bir sipariş uygulayın.
Devre Kesici	Uzak bir hizmetin veya kaynağın kullanılabilirliğini beklerken engelleme yapmak yerine, kurtarma sürecini bekleyerek veya istekleri hızla reddederek kararlılık sağlar. Bu düzen, uzak bir hizmete veya kaynağa bağlantı yapıldığında kurtarılması değişken bir süre sürebilecek hataları da işler.
Bölme Perdesi	Hizmet işlevlerini sürdürmek için hataları yalıtarak yük ve kullanılabilirlik gereksinimlerine göre hizmet örneklerini gruplara ayırmaya çalışır.
Saga	Hizmetlerin tanımlı olay veya ileti kanalları aracılığıyla birbirini güncelleştirmesini sağlayarak bağımsız veri depoları olan mikro hizmetler genelinde veri tutarlılığını yönetir. Her hizmet kendi durumunu güncelleştirmek için yerel işlemler gerçekleştirir ve bir olay yayımlayarak destandaki bir sonraki yerel işlemi tetikler. Bir hizmet güncelleştirmesi başarısız olursa, saga, önceki hizmet güncelleştirme adımlarını telafi etmek için telafi işlemleri çalıştırır. Tek tek servis güncelleme adımları, yeniden deneme gibi dayanıklılık şablonları uygulayabilir.
Sağlık Uç Nokta İzleme	Dış araçların belirli aralıklarla kullanıma sunulan uç noktalar üzerinden erişebildiği bir uygulamada işlevsel denetimler uygular. Uygulama durumunu bilgilendirmek ve uyarı oluşturma veya telafi geri alma dağıtımı gerçekleştirme gibi işlemsel yanıtları tetikleme amacıyla önemli işletimsel ölçümleri kullanarak uç noktalardan gelen yanıtları yorumlayabilirsiniz.
Yeniden dene	Geçici hataları zarif ve şeffaf bir şekilde işler. - Hatanın geçici olma olasılığı düşükse ve işlem yeniden denenirse başarılı olma olasılığı düşükse iptal edin. - Hatanın olağan dışı veya nadir olup olmadığını ve hemen yeniden denenirse işlemin başarılı olma olasılığının yüksek olup olmadığını yeniden deneyin. - Hatanın kurtarılması kısa bir süre gerekebilecek bir koşuldan kaynaklanıyorsa (ağ bağlantısı veya yüksek yük hataları gibi) gecikmeden sonra yeniden deneyin. Yeniden deneme gecikmeleri arttıkça uygun bir geri dönüş stratejisi uygulayın.
Kısma	Uygulama bileşenleri tarafından kullanılan kaynakların tüketimini denetleyerek aşırı yüklenmelerine karşı korur. Bir kaynak yük eşiğine ulaştığında, düşük öncelikli işlemleri ve temel olmayan işlevleri düşürerek, temel işlevlerin normal çalışmaya geri dönmek için yeterli kaynak sağlanana kadar devam edebilmesini sağlar.

Bazı ek öneriler şunlardır:

• Bağımlı hizmetlere bağlanmak için Azure SDK'ları gibi satıcı tarafından sağlanan SDK'ları kullanın. Özel işlevsellik uygulamak yerine yerleşik dayanıklılık özelliklerini kullanın.

• Kendi kendine uygulanan bir DDoS senaryosundan kaçınmak için başarısız bağımlılık çağrılarını yeniden denerken uygun bir geri alma stratejisi uygulayın.

• Uygulama düzeyinde dayanıklılık desenlerinin kullanımında tutarlılık ve hız sağlamak için tüm uygulama mikro hizmet ekipleri için ortak mühendislik ölçütlerini tanımlayın.

• C# için Polly veya Java için Sentinel gibi kanıtlanmış standartlaştırılmış paketleri kullanarak dayanıklılık desenleri uygulamayı göz önünde bulundurun. Ayrıca, NServiceBus veya MassTransit gibi mesajlaşma çerçeveleri, ek güvenilirlik koduna ihtiyaç duymaktan kaçınmaya yardımcı olan yerleşik dayanıklılık özellikleri sağlar.

• Tüm izleme olayları ve günlük iletilerini belirli bir isteğe bağlamak için bağıntı kimliklerini kullanın. Yalnızca başarısız istekler için değil, tüm çağrılar için çağıranın bağıntı kimliklerini döndürür.

• Tüm günlük iletileri için yapılandırılmış günlükleri kullanın. Operatörlerin sorunları kolayca çözmesini sağlamak için uygulama izlemeleri, ölçümler ve günlükler için birleşik bir operasyonel veri havuzu seçin. Daha fazla bilgi için bkz Bulut uygulamaları için izleme verilerini toplama, birleştirme ve depolama.

• Operasyonel verilerin iş gereksinimleriyle birlikte uygulama sağlığı modelini bilgilendirmek için kullanıldığından emin olun.

Programlama dili seçimi

Doğru programlama dillerini ve çerçevelerini seçmek önemlidir. Bu kararlar genellikle kuruluştaki beceri kümelerine veya standartlaştırılmış teknolojilere göre belirlenir. Ancak, çeşitli dil ve çerçevelerin performansını, dayanıklılığını ve genel özelliklerini değerlendirmek önemlidir.

Tasarımla ilgili dikkat edilecek noktalar

• Geliştirme seti özellikleri. Azure hizmet SDK'ları tarafından çeşitli dillerde sunulan özelliklerde farklılıklar vardır. Bu farklılıklar, Azure hizmeti veya programlama dili seçiminizi etkileyebilir. Örneğin, Azure Cosmos DB uygulanabilir bir seçenekse Go, birinci taraf SDK olmadığından uygun bir geliştirme dili olmayabilir.

• Özellik güncelleştirmeleri. SDK'nın seçilen dil için yeni özelliklerle ne sıklıkta güncelleştirildiğinden emin olun. .NET ve Java kitaplıkları gibi yaygın kullanılan SDK'lar sık güncelleştirilir. Diğer diller için diğer SDK'lar veya SDK'lar daha az sıklıkta güncelleştirilebilir.

• Birden çok programlama dili veya çerçeve. Çeşitli bileşik iş yüklerini desteklemek için birden çok teknoloji kullanabilirsiniz. Ancak, yönetim karmaşıklığı ve operasyonel zorluklara neden olduğundan yayılmaktan kaçınmalısınız.

• İşlem seçeneği. Eski veya özel yazılımlar PaaS hizmetlerinde çalışmayabilir. Ayrıca, eski veya özel yazılımları kapsayıcılara ekleyemeyebilirsiniz.

Tasarım önerileri

• İhtiyacınız olan özellikler ve seçtiğiniz programlama dilleri için tüm ilgili Azure SDK'larını değerlendirin. İşlevsel olmayan gereksinimlerle hizalamayı doğrulayın.

• Programlama dillerinin ve çerçevelerinin seçimini mikro hizmet düzeyinde iyileştirin. Birden çok teknolojiyi uygun şekilde kullanın.

• Güvenilirliği ve performansı iyileştirmek için .NET SDK'sının önceliğini belirleyin. .NET Azure SDK'ları genellikle daha fazla özellik sağlar ve sık sık güncelleştirilir.

Sonraki adım

Uygulama platformuyla ilgili dikkat edilmesi gerekenleri gözden geçirin.

Uygulama platformu