- AWS, perşembe gecesinden itibaren operasyonel sorunlar bildirdi; Kuzey Virginia’daki US-East-1 bölgesinde veri merkezi aşırı ısınmasıyla bağlantılı kesinti, Coinbase ve FanDuel gibi işlem platformlarını etkiledi
- AWS, cuma günü saat 15:29'da (ET) yayımladığı güncellemede tam toparlanmanın hâlâ birkaç saat süreceğinin beklendiğini ve kurtarma çalışmalarının önceki tahminlerden daha yavaş ilerlediğini belirtti
- AWS, söz konusu bölgede tek bir Availability Zone içinde sorun yaşandığını ve ek soğutma sistemi kapasitesini devreye alarak kalan donanımı kurtarmakta olduğunu açıkladı
- FanDuel, kullanıcıların platforma erişememesine yol açan teknik sorunları inceledikten sonra bunun daha geniş kapsamlı AWS kesintisiyle bağlantılı olduğunu söyledi; kullanıcılar nakde çevirememe nedeniyle bahis kayıpları yaşadıklarını dile getirdi
- Coinbase, birden fazla AWS alanındaki kesintilerin temel işlem hizmetlerinde uzun süreli kesintiye yol açtığını söyledi ve ana sorunların tamamen çözüldüğünü paylaştı
Kurtarma süreci
- AWS, cuma günü saat 09:51'de (ET) yayımladığı güncellemede “ek soğutma sistemi kapasitesini devreye almak için aktif şekilde çalışıyoruz; bu da etkilenen alandaki kalan donanımı kurtarmamıza olanak sağlayacak” dedi
- AWS, sanal sunucu kapasitesi sağlayan EC2 instance kesintisini gidermeye çalışıyor
- AWS sağlık panosu, perşembe günü saat 20:25'te (ET) ilk olarak “instance kesintisini inceliyoruz” paylaşımını yaptı
- AWS ek bir açıklama yapmadı
Hizmet bazında etki
- FanDuel, perşembe günü saat 21:00'de (ET) X üzerinden kullanıcıların platforma erişememesine yol açan mevcut teknik zorlukların farkında olduğunu ve konuyu araştırdığını açıkladı
- FanDuel, yaklaşık 2 saat sonra sorunun daha geniş AWS kesintisiyle bağlantılı olduğunu belirten bir güncelleme paylaştı
- FanDuel kullanıcıları, platformda nakde çıkamadıkları için bahis kayıpları yaşadıklarını dile getirdi
- Coinbase de cuma günü X'te, birden fazla AWS alanındaki kesintilerin “temel işlem hizmetlerinde uzun süreli kesintiye” yol açtığını paylaştı
- Coinbase, aynı paylaşımda ana sorunların tamamen çözüldüğünü belirtti
Bulut pazarı bağlamı
- AWS, bulut altyapısı teknolojisi pazarının yaklaşık üçte birini oluşturuyor
- AWS, milyonlarca şirkete hizmet veriyor
1 yorum
Hacker News görüşleri
AWS US-East 1 internetin Aşil tendonu olmaya devam ediyor
Birden çok region ve availability zone genelinde kurulum yapılabiliyor, ancak AWS, US-East 1 sorunlarının daha geniş etki yarattığı olayları tekrar tekrar yaşadı ve bu da AWS’nin ima ettiği kadar yüksek yedeklilik ve dayanıklılık sunmadığını gösteriyor
Çin dışındaki public cloud’un tüm kimlik ve erişim servisleri, yani çalışanların “aws partition için IAM” dediği yapı, us-east-1’de merkezileştirilmiş durumda. Hesapları, faturalandırmayı ve yetkileri tutarlı şekilde görebilmek için pratikte böyle bir merkezileştirme gerekiyor
IAM de tamamen bağımsız bir yazılım yığını değil; DynamoDB gibi bazı servislere bağımlı ve bu servisler de tekrar IAM’e döngüsel olarak bağımlı
us-east-1 kesintileri sırasında başka region’larda mevcut kimlik doğrulama token’larını veya oturumları kullanmaya devam etmek bazen mümkün olsa da yeni token verilemeyebilir. Eskiden çalıştığım yerde, kesinti bitene kadar kilitli kalabilirsiniz diye on-call ekibe SSH oturumlarını veya AWS konsolundaki tarayıcı sekmelerini kapatmamasını söylediğimizi hatırlıyorum
Son 3 yılda startup’ı neredeyse tamamen use-1 üzerinde işlettim; yalnızca bir kez region kesintisi yaşadık ve o da kısmi kesintiydi, çoğu instance etkilenmemişti
Açıkçası müşterilerin sistemleri de tamamen use-1’de olduğu için, kesintinin müşterilerle korelasyon göstermesi gibi bir avantajı var
Hayali bir sihir ülkesinde yük farklı bulut sağlayıcılarına eşit biçimde dağılır ve tek hata noktası diye bir şey olmaz
İlk kız arkadaşımla da her şey yolunda gitmiştir, ikizler İngilizce ve Korece bilir, büyük ölçekli servis dağıtırken yalnızca AWS’ye bağımlı olmamanız gerektiğini de bilirsiniz
ABD’de sağlık giderleri de karşılanabilir düzeydedir. Ama gerçek dünyada bir gün daha geçer ve tek başına AWS US-East 1 internetin büyük kısmını devirebilir
2 region için 2 kat kapasite, 3 region için 1,5 kat kapasite hazırlamanız gerekir ve multi-region kurulumda makinelerin zaten çalışıyor olması gerekir. Kesinti anında instance ayağa kaldırabileceğinizi veya kapasite bulabileceğinizi varsaymayın; ayrıca multi-region barındırmanın getirdiği ek karmaşıklığı da yönetmeniz gerekir
Birden çok region/availability zone kurgusunun bu kadar açık biçimde göstermelik görünmesine rağmen herkesin bunu bulut dininin bir inancı gibi kabul etmesi biraz komik
Bu tür bahisler riskli. Çünkü AWS’yi indirebilecek bir çalışan gibi biri bahis yapabiliyor olabilir
Bu tür bahisler göründüğü kadar zararsız değil; çünkü bahsi yapan kişi çoğu zaman sonuca etki edebilecek ya da sonucu değiştirebilecek konumda olabilir
Genel olarak bu tür prediction market’lerin insider trading ve olumsuz senaryolar için teşvik yaratabildiği görüşüne katılıyorum. Böyle bir durumdan fayda sağlamak için motivasyon doğuyor
Veri merkezlerinde soğutmanın büyük ölçüde önceden planlandığını ve soğutulabilecek olandan fazlasının kurulmadığını sanıyordum
Burada soğutma ekipmanının mı arızalandığını, aşırı ısınmanın dışsal bir nedeni mi olduğunu, yoksa Amazon’un veri merkezi soğutma kapasitesini fazla mı sattığını merak ediyorum
Bize ayrıntılar verilmedi ama katlarla çatı arasındaki borulama muhtemelen yedekli değildi ve onarım neredeyse 24 saat sürmüştü
Veri merkezi soğutmasında da diğer her şey gibi aynı anda hem aşırı provision hem de eksik provision vardır
Büyük ısı değişim ekipmanları N+1’dir ve çok kritik küçük yük tesislerinde 2N/3N kurulur; bu yüzden aşırı provision vardır. Düzenli bakım için kapatılmaları gerekir, geleneksel veri merkezi bileşenlerinden daha yüksek arıza oranlarına sahiptirler ve uzman personel ile uzun tedarik süresi gerektiren mekanik onarımlar isterler
Büyük tesislerde N büyüdükçe soğutmanın N+3 veya daha üstü olması da nadir değildir. Her zaman bakımda olan bir şeyler vardır ya da artık üretilmeyen parçalar raftan özel olarak imal ettirilir; çünkü bu, tüm ekipmanı değiştirmekten daha ucuzdur, bu yüzden parça bekleyen cihazlar olur
Öte yandan tesisin tüm bilişim kapasitesi ortalama güç tüketiminden bir anda %100’e çıkarsa soğutma kapasitesi aşılır; dolayısıyla eksik provision da söz konusudur. Elektrik ve diğer hatlar da sık sık aşırı yüklenir; sektörün doğası bir bakıma fazla satmaya yakındır
Genelde bu büyük bir sorun olmaz. Bilişim yükünün toplam kapasitenin %100’üne fırlaması nadirdir; fırlasa bile uzun sürmez ve kimse tesisi soğutma ya da güç kapasitesi tam sınırda olacak şekilde kurmaz
Sorun, birden fazla olay kesiştiğinde çıkar. Soğutma sistemi ortalama yükün %200’ünü kaldıracak şekilde tasarlanır; bu da bakım ve arızalar için yeterli pay bırakır
Salı günü tamir teknisyeni bir ünitenin bakımına gelir, rulman arızası bulur ve başka eyaletten parça getirilmesi gerekir; fan grubuna zarar verme riskinden kaçınmak için ekipmanı gece boyunca kapalı bırakırlar
Yanındaki iki soğutma ünitesi biraz daha fazla çalışmaya başlar; bunlardan birinde hafif dengesiz bir motor veya gevşeyip ısınan bir sigorta vardır ve yıllardır dayanan parça artan çalışma oranı yüzünden patlar
Artık N+2 tesiste iki ünite devre dışıdır, ama ortalama yükün %200’üne göre tasarlandığı için hâlâ kritik değildir
İlk arızalı ünitenin karşı tarafındaki üçüncü ünitede de yük artışı altında gizli bir kusur ortaya çıkarsa, N+2 tesiste üç ünite gider. Yine de sistem ortalama yükün %200’üne göre tasarlanmıştır; hâlâ tam bir felaket değildir
Ama saat sabah 4’tür, sahadaki operatör bu arızayı gideremez ve yüklenici firma ancak 7’de uyanıp 9’da sahaya gelir. Bu sırada yük artmaya başlar
Bu tür şeyler ABD’deki bir veri merkezinde her gün olur ve muhtemelen her veri merkezinde yılda bir kez yaşanır
Sonra yaşanacak bir sonraki olayın buna eklenmesi haberi oluşturur. Büyük bir müşteri bunun büyük bir batch işini başlatmak için iyi bir zaman olduğuna karar verir. Bir fintech şirketi piyasa açılmadan önce büyük bir model çalıştırır ya da bir petrol şirketi yeni sahalar için hızlı analiz yürütür
10.000 yeni VM ayağa kaldırılır. Normalde boş kapasite olduğu için sorun olmaz
Ama soğutma sadece ortalama soğutma kapasitesinin %200’üne göre planlanmıştır ve bu node’lar orta düzey meşgul node’lar değil; en yüksek gücü çekip en fazla atık ısı üreten, optimize edilmiş yoğun sayısal hesaplama yapan node’lardır
Böylece yalnızca toplam makine sayısına göre yük değil, ortalama atık ısı etkisi de artar. Sonra zincirleme arıza başlar ve soğutma N-4 olur
Sunucu fanları daha hızlı dönmeye başlar, daha fazla güç çeker ve soğutma N-5 olur. Her tarafta alarmlar çalar
Soğutma ünitelerinin güvenlik mekanizmaları, yük ve soğutucu akışkan basıncı arttıkça teker teker devreye girer; soğutma N-6, N-7 ve sonunda 0 olur
Bu yıl AB’de Hetzner’in uptime’ı AWS’den daha mı iyiydi diye merak ediyorum
Hetzner’in arayüzü bana fazla karışık geliyor ve yönetmesi zor hissettiriyor
İlgili yazı: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
Her zaman East 1. Şakayı bir kenara bırakırsak, east-1’in diğer region’lara kıyasla neden bu kadar sık çöktüğünü anlamıyorum
Mimari olarak diğer region’lara oldukça benzer olması gerekmez miydi?
Diğer region’lardan daha fazla yük alıyor ve ilk kurulduğunda tecrübe daha az olduğundan teknik borç ile mimari/mühendislik borcu da daha fazladır diye düşünüyorum
Yanlış hatırlamıyorsam IAM ya da bazı S3 yapılandırmaları gibi east-1’i tek hata noktası olarak kullanan servisler de var
Coinbase birden fazla availability zone’un etkilendiğini söyledi ama AWS açıklamasında yalnızca tek bir availability zone etkilendiği yazıyordu
Daha fazla detay bilen var mı merak ediyorum
us-east-1’de sistem çalıştırıyorum ve olay sırasında az4 dışında da daha önce görmediğim, açıklaması zor, aralıklı bağlantı sorunları gördüm
Birkaç ortamda yalnızca tek availability zone’a ait EBS volume’larda hafif bozulma vardı; kesinlikle tek availability zone (use-az4) sorunu gibi görünüyordu
Geçenlerde “Gerçek bir arkadaş, arkadaşının USE1 kullanmasına izin vermez” sözünü görmüştüm; sonra Slack’te USE1 ve oraya deploy edilen her şeyin tamamen bozulduğuna dair mesaj görünce o söz aklıma geldi
Buradaki yorumlarda us-east-1’in merkezileştiği, AWS’nin tek hata noktası olduğu, düzeltilmesi gerektiği ve oraya hiçbir şey konulmaması gerektiği gibi tanıdık laflar çok
Bu olay, çok bölgeli bir region içindeki tek bir zone’daki tek bir veri merkezinin sorunuymuş
IAM/R53 gibi şeyler gerçekten orada merkezileşmiş ve bunları dağıtık/region’lar arası bir yapıya taşımak iyi olur. Ama us-east-1’in kendisi zaten 6 zone’lu, 2026’da 7’ncisi gelmesi planlanan çok zone’lu bir region ve her zone’un içinde de birden fazla veri merkezi var
Hatırladığım kadarıyla IAM gibi global servisler çöktüğünde bunun nedeni genelde “cross-region olsaydı ölmezdi” olmaktan çok implementasyon ya da bağımlılık hataları oluyor
Bu sefer AWS global servislerinin kesintisi değildi. Daha büyük etki yaratmış görünen tek şey MSK’ydi; o da muhtemelen AWS’den ziyade Kafka tarafındaki bir sorun
Neden bunları deniz kenarına inşa etmediklerini merak ediyorum. Nükleer santraller gibi soğutma kapasitesine çok ihtiyaç duyan tesisler için de mantıklı değil mi?
Isıyı almak için ısı değiştiricili iki devreli sirkülasyon kullanılabilir gibi geliyor
1990’larda dünya internet trafiğinin yaklaşık yarısı MAE-East’ten geçiyordu ve bunun sonucu olarak AWS ilk region’unu oraya koydu. us-east-1, eu-west-1’den 2 yıl, us-west-1’den ise 3 yıl önce açıldı
Veri merkezi inşa etmeyi bilen insanlar ve tedarik sağlayabilen şirketler orada birikince Dulles Corridor, birçok şirketin veri merkezleri için büyük bir merkez oldu
AWS tarafında us-east-1 ilk region olduğu için açık ara en karmaşık ve en tuhaf olanı; diğer AWS servislerinin pek çok control plane’i buna bağımlı hâle geldi. Bu yüzden diğer region’lardan daha sık çöküyor ve çöktüğünde İspanya’daki eu-south-2 gibi değil, ülke çapında haberlere çıkıyor
NoVA burada fabrika değil veri merkezleri için bir örnek; Paul Krugman’a Nobel Ekonomi Ödülü kazandıran çalışmalardakiyle aynı tür ekonomik kümelenme söz konusu
Biri Hosting.com’un SOMA veri merkezinin aşırı ısınıp çatısından hortumla su sıkılarak soğutulmaya çalışıldığı olaydı; diğeri ise Alibaba’nın Chai Wan veri merkezinin fazla ısınıp orada çalışan her şeyi, control plane dâhil, düşürdüğü olaydı
Bu yüzden denize yakın olmanın acil ısı atımı açısından ekstra bir avantaj sağladığını düşünmüyorum. Isıyı dışarı atma kapasitesi bellidir; ister kıyıda olun ister Nebraska’nın ortasında, tüm sistem belirli bir performansı karşılayacak şekilde tasarlanmak zorundadır
Slaytlarda veri merkezi konumunu etkileyen unsurlar vardı ve bunların arasında yeterli alan ile o veri merkezinde çalışacak nitelikli iş gücünü bulmak gibi maddeler de yer alıyordu. Bazen bir sonraki veri merkezinin nereye kurulacağına siyasetin de etki ettiğini söylemişti
Kıyı arazisi çok daha pahalı ve uzak kıyı bölgelerine giderseniz elektrik erişimi iyi olmayabilir
Kıyı sahaları genelde daha sert hava olaylarına maruz kalır
Bir de öngörülemeyen şeyler var. Diablo Canyon nükleer santrali, deniz suyu soğutma alım ağzının çer çöp ve denizanası göçü nedeniyle tıkanması gibi sorunlar yaşadı
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
Suyun yeterince derin olması gerekir; aksi takdirde yüzey sıcaklığına kadar ısınır. Ayrıca geleneksel evaporatif soğutmayla maliyet açısından da rekabet edebilmelidir
Bunun iyi işlediği ders kitabı örneği Toronto’dur. Kıyıya nispeten yakın, derin bir tatlı su gölü vardır ve şehir merkezinde gayrimenkul pahalı olduğu için geleneksel yöntemler kısıtlıdır
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System