CIO analizi: Amazon'un bulut arızasını incelemek

Amazon'un son web hizmetleri Kesinti Reddit, Foursquare ve Quora dahil olmak üzere bir dizi yüksek profilli web sitesini kapattı. Bu durumu çevreleyen kapsam, spekülasyon ve FUD göz önüne alındığında, CIO perspektifinin faydalı olacağını düşündüm.

Detaylı ölüm sonrası analiz Amazon, olanları şöyle anlatıyor:

Geçen hafta EC2 müşterilerini etkileyen sorunlar öncelikle Amazon Elastic Block Store'un ("EBS") bir alt kümesini içeriyordu. ABD Doğu Bölgesi içindeki tek bir Erişilebilirlik Alanında okuma ve yazma hizmeti veremeyen birimler operasyonlar. Bu belgede bunlardan "sıkışmış" ciltler olarak bahsedeceğiz. Bu, etkilenen birimleri kullanmaya çalışan örneklerin, bunları okumaya veya yazmaya çalıştıklarında "takılıp kalmalarına" neden oldu. Bu birimleri geri yüklemek ve söz konusu Erişilebilirlik Alanındaki EBS kümesini stabilize etmek için tüm kontrol API'lerini devre dışı bıraktık (ör. Etkilenen Erişilebilirlik Alanında EBS için Birim, Birim Ekle, Birimi Ayır ve Anlık Görüntü Oluştur) etkinlik. Sorunun ilk gününde iki dönem boyunca, bozulmuş EBS kümesi, EBS API'lerini etkiledi ve ABD Doğu'sunun tamamında bu API'lere yapılan EBS çağrılarında yüksek hata oranlarına ve gecikmelere neden oldu Bölge. Her karmaşık operasyonel sorunda olduğu gibi, bu sorun da tek bir sorunla etkileşime giren birkaç temel nedenden kaynaklandı. ve bu nedenle hizmeti benzer olaylara karşı korumamız için bize birçok fırsat sunuyor tekrarlanıyor.

Bu ayrıntılı bir tekno-geek tartışması, ancak düz bir İngilizceyle Amazon'un sistemlerinde kontrolden çıkan ve dolayısıyla kullanılabilirlik eksikliğine neden olan yerel tıkanıklık yaşandı. Daha da kötüsü Amazon aslında kayıp bazı müşterilerin verileri.

CIO perspektifinden bakıldığında birkaç noktayı aklımızda tutmalıyız:

1. Gökyüzü düşmedi ve bulut burada kalacak.

Bu kesinti, bulutun benimsenmesinde kısa vadeli caydırıcı bir etkiye neden olabilir. Genel iş yayını olarak, Ekonomist, raporlar, bu tür kesintiler:

Müşterilerin bulutun ardındaki temel fikre, yani bilişim hizmetlerini tıpkı bir kamu hizmet kuruluşundan gaz veya su gibi satın alabilmeniz gibi internetten satın alınabileceği fikrine gerçekten güvenip güvenemeyecekleri sorusunu gündeme getirdik.

Ancak hem anekdotsal kanıtlar hem de CIO'nun fikir paylaşımı, bulut bilişimin ve SaaS'ın öneminin arttığını gösteriyor. Yakın zamanda yapılan bir çalışma Bilgisayar Ekonomisi Aşağıdaki grafikte gösterildiği gibi, SaaS'ta büyüme ve yatırım üzerine ampirik araştırmanın ışığını parlatıyor:

Focus.com'da da ilginç bir konu var. bu konuyu tartışıyoruz.

2. Bulut avantajı dost ya da düşman olabilir

Merkezi hizmet tesisleri, bulut bilişimin ve SaaS'ın temel ilkesidir. Amazon gibi bulut satıcıları altyapılarını birçok müşteri arasında "kiralama" esasına göre paylaştırıyor. Bu paylaşılan tesisler ölçek ekonomisi yaratır ve bulut bilişimi finansal açıdan çekici kılan kaldıracı kolaylaştırır.

Ancak merkezileşmenin karanlık bir tarafı da vardır; merkezi tesisler bozulduğunda olumsuz bir büyütme etkisi ortaya çıkar. Eski günlerde, her büyük kuruluş kendi altyapısını koruyarak birçok şirketin aynı anda tek bir başarısızlık noktasından çökme riskini azaltıyordu. Geleneksel altyapı pahalı, verimsiz ve yedekli olabilse de, işler kötüye gittiğinde bulut daha geniş bir arıza izi yaratır.

Bununla birlikte, çoğu kuruluş için bulut ve SaaS, mükemmel bir iş senaryosuyla birlikte çok sayıda cazip ekonomik fayda sunmaktadır. Gibi başka bir makale The Economist'te şunları belirtti:

