Jaka jest dobra strategia utrzymywania mojej witryny w trybie online, gdy S3 przechodzi w tryb offline?

Jaka jest dobra strategia utrzymywania mojej witryny w trybie online, gdy S3 przechodzi w tryb offline?

Jeśli S3 US East 1 przejdzie w tryb offline, jak powinienem skonfigurować / ustrukturyzować moją aplikację, aby zapobiec przełączeniu całej witryny w tryb offline?

Jakie są najlepsze strategie dywersyfikacji w takiej sytuacji?

W marcu 2015 r. Amazon AWS ogłosił, że obsługuje replikację S3 w różnych regionach. Gdy określony region w S3 przechodzi w tryb offline, możesz udostępniać pliki z serwera lustrzanego w innym regionie.

^{źródło: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

Praktyka utrzymywania infrastruktury w trybie online poprzez przejście do innego regionu jest złożona, ale S3 jest stosunkowo małym i prostym komponentem. Netflix ma świetny artykuł na temat swoich doświadczeń z Gorylem Chaosu.

Dotyczy to również degradacji usług, takich jak zwiększone opóźnienie. Nie tylko wtedy, gdy usługa, na której polegasz, jest całkowicie offline. Netflix ma również artykuł na ten temat: Ulepszona inżynieria chaosu .

To, o co prosisz, to w zasadzie wysoka dostępność. Aby system był wysoce dostępny, potrzebujesz trzech rzeczy:

1. Wyeliminuj pojedyncze punkty awarii
2. Mechanizm przełączania z punktu końcowego na inny
3. Sposób na wykrycie awarii

Wyeliminuj pojedyncze punkty awarii

W przypadku S3, punkt # 1 jest rozwiązany, jak wskazał Evgeny, przez replikację między regionami S3 .

Replikacja nie jest jednak natychmiastowa i będziesz chciał sprawdzić, czy chcesz, aby replikacja aplikacji była świadoma, czy nie. W przypadku awarii może się zdarzyć, że coś, co zostało zapisane w źródłowym segmencie, jeszcze go nie uczyniło (nie zostało zreplikowane) w docelowym segmencie. Musisz pomyśleć, jak aplikacja poradziłaby sobie z takim scenariuszem. To naprawdę zależy od rodzaju danych, tego, co się z nimi dzieje i (potencjalnie) oczekiwań użytkowników końcowych lub kierownictwa.

Mechanizm przełączania z punktu końcowego na inny

W przypadku S3 oznacza to, że w przypadku awarii chcesz, aby aplikacja przestała czytać i zapisywać z / do segmentu A i zamiast tego używała segmentu B.

O tym, jak to osiągnąć, zależy od ciebie. Niektóre inne usługi AWS oferują całkowicie transparentne przełączenia awaryjne, ale w tej chwili nie jestem świadomy czegoś takiego dla S3.

Istnieją różne sposoby osiągnięcia tego celu. Jednym z przykładów jest użycie serwera proxy, który przekieruje ruch do odpowiedniego segmentu. Podczas awarii należy zaktualizować / zmienić serwer proxy, aby kierować ruch do segmentu, na który nie ma wpływu awaria. Innym przykładem może być dynamiczna konfiguracja aplikacji i przechowywanie jej w magazynie klucz-wartość. Jeśli aplikacja dość często odczytuje magazyn KV w celu zaktualizowania właściwości, możesz zmienić miejsce odczytu i zapisu (Spring Cloud obsługuje na przykład nasłuchiwanie „EnvironmentChange”).

Sposób na wykrycie awarii

Myślę, że ten jest łatwy. Wystarczy skonfigurować pętlę zapisu + odczytu i powiadomić, gdy tylko coś będzie nie tak :)

Notatki końcowe

• Jeśli aplikacja pisze do wiadra, musisz pomyśleć o tym, co by się stało w przypadku przełączenia awaryjnego. Czy wszystkie zapisy dotarły do ​​segmentu docelowego (i czy możesz powiedzieć)? Czy możesz zezwolić na zapisy w segmencie docelowym (co czyni go nowym „podstawowym”)? Staranne planowanie pozwoli uniknąć scenariuszy podzielonego mózgu lub utraconych aktualizacji.
• W zależności od umowy SLA możesz chcieć, aby punkty 2 i 3 były zautomatyzowane lub automatyczne. Wymaga to dodatkowego planowania, oprzyrządowania i testowania, ale dobrze napisane skrypty zawsze będą reagować szybciej i w bardziej przewidywalny sposób niż ludzie (awarie mają również irytujący zwyczaj zdarzania się w środku nocy, gdy interwencja człowieka jest czymś niebezpiecznym.
• Warto wspomnieć, że nawet replikacja między regionami nie eliminuje całkowicie pojedynczych punktów awarii. Jasne, jeśli region upadnie, jesteś objęty ubezpieczeniem. Ale co się stanie, jeśli nastąpi awaria AWS w USA? Azure miał częściową, ale globalną awarię w ubiegłym roku i jedną w 2014 r.