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 Well-Architected Framework 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 iş yükü nedir? ile başlamanızı öneririz.

Ölçek birimi mimarisi

Bir çözümün tüm işlevsel yönlerinin, talepteki değişiklikleri karşılamak için ölçeklendirme yapabilmesi gerekir. 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 bir mantıksal 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 alan bu yaklaşımı öneririz. Bir ölçek birimi tek bir birim olarak dağıtılabildiğinden karmaşık dağıtım ve güncelleştirme senaryolarında yardımcı olur. Ayrıca, kullanıcı trafiğini üniteye yönlendirmeden önce bir birimdeki 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şlev birimlerini 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.

Tasarım konusunda dikkat edilmesi gerekenler

• Kapsam. Ölçek biriminin kapsamı, ölçek birimleri arasındaki ilişki ve bileşenleri 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ı uygulama tasarımını, teknoloji seçimlerini ve ölçek birimlerinin tanımını dikkate alabilir. Ölçek birimleri, bir hizmetin ölçek sınırlarını atlamanıza yardımcı olabilir. Örneğin, bir birimdeki bir AKS kümesinde yalnızca 1.000 düğüm olabilirse, 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ı (saniyedeki 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üzeyi düşürülmüş bir hizmetin yük altında kabul edilebilir olup olmadığını belirleyin. Gerekli kapasiteyi modellerken, yük altındaki çö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 birimin ölçeklendirilmesini 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çeklenebildiğinden emin olun.

• 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.

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

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

• Trafikteki doğal değişimlerin kabul edilemez düzeyde hizmet düşüşü oluşturmadığından emin olmak için ölçeği genişletme ve ölçeği daraltma işlemleri yapmak için gereken süreyi ölçün. Ölçeklendirme işlemi sürelerini operasyonel ölçüm olarak izleyin.

Not

Bir Azure giriş bölgesinde dağıtım yaparken, giriş bölgesi aboneliğinin uygulamaya açık bir yönetim sınırı sağlamak ve Gürültülü Komşu kötü modelinden kaçınmak için 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ölgesel hatalara 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 bilgi edinmek için bu videoyu izleyin:

Tasarım konusunda dikkat edilmesi gerekenler

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

• Etkin/etkin 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 çabası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 çevresinde önemli miktarda karmaşıklık sağlar. 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ğıtım. İş yükü coğrafi veri yerleşimi, veri koruması ve veri saklama için uyumluluk gereksinimlerine sahip olabilir. Verilerin bulunması gereken belirli bölgeler olup olmadığını veya kaynakların dağıtılması gerekip gerekmediğini göz önünde bulundurun.

• İstek kaynağı. 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ı etkileyecektir. Uygulamanın genel İnternet üzerinden mi yoksa VPN veya Azure ExpressRoute bağlantı hatları 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ğlantı, iyi tanımlanmış arabirimler aracılığıyla hizmetler arası iletişime olanak tanır. Gevşek bağlantı, bir uygulama bileşeninin bağımsız olarak çalışmasına olanak tanır. Mikro hizmet mimarisi stili, görev açısından kritik gereksinimlerle tutarlıdır. Art arda hataları önleyerek yüksek kullanılabilirliği kolaylaştırır.

Gevşek bağlantı için , olay odaklı tasarımı birleştirmenizi kesinlikle öneririz. Bir aracı aracılığıyla zaman uyumsuz ileti işleme dayanıklılık oluşturabilir.

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

Tasarım konusunda dikkat edilmesi gerekenler

• Çalışma zamanı bağımlılıkları. Gevşek 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. Hizmetler bağımsız olarak ölçeklendirilebilmelidir. Altyapı ve platform kaynaklarının kullanımını iyileştirme.

• Hataya dayanıklılık. Hatalar ayrı ayrı işlenmeli ve istemci işlemlerini etkilememelidir.

• İşlem bütünlüğü. Ayrı hizmetlerde gerçekleşen veri oluşturma ve kalıcılık 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 iyi performansı desteklemek için mümkün olduğunda olay odaklı zaman uyumsuz iletişimi kullanın.

• Her iletinin doğru işlenmesi için tutarlılığı garanti etmek için Giden Kutusu ve İşlem Oturumu gibi desenleri kullanın.

Örnek: Olay odaklı yaklaşım

Görev Açısından Kritik Çevrimiçi başvuru uygulaması, tek bir iş işlemini işlemek için mikro hizmetleri kullanır. Yazma işlemlerini bir ileti aracısı ve çalışanı ile zaman uyumsuz olarak uygular. Okuma işlemleri zaman uyumludur ve sonuç doğrudan çağırana döndürülür.

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. Uygulamanın, Geri Alma ve Devre Kesiciile Yeniden Denemeler gibi tasarım desenlerini kullanarak uygulayabileceğiniz kendi kendini onarma özelliklerine sahip olması gerekir.

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. Bir hata oluştuğunda çağıranın bağıntı kimliğini içeren kapsamlı bir hata iletisi sağlamak için dağıtılmış izleme uygulamanız gerekir.

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

Tasarım konusunda dikkat edilmesi gerekenler

• 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 şiddetlenir. Yeniden deneme gecikmelerini doğrusal olarak uzayabilir veya artan gecikmelerden geri dönmek için katlanarak artırabilirsiniz.

• Sistem durumu uç noktaları. Dış çözümlerin uygulama bileşeni sistem durumu durumunu almak için yokladığı sistem durumu uç noktalarını kullanarak uygulama kodu içinde işlevsel denetimleri kullanıma sağlayabilirsiniz.

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 ekler. Tüketici istekleri kuyruğa alındıkçe, bir çalışan işlemi bunları çalışan tarafından ayarlanan bir hızda ve istenen kaynağın istekleri işleme yeteneğiyle istenen kaynağa karşı işler. Tüketiciler isteklerine yanıt bekliyorsa, ayrı bir yanıt mekanizması uygulamanız gerekir. Öncelikle en önemli etkinliklerin gerçekleştirilmesi için önceliklendirilmiş bir sıra uygulayın.
Devre Kesici	Kullanılabilir olmayan bir uzak hizmeti veya kaynağı beklerken kurtarmayı beklerken veya istekleri engellemek yerine hızlı bir şekilde reddederek kararlılık sağlar. Bu düzen, uzak bir hizmet veya kaynağa bağlantı yapıldığında kurtarılması uzun 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ına sahip mikro hizmetler arasında veri tutarlılığını yönetir. Her hizmet kendi durumunu güncelleştirmek için yerel işlemler gerçekleştirir ve saga'da sonraki yerel işlemi tetikleyen bir olay yayımlar. Bir hizmet güncelleştirmesi başarısız olursa saga, hizmet güncelleştirme adımlarından önce karşı koymak için telafi işlemleri çalıştırır. Tek tek hizmet güncelleştirme adımları, yeniden deneme gibi dayanıklılık düzenlerini kendileri uygulayabilir.
Sistem Durumu Uç Nokta İzleme	Dış araçların belirli aralıklarla kullanıma sunulan uç noktalar aracılığıyla erişebildiği bir uygulamada işlevsel denetimler uygular. Uygulama durumunu bildirmek ve uyarı oluşturma veya telafi edici bir geri alma dağıtımı gerçekleştirme gibi operasyonel yanıtları tetikleme amacıyla önemli işlem ölçümlerini kullanarak uç noktalardan gelen yanıtları yorumlayabilirsiniz.
Yeniden Deneme	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. - Hata olağan dışı veya nadirse yeniden deneyin ve hemen yeniden denenirse işlemin başarılı olma olasılığı yüksektir. - Hatanın kurtarılması için ağ bağlantısı veya yüksek yük hataları gibi kısa bir süre gerekebilecek bir koşuldan kaynaklandığında gecikmeden sonra yeniden deneyin. Yeniden deneme gecikmeleri arttıkça uygun bir geri dönüş stratejisi uygulayın.
Azaltma	Uygulama bileşenleri tarafından kullanılan kaynakların tüketimini denetleyerek aşırı kuvuz haline gelmesini engeller. Bir kaynak yük eşiğine ulaştığında, temel işlevlerin normal çalışmaya dönmek için yeterli kaynak sağlanana kadar devam edebilmesi için düşük öncelikli işlemleri ve temel olmayan işlevleri düşürür.

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şlevler 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 uygulayın.

• Belirli bir isteğe bağlamak için tüm izleme olayları ve günlük iletileri 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üğe kaydetmeyi kullanın. İşleçlerin sorunlarda kolayca hata ayıklamasını sağlamak üzere uygulama izlemeleri, ölçümler ve günlükler için birleşik bir işletimsel veri havuzu seçin. Daha fazla bilgi için bkz. Bulut uygulamaları için izleme verilerini toplama, toplama ve depolama.

• Bir uygulama durumu modelini bilgilendirmek için operasyonel verilerin iş gereksinimleriyle birlikte 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ümeleri veya standartlaştırılmış teknolojiler tarafından belirlenir. Bununla birlikte, çeşitli dillerin ve çerçevelerin performansını, dayanıklılığını ve genel özelliklerini değerlendirmek önemlidir.

Tasarım konusunda dikkat edilmesi gerekenler

• Geliştirme seti özellikleri. Azure hizmet SDK'ları tarafından çeşitli dillerde sunulan özelliklerde farklılıklar vardır. Bu farklılıklar bir Azure hizmeti veya programlama dili seçiminizi etkileyebilir. Örneğin, Azure Cosmos DB uygun 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 olarak 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 zorluklar getirdiğinden yayılmaktan kaçınmanız gerekir.

• İş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