Hatalara Karşı Dayanıklı Tasarım (Azure ile Real-World Cloud Apps Oluşturma)

  • Makale
  • Okumak için 8 dakika

tarafından Rick Anderson, Tom Dykstra

Fix It Project'i indirin veya E-kitabı indirin

Azure e-kitabıyla Gerçek Dünya Bulut Uygulamaları Oluşturma, Scott Guthrie tarafından geliştirilen bir sunuyu temel alır. Bulut için web uygulamalarını başarıyla geliştirmenize yardımcı olabilecek 13 desen ve uygulama açıklanmaktadır. E-kitap hakkında bilgi için ilk bölüme bakın.

Herhangi bir uygulama türünü oluştururken düşünmeniz gereken şeylerden biri, ancak özellikle de çok sayıda kişinin kullanacağı bulutta çalışacak olan uygulama, hataları düzgün bir şekilde işleyebilmesi ve mümkün olduğunca değer sunmaya devam edebilmesi için uygulamayı nasıl tasarlayabileceğinizdir. Yeterince zaman verildiğinde, herhangi bir ortamda veya herhangi bir yazılım sisteminde işler ters gidecektir. Uygulamanızın bu durumlarla nasıl başa çıkacağı, müşterilerinizin ne kadar üzüleceğini ve sorunları analiz edip çözmek için ne kadar zaman harcamanız gerekeceğini belirler.

Hata türleri

Farklı şekilde işlemek isteyeceğiniz iki temel hata kategorisi vardır:

  • Aralıklı ağ bağlantısı sorunları gibi geçici, kendi kendini iyileştiren hatalar.
  • Müdahale gerektiren kalıcı hatalar.

Geçici hatalar için, uygulamanın çoğu zaman hızlı ve otomatik olarak kurtarılmasını sağlamak için bir yeniden deneme ilkesi uygulayabilirsiniz. Müşterileriniz yanıt süresinin biraz daha uzun olduğunu fark edebilir, ancak aksi takdirde etkilenmez. Geçici Hata İşleme bölümünde bu hataları işlemenin bazı yollarını göstereceğiz.

Kalıcı hatalar için, sorunlar ortaya çıktığında size hemen bildiren ve kök neden analizini kolaylaştıran izleme ve günlüğe kaydetme işlevselliği uygulayabilirsiniz. İzleme ve Telemetri bölümünde bu tür hatalardan haberdar olmanıza yardımcı olacak bazı yollar göstereceğiz.

Hata kapsamı

Ayrıca tek bir makinenin etkilenip etkilenmediğini, SQL Veritabanı veya Depolama gibi bir hizmetin tamamını ya da bölgenin tamamını da düşünmeniz gerekir.

Hata kapsamı

Makine hataları

Azure'da, başarısız bir sunucu otomatik olarak yeni bir sunucuyla değiştirilir ve iyi tasarlanmış bir bulut uygulaması bu tür hatalardan otomatik olarak ve hızlı bir şekilde kurtarılır. Daha önce durum bilgisi olmayan bir web katmanının ölçeklenebilirlik avantajlarını vurguladık ve başarısız bir sunucudan kurtarma kolaylığı da durum bilgisizliğinin bir diğer avantajı oldu. Kurtarma kolaylığı, SQL Veritabanı ve Azure App Service Web Apps gibi hizmet olarak platform (PaaS) özelliklerinin avantajlarından biridir. Donanım hataları nadirdir, ancak oluştuğunda bu hizmetler bunları otomatik olarak işler; Bu hizmetlerden birini kullanırken makine hatalarını işlemek için kod yazmanız bile gerekmez.

Hizmet hataları

Bulut uygulamaları genellikle birden çok hizmet kullanır. Örneğin, Düzelt uygulaması SQL Veritabanı hizmetini, Depolama hizmetini kullanır ve web uygulaması Azure App Service dağıtılır. Bağımlı olduğunuz hizmetlerden biri başarısız olursa uygulamanız ne yapar? Bazı hizmet hataları için yapabileceğiniz en kolay "üzgünüz, daha sonra yeniden deneyin" iletisi olabilir. Ancak birçok senaryoda daha iyisini yapabilirsiniz. Örneğin, arka uç veri deponuz kapalı olduğunda kullanıcı girişini kabul edebilir, "isteğiniz alındı" ifadesini görüntüleyebilir ve girişi geçici olarak başka bir yerde depolayabilirsiniz; ardından ihtiyacınız olan hizmet yeniden çalışır duruma geldiğinde girişi alabilir ve işleyebilirsiniz.

