S3 çevrimdışı olduğunda sitemi çevrimiçi tutmak için iyi bir strateji nedir?

S3 çevrimdışı olduğunda sitemi çevrimiçi tutmak için iyi bir strateji nedir?

S3 ABD Doğu 1 çevrimdışıysa, sitemin tamamını çevrimdışına almasını engellemek için uygulamamı nasıl yapılandırmalı / yapılandırmalıyım?

Bu tür durumlarda çeşitlendirmek için en iyi stratejiler nelerdir?

Mart 2015’te, Amazon AWS bölgeler arasında S3 replikasyonunu desteklediklerini açıkladı . S3'teki belirli bir bölge çevrimdışı olduğunda, aynanızdaki dosyaları başka bir bölgede sunabilirsiniz.

^{kaynak: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

Altyapınızı başka bir bölgeye geçiş yaparak çevrimiçi tutma uygulaması karmaşıktır ancak S3 nispeten küçük ve basit bir bileşendir. Netflix'in Chaos Gorilla ile olan deneyimleri hakkında harika bir makalesi var.

Bu aynı zamanda gecikme süresinin artması gibi hizmetlerin bozulması için de geçerlidir. Sadece güvendiğiniz bir hizmet tamamen çevrimdışı olduğunda değil. Netflix'in bu konuda da bir makalesi var: Kaos Mühendisliği Yükseltildi .

İstediğiniz şey, temel olarak, yüksek kullanılabilirlik. Bir sistemi yüksek oranda kullanılabilir hale getirmek için üç şeye ihtiyacınız vardır:

1. Tekli başarısızlık noktalarını ortadan kaldırın
2. Bir uç noktadan diğerine geçiş için bir mekanizma
3. Hataları tespit etmenin bir yolu

Tekli başarısızlık noktalarını ortadan kaldırın

S3 durumunda, 1 no'lu noktaya, Evgeny'nin işaret ettiği gibi, S3 bölgeler arası çoğaltmasıyla değinilmektedir .

Bununla birlikte, çoğaltma anlık değildir ve uygulama çoğaltmanın farkında olmasını sağlamak isteyip istemediğinizi kontrol etmek istersiniz. Bir kesinti olması durumunda, kaynak kodunuza yazılan bir şeyin henüz hedef kovaya yazmaması (çoğaltılmaması) mümkündür. Uygulamanın böyle bir senaryoyu nasıl idare edeceğini düşünmeniz gerekir. Bu gerçekten veri türüne, bununla ne yapıldığına ve (potansiyel olarak) son kullanıcılara veya yönetim beklentilerine bağlıdır.

Bir uç noktadan diğerine geçiş için bir mekanizma

S3 için, bir kesinti olması durumunda, uygulamanın kova A'dan / a okuma ve yazma işlemini durdurmasını ve bunun yerine kova B'yi kullanmasını istediğiniz anlamına gelir.

Bunu başarabilmem, bildiğim kadarıyla, şimdilik. Diğer bazı AWS hizmetleri tamamen şeffaf başarısızlıklar sunar, ancak şu anda S3 için böyle bir şeyden haberdar değilim.

Bunu başarmanın çeşitli yolları var. Bir örnek, trafiği uygun kovaya yönlendirecek bir proxy kullanıyor. Bir kesinti sırasında, trafiği kesintiden etkilenmeyen bir kovaya yönlendirmek için proxy'yi günceller / değiştirirsiniz. Başka bir örnek, uygulama yapılandırmanızı dinamik hale getirmek ve bir anahtar-değer deposunda saklamaktır. Uygulama, güncellenmiş özellikler için KV mağazasını yeterince sık okursa, nereden okuyup yazabilirsiniz (Spring Cloud, örneğin bir "EnvironmentChange" dinleyicisini destekler).

Hataları tespit etmenin bir yolu

Sanırım bu kolay. Basitçe bir yazma + okuma döngüsü ayarlayın ve bir şey doğru olmaz olmaz uyarı verin :)

Kapanış notları

• Uygulamanız kovaya yazıyorsa, başarısızlık durumunda ne olacağını düşünmeniz gerekir. Bütün yazarlar hedef kovasına koymuşlar mı (ve söyleyebilir misin)? Hedef kovasına yazmaya izin verir misiniz (yeni "birincil" yapar)? Dikkatli planlama, bölünmüş beyin veya kaybolan güncelleme senaryolarını önleyecektir.
• SLA'nıza bağlı olarak, # 2 ve # 3 noktalarının otomatik veya otomatik olmasını isteyebilirsiniz. Bu, ek planlama, uygulama ve test gerektirir, ancak iyi yazılmış senaryolar her zaman insanın yapabileceğinden daha hızlı ve daha öngörülebilir şekillerde tepki verir (başarısızlıklar da insan müdahalesinin tehlikeli bir şey olduğu gecenin ortasında can sıkıcı bir alışkanlık yaşar).
• Bölgeler arası çoğaltmanın bile tek başarısızlık noktasını tamamen ortadan kaldırmadığını söylemeye değer. Elbette, eğer bir bölge çökerse, gizlenirsiniz. Peki ya ABD çapında bir AWS kesintisi olursa? Azure geçen yıl kısmi fakat küresel bir kesintiye, 2014'te de bir kesikti.