Saat gece 3'ü gösterirken bir kullanılabilirlik bölgesi (availability zone) aniden çöker. Eğer sisteminiz iyi tasarlanmışsa hiçbir şey olmaz; trafik yönlendirilir, yedekler devreye girer ve siz uykunuza devam edersiniz. Ama değilse, ölü bir servisle uyanır, CEO'nun 'ne zaman döneriz?' sorusuyla ve daha da kötüsü 'ne kadar veri kaybettik?' sorusuyla yüzleşirsiniz. İşte bu iki soru, ne kadar süre ve ne kadar veri, bu makalenin tam konusudur.
Çoğu mühendis yüksek kullanılabilirliği (High Availability - HA) ve felaket kurtarmayı (Disaster Recovery - DR) birbirine karıştırır. Oysa bunlar aynı şey değildir, maliyetleri çok farklıdır ve ikisini tek bir plan olarak ele almak, ya hiç kullanılmayacak bir dayanıklılığa aşırı harcama yapmanıza ya da gerçek bir kesinti sırasında 'yedeklerinizin' geri yüklenemeyeceğini keşfetmenize yol açar. Bu konu kıdemli mühendisler içindir çünkü zor olan teknoloji değil, ne kadar dayanıklılığa para harcamaya değer olduğuna karar vermektir.
Yüksek kullanılabilirlik, tek bir arızanın kesintiye yol açmaması için tasarım yapmaktır. Felaket kurtarma ise, tek bir arızadan daha büyük bir olay sizi devre dışı bıraktığında geri dönüş planıdır. HA, hala çalışan bir sistem içindeki yedeklilikle ilgilidir: iki uygulama sunucusu bir yük dengeleyici arkasında, yedek kopyası olan bir veritabanı, kullanılabilirlik bölgelerine yayılmış. DR ise sistemin kendisi yok olduktan sonra yeniden inşa etmekle ilgilidir: bölge çapında kesinti, tüm kopyaları bozan kötü bir dağıtım, fidye yazılımı saldırısı, production'da yanlışlıkla rm -rf çalıştırmak. HA'nın bunlara cevabı yoktur, DR'ın vardır.
Nasıl Önlem Alınmalı?
Her DR konuşması, iş birimleriyle anlaşılmış ve yazılı hale getirilmiş iki sayı ile başlamalıdır: RTO (Recovery Time Objective) ve RPO (Recovery Point Objective). RTO, 'ne kadar süre kapalı kalabiliriz?' sorusunu yanıtlarken, RPO 'ne kadar veri kaybedebiliriz?' sorusunu yanıtlar. RTO, felaketten sonraki süreyi ölçer; RPO ise son yedekleme ile felaket arasındaki süreyi. Her ikisini de düşürmek maliyetlidir ve bu kararlar iş tarafından verilmelidir. Bir iç aracın ve bir ödeme sisteminin çok farklı RTO/RPO değerleri olmalıdır.
DR stratejileri, ucuz ve yavaştan pahalı ve anlık olana kadar bir spektrumda sıralanır. En yaygın dört strateji: Yedekle ve Geri Yükle (Backup & Restore): Veriler ve altyapı kodu başka bir bölgeye yedeklenir, kesintide her şey sıfırdan kurulur; saatler süren RTO/RPO, en ucuz seçenek. Pilot Işık (Pilot Light): Kritik veritabanı sürekli çoğaltılır ve DR bölgesinde her zaman açıktır; diğer bileşenler şablon olarak bekler; devreye almada veri sıcak olduğu için dakikalar mertebesinde RTO/RPO. Sıcak Bekleme (Warm Standby): Eksiksiz ama düşük kapasiteli bir kopya DR bölgesinde sürekli çalışır; kesintide ölçeklenir ve trafik yönlendirilir; RTO/RPO dakikalar/saniyeler. Çoklu Site Aktif/Aktif (Multi-Site Active/Active): Her iki bölge de tam kapasite çalışır ve trafik alır; bir bölge düştüğünde trafik diğerine kayar; neredeyse sıfır RTO/RPO, ancak en pahalı seçenek.
Önemli Gelişmeler
Sonuç olarak, HA ve DR'ı ayrı ayrı planlayın ve bütçelendirin. HA, rastgele donanım arızalarına karşı korurken, DR, ilişkili ve felaket boyutundaki arızalara karşı korur. RTO ve RPO değerlerini iş ihtiyaçlarına göre belirleyin ve bu değerleri karşılayan en ucuz DR stratejisini seçin. Unutmayın: RTO/RPO iş kararlarıdır, mühendislik kararları değil. Doğru sayıları bulmak için iş birimlerine 'son 5 dakikalık siparişi kaybetmenin maliyeti nedir?' ve 'Salı günü 4 saat kapalı kalmanın maliyeti nedir?' gibi sorular sorun.
Kaynak: dev.to
