Bulut mimarisi tasarımı: çerçeve sorularıyla değerlendirme

Bulut mimarisi tasarımı neyi kapsar?

Bulut mimarisi tasarımı, bir iş yükünün bulutta hangi hizmetlerle, hangi düzende ve hangi kısıtlarla çalışacağına karar verme işidir. Yalnızca "hangi hizmeti seçelim" sorusu değildir; aynı zamanda hata olduğunda ne olacağı, yük arttığında nasıl ölçekleneceği, kimin neye erişeceği, maliyetin nasıl izleneceği ve ekibin sistemi nasıl işleteceği sorularının cevabıdır.

İyi bir mimari karar, tek bir doğru cevaba dayanmaz; çelişen hedefler arasında bilinçli bir denge kurar. Daha yüksek dayanıklılık maliyeti artırır, daha sıkı güvenlik geliştirme hızını yavaşlatabilir. Mimarinin işi bu takasları görünür kılmak ve iş sahibinin kararına dayanak oluşturmaktır. Bu denge sorularını sistematik sormak için sağlayıcıların yayımladığı çerçeveler kullanılır.

Well-Architected çerçevesi nedir?

Well-Architected, bir mimarinin kalitesini ortak başlıklar altında değerlendirmeye yarayan sağlayıcı çerçevesidir. AWS'nin çerçevesi altı sütun üzerine kuruludur: operasyonel mükemmellik (operational excellence), güvenlik, güvenilirlik (reliability), performans verimliliği, maliyet optimizasyonu ve sürdürülebilirlik. Diğer büyük sağlayıcıların da benzer çerçeveleri vardır; sütun sayısı ve adları sağlayıcıya göre değişir, bu nedenle kullandığınız sağlayıcının güncel dokümantasyonuna bakmak gerekir.

Çerçeve bir kontrol listesi değil, bir soru setidir. Her sütunda mimariye "bu iş yükünde bu risk nasıl ele alınıyor" diye sorulur; cevaplar boşlukları ve öncelikleri ortaya çıkarır. Çerçevenin değeri tek tek soruların kendisinden çok, ekibi aynı konuları ortak bir dille konuşmaya zorlamasındadır.

Adım adım: bir mimari nasıl tasarlanır?

Tasarım şu akışla ilerler.

Önce gereksinimler yazılır. İşlevsel olmayan hedefler (kullanılabilirlik, gecikme, veri kaybı toleransı, uyum yükümlülükleri) ölçülebilir hale getirilir; belirsiz kalan hedef tasarımı da belirsiz kılar. Sonra iş yükü bileşenlerine ayrılır: giriş katmanı, uygulama, veri, entegrasyon, izleme.

Her bileşen için seçenekler karşılaştırılır. Yönetilen hizmet mi yoksa kendi işleteceğiniz çözüm mü, sunucusuz mu yoksa konteyner mi, eşzamanlı mı yoksa olay tabanlı mı? Her seçimin gerekçesi bir mimari karar kaydında tutulur. Ardından çerçeve soruları üzerinden değerlendirme yapılır: tek hata noktası var mı, veri şifreli mi, kimlik ve yetkiler en az yetki ilkesine uyuyor mu, maliyet kimin sorumluluğunda, performans nasıl ölçülecek?

Son adım iyileştirme planıdır. Bulunan riskler önem sırasına dizilir, her birine sahip ve takvim atanır. Mimari bir kez çizilip bırakılmaz; çerçeve değerlendirmesi düzenli aralıklarla ve iş yükü ciddi biçimde değiştiğinde yinelenir.

Her sütunda somut sorular

• Operasyonel mükemmellik: Dağıtımlar otomatik mi? Olay olunca kim, hangi kılavuzla müdahale ediyor? Değişiklikler izlenebilir mi?
• Güvenlik: Kimlik ve yetki yönetimi merkezi mi? Veriler beklerken ve aktarım sırasında şifreli mi? Güvenlik olayları algılanıp kaydediliyor mu?
• Güvenilirlik: Tek hata noktası var mı? Ağ ve bölge kesintisinde sistem ne yapıyor? Yedekten geri yükleme sınandı mı?
• Performans verimliliği: Kaynak boyutları gerçek yüke göre mi seçildi? Önbellekleme ve ölçekleme kullanılıyor mu?
• Maliyet optimizasyonu: Maliyet iş birimine atfediliyor mu? Kullanılmayan kaynaklar kapatılıyor mu?
• Sürdürülebilirlik: Kaynaklar ihtiyaçtan büyük mü kurulmuş? Gereksiz çalışan iş yükleri var mı?

