Bir haftada üç veri merkezi: Yandex Cloud kesintisi felaket kurtarma planlarımıza ne söylüyor?

Bulut mimarisi anlatılırken neredeyse her zaman aynı cümle kurulur: "Uygulamanı birden fazla erişilebilirlik bölgesine (availability zone) dağıt, bir veri merkezi çökse de ayakta kalırsın." Geçen hafta Rusya'da yaşananlar, bu cümlenin hangi varsayımlara dayandığını hatırlatan nadir ve somut bir örnek oldu.

Bu yazıda olayın siyasi boyutuna değil, altyapı tarafına odaklanacağım: Ne oldu, bulut müşterileri neyle karşılaştı ve bizim kendi sistemlerimiz için hangi dersleri çıkarabiliriz?

Ne oldu?

Yayımlanan haberlere göre Yandex'e ait üç veri merkezi, birkaç gün arayla drone saldırılarına uğradı:

• 8 Ekim: Ryazan bölgesindeki Sasovo veri merkezinde yangın çıktı ve tesis tamamen durdu.
• 9 Ekim: Kaluga'daki veri merkezinde birkaç modül devre dışı kaldı.
• 11 Ekim: Vladimir'deki veri merkezi tamamen kapandı. Aynı gün Yandex Cloud, ru-central1-a erişilebilirlik bölgesinde elektrik kesintileri olduğunu duyurdu.

Yandex Cloud'un kendi dokümantasyonuna göre platform, dört veri merkezine yayılmış ve hepsi ru-central1 önekini taşıyan birkaç erişilebilirlik bölgesinden oluşuyor. Yani kâğıt üzerinde tipik bir "tek bölge, çoklu zone" mimarisi. Bir haftadan kısa sürede bu tesislerin üçünün etkilenmesi, söz konusu mimarinin tasarlanırken pek hesaba katılmayan bir senaryoyla karşılaştığı anlamına geliyor.

Müşteriler neyle karşılaştı?

BleepingComputer'ın 12 Ekim tarihli haberine göre Yandex, kalan kaynak yapılandırmasını "istikrarsız" olarak nitelendiriyor ve platformun acil durum modunda çalıştığını söylüyor. Aynı habere göre son durum güncellemesinde konsol, API, IAM, Container Registry, veritabanları, S3 uyumlu depolama ve Kubernetes "performans veya erişilebilirlik sorunlarıyla" çalışıyordu; Compute ve bazı güvenlik servisleri kısmen erişilebilirdi, Monium izleme servisi ise tamamen kapalıydı.

Benim gözümde asıl dikkat çekici olan birkaç ayrıntı var:

1. Yandex müşterilerine kendi alternatif felaket kurtarma planlarını devreye almalarını önerdi. Yani sağlayıcı açıkça "şu an size güvenilir bir toparlanma süresi veremiyoruz" diyor.
2. Ayakta kalan bölgelerde yeni kaynak açmaya kısıtlama getirildi. The Insider'ın aktardığına göre yeni sanal makine, Kubernetes kümesi ve veritabanı oluşturma tarafında sınırlamalar sürüyordu. "Bir zone giderse diğerinde yenisini açarım" stratejisi, herkes aynı anda aynı şeyi yapmaya çalıştığında işe yaramıyor.
3. Destek kanalları da etkilendi. Yoğunluk nedeniyle teknik destekte gecikmeler yaşandı.
4. Kullanıcı sözleşmesi güncellendi. Kyiv Independent'ın haberine göre Yandex 10 Ekim'de kullanıcı sözleşmesini değiştirerek drone ve füze saldırılarını mücbir sebep (force majeure) olayları arasına ekledi.
5. Donanım tedariki zaman alıyor. The Insider, Kommersant'a konuşan bir sektör kaynağına dayanarak yedek ekipman teslimatının altı aya kadar sürebileceğini aktarıyor.

Veri kaybı olup olmadığı ise şu an için belirsiz; Yandex bu konuda bir açıklama yapmadı.

Çoklu zone neyi korur, neyi korumaz?

Erişilebilirlik bölgeleri genellikle tek bir veri merkezindeki elektrik, soğutma, ağ veya donanım arızasına karşı tasarlanır. Bu senaryolarda gerçekten çok iyi çalışırlar. Ancak zone'lar aynı bölgede, aynı kontrol düzleminde (control plane) ve çoğu zaman aynı tedarik zincirine bağlı olarak çalışır.

Bu olay, birbirinden bağımsız sandığımız arızaların aslında ilişkili (correlated) olabileceğini gösteriyor. Aynı nedenle birden fazla tesis etkilendiğinde:

• Ayakta kalan zone'lar ani yük artışıyla karşılaşır,
• Sağlayıcı kapasiteyi korumak için yeni kaynak açılmasını kısıtlar,
• Ortak servisler (IAM, konsol, izleme) de sorun yaşamaya başlar,
• Ve toparlanma, fiziksel donanım gelene kadar uzayabilir.

Bu tablo yalnızca savaş bölgelerine özgü değil. Büyük bir deprem, bölgesel elektrik krizi, sel veya yaygın bir yazılım hatası da benzer ilişkili arızalar üretebilir. Türkiye'de altyapı planlayan herkes için deprem senaryosu zaten gündemde olmalı.

Pratikte ne yapmalı?

Her sistemin çok bölgeli, çok sağlayıcılı olması gerekmiyor; bu ciddi bir maliyet ve karmaşıklık demek. Ama aşağıdaki soruları bilinçli olarak yanıtlamış olmak gerekiyor.

1. RTO ve RPO'nuzu yazılı hâle getirin

Bir sistemin ne kadar süre kapalı kalabileceği (RTO) ve ne kadar veri kaybını tolere edebileceği (RPO) iş tarafıyla birlikte konuşulmalı. "Birkaç saat" ile "birkaç hafta" arasındaki fark, mimari kararları tamamen değiştirir.

2. Yedeklerin en az bir kopyası sağlayıcının dışında olsun

Aynı sağlayıcının aynı bölgesindeki yedek, bu tür bir olayda birincil veriyle birlikte erişilemez hâle gelebilir. Klasik 3-2-1 kuralı (üç kopya, iki farklı ortam, bir kopya başka yerde) hâlâ geçerli. Örneğin nesne depolamadaki kritik verileri farklı bir sağlayıcıya periyodik olarak kopyalamak için rclone gibi araçlar yeterli olabilir:

rclone sync birincil:uretim-yedekleri ikincil:uretim-yedekleri --checksum

3. Kapasiteyi felaket anında bulacağınızı varsaymayın

Planınız "diğer zone'da yeni sunucu açarız" ise, o kapasitenin o anda size verileceğini garanti eden bir mekanizmanız olmalı: önceden ayrılmış kapasite, sıcak bekleme (warm standby) ortamı veya başka bir bölge/sağlayıcı.

4. Altyapıyı kodla tanımlayın ve başka yerde ayağa kaldırmayı deneyin

Terraform, OpenTofu, Pulumi veya Kubernetes manifest'leriyle tanımlanmış bir altyapı, başka bir ortama taşınabilir bir başlangıç noktası sunar. Ama bu ancak düzenli olarak denendiğinde anlam kazanır. Hiç test edilmemiş bir felaket kurtarma planı, çoğu zaman yalnızca bir belgedir.

5. Yönetilen servislere bağımlılığı haritalayın

Kimlik yönetimi, DNS, gizli anahtar yönetimi ve izleme gibi servisler genellikle göz ardı edilir. Yandex örneğinde izleme servisinin tamamen kapanması, kriz anında sistemin durumunu görmenin bile zorlaşabileceğini gösteriyor. İzleme ve uyarı altyapısının en azından bir parçasını izlediği sistemden bağımsız tutmak iyi bir pratik.

6. SLA metnini okuyun

SLA'lar genellikle kredi iadesi sağlar, işinizin kaybını telafi etmez. Mücbir sebep maddeleri de bu kredilerin bile hangi durumlarda geçerli olmadığını belirler. Kritik iş yükleri için sözleşme maddelerini hukuk ekibiyle birlikte gözden geçirmek gerekir.

Son söz

Bu olay, bulutun soyut bir kavram olmadığını, sonunda belirli şehirlerde duran binalar, kablolar ve sunuculardan oluştuğunu sert bir şekilde hatırlatıyor. Çoklu zone mimarisi hâlâ değerli; ama tek başına bir felaket kurtarma planı değil. Kendi sistemleriniz için şu soruyu sormak iyi bir başlangıç olabilir: "Sağlayıcımın bir bölgesinin tamamı iki hafta boyunca kısıtlı çalışsa ne yapardık?" Bu soruya net bir yanıtınız yoksa, bu haftanın gündemine eklemeye değer.