[A]sayısız kişi ve şirket, işleri çevrimiçi yapmanın faydalarının risklerden çok daha ağır bastığını fark etti.

Bununla birlikte akıllı kuruluşlar, temel bileşenlerin ve sistemlerin bulutta merkezileştirilmesinin doğasında olan risklerin farkına varır ve buna göre plan yapar. Gartner analisti, Lydia Leong, bu noktada bilgece yorumlar sunuyor:

Bulut IaaS'de [Hizmet Olarak Altyapı] çok sayıda hareketli parça vardır. Bunlardan herhangi birinin yanlış gitmesi tüm sitenizi/uygulamanızı bozabilir. Asıl sorununuz, riskin uygun şekilde azaltılmasıdır - kesinti riski ve buna bağlı kayıplar ile altyapı yedekliliğinin yarattığı komplikasyonlar, teknik zorluklar ve maliyetler.

3. Bulut hala olgunlaşıyor ve gelişiyor

Hem iş hem de teknoloji açısından bakıldığında bulut dünyası zaman içinde değişiyor ve gelişiyor. Amazon'un kendisi hâlâ nasıl daha iyi planlama yapabileceğini ve kendi sistemlerini nasıl daha sağlam hale getirebileceğini değerlendiriyor.

Danışmanlık ve dış kaynak yönetimi, Sadagopan Singam, bunu perspektife koyuyor (vurgu eklenmiştir):

Düğümlerin kullanılamaması sorunu ortaya çıktığında Amazon'un neredeyse kendi ortamlarında hizmet reddi saldırılarına girmeye başladığını görmek biraz tuhaf. Amazon artık krizle ilgili eylemlerin bu yönünün doğru şekilde ayarlandığını iddia ediyor, ancak başka nelerin yol açabileceğini görmek için bir sonraki kesintiye kadar beklemek gerekebilir. Amazon bulut hizmetlerinin 2008'de büyük bir kesinti yaşadığını belirtmekte fayda var; arıza modeli, tanı konulduğunda biraz benzer görünüyor.

Açıkçası, sistemlerin farklı koşullar altında farklı şekilde çalışması gerekiyor; ancak düğümlerin bu durumu sürdürmesi normaldir. Depolama/erişim endişelerini kopyalayarak, sistemin farklı bir doğaya sahip farklı davranışlar sergilemesi gerekir. kriz. Genel bulut hizmetlerinin giderek daha fazla benimsenmesiyle birlikte, kesinlikle bulut hizmetlerinin hacmi, karmaşıklığı ve kapsamı da artacaktır. iş yükleri artacak ve sistemler kullanılabilirlik açısından değişen koşullar altında test edilecek ve güvenilirlik. Tüm işletme ve BT kullanıcıları, iş yüklerini buluta taşımayı düşünürken bu tür soruların yanıtlarını arayacaktır.

4. Kendine güven ve doğru planlama kritik öneme sahiptir

Dış kaynak kullanımı, kurumsal alıcıları kendi kaderlerini yönetme sorumluluğunu ortadan kaldırmaz. Bulut bilişim açısından bu, kuruluşun olağanüstü durum kurtarmayı planlarken esneklik için uygulamalar tasarlaması gerektiği anlamına gelir.

Bulut otomasyonu CTO'su, George Reese, uygulamalara veri merkezi kesintilerinden bir dereceye kadar bağımsızlık kazandırmak için "başarısızlık için tasarım" öneriyor:

Arızaya yönelik tasarım modelinde, yazılımınızın ve yönetim araçlarınızın kombinasyonları, uygulamanın kullanılabilirliğinin sorumluluğunu üstlenir. Gerçek altyapı kullanılabilirliği, uygulama kullanılabilirliğinizle tamamen ilgisizdir. Bulut sağlayıcınızda veri merkezi çapında çok büyük bir kesinti olsa bile %100 çalışma süresine ulaşılabilir olmalıdır.

Geleneksel modelin avantajı, herhangi bir uygulamanın bu modele yerleştirilebilmesi ve işlevine uygun artıklık seviyesinin atanabilmesidir. Dezavantajı ise geleneksel modelin coğrafya tarafından büyük ölçüde kısıtlanmış olmasıdır. Bu düzeyde bir bulut sağlayıcısı (kamu veya özel) kesintisinden kurtulmanıza yardımcı olmazdı.

"Başarısızlık için tasarım" modelinin avantajı, uygulama geliştiricisinin yalnızca veri modeli ve coğrafi sınırlamalar getiren hacim ile bunların kullanılabilirliği üzerinde tam kontrole sahip olmasıdır. "Başarısızlık için tasarım" modelinin dezavantajı, baştan "başarısızlık için tasarım" yapmak zorunda olmanızdır.

