Kendi kendini iyileştirecek şekilde tasarlayın

Uygulamanızı hata gerçekleştiğinde kendi kendini iyileştirecek şekilde tasarlayın

Dağıtılmış bir sistemde hataların gerçekleşmesi beklenmelidir. Donanımlar arızalanabilir. Ağda geçici hatalar yaşanabilir. Bir hizmet, veri merkezi ve hatta Azure bölgesinin tamamı nadiren kesinti yaşar, ancak bunların bile iş yükü mimarinizde tasarlanması gerekir. Dayanıklılık ve kurtarma, iş yükü tasarımınızın erken aşamalarında ele alınmalıdır.

Bu nedenle, hatalar oluştuğunda kendi kendini iyileştiren bir uygulama tasarlayın. Bunun için üç başlı bir yaklaşım gerekir:

• Hataları algılama.
• Hatalara düzgün bir şekilde yanıt verme.
• İşletimsel içgörüler sağlamak için hataları günlüğe kaydetme ve izleme.

Belirli bir hata türüne nasıl yanıt vereceğiniz, uygulamanızın kullanılabilirlik gereksinimlerine bağlıdır. Örneğin, yüksek kullanılabilirlik gerekiyorsa, bir bölgedeki birden çok kullanılabilirlik alanına dağıtabilirsiniz. Kesintileri önlemek için, kesinti yaşanması olası bir Azure bölgesinin tamamında kesinti yaşanması durumunda bile bölgesel bir kesinti sırasında otomatik olarak ikincil bölgeye yük devredebilirsiniz. Ancak bu, tek bölgeli dağıtımdan daha yüksek maliyet ve potansiyel olarak daha düşük performansa neden olur.

Ayrıca, genellikle nadir olan bölgesel kesintiler gibi büyük olaylardan daha fazlasını göz önünde bulundurun. Ağ bağlantısı sorunları veya başarısız veritabanı bağlantıları gibi yerel, kısa süreli hatalara da en az bunlar kadar, hatta bunlardan daha çok odaklanmalısınız.

Öneriler

Zaman uyumsuz iletişim kuran ayrılmış bileşenleri kullanın. İdeal olarak, bileşenler zaman ve alan açısından ayrılır. Zaman içinde ayrılmış olması, iletişimin mümkün olması için bileşenlerin aynı anda mevcut olması gerekmeyecek anlamına gelir. Boşlukla ayrılmış olması, gönderenin ve alıcının aynı işlemde çalışması gerekmeyecek, ancak daha verimli olduğu her yerde çalıştırabilecekleri anlamına gelir. Ayrılmış bileşenler, birbirleriyle iletişim kurmak için ideal olarak olayları kullanır. Bu, basamaklı hata olasılığını en aza indirmeye yardımcı olur.

Başarısız işlemleri yeniden deneme. Geçici hatalar ağ bağlantısının anlık kaybından, bırakılan veritabanı bağlantısından veya hizmet meşgul olduğunda zaman aşımından kaynaklanabilir. 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.

Başarısız olan uzak hizmetleri koruma (Devre Kesici). Geçici bir hatadan sonra yeniden deneme iyidir, ancak hata devam ederse zaten başarısız olan bir hizmeti çağrı bombardımanına tutabilirsiniz. Bu, istekler yedekledikçe art arda hatalara yol açabilir. Bir işlemin başarısız olma olasılığı yüksek olduğunda hızlı (uzak çağrı yapmadan) başarısız olmak için Devre Kesici düzenini kullanın.

Kritik kaynakları yalıtma (Bölme Perdesi). Bazen tek bir alt sistemdeki hatalar zincirleme bir şekilde yayılabilir. Bir hata, iş parçacıkları veya yuvalar gibi bazı kaynakların zamanında boşaltılmamasına ve kaynak tükenmesine yol açmasına neden olursa bu durum oluşabilir. Bunu önlemek için, bir sistemi yalıtılmış gruplar halinde bölümlendirmek için Bulkhead desenini kullanın, böylece bir bölümdeki bir hata sistemin tamamını düşürmez.

Yük dengeleme gerçekleştirme. Uygulamalarda trafikte ani ani ani artışlar yaşanabilir ve bu ani artışlar arka uçtaki hizmetleri bunaltabilir. Bunu önlemek için, iş öğelerini zaman uyumsuz olarak çalışacak şekilde kuyruğa almak için Kuyruk Tabanlı Yük Dengeleme düzenini kullanın. Kuyruk, yükteki çıkışları düzleştiren bir arabellek görevini görür.

Yük devretme. Bir örneğe ulaşılamıyorsa başka bir örneğe yük devri gerçekleştirin. Web sunucusu gibi durum bilgisi olmayan öğeler için bir yük dengeleyicisinin veya trafik yöneticisinin arkasına birkaç örnek yerleştirin. Veritabanı gibi durum bilgisi depolayan öğeler için çoğaltmaları kullanın ve yük devretme gerçekleştirin. Veri deposuna ve çoğaltma şekline bağlı olarak, uygulamanın nihai tutarlılık ile ilgilenmesi gerekebilir.