Kuyruk merkezli çalışma düzeni bölümü, bu senaryoyu işlemenin bir yolunu gösterir. Düzelt uygulaması görevleri SQL Veritabanı depolar, ancak SQL Veritabanı kapalıyken çalışmayı bırakması gerekmez. Bu bölümde, kuyruktaki bir görevin kullanıcı girişini depolamayı, kuyruğu okumak ve görevi güncelleştirmek için çalışan işlemini kullanmayı göreceğiz. SQL kapalıysa, Düzelt görevlerini oluşturma özelliği etkilenmez; çalışan işlemi, SQL Veritabanı kullanılabilir olduğunda yeni görevleri bekleyebilir ve işleyebilir.

Bölge hataları

Bölgelerin tamamı başarısız olabilir. Doğal bir afet bir veri merkezini yok edebilir, bir gök taşı tarafından düzleştirilebilir, veri merkezine giden ana hat bir çiftçi tarafından kesilebilir ve bir ineği destekçiyle gömebilir, vb. Uygulamanız, kısıtlı veri merkezinde barındırılıyorsa ne yaparsınız? Azure'da uygulamanızı birden çok bölgede aynı anda çalışacak şekilde ayarlayabilirsiniz, böylece bir bölgede olağanüstü durum oluşursa başka bir bölgede çalışmaya devam edebilirsiniz. Bu tür hatalar son derece nadir görülen durumlardır ve çoğu uygulama, bu tür hatalarla kesintisiz hizmet sağlamak için gereken halkalardan atlamaz. Bölge hatası durumunda bile uygulamanızı kullanılabilir durumda tutma hakkında bilgi için bölümün sonundaki Kaynaklar bölümüne bakın.

Azure'ın bir amacı, bu tür hataların tümünün işlenmesini çok daha kolay hale getirmektir ve aşağıdaki bölümlerde bunu nasıl yaptığımıza ilişkin bazı örnekler göreceksiniz.

SLA’lar

İnsanlar genellikle bulut ortamındaki hizmet düzeyi sözleşmelerini (SLA' lar) duyar. Temel olarak bunlar, şirketlerin hizmetlerinin ne kadar güvenilir olduğu konusunda verdikleri sözlerdir. %99,9 SLA değeri, hizmetin %99,9 oranında düzgün çalışmasını beklemeniz gerektiği anlamına gelir. Bu, SLA için oldukça tipik bir değerdir ve çok yüksek bir sayı gibi görünür, ancak aslında %1'lik bir düşüş süresinin ne kadar olduğunu fark edemeyebilirsiniz. Aşağıda, çeşitli SLA yüzdelerinin bir yıl, bir ay ve bir haftadan daha fazla kapalı kalma süresini gösteren bir tablo yer almaktadır.

SLA tablosu

Bu nedenle %99,9 SLA, hizmetinizin yılda 8,76 saat veya ayda 43,2 dakika kapalı olabileceği anlamına gelir. Bu çoğu insanın farkedenden daha fazla zaman alır. Bu nedenle bir geliştirici olarak belirli bir sürenin mümkün olduğunu ve bunu zarif bir şekilde ele alındığını bilmek istiyorsunuz. Bir noktada birisi uygulamanızı kullanıyor olacak ve bir hizmet kapanacak ve bunun müşteri üzerindeki olumsuz etkisini en aza indirmek istiyorsunuz.

SLA hakkında bilmeniz gereken bir şey, hangi zaman çerçevesine başvurduğudur: saat her hafta, her ay veya her yıl sıfırlanır mı? Azure'da her ay saati sıfırlıyoruz ve bu sizin için yıllık SLA'dan daha iyidir çünkü yıllık bir SLA, kötü ayları bir dizi iyi ayla sıfırlayarak gizleyebilir.

Tabii ki her zaman SLA'dan daha iyisini yapmak istiyoruz; Genellikle bundan çok daha az yere inersin. Söz veriyorum, eğer maksimum çalışma süresinden daha uzun süre kalırsak parayı geri isteyebilirsiniz. Geri aldığınız para miktarı büyük olasılıkla fazla çalışma süresinin iş etkisini tam olarak telafi etmez, ancak SLA'nın bu yönü bir uygulama ilkesi görevi görür ve bunu çok ciddiye aldığımızı size bildirir.

Bileşik SLA'lar

SLA'lara bakarken dikkate almanız gereken önemli bir nokta, her hizmetin ayrı bir SLA'ya sahip olduğu bir uygulamada birden çok hizmet kullanmanın etkisidir. Örneğin Düzelt uygulaması Azure App Service Web Apps, Azure Depolama ve SQL Veritabanı kullanır. Bu e-kitabın Aralık 2013'te yazıldığı tarih itibarıyla SLA numaraları şunlardır:

SLA Web Sitesi, Depolama SQL Veritabanı

Bu hizmet SLA'larını temel alarak uygulama için beklemeniz gereken en uzun çalışma süresi nedir? Bu durumda, inme sürenizin en kötü SLA yüzdesine veya %99,9'a eşit olacağını düşünebilirsiniz. Bu, üç hizmetin de her zaman aynı anda başarısız olması durumunda geçerli olur, ancak gerçekte olan bu olmayabilir. Her hizmet farklı zamanlarda bağımsız olarak başarısız olabilir, bu nedenle tek tek SLA sayılarını çarparak bileşik SLA'yı hesaplamanız gerekir.

Bileşik SLA

Bu nedenle uygulamanız ayda yalnızca 43,2 dakika değil, bu tutarın 3 katı, ayda 108 dakika olabilir ve yine de Azure SLA sınırları içinde olabilir.

Bu sorun Azure'a özgü değildir. Kullanılabilir tüm bulut hizmetlerinin en iyi bulut SLA'larını sağlarız ve satıcının bulut hizmetlerini kullanıyorsanız benzer sorunlarla karşılaşırsınız. Bunun vurgulandığı nokta, uygulamanızı kaçınılmaz hizmet hatalarını düzgün bir şekilde ele almak için nasıl tasarlayabileceğinizi düşünmenin önemidir, çünkü bunlar müşterilerinizi veya kullanıcılarınızı etkileyecek kadar sık gerçekleşebilir.

Bulut SLA'ları, kurumsal kesinti süresi deneyimiyle karşılaştırıldığında

İnsanlar bazen "Kurumsal uygulamamda bu sorunları hiç yaşamam" der. Ayda ne kadar çalışmadıklarını sorarsanız genellikle "Arada sırada olur" derler. Ne sıklıkta sorulduğunu sorarsanız, "Bazen yeni bir sunucu yedeklememiz veya yüklememiz veya yazılımı güncelleştirmemiz gerekir" ifadesini kabul ederler. Tabii ki, bu zaman düşüş olarak sayılır. Özellikle görev açısından kritik olmayan çoğu kurumsal uygulama, hizmet SLA'larımızın izin verdiği süreden daha uzun süre kapalıdır. Ancak sunucunuz, altyapınız ve bundan sorumlu olduğunuzda ve denetimi size ait olduğunda, daha az kötü zamanlarda kendinizi daha az angst hissetme eğiliminde olursunuz. Bulut ortamında başka birine bağımlısınız ve neler olduğunu bilmiyorsunuz, bu nedenle bu konuda daha fazla endişelenme eğiliminde olabilirsiniz.

Bir kuruluş, bulut SLA'sından elde ettiğinizden daha fazla çalışma zamanı yüzdesi elde ettiğinde, bunu donanıma çok daha fazla para harcayarak yapar. Bir bulut hizmeti bunu yapabilir ancak hizmetleri için çok daha fazla ücret ödemesi gerekir. Bunun yerine, uygun maliyetli hizmetlerden yararlanıp yazılımınızı, kaçınılmaz hataların müşterileriniz için minimum kesintiye neden olacak şekilde tasarlamanız gerekir. Bulut uygulaması tasarımcısı olarak işiniz, felaketleri önlemek için hatalardan kaçınmak için çok fazla değildir ve bunu donanıma değil yazılıma odaklanarak yaparsınız. Kurumsal uygulamalar hatalar arasındaki ortalama süreyi en üst düzeye çıkarmaya çalışırken, bulut uygulamaları ortalama kurtarma süresini en aza indirmeye çalışır.

Tüm bulut hizmetlerinin SLA'ları yoktur

Ayrıca her bulut hizmetinin bir SLA'sı bile olmadığını unutmayın. Uygulamanız çalışma süresi garantisi olmayan bir hizmete bağımlıysa hayal edebileceğinizden çok daha uzun süre kapalı olabilirsiniz. Örneğin, Facebook veya Twitter gibi bir sosyal sağlayıcı kullanarak sitenizde oturum açmayı etkinleştirirseniz, bir SLA olup olmadığını öğrenmek için hizmet sağlayıcısına başvurun ve bunun olmadığını öğrenebilirsiniz. Ancak kimlik doğrulama hizmeti kapanırsa veya oluşturduğunuz istek hacmini destekleyemezse müşterileriniz uygulamanızdan kilitlenir. Günler ya da daha uzun süre kapalı olabilirsin. Yeni bir uygulamanın oluşturucuları yüz milyonlarca indirme bekliyor ve Facebook kimlik doğrulamasına bağımlıydı - ancak canlı yayına geçmeden önce Facebook'la konuşmadı ve bu hizmet için SLA olmadığını çok geç keşfetti.

Tüm kapalı kalma süreleri SLA'lara göre sayılmaz

Bazı bulut hizmetleri, uygulamanız bunları fazla kullanıyorsa hizmeti kasıtlı olarak reddedebilir. Buna azaltma denir. Bir hizmetin SLA'sı varsa, kısıtlanabileceğiniz koşulları belirtmeli ve uygulama tasarımınız bu koşullardan kaçınmalı ve gerçekleşirse azaltmaya uygun şekilde tepki vermelidir. Örneğin, bir hizmete yönelik istekler saniye başına belirli bir sayıyı aştığınızda başarısız oluyorsa, otomatik yeniden denemelerin azaltmanın devam etmesine neden olacak kadar hızlı gerçekleşmediğinden emin olmak istersiniz. Geçici Hata İşleme bölümünde azaltma hakkında daha fazla bilgi edineceğiz.

Özet

Bu bölüm, gerçek bir bulut uygulamasının hatalara düzgün bir şekilde devam etmek için neden tasarlanması gerektiğini fark etmeye yardımcı olmaya çalışmıştır. Sonraki bölümden başlayarak, bu serideki kalan desenler bunu yapmak için kullanabileceğiniz bazı stratejiler hakkında daha ayrıntılı bilgi edinmektedir:

  • İyi izleme ve telemetriye sahip olduğunuzdan, müdahale gerektiren hatalar hakkında hızlı bir şekilde bilgi edinebilir ve bunları çözmek için yeterli bilgiye sahip olursunuz.
  • Akıllı yeniden deneme mantığı uygulayarak geçici hataları işleyin, böylece uygulamanız kurtarabildiğinde otomatik olarak kurtarılır ve kurtarılamadığında devre kesici mantığına geri döner.
  • Veritabanı erişimiyle ilgili aktarım hızını, gecikme süresini ve bağlantı sorunlarını en aza indirmek için dağıtılmış önbelleğe alma özelliğini kullanın.
  • Arka uç kapalıyken uygulamanızın ön ucunun çalışmaya devam edebilmesi için kuyruk merkezli iş düzeni aracılığıyla gevşek bağlama uygulayın.

Kaynaklar

Daha fazla bilgi için bu e-kitabın sonraki bölümlerine ve aşağıdaki kaynaklara bakın.

Belgeler:

Videolar:

  • FailSafe: Ölçeklenebilir, Dayanıklı Cloud Services oluşturma. Ulrich Homann, Marc Mercuri ve Mark Simms tarafından 9 bölümlü seri. Microsoft Müşteri Danışmanlık Ekibi (CAT) deneyiminin gerçek müşterilerle olan hikayeleriyle üst düzey kavramları ve mimari ilkeleri çok erişilebilir ve ilginç bir şekilde sunar. Bölüm 1 ve 8, hatalardan kurtulmak için bulut uygulamaları tasarlamanın nedenlerini derinlemesine açıklar. Bölüm 2'de saat 49:57'de başlayan azaltmanın takip tartışması, 2. bölümde hata noktalarının ve hata modlarının 56:05'te başlaması ve bölüm 3'te 40:55'te başlayan devre kesici tartışmalarına da bakın.
  • Büyük Derleme: Azure müşterilerinden alınan dersler - Bölüm II. Mark Simms, başarısızlık tasarımından ve her şeyi izlemeden bahsediyor. Failsafe serisine benzer ancak daha fazla nasıl yapılır ayrıntılarına gider.

ÖncekiSonraki