Multi-Bulut Mimarisi: Tek Başarısızlık Noktasından Sakınmak Yeterli mi?

Görüntüsü Kusursuz, Gerçeği İse Farklı

Altyapı dünyasında biraz zaman geçirdin mi, aynı argümanı defalarca duyarsın: işyüklerini AWS'ye, Google Cloud'a ve kendi sunucularına dağıt, böylece tek bir sağlayıcının arızası seni etkilemez. Mantıklı geliyor. Böyle olması gerekiyor.

Railway, modern bir bulut dağıtım platformu, tam da bu düşüncede idi. Müşterilerinin uygulamaları Google Cloud, AWS ve kendi özel altyapısı Railway Metal'da çalışıyordu. Her bakış açısından yedeklilik sağlanmış görünüyordu.

Sonra 19 Mayıs 2026 akşamı her şey çöktü. Nedeni bir hava olayı değildi, bilinen bir güvenlik açığı da değildi. Hatta Google Cloud'un gerçek bir altyapı sorunu da yoktu. Google Cloud'un otomatik sistemleri, hiç uyarı vermeden Railway'in üretim hesabını yanlışlıkla askıya aldı. Mühendisler sabah boyunca uğraştıktan sekiz saat sonra, Railway nihayet yeniden hizmete girdi.

En kötü kısmı ise şu: Aslında tüm uygulamalar sorunsuz çalışıyordu.

Görünmeyen Engel: Kontrol Sistemi de Kritik Altyapıdır

Burada mimari hakikaten ilginçleşiyor ve derstir burada gizlidir.

Railway barındıran bir uygulamaya gelen her istek doğrudan uygulamaya gitmiyor. İstekler ağ kenarında bulunan edge proxy'lere çarpıyor; bu akıllı reverse proxy'ler her isteği nereye yönlendireceğine karar veriyorlar. Bu proxy'lerin bilmesi gereken önemli bir şey var: bu uygulama şu anda nerede çalışıyor?

Bu yönlendirme bilgisi kontrol düzleminden geliyor—basitçe söylemek gerekirse "bu işyükü burada, o işyükü orada" diye kaydedilmiş bir veritabanı. Railway'in kontrol düzlemi? Tamamen Google Cloud üzerinde.

Google Cloud hesabı askıya alındığında, kontrol düzlemi karardı. Edge proxy'ler hemen panik yapmadı. Yönlendirme tablosunun yerel bir kopyasını tutuyorlardı—bu cache yaklaşık 35 dakika boyunca güncel kaldı. İstekler akıp gitti. AWS ve Railway Metal üzerindeki işyükleri rahatça çalışmaya devam etti.

Sonra cache süresi bitti.

O anda proxy'ler trafiği nereye göndereceğini bilmedi. Her tek istek—altında çalışan işyükün AWS'de ya da Railway Metal'de sağlıklı ve aktif olup olmaması fark etmeksizin—404 hatası döndürdü. Müşteri perspektifinden Railway tamamen çökmüştü.

Sorun Zincirleme Büyüyor: Bir Arıza Başkasını Tetikliyor

Durumun daha kötüleşemeyeceğini düşünüyorsunuz, sonra kötüleşiyor.

Başarısız isteklerin ve yeniden deneme çabaları, GitHub'ın Railway OAuth uç noktalarına karşı hız sınırlamasını tetikledi. Bu GitHub'ın arızası değildi; GitHub tam da yapması gerekeni yaptı—kendini saldırı gibi görünen şeyden korumak.

Sonuç? Kullanıcılar Railway'e giriş yapamadı. Dağıtımlar tetiklenemedi. Kontrol düzlemi geri geldi ve diğer hizmetler kurtulduktan sonra dahi, bu ikinci arıza kullanıcı erişimini engellemeye devam etti. Kapı nihayet açıldığında alarm sisteminin hala aktif olduğunu görmek gibiydi.

Asıl Ders: Orkestrasyon Olmadan Yedeklilik Sadece Gösterişse Kalıyor

Bu olay deneyimli mimarları bile yanıltan bir gerçeği ortaya serinç: dağıtılmış işyükleri ile dağıtılmış kontrol sistemleri arasında fark vardır.

Railway birincisini başarmıştı. Gerçek uygulama konteynerları birden fazla bulut ve bare metal'de çalışıyordu. Bunu iyi yapmak zordur; onlar başarmışlardı.

Ama kontrol düzlemi—dünyanın bu işyüklerinin nerede olduğunu söyleyen şey—tek bir yerde yaşıyordu. Google Cloud'un hesap yönetim sisteminin otomatik bir eylemi (şüpheli aktiviteyi yakalamak için tasarlanmış) tüm şirketin yönlendirme altyapısını dibe attı.

Bu yüzden son zamanlarda bulut mimarisinde kontrol düzlemi yedekliğine artan ilgi görüyoruz. İlgi çekici değil. Performans karşılaştırmalarında yer almıyor. Ama başarısız olduğu zaman, bütün yapı çöküyor.

Senin Mimarinde Bu Ne Anlama Geliyor?

Eğer altyapı kuruyorsan, özellikle de multi-bulut esnekliğine bahis oynuyorsan, Railway'in bu olayı sert dersler sunuyor:

Kontrol düzlemi ve veri düzlemi farklı şeylerdir. İşlemleriniz dağıtılabilir, ama yönlendirme, orkestrasyonu ve hizmet keşfi tek bir yerde yaşıyorsa, düşündüğünü satın almamışsın demektir. Bu dağılım sadece vitrin dekorasyonu olmuş.

Cache geçici bir merhemdir, çözüm değildir. Evet, Railway'in cache yapılı yönlendirme verisi 35 dakikada daha aktif çalışma zamanı kazandırdı. Bu hiç yoktan iyidir. Ama cache süresi dolma anlamına gelir saatin Google Cloud'un çökmesiyle birlikte geriye doğru sayıyordur. Sadece taktiksel zaman kazanç değil, mimari çözümlere ihtiyacın var.

Zincirleme arızalar gerçek ve hızla yayılırlar. GitHub hız sınırlamaya başladığında, kurtarma süreci daha yavaş ve karmaşık hale geldi. Her başarısız istek yeni arıza koşulları doğuruyor. İşte bu yüzden arıza yanıt prosedürleri, mimari seçimler kadar önem taşıyor.

Bulut sağlayıcın otomatik sistemleriyle konuş. Railway, Google Cloud'un hesap askıya alma sistemini tetiklemeyi engelleyemedi—bu Google'ın güvenlik altyapısı işini yapıyor. Ama bu otomasyonları nelerin tetiklediğini bilmek ve açık iletişim kanalları olmak (acil destek yükseltmeleri gibi) müdahale etme şansı verir.

Aydınlık Tarafı

Adaletle söylememiz gerekirse, Railway bunu ciddiye aldı. Google Cloud'u veri düzleminden çıkarmaya ve kontrol düzlemini AWS ile Railway Metal arasında genişletmeye açıkça taahhüt etti. Bu tür pahalı, kesintiye neden olan işler gerçekten problemleri çözer.

Kalan hepimiz için bu, bulut mimarisinin gizli bağımlılık ve tek başarısızlık noktası bulma oyunu olduğinin hatırlatması. Savaş odamızda bulduklarımız öğrenme tecrübesi. 22:19 UTC'de üretim ortamında keşfettiklerimiz ise pahalı olma eğilimindedir.

Senin multi-bulut kurulumunun hikayesi ne? Altyapında benzer gizli bağımlılıklar keşfettin mi? Arıza yanıt topluluğu paylaşılan hikayelerden en iyi şekilde öğrenir—yorumlarında veya sosyal medyada paylaş.