Bölgeler ve kullanılabilirlik alanları arasında kullanılabilirliği planlayın

Kullanıcı işlemiyle başlayın

Yüksek kullanılabilirlik (HA), bileşen arızalarına rağmen hizmeti kullanılabilir tutmayı amaçlar. Mimariyi seçmeden önce kullanılabilirliği tanımlayın. Tüm rezervasyon istekleri başarısız olurken başarıyla yüklenen bir rezervasyon sayfası, kullanılabilir bir rezervasyon hizmeti değildir.

Önemli işlem için bir hizmet seviyesi hedefi (SLO) belirleyin. Hangi isteklerin sayılacağını, başarının ne anlama geldiğini ve ölçüm dönemini tanımlayın. Bulut hizmetinin SLA’sı, o sağlayıcının taahhüdünü açıklar. Uygulamanızın ölçülmüş kullanılabilirliğini ortaya koymaz.

Örnek olarak, zamana dayalı %99,9 kullanılabilirlik, 30 günlük ayda 43,2 dakika kullanılamama süresine izin verir. İsteğe dayalı SLO farklı bir payda kullanır. Bu ölçütlerin hiçbiri ne kadar veri kaybedebileceğinizi söylemez veya tek bir kesintinin azami süresini garanti etmez.

Hata sınırlarını anlayın

AWS Availability Zone (AZ), bir Region içindeki yalıtılmış altyapı konumudur. Bir Region birden fazla AZ içerir. Çok bölgeli tasarım, iş yükü bileşenlerini Region’lar arasında dağıtır. Diğer sağlayıcıların sınırları ve hizmet davranışları farklıdır; seçilen hizmeti inceleyin.

Bunlar tasarım seçenekleridir; kullanılabilirlik garantileri değildir. Bir etiket, gereken her bileşenin amaçlanan sınırı kullandığını kanıtlamaz.

İstek yolunun tamamını izleyin

Kurgusal bir rezervasyon hizmetini ele alın. Web kopyaları iki AZ’de çalışır. Her ikisi de AZ A’daki tek veri tabanını ve tek dış bağlantı ağ geçidini kullanır. Ödeme sağlayıcısını çağırmak için bu ağ geçidi gerekir.

AZ A arızalanırsa AZ B’deki web kopyası sağlıklı kalabilir, ancak rezervasyon yine de başarısız olur. Ekip; veri tabanını, ağ yolunu, kimlik sağlayıcısını, ödeme bağımlılığını ve yönlendirmeyi değerlendirmelidir. Yönetilen veri tabanının gerçek modunu inceleyin: replikasyon, failover ve okuma kopyalarının davranışı ürüne ve yapılandırmaya göre değişir.

Kapasiteyi de kontrol edin. Ayakta kalan kaynaklar gereken yükü karşılamalıdır. Olay sırasında kapasite oluşturmaya dayanan tasarım, kotalara, mevcut kaynaklara ve kontrol düzlemi işlemlerine bağımlıdır.

Tanımlı sınırı, durdurma koşulları ve sorumlusu olan kontrollü bir alıştırma yürütün. Ödeme mutabakatı dahil, eksiksiz rezervasyonu doğrulayın. Başarısız istekleri ve kullanılabilir işleyişin geri gelme süresini kaydedin.

Başka bir Region’ın sorunu çözüp çözmediğine karar verin

Çok bölgeli işletim; veri aktarımı, yinelenen kaynaklar, dağıtım koordinasyonu ve işletim işi ekler. Aktif/pasif düzende bir ortam trafik almaya hazır tutulur. Aktif/aktif düzen, birden fazla ortamda trafiğe hizmet verir. Gereken hazırlık ve veri davranışı farklıdır.

Rezervasyon hizmetinde eşzamanlı yazmalar bir soru doğurur: iki Region aynı koltuğu satabilir mi? Bir rezervasyonun yetki kaynağını ve replikasyon kesildiğindeki davranışı tanımlayın. “Veri tabanını replike edin” eksiksiz bir yanıt değildir.

İzin verilen veri konumlarını, şifreleme anahtarlarını, sertifikaları, DNS’i, gizli bilgileri ve dış hizmetleri kontrol edin. Ortak kimlik hizmetindeki kesinti veya hatalı yayın birden fazla Region’ı etkileyebilir. Daha fazla konum, her ortak nedeni ortadan kaldırmaz.

Kullanılabilirliği kurtarmaya bağlayın

HA, işletim sırasında belirlenmiş arızaları ele alır. Felaket kurtarma, işleyişi bozan bir olaydan sonra kullanılabilir hizmeti ve verilerini geri getirir. Çok bölgeli bir hizmetin de silinme veya bozulmuş veriler için kurtarma planına ihtiyacı vardır.

Seçilen arıza senaryolarını ve iş biriminin kabul ettiklerini belgeleyin. Uygulama değiştikçe testleri ve altyapı tanımlarını uyumlu tutun. RTO, RPO ve felaket kurtarma ile devam edin.