AWS Çoklu Bölge Yüksek Erişilebilirlik Mimari Diyagramı

Çoğu AWS çoklu bölge mimari diyagramı aynı şekilde başarısız olur: us-east-1 ve eu-west-1 etiketli, yan yana duran iki özdeş kutu ve aralarında hiçbir şey yok. Yüksek erişilebilirlik gibi görünür, ama bir inceleme toplantısında ya da nöbetteki mühendisin aklına gelecek soruların hiçbirini yanıtlamaz. Yazmalar nereye gidiyor? Veri hangi yönde replike oluyor? Bir bölge bozulduğunda trafiği ne taşıyor ve buna kim ya da ne karar veriyor? Bu yazıda diyagramın neyi göstermesi gerektiğini, active-active ve active-passive tasarımların kâğıt üzerinde nasıl ayrıştığını ve bunu Archboard'da ücretsiz bir örnekten başlayarak nasıl çizeceğinizi anlatıyoruz.

Bir AWS çoklu bölge mimari diyagramı neyi göstermeli

Diyagramı yukarıdan aşağıya, bir isteğin izlediği yol gibi okuyun.

1. Global giriş: Route 53 ve CloudFront

• Amazon Route 53 bölgelerden birinin içinde değil, ikisinin üzerinde durur. Yönlendirme politikasını kenar etiketine yazın: failover (health check'lere bağlı birincil ve ikincil kayıtlar), latency-based (her kullanıcıyı en düşük gecikmeli bölgeye gönderir) ya da weighted. Health check'leri de çizin; failover yönlendirmesi ancak onlar varsa çalışır.
• Amazon CloudFront bölgesel origin'lerin önünde durur. Origin failover özellikli bir origin group kullanıyorsanız iki origin'i de çizin ve hangisinin birincil olduğunu işaretleyin. CloudFront origin failover GET, HEAD ve OPTIONS isteklerine uygulanır; yazma istekleri için ayrı bir yol gerekir.

2. Bölgesel giriş: Application Load Balancer

ALB, kendisi için etkinleştirdiğiniz Availability Zone'lara yayılan bölgesel bir kaynaktır. Her bölgeye bir tane, bölge sınırının içinde çizin; hedefleri en az iki AZ'de olsun.

3. Availability Zone'lara yayılmış compute

Uygulamanızı hangisi çalıştırıyorsa (Amazon ECS servisleri, Amazon EKS node grupları ya da EC2 Auto Scaling grupları) iki veya üç AZ çerçevesine yayılmış olarak çizin. Diyagram tek bir noktayı net göstermeli: bir AZ kaybı bölge içinde karşılanır, bir bölge kaybı global katmanda karşılanır.

4. Veri katmanı, oklarla birlikte

Çoğu diyagramın sustuğu yer burası. Her veri deposunun kendi replikasyon modeli vardır ve okun yönü hikâyenin tamamıdır.

S3 replikasyon kurallarının yeni nesnelere uygulandığını, kuraldan önce var olan nesneler için S3 Batch Replication gerektiğini bir notla belirtin. Mutlaka biri soracaktır.

5. Secret'lar ve yapılandırma

AWS Secrets Manager bir secret'ı başka bölgelere replike edebilir, AWS KMS de multi-Region anahtarları destekler. Systems Manager Parameter Store ise bölgeseldir. Her bölgenin secret'larını ve yapılandırmasını nereden okuduğunu çizin. Uygulamanın veritabanı parolasını çözemediği ana kadar çalışan bir failover, failover değildir.

6. Gözlemlenebilirlik ve kontrol düzlemi

Arızayı neyin tespit ettiğini ve neyin harekete geçtiğini gösterin: Route 53 health check'leri, her bölgedeki CloudWatch alarmları, sentetik canary'ler ve bölgeler arası bir dashboard. Failover, Amazon Application Recovery Controller (ARC) routing control'leri ya da bir runbook ile tetikleniyorsa bunu da diyagrama koyun. AWS Well-Architected Reliability Pillar, kurtarma sırasında kontrol düzlemi değişikliklerine değil veri düzlemi işlemlerine güvenmeyi önerir. Health check'e dayalı DNS failover ilk türe bir örnektir ve hangisine bağımlı olduğunuzu göstermenin doğru yeri diyagramdır.

Active-active ve active-passive

AWS dört felaket kurtarma stratejisi tanımlar. Bunlardan üçü ikinci bölgede bir şeyler çalıştırır ve her biri diyagramın söylemesi gerekeni değiştirir.

Sayıları siz belirlersiniz. RTO ve RPO hedeflerinizi stratejinin yanına, canvas üzerine yazın; böylece diyagram ile iş gereksinimi birbirine karşı kontrol edilebilir.

Active-active otomatik olarak daha iyi değildir. Terfi adımını ortadan kaldırır, ama her veri deposunun eşzamanlı yazmaları nasıl ele aldığına karar vermenizi zorunlu kılar. Aurora Global Database'de aynı anda yalnızca bir bölge yazar; bu yüzden onun üzerine kurulu bir active-active tasarımın da tek bir yazma bölgesi vardır. Bunu dürüstçe çizin.

Failover yolunu açıkça gösterin

Üç kenar stili kullanın ve bunu bir lejantta belirtin:

• İstek yolu: kullanıcılardan DNS, CDN, ALB ve compute'a uzanan düz oklar.
• Replikasyon: veri depoları arasında, yönü ve modu (async, multi-active) etiketlenmiş kesikli oklar.
• Failover: birincil bölge sağlıksız olduğunda trafiğin nereye gittiğini gösteren ayrı, etiketli bir yol.

Ardından failover sırasını canvas üzerindeki bir notta numaralandırın:

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

Bir adım manuelse kimin yürüttüğünü yazın. Bir adım kontrol düzlemi API'sine bağlıysa işaretleyin.

Sık yapılan hatalar

• Aynı bölgenin veri akışı olmadan iki kez çizilmesi. Replikasyon okları olmayan aynı yığının iki kopyası, kurtarma hakkında hiçbir şey söylemez.
• Kontrol düzlemini gizlemek. Failover'ın gerçekleşip gerçekleşmeyeceğine health check'ler, routing control'ler ve runbook'lar karar verir. Bunları dışarıda bırakırsanız diyagram failover yapamayan bir sistemi anlatır.
• Failover okları yok. Normal işleyişteki istek yolu hikâyenin yarısıdır.
• Global servislerin bir bölgenin içine çizilmesi. Route 53 ve CloudFront globaldir; onları tek bir bölge çerçevesine koymak olmayan bir bağımlılığı ima eder ya da var olanı gizler.
• AZ'lerin olmaması. Bölge seviyesindeki yedeklilik, AZ seviyesindeki yedekliliğin yerini tutmaz; ikisini de gösterin.
• Unutulan state. Cache'ler, kuyruklar ve session store'lar da bölgeseldir. Nerede durduklarını ve onlara ne olduğunu gösterin.

Archboard'da oluşturun

Archboard'da bunu Cloud ve Network paketi node'larıyla kurarsınız: AWS servis adlarıyla etiketlediğiniz, portlu birinci sınıf node'lar. Böylece her kutu hem rolünü hem de tam servisi gösterir. Diyagramı şöyle kurabilirsiniz.

1. Ücretsiz şablonu inceleyin. /examples/multi-region-cloud-ha sayfasını açın. Bölgeler arasında bir CDN, iki bölgeli bir yük dengeleyici, compute ve yönetilen bir veritabanı gösteriyor. Onu referans alın ya da Bu örneği kullan ile çalışma alanınıza kopyalayın, ardından yukarıdaki katmanlarla genişletin.
2. Bölge ve AZ sınırlarını oluşturun. us-east-1 (primary) ve eu-west-1 (secondary) etiketli iki Cloud pack Region frame'i ekleyin. Her birinin içine AZ'ler için Core Frame öğeleri koyun.
3. Global katmanı bölgelerin üzerine ekleyin. Kullanıcılar için Network pack Internet, Route 53 (failover routing) etiketli Network pack DNS ve CloudFront etiketli Cloud pack CDN.
4. Her bölgeyi doldurun. ALB etiketli Cloud pack Cloud LB; her AZ frame'inde ECS service ya da EC2 Auto Scaling group etiketli Compute node'ları (EKS için Kubernetes Cluster node'u); Aurora (writer) ve Aurora (secondary, read-only) etiketli Managed DB node'ları, DynamoDB global table için bir tane daha ve S3 etiketli Object Storage.
5. Port'ları bağlayın ve her kenarı etiketleyin. İstek yolu, replikasyon yönü ve modu, failover yolu. Yönlendirme politikası ve replikasyon türü için kenar etiketlerini kullanın.
6. Kontrol düzlemini ve notları ekleyin. Secrets Manager, CloudWatch ve health check'ler için Core Box node'ları; numaralı failover sırasını içeren bir Note; RTO ve RPO hedeflerinizi ve seçtiğiniz stratejiyi yazdığınız bir Markdown bloğu.

Başlamadan önce node'larınızı sayın: Tam bir iki bölgeli harita genellikle Free planın diyagram başına 15 diyagram node'unu aşar (notlar ve metinler ayrı sayılır, 150'ye kadar); bu yüzden sınırsız node, doküman sitenize gömme ve PDF dışa aktarımıyla Pro doğal tercihtir. Daha fazla kalıp için bulut kullanım senaryosu sayfasına bakın.

SSS

Archboard'da resmi AWS ikonlarını kullanabilir miyim? Archboard'un tipli Cloud ve Network node'ları sağlayıcıdan bağımsızdır, ama AWS logolarını Iconify'da arama yapan Core Icon node'uyla (örneğin logos:aws-route53) ekleyebilir ya da resmi AWS Architecture Icons'ı görsel olarak yükleyebilirsiniz. Her node'u Route 53 ya da Aurora Global Database gibi AWS servis adıyla etiketleyin; diyagram AWS bilen herkes için net okunur.

Hem bölgeleri hem AZ'leri çizmeli miyim? Evet. AZ'ler bir zone arızasından nasıl kurtulduğunuzu, bölgeler ise bölgesel bir arızadan nasıl kurtulduğunuzu gösterir. Bunlar farklı arıza türleri ve farklı mekanizmalardır.

Active-active mi, active-passive mi? RTO ve RPO hedeflerinizden ve veri modelinizden başlayın. Ana veritabanınızın tek bir yazma bölgesi varsa active-passive (pilot light veya warm standby) çoğu zaman daha basit ve gerçeğe daha uygun tasarımdır. Kararı diyagrama yazın.

Nasıl paylaşırım? SVG veya PNG olarak dışa aktarın (Free'de filigranlı), herkese açık bir bağlantı paylaşın ya da Pro'da dokümanlarınıza gömün.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez