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, başarısızlıklar meydana gelebilir. Donanımlar arızalanabilir. Ağda geçici hatalar yaşanabilir. Nadiren de olsa bir hizmet veya bölgenin tamamında kesintiyle karşılaşılabilir, ancak bu durumlar için bile hazırlıklı olmak gerekir.

Bu nedenle, uygulamaları hata gerçekleştiğinde kendi kendini iyileştirecek şekilde tasarlayın. Bunun için üç başlı bir yaklaşım gerekir:

• Hataları algılama.
• Hatalara düzgün bir şekilde yanıt verme.
• İşletimsel öngörüler elde etmek 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ı olabilir. Örneğin, çok yüksek kullanılabilirlik gerekiyorsa bölgesel bir kesinti sırasında otomatik olarak ikincil bir bölgeye yük devretmek isteyebilirsiniz. Ancak bu, tek bölgeli bir dağıtımdan daha yüksek maliyete yol açar.

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

Başarısız Işlemleri yeniden deneyin. Anlık ağ bağlantısı kaybı, kopan bir veritabanı bağlantısı veya hizmet meşgul olduğunda yaşanan bir zaman aşımı nedeniyle geçici hatalar 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 biçimi.

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 biriktikçe hataların zincirleme bir şekilde yayılmasına neden olabilir. Bir işlemin başarısız olma olasılığı varsa, devre kesici modelini kullanarak hızlı bir şekilde başarısız olur (uzaktan çağrı yapmadan).

Kritik kaynakları yalıtma (Bölme Perdesi). Bazen tek bir alt sistemdeki hatalar zincirleme bir şekilde yayılabilir. Böyle bir durum, hata nedeniyle iş parçacıkları veya yuvalar gibi bazı kaynaklar zamanında serbest kalmıyor ve bu da kaynak tükenmesine yol açıyorsa görülebilir. Bunu önlemek için sistemi yalıtılmış gruplar halinde bölümlere ayırın. Bu sayede, bir bölümdeki hata tüm sistemin çökmesine neden olmaz.

Yük dengeleme gerçekleştirme. Uygulamaların trafiğinde yaşanan ani artışlar arka uçtaki hizmetleri zor duruma sokabilir. Bunu önlemek için, zaman uyumsuz olarak çalıştırmak üzere iş öğelerini sıraya almak için kuyruk tabanlı yük dengeleme modelini 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 bunun nasıl çoğaltıldığına bağlı olarak, uygulamanın son tutarlılık gereksinimleri olabilir.

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.

Performansı düzgün bir şekilde düşürme. 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 büyük olasılıkla ürün önerilerinin gösterilmesi siparişlerin işlenmesinden daha az önemlidir.

İ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. Daraltma düzeninebakın.

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 ve anormal koşullar ekleyerek hata ekleme kavramının sınırlarını genişletir.

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