HA ve Hata Toleransı: Tanımlar ve Ödünleşimler

Yüksek Kullanılabilirlik (HA) ve Hata Toleransı (FT), mimarların sıklıkla karıştırdığı iki farklı güvenilirlik hedefidir. Yüksek kullanılabilirlik, bir sistemin en az düzeyde kesinti yaşaması anlamına gelir; sistem arızalara dayanabilir ancak kurtarma sırasında kısa süreli kesintiler yaşanabilir. Hata toleransı ise bileşenler arızalansa bile, anında devreye giren tamamen yedekli yollar sayesinde sistemin hiçbir kesinti olmadan çalışmaya devam etmesi anlamına gelir.

Kullanılabilirlik, bir yıl içindeki çalışma süresinin yüzdesi olarak ölçülür. %99,9 kullanılabilirlik (üç dokuz), yılda yaklaşık 8,7 saat kesinti anlamına gelirken %99,99 (dört dokuz) yalnızca 52,6 dakikaya izin verir. %99,999 (beş dokuz) ise yalnızca 5,26 dakikaya izin verir. Her ek dokuz genellikle daha fazla yedeklilik, otomasyon ve maliyet gerektirir. SAA-C03 sınavında çoğu zaman, belirli bir kullanılabilirlik hedefini hangi mimarinin karşıladığını belirlemeniz istenir.