Başarısız işlemleri telafi etme. Genel olarak, dağıtılmış işlemler farklı hizmet ve kaynaklar arasında koordinasyon gerektirdiği için bunlardan kaçının. Bunun yerine, daha küçük ve tekil işlemlerden oluşan bir işlem oluşturun. İşlem sürecin yarısında başarısız olursa, zaten tamamlanmış olan adımları geri almak için Telafi İşlemleri kullanın.

Uzun süre çalışan işlemler için denetim noktası kullanma. Denetim noktaları, uzun süre çalışan bir işlemin başarısız olması durumunda dayanıklılık sağlar. İşlem yeniden başlatıldığında (örneğin, başka bir VM tarafından devralındığında) son denetim noktasından sürdürülebilir. Görevle ilgili durum bilgilerini düzenli aralıklarla kaydeden ve bu durumu görevi çalıştıran işlemin herhangi bir örneği tarafından erişilebilen dayanıklı depolama alanına kaydeden bir mekanizma uygulamayı düşünün. Bu şekilde, işlem kapatılırsa, gerçekleştirdiği çalışma başka bir örnek kullanılarak son denetim noktasından sürdürülebilir. NServiceBus ve MassTransit gibi bu işlevselliği sağlayan kitaplıklar vardır. Aralıkların Azure Service Bus'taki kuyruklardan gelen iletilerin işlenmesiyle hizalandığı durumu saydam bir şekilde kalıcı hale getirir.

Düzgün bir şekilde düşürüp hata sırasında yanıt vermeye devam edin. Bir soruna geçici çözüm bulamadığınız, ancak daha az olmasına rağmen kullanışlı olan işlevler sağlayabileceğiniz durumlar olabilir. Bir kitap kataloğu gösteren bir uygulama düşünün. Uygulama kitap kapağına ait küçük resmi alamıyorsa bunun yerine yer tutucu bir resim gösterebilir. Uygulama için bazı alt sistemler kritik olmayabilir. Örneğin, bir e-ticaret sitesinde ürün önerilerini göstermek büyük olasılıkla siparişleri işlemekten daha az kritiktir.

İstemcileri kısıtlama. Bazen az sayıda kullanıcı aşırı miktarda yük oluşturarak diğer kullanıcılar için uygulamanızın kullanılabilirliğini azaltabilir. Bu durumda, istemciyi belirli bir süreliğine kısıtlayın. Bkz. Azaltma düzeni.

Kötü aktörleri engelleyin. Bir istemcinin kısıtlanması, kötü amaçlı olduğu anlamına gelmez. Yalnızca 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ının engellemesinin kaldırılmasını istemesi bir bant dışı işlemi tanımlayın.

Öncü seçimi kullanma. Bir görevi koordine etmeniz gerektiğinde düzenleyici seçmek için Öncü Seçimi kullanın. Böylece, düzenleyici tek bir hata noktası olmaz. Düzenleyici başarısız olursa, yeni bir düzenleyici seçilir. Sıfırdan öncü seçim algoritması oluşturmak yerine Zookeeper gibi kullanıma hazır bir çözümü göz önünde bulundurun.

Hata ekleme ile test etme. Çoğu zaman başarıya giden yollar iyi test edilse de başarısızlığa giden yollar pek test edilmez. Bir sistem, başarısızlığa neden olan bir yöntem uygulanmadan önce üretimde uzun süre çalışabilir. Sistemin hatalara karşı dayanıklılığını, gerçek hatalar tetikleyerek veya bunların benzetimini yaparak test etmek için hata ekleme yöntemini kullanın.

Kaos mühendisliğini benimseme. Kaos mühendisliği, üretim örneklerine rastgele hatalar veya anormal koşullar ekleyerek hata ekleme anlayışını genişletir.

Kullanılabilirlik alanlarını kullanın. Birçok Azure bölgesi, bölgedeki veri merkezlerinin yalıtılmış kümeleri olan kullanılabilirlik alanları sağlar. Bazı Azure hizmetleri, belirli bir bölgeye yerleştirilmelerini sağlayan ve aynı iş yükündeki bileşenler arasında iletişimde gecikme süresini azaltmaya yardımcı olan bölgesel olarak dağıtılabilir. Alternatif olarak, bazı hizmetler alanlar arası yedeklilik ile dağıtılabilir; bu da Azure'ın yüksek kullanılabilirlik için kaynağı bölgeler arasında otomatik olarak çoğaltacağı anlamına gelir. Çözümünüz için en iyi dengeyi sağlayan yaklaşımı göz önünde bulundurun. Çözümünüzü kullanılabilirlik alanlarını ve bölgelerini kullanacak şekilde tasarlama hakkında daha fazla bilgi edinmek için bkz . Kullanılabilirlik alanlarını ve bölgelerini kullanma önerileri.

Uygulamalarınızı kendi kendine iyileştirmeye yönelik yapılandırılmış bir yaklaşım için bkz . Azure için güvenilir uygulamalar tasarlama.