Bir web uygulaması para kazandırıyorsa ya da iş sürekliliği ona bağlıysa, tek sunucuda çalıştırmak kumar oynamaktır. Bu yazıyı ilk yayınladığımda Azure App Service üzerine yaptığım bir Cloud Talk konuşmasının özetiydi; sunum linki çoktan emekli oldu ama konu bugün daha da güncel. Kritik bir web uygulamasını Azure’da ayakta tutmak için hangi servislerin ne işe yaradığını, sahada kurduğum mimarilerden süzerek anlatayım.
Neden App Service?
Azure App Service, web uygulamanızı sunucu yönetmeden çalıştırdığınız platform. İşletim sistemi yamaları, web sunucusu yapılandırması, güvenlik güncellemeleri Microsoft’un sorumluluğunda; siz sadece kodunuzu dağıtıyorsunuz. Sanal makinede site barındıran biriyseniz farkı ilk ay hissedersiniz: gece yarısı yama geçme, disk doldu alarmı, IIS uygulama havuzu çökmesi gibi dertlerin tamamı masadan kalkıyor.
Kritik uygulama tarafında asıl değer ölçekleme ve yedeklilikte. App Service planınızı dikey büyütebilir, daha önemlisi kural bazlı yatay ölçekleme kurabilirsiniz: CPU yüzde 70’i geçince yeni instance ekle, gece trafiği düşünce geri çek. Trafiği önceden kestirilemeyen kampanya siteleri için bu özellik tek başına platform tercih sebebi.
Yüksek erişilebilirlik: iki bölge, aktif-aktif
İşin kalbi burası. Tek bölgedeki en iyi kurulum bile o bölgenin kesintisinde sizinle beraber düşer. Kritik uygulamada standart reçetem şu: uygulamayı iki ayrı Azure bölgesinde aktif-aktif çalıştırmak ve önüne global bir yük dengeleyici koymak.
Bu global katman için güncel araç Azure Front Door. Kullanıcıyı en yakın sağlıklı bölgeye yönlendirir, bir bölge sağlık kontrolünden geçemezse trafiği saniyeler içinde diğerine akıtır. Üzerinde Web Application Firewall da açabildiğiniz için güvenlik katmanını da aynı noktada çözersiniz. Eski kurulumlarda bu iş için Traffic Manager kullanırdık; DNS tabanlı çalıştığı için geçiş süreleri daha uzundu, yeni projelerde tercihim Front Door.
Bölge içinde de bir yedeklilik katmanı var: App Service’in ölçeklendirilmiş instance’ları zaten farklı donanımlara dağılır, Premium katmanlarda availability zone desteğiyle instance’larınızı bölge içindeki ayrı veri merkezlerine yayabilirsiniz.
Veritabanını unutmayın
Web katmanını iki bölgeye yaydınız; peki veritabanı? Azure SQL kullanıyorsanız failover group kurarak veritabanının ikinci bölgede sürekli eşitlenen bir kopyasını tutarsınız; kesintide bağlantı adresi değişmeden ikinci bölgeye döner. Bu adım atlanırsa yaptığınız şey yüksek erişilebilirlik değil, süslü bir tek nokta arızasıdır. Projelerimde gördüğüm en yaygın eksik tam olarak bu: web önyüzü çift bölgeli, veritabanı tek bölgede.
Maliyet gerçeği
İki bölgeli aktif-aktif mimari kabaca iki kat App Service maliyeti artı Front Door demek. Her uygulama bunu hak etmiyor; aylık cirosu kesinti maliyetinin altında kalan bir site için tek bölge, iyi yedekleme ve hızlı kurtarma planı çoğu zaman yeterli. Benim müşterilerime sorduğum soru hep aynı: bu uygulama bir saat kapalı kalırsa kaç para kaybedersiniz? Cevap Front Door faturasından büyükse mimari kendini ödüyor demektir.
Toparlayalım
- App Service, sunucu yönetim yükünü Microsoft’a devredip kritik uygulamada işinize odaklanmanızı sağlar.
- Gerçek yüksek erişilebilirlik iki bölge, aktif-aktif kurulum ve önde Azure Front Door ile gelir.
- Veritabanı katmanına failover group kurmadan mimari tamamlanmış sayılmaz.
- Karar ölçüsü basit: bir saatlik kesintinin maliyeti, yedekli mimarinin faturasını geçiyor mu?
Azure tarafında site-to-site VPN kurulumu yazıma da göz atabilirsiniz. Sorularınız olursa yorumlarda buluşalım.
Bora Hocam,
Yıllarca seninle omuz omuza çalıştığım için ayrıca bu sunumunu görünce mutlu oldum. Belki bir gün gene beraber çalışma fırsatımız olur. Microsoft Azure üzerine senden öğrenecek olduğumuz konu var konular hakkında yeni yazıların hevesle beklemekteyim.
Saygılarımla.
Çok teşekkür ederim Cem, senin gibi değerli bir meslektaşımdan bu mesajı almak beni çok mutlu etti, tekrar birlikte çalışma fırsatımız olur umarım!