Bulut veya başka türlü kesintiler meydana geldiğinde olağanüstü durum kurtarma önemli bir konu haline gelir. Pek çok kuruluş, olağanüstü durum kurtarmaya sözde bağlılık gösterir, ancak aslında bir kesinti meydana gelmeden önce sistemlerini kapsamlı bir şekilde test etmez. Kıdemli teknoloji uzmanı, Bob Warfield, olağanüstü durum kurtarma planlarının bulut ortamında uygulanmasına yönelik öneriler sunar:

Şirketlerin iş yeri dışı yedeklemenin Bulut eşdeğerine ihtiyacı var. En azından altyapınızın bir yedeğine (yeniden başlatmak için gereken tüm AMI'lere ve Verilere) erişebildiğinizden emin olmanız gerekir. Depolama ucuzdur. Heck, eğer tamamen paranoyaksanız, durumu tersine çevirin ve Bulutu yalnızca yedekleme altyapısından oluşan kendi veri merkezinize yedekleyin. En azından bu şekilde her zaman verilere sahip olursunuz. Evet, gecikme sorunları olacak ve bu veriler güncel olmayacaktır. Ama olan bitene bakın. Diyelim ki 2 saatlik veri kaybıyla başka bir bölgeye dönmüş olabilirsiniz. İyi değil, hiç iyi değil. Peki bu gerçekten 24 saatten fazla beklemekten daha mı kötü, yoksa bunu acil duruma 2 saat kala yapabilseydiniz şimdi kendinizi şanslı mı hissederdiniz?

Bunlar felaketten kurtarma için düşünülmesi gereken türden değiş-tokuşlardır. Daha dayanıklı bir mimari elde edene kadar sakız çiğnemek ve telleri kurtarmak gerekir, ancak kesinlikle hiçbir seçeneğe sahip olmamak ve beklemekten daha iyidir.

5. Başarı öykülerinden ders alın

Bazı Amazon müşterileri olayı nispeten zarar görmeden atlattı. Kuruluşunuzun daha iyi hazırlanmasına yardımcı olmak için onlardan ders alın.

Kendi otopsi video dağıtım devi, netflix, diyor:

Neden bazı web siteleri etkilenirken diğerleri etkilenmedi? Netflix için bunun kısa yanıtı, sistemlerimizin özellikle bu tür arızalar için tasarlanmış olmasıdır. Bulut için yeniden tasarladığımızda bu Amazon hatası tam olarak dirençli olmak istediğimiz türde bir sorundu. Mimarimiz, EBS'yi ana veri depolama hizmetimiz olarak kullanmaktan kaçınıyor ve bağımlı olduğumuz SimpleDB, S3 ve Cassandra hizmetleri kesintiden etkilenmedi.

Benzer şekilde, coğrafi konum geliştirme sağlayıcısı, SimpleGeo, zarar görmeden hayatta kaldı. Blogları şirketin ilgili teknik mimari kararlarının altında yatan felsefi görüşü açıklıyor:

SimpleGeo'da başarısızlık birinci sınıf vatandaştır. Tasarım tartışmalarında bunun hakkında çok konuşuyoruz, operasyonel prosedürlerimizi etkiliyor, kodlama yaparken bunun hakkında düşünüyoruz ve öğle yemeğinde bunun hakkında şaka yapıyoruz. Sistem arıza mekanizmalarını anlamaya ve bunlar hakkında açık olmaya yapılan bu vurgunun, bunlarla baş etmenin ilk adımı olduğuna inanıyorum. Altyapımıza yeni bir bileşen eklemeden önce, kaçınılmaz olarak başarısız olması durumunda onunla nasıl başa çıkacağımızı planlıyoruz.

GİRİŞİMCİ CIO'LARA TAVSİYELER

Birçok kuruluş için en azından bazı uygulama ve sistemleri SaaS'a ve buluta taşımak kaçınılmazdır. Sorun, hangi uygulamaların ne zaman taşınacağına karar vermek, geçişin nasıl gerçekleştirileceğini bulmak ve şirket içinde doğru becerileri geliştirmektir.

Amazon'un durumu, buluta geçişin ya hep ya hiç meselesi olmadığını gösteriyor. Bu durumda, daha iyi planlama ve mimari tasarıma sahip kuruluşlar hayatta kalırken diğerleri battı. Ayrıca, gelişmiş teknik bilginin önemi ne kadar vurgulansa azdır.

CIO'lar, kuruluşlarının bulut yatırımı/risk eğrisinin neresinde yer aldığına karar vermelidir. Diğer iş alanlarında olduğu gibi, sağlam tasarıma yapılan yatırımın arttırılması operasyonel riski azaltabilir ancak daha yüksek finansal maliyete neden olur. Her CIO, yatırım, teknik gelişme ve risk arasındaki doğru dengeyi belirlemek için kendi organizasyonunu değerlendirmelidir.

[Bulut fotoğrafı: Michael Krigsman]