Kendi kendini iyileştirecek şekilde tasarlama

Dağıtılmış bir sistemde hatalar kaçınılmazdır. Donanımlar arızalanabilir. Ağda geçici hatalar yaşanabilir. Hizmetlerin, veri merkezlerinin ve hatta Azure bölgelerinin tamamında nadiren kesinti yaşanıyor, ancak iş yükü mimarinizin bu kesintileri hesaba eklemesi gerekiyor. İş yükü tasarımınızın erken aşamalarında dayanıklılık ve kurtarmayı ele alın.

Hatalar oluştuğunda kendi kendini iyileştiren bir uygulama tasarlayın. Aşağıdaki yaklaşımı kullanın:

• Hataları algılama.
• Hatalara nazikçe yanıt verin.
• İşletimsel içgörü sağlamak için hataları günlüğe kaydetme ve izleme.

Hatalar oluştuğunda uygulamanızı kendi kendine onaracak şekilde tasarlama

Yanıtınızı hatalara iş yükünüzün kullanılabilirlik gereksinimleriyle uyumlu hale getirme. Örneğin, yüksek kullanılabilirlik gerekiyorsa, bir bölgedeki birden çok kullanılabilirlik alanına dağıtabilirsiniz. Azure bölgesinde kesinti yaşandığında kesinti yaşanmasını önlemek için ikincil bölgeye otomatik olarak yük devredebilirsiniz. Bu yaklaşım maliyeti artırır ve tek bölgeli dağıtıma kıyasla performansı düşürebilir.

Yalnızca bölgesel kesintiler gibi nadir, büyük ölçekli olaylara odaklanmayın. Ağ bağlantısı kaybı veya veritabanı bağlantısı hataları gibi yerel, kısa süreli hatalara eşit veya daha fazla odaklanın.

Kendi kendini iyileştiren iş yükü tasarımı, arızalara dayanabilen ve tamamen çalışır duruma geri kazanabilen dayanıklı sistemler oluşturmayı vurgulayan Azure Well-Architected Framework Güvenilirlik ayağında temeldir. Hizmet düzeyi hedefleri (SLO' lar) dahil olmak üzere iş yükünüzün kullanılabilirlik hedeflerini desteklemek için kendi kendini düzeltme stratejinizi oluşturun.

Recommendations

Zaman uyumsuz iletişim kuran ayrılmış bileşenleri kullanın. Zaman ve alan açısından ayrıştırılacak tasarım bileşenleri. Zaman içinde ayrıştırma, bileşenlerin iletişim için aynı anda mevcut olması gerekmeyacağı anlamına gelir. Alanda ayrıştırma, gönderenin ve alıcının aynı işlemde çalışması gerekmeytiği anlamına gelir. Ayrılmış bileşenler birbirleriyle iletişim kurmak için olayları kullanmalıdır ve bu da basamaklı hata olasılığını en aza indirmeye yardımcı olur.

Başarısız işlemleri yeniden deneyin. Geçici hatalar, ağ bağlantısının anlık kaybı, bırakılan veritabanı bağlantısı veya hizmet meşgul olduğunda zaman aşımı nedeniyle oluşabilir. Uygulamanızı yerleşik olarak geçici hataları işlemeye yönelik bir yeniden deneme mantığı içerecek şekilde tasarlayın. Çoğu Azure hizmeti için istemci SDK’sı tarafından otomatik yeniden deneme uygulanır. Daha fazla bilgi için bkz. Geçici hata işleme ve Yeniden deneme düzeni.

Sistem durumu uç noktası izlemesini uygulayın. Her hizmet, kendi geçerli durumu ile bağımlılıklarının durumunu belirten bir sağlık uç noktası sağlamalıdır. Dış izleme sistemleri, yük dengeleyiciler ve düzenleyiciler bir hizmetin iyi durumda olup olmadığını belirlemek ve trafiği uygun şekilde yönlendirmek için bu sistem durumu uç noktalarını kullanır. Daha fazla bilgi için bkz. Sağlık Uç Noktası İzleme Deseni.

Başarısız olan uzak hizmetleri koruyun. Geçici bir hatadan sonra yeniden denemek iyi bir uygulamadır, ancak kalıcı hata başarısız olan bir hizmeti aşırı yükleyip basamaklı hatalara neden olabilir. Bir işlemin başarısız olma olasılığı yüksek olduğunda uzak çağrı yapmadan hızlı bir şekilde başarısız olmak için Devre Kesici düzenini kullanın.

Kritik kaynakları yalıtma. bir alt sistemdeki hatalar, iş parçacıkları veya yuvalar gibi kaynaklar hemen serbest bırakılmazsa art arda gelebilir ve bu da kaynak tükenmesine neden olabilir. Bir bölümdeki bir hatanın sistemin tamamını etkilememesi için bir sistemi yalıtılmış gruplara bölmek için Bölme Ucu desenini kullanın.

Yük dengeleme gerçekleştirin. Uygulamalar, arka uçta hizmetleri bunaltan trafikte ani ani artışlarla karşılaşabilir. İş öğelerini zaman uyumsuz olarak çalışacak şekilde kuyruğa almak için Queue-Based Yük Dengeleme düzenini kullanın. Kuyruk, yük tepelerini düzelten bir arabellek işlevi görür.

Yük devretme. Eğer bir sunucu örneğine ulaşılamıyorsa, başka bir sunucu örneğine yük devri gerçekleştirin. Web sunucuları gibi durum bilgisi olmayan bileşenler için yük dengeleyicinin veya trafik yöneticisinin arkasına birden çok örnek yerleştirin. Veritabanları gibi durum bilgisi olan bileşenler için çoğaltmaları kullanın ve yük devretme mekanizmaları uygulayın. Veri deposuna ve çoğaltma şekline bağlı olarak, uygulamanın nihai tutarlılığı işlemesi gerekebilir.

Başarısız işlemleri telafi edin. Genel olarak, hizmetler ve kaynaklar arasında koordinasyon gerektirdiğinden dağıtılmış işlemlerden kaçının. Bunun yerine, daha küçük ve tekil işlemlerden oluşan bir işlem oluşturun. İşlem yarıda başarısız olursa, tamamlanan adımları geri almak için Telafi İşlemi düzenini kullanın.

Uzun süre çalışan işlemlere denetim noktaları ekleyin. Denetim noktaları, uzun süre çalışan bir işlem başarısız olursa dayanıklılık sağlar. İşlem yeniden başlatıldığında , örneğin başka bir sanal makine tarafından alınıyorsa, son denetim noktasından devam edebilir. Görevle ilgili durum bilgilerini düzenli aralıklarla kaydeden bir mekanizma uygulamayı düşünün. Bu durumu, görevi çalıştıran işlemin herhangi bir örneğinin erişebileceği dayanıklı depolama alanına kaydedin. İşlem kapatılırsa, başka bir örnek çalışmayı son denetim noktasından sürdürebilir. NServiceBus ve MassTransit gibi kitaplıklar bu işlevi sağlar. Durumu saydam bir şekilde kalıcı hale getirirler ve aralıklar Azure Service Bus'taki kuyruklardan ileti işlemeyle uyumlu olur.

Düzgün bir şekilde düşürüp hata sırasında yanıt vermeye devam edin. Bazen bir soruna geçici çözüm bulamazsınız, ancak yararlı olmaya devam eden daha az işlevsellik sağlayabilirsiniz. Örneğin, bir uygulama kitap kapağı küçük resmi alamıyorsa yer tutucu bir görüntü gösterebilir. Tüm alt sistemler, sipariş işlemeye kıyasla e-ticaret sitesindeki ürün önerileri gibi kritik olmayabilir.

İstemcileri kısıtlama. Bazen birkaç kullanıcı aşırı yük oluşturur ve bu da uygulamanızın diğer kullanıcılar için kullanılabilirliğini azaltabilir. Bu durumda, istemciyi belirli bir süre için kısıtlar. Daha fazla bilgi için bkz . Azaltma düzeni.

Kötü aktörleri engelle. Azaltma, kötü amaçlı bir amaç anlamına gelmez. Bu, istemcinin hizmet kotasını aştığı anlamına gelir. Ancak bir istemci tutarlı olarak hizmet kotasını aşıyor veya başka bir kötü davranış sergiliyorsa bu istemciyi engelleyebilirsiniz. Kullanıcıların engellemeyi kaldırma isteğinde bulunmaları için bant dışı bir işlem tanımlayın.

Öncü seçimi kullan. Bir görevi koordine etmeniz gerektiğinde, bir koordinatör seçmek için Öncü Seçimi düzenini kullanın. Bu yaklaşım, koordinatörün tek bir hata noktası olmamasını sağlar. Koordinatör başarısız olursa sistem yeni bir tane seçer. Özel öncü seçim algoritması uygulamak yerine Apache ZooKeeper gibi önceden oluşturulmuş bir çözümü göz önünde bulundurun.

Hata ekleme kullanarak test edin. Başarı yolu genellikle kapsamlı testler alır, ancak hata yolu almaz. Bir sistem, bir hata yolu tetiklenmesinden önce üretimde uzun süre çalışabilir. Hataları tetikleyerek veya benzeterek sistemin dayanıklılığını test etmek için hata ekleme özelliğini kullanın.

Kaos mühendisliği uygulama. Kaos mühendisliği, üretim örneklerine rastgele hatalar veya anormal koşullar ekleyerek hata ekleme kavramını genişletir. Azure Chaos Studio gibi araçlar, kendi kendini iyileştirme stratejinizdeki zayıflıkları tanımlayan denetimli kaos denemeleri çalıştırmanıza yardımcı olur.

Kullanılabilirlik alanlarını kullanın. Birçok Azure bölgesi, bölgedeki yalıtılmış veri merkezi kümeleri olan kullanılabilirlik alanları sağlar. Belirli bir bölgede yer almalarını sağlayan ve aynı iş yükündeki bileşenler arasındaki iletişimin gecikme süresini azaltmaya yardımcı olabilecek bazı Azure hizmetlerini bölge içinde dağıtabilirsiniz. Alternatif olarak, bazı hizmetleri alanlar arası yedeklilik ile dağıtabilirsiniz; bu da Azure'ın yüksek kullanılabilirlik için kaynağı bölgeler arasında otomatik olarak çoğalttığı anlamına gelir. Çözümünüz için en iyi dengeyi sağlayan yaklaşımı göz önünde bulundurun. Daha fazla bilgi için bkz. Kullanılabilirlik alanları ve bölgeleri için öneriler. Kullanılabilirlik alanlarını destekleyen bazı hizmetler, örneğin en düşük örnek sayısını üç olarak ayarlayarak hizmeti bu bölgeler arasında özel olarak ölçeği genişletecek şekilde yapılandırmanızı gerektirir.

İhtiyacınız olandan fazlasını eklemeyin. Kendi kendini iyileştirme stratejiniz maliyet kısıtlamalarınız, performans hedefleriniz ve kabul edilebilir kapalı kalma sürelerinizle uyumlu olmalıdır. İş yükünüzün bu düzeyde otomatik kurtarma gerektirmeyen bölümlerine kendi kendini düzeltme özellikleri uygulamaktan kaçının.

Sonraki adım

Azure uygulamaları için on tasarım ilkesi