Yüksek kullanılabilirliğe sahip bir mimari, bir bileşenin arızasını otomatik olarak algılayıp saniyeler veya dakikalar içinde sağlıklı bir yedeğe geçerek bu arızaya dayanır. Örnekler arasında RDS Multi-AZ (farklı bir AZ'deki bekleme örneğine otomatik geçiş), sonlandırılan örnekleri değiştiren Auto Scaling Groups ve trafiği sağlıksız hedeflerden uzaklaştıran Elastic Load Balancers bulunur. Kısa bir kesinti yaşanır; ancak sistem, manuel müdahale olmadan kurtulur.

Hata toleranslı bir mimaride etkin yedeklilik bulunur: birden çok özdeş bileşen istekleri aynı anda karşılar ve biri arızalandığında diğerleri yükü sıfır kesintiyle anında üstlenir. Örnekler arasında birden çok EC2 örneğine sahip etkin-etkin ELB, aynı anda birden çok bölgede okuma ve yazma işlemlerine hizmet veren DynamoDB Global Tables ve birden çok okuma çoğaltıcısına sahip Aurora bulunur. Hata toleransı, her zaman çalışır durumda daha fazla kaynak gerektirir.

Hata toleransı, her zaman tamamen sağlanmış yedek kapasite gerektirdiğinden yüksek kullanılabilirlikten önemli ölçüde daha pahalıdır. Yüksek kullanılabilirliğe sahip bir RDS Multi-AZ örneği, yalnızca arıza durumunda etkinleşen bir bekleme örneği için veritabanı maliyetinizi iki katına çıkarır. Hata toleranslı çok bölgeli etkin-etkin Aurora dağıtımı dört kat daha pahalı olabilir; ancak bölgesel arızalar sırasında tüm kesintileri ortadan kaldırır. Mimarlar, yedeklilik maliyeti ile kesintinin işletmeye maliyeti arasında denge kurmalıdır.

Kurtarma Süresi Hedefi (RTO), bir sistemin kullanılamaz durumda kalabileceği kabul edilebilir en uzun süredir. Yüksek kullanılabilirlik mimarileri, otomatik geçiş yoluyla genellikle dakikalar düzeyinde düşük bir RTO hedefler. Hata toleranslı mimariler ise sıfıra yakın bir RTO hedefler. HA için tasarım yaparken, kurtarmayı RTO bütçeniz içinde garanti eden hizmetleri ve yapılandırmaları seçmeniz gerekir. Örneğin RDS Multi-AZ, birçok HA gereksinimi için uygun olan yaklaşık 60-120 saniyelik bir RTO sağlar.

Tek Hata Noktası (SPOF), arızalandığında tüm sistemin çalışmamasına neden olan herhangi bir bileşendir. Yaygın SPOF'lar arasında ASG'si olmayan tek bir EC2 örneği, tek bir AZ'deki RDS veritabanı, tek bir NAT ağ geçidi veya tek bir kullanılabilirlik alanı bulunur. SPOF'ları ortadan kaldırmak, hem HA hem de FT'ye giden ilk adımdır. SAA-C03 sınavında, verilen mimari şemalardaki SPOF'ları belirleyip ortadan kaldırma beceriniz sık sık test edilir.

Durumsuz hizmetler (web sunucuları veya Lambda işlevleri gibi) için HA veya FT elde etmek çok daha kolaydır; çünkü herhangi bir örnek herhangi bir isteği işleyebilir. Durum bilgili hizmetler (veritabanları, önbellekler, dosya sistemleri) daha zordur: durumu çoğaltmalar arasında eşitlemeniz, çoğaltma gecikmesini yönetmeniz ve geçiş sırasında tutarlılığı sağlamanız gerekir. EFS (paylaşılan dosya sistemi), çoğaltma gruplarına sahip ElastiCache ve Aurora (paylaşılan depolama) gibi AWS hizmetleri, durum bilgili HA'yı kolaylaştırmak üzere tasarlanmıştır.

AWS'deki yaygın HA kalıpları şunlardır: 1) Multi-AZ Yük Dengeleme — EC2 örneklerini AZ'ler arasında dağıtıp bir ALB'nin arkasına yerleştirin. 2) Okuma Çoğaltıcıları — okuma trafiğini azaltın ve DR sırasında yükseltin. 3) Durumsuz varlıklar için S3 — S3, 11 dokuzluk kalıcılığa sahip, doğası gereği HA bir hizmettir. 4) Global Accelerator — bölgeler arasındaki sağlıklı uç noktalara yönlendirme yapan statik Anycast IP'leri. Her kalıp, belirli bir kullanılabilirlik düzeyi karşılığında maliyeti artırır.

Hata toleranslı kalıplar her yerde etkin yedeklilik gerektirir. Temel FT kalıpları şunlardır: DynamoDB doğası gereği hata toleranslıdır; verileri üç AZ arasında çoğaltır ve geçiş gerektirmez. S3 yerleşik FT özelliğine sahiptir. Aurora Multi-Master (artık Aurora Serverless v2 çok yazarlı), birden çok AZ'ye aynı anda yazılmasına olanak tanır. Kinesis, verileri varsayılan olarak birden çok AZ'de depolar. Yerleşik FT özelliklerine sahip yönetilen hizmetleri seçmek, sıfır kesintili mimarilere ulaşmanın en uygun maliyetli yoludur.

HA veya FT için tasarım yapmak, testlerinizin kalitesiyle sınırlıdır. AWS, örnekleri sonlandıran, API'leri kısıtlayan veya ağ arızaları oluşturan kontrollü deneyler yürütmek için AWS Fault Injection Simulator (FIS) kullanılmasını önerir. Geçişin gerçekten RTO'nuz içinde tamamlandığını, RPO'nuzun ötesinde veri kaybedilmediğini ve alarmların doğru şekilde tetiklendiğini doğrulamalısınız. Düzenli tatbikat günleri ve kaos mühendisliği çalışmaları, üretim olaylarından önce dayanıklılık varsayımlarınızdaki eksikleri ortaya çıkarır.

Bu derste ele alınan AWS Solutions Architect (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Bu derste şunları öğrendiniz: Yüksek Kullanılabilirlik, otomatik kurtarma yoluyla kesintiyi en aza indirir (dakikalar düzeyinde RTO), Hata Toleransı, etkin yedeklilik yoluyla kesintiyi ortadan kaldırır (sıfır RTO) ve dayanıklılığın her düzeyiyle maliyet önemli ölçüde artar. Tek Hata Noktalarını ortadan kaldırmak, her iki yaklaşımın da temelidir. Sırada durum bilgili hizmetler için çoklu AZ kalıplarını inceleyeceğiz.