Bu soruların her biri bir mimari kusurun erken işaretidir. Sorulara "evet, ama" diye yanıt verilen yerler, iyileştirme planının asıl girdileridir.

Örnek senaryo: kampanya yüküne açık bir e-ticaret uygulaması

Örneğin bir e-ticaret sitesi kampanya dönemlerinde ani yük alıyor. İlk tasarım tek bir sunucu grubunda uygulama ve veritabanını birlikte çalıştırıyor. Çerçeve değerlendirmesi şunu gösterir: veritabanı tek hata noktası (güvenilirlik), ölçekleme el ile yapılıyor (performans ve operasyon), günlükler dağınık (operasyon), yük dışında da büyük kaynaklar çalışıyor (maliyet).

İyileştirme planı şöyle olabilir: veritabanı yönetilen, çok erişilebilirlik alanlı hizmete taşınır; uygulama katmanı yük altında otomatik ölçeklenir; statik içerik önbelleğe alınır; günlükler merkezi bir yerde toplanıp uyarılara bağlanır; kaynaklar etiketlenerek maliyet birimlere atfedilir. Bu değişikliklerin her biri tek bir sütunu değil birkaçını aynı anda geliştirir; çerçevenin gösterdiği şey de budur. Değerlendirme sırasında ayrıca bir yük testi planlanır: otomatik ölçeklemenin eşiği, veritabanı bağlantı sınırları ve önbellek davranışı gerçek kampanya yüküne benzer bir senaryoda denenir. Test sonuçları, hangi iyileştirmenin ilk sırada yapılacağını tahmin yerine ölçüme dayandırır.

Sık yapılan hatalar

• Çerçeveyi bir kez doldurulup unutulan form olarak görmek.
• Gereksinimleri ölçülebilir yazmamak; "yüksek kullanılabilirlik" gibi belirsiz hedeflerle tasarım yapmak.
• Her sütunda en üst düzeyi hedeflemek; takaslar görmezden gelindiği için bütçe ve zaman yetmez.
• Güvenliği sona bırakmak; sonradan eklenen güvenlik pahalı ve eksik kalır.
• Mimari karar gerekçelerini kaydetmemek; birkaç ay sonra kimse neden o seçimin yapıldığını bilmez.
• Tek bir sağlayıcı çerçevesini körü körüne uygulamak; çerçeve bir rehberdir, iş yükünün özel koşullarının yerini tutmaz.
• Operasyon ekibini tasarıma dahil etmemek; işletemeyeceği bir mimari ortaya çıkar.

Nasıl öğrenilir ve Mindset programlarında nerede çalışılır?

Bir sağlayıcıdaki temel hizmet gruplarını (hesaplama, depolama, ağ, veritabanı, kimlik) öğrendikten sonra, çalıştığınız kurumdaki bir uygulamanın mimarisini çizip çerçevenin sorularıyla değerlendirmek en hızlı öğrenme yoludur. Mimari karar kaydı tutma alışkanlığını erken edinin: her kayıtta bağlam, seçilen çözüm, reddedilen alternatifler ve sonuçları kısaca yazılır. Altyapıyı kodla tanımlayan bir aracı öğrenmek de tasarımınızı tekrarlanabilir ve gözden geçirilebilir yapar.

Mindset kataloğundaki AWS Well-Architected Framework Değerlendirme Atölyesi programının modülleri çerçevenin yapısı ve sütunlar, değerlendirme yöntemi ve hazırlık, bulgu analizi ve risk sınıflandırması, iyileştirme planı ve takip başlıklarından oluşuyor. Bulut Doğal (Cloud-Native) Uygulama Tasarım Prensipleri programı ise on iki faktör ilkeleri, durum yönetimi ve veri tasarımı, dayanıklılık ve hata toleransı desenleri, gözlemlenebilirlik ve dönüşüm yol haritasını işliyor.