Zacznijmy od tego, co 4 9’s oznacza dokładnie:

Cztery dziewiątki to 4,38 minuty przestoju miesięcznie lub 52,56 minuty rocznie.

To prawdopodobnie więcej niż akceptowalne dla prawie wszystkich usług w Internecie, nie wszystkich, ale prawie wszystkich. Więc twój e-mail jest w dół na 4 minuty każdego miesiąca, a nie koniec świata. Mam na myśli, że prawdopodobnie nawet nie zauważy. Do czasu poszedł do sprawdzenia Twitter, aby zobaczyć, czy to tylko ty, czy nie, to będzie z powrotem up.

Typowo, aby uzyskać dobry uptime, myślimy o dodaniu redundancji i replikacji, więc jeśli serwer nie powiedzie się, masz inne działające już, że natychmiast przejąć. Problem z tym podejściem polega na tym, że jest ono skomplikowane i kosztowne. Potrzebujesz wielu serwerów, zwykle 3 lub więcej zarówno dla aplikacji jak i bazy danych, plus będziesz potrzebował load balancera z przodu. I wtedy musisz zarządzać/monitorować wszystkie te maszyny.

A z nowym trendem Microservices, gdzie ludzie rozbijają swoje aplikacje na mniejsze usługi, musisz powtórzyć te skomplikowane konfiguracje dla każdej usługi.

Jeśli budujesz Microservice, im mniej „rzeczy” potrzebujesz, aby go uruchomić, tym lepiej. Nie chcesz mieć potrzeby konfigurowania nowej replikowanej bazy danych za każdym razem, gdy chcesz rzucić razem małe API, prawda? Chcę być super produktywny, chcę być w stanie szybko uruchomić usługę bez konieczności zajmowania się wszystkimi skomplikowanymi, marnującymi czas rzeczami ops.

Więc zacząłem myśleć, „cóż, co jeśli jest sposób, aby być… wystarczająco niezawodny?” Chodzi mi o to, ile z rzeczy, które budujesz, faktycznie musi być wysoce dostępnych? Jak wiele usług nie może sobie pozwolić na kilkuminutowe przestoje tu i tam lub utratę niewielkiej ilości danych raz na jakiś czas z powodu fatalnej awarii serwera?

Moim zdaniem nie ma zbyt wielu usług, które nie mogą sobie pozwolić na utratę bardzo małej ilości danych i kilkuminutowe przestoje w ciągu roku. Nawet jeśli architektem piekła swojej usługi, prawdopodobnie nadal będziesz miał przestoje z jakiegoś powodu. Więc dlaczego nie po prostu zachować to proste.

Po pierwsze, niektóre liczby: powiedzmy, że średnio instancja AWS EC2 zawodzi co sześć miesięcy. Myślę, że w dzisiejszych czasach jest to o wiele mniej niż to, ale nikt tak naprawdę nie wie, więc będziemy konserwatywni. To daje nam około 26,5 minuty na odzyskanie aplikacji co sześć miesięcy, podczas gdy nadal mamy 4 9’s uptime.

Oto jak możesz uzyskać 4 9’s na pojedynczej maszynie.

Krok 1) Uruchom serwer, wdróż aplikację i zmień DNS Script

Pierwszą rzeczą, której potrzebujemy jest prosty skrypt, który może uruchomić nową instancję, uruchomić aplikację (Docker to ułatwia) i zmienić DNS, aby wskazać na nową instancję. Nie będę się zagłębiał w szczegóły tego kroku w tym poście, ale jeśli potrafisz stworzyć jednolinijkowy skrypt, który może wykonać te kroki, jesteś dobry. Service fails: run script.

Krok 2) Baza danych z automatyczną kopią zapasową i automatycznym odzyskiwaniem

Jeśli możesz zapewnić, że masz bardzo aktualne kopie zapasowe swojej bazy danych i są one przechowywane w łatwo dostępnym miejscu, takim jak S3, to możesz stworzyć aplikację, która może odzyskać siebie, gdy się uruchomi. Używanie wbudowanej bazy danych sprawia, że wszystko jest prostsze, ponieważ musisz wdrożyć tylko jedną rzecz: swoją aplikację.

Ostatnio często używam BoltDB, głównie dlatego, że piszę dużo w Go, a Bolt jest prostą wbudowaną bazą danych dostępną w pakiecie Go, której używasz jak każdej innej zależności. Nie musisz więc uruchamiać oddzielnej bazy danych, z którą się łączysz i musisz sobie radzić z utrzymaniem jej działania. Po prostu używasz biblioteki, a dane są zapisywane na twoim lokalnym dysku.

Teraz jest też problem z Boltem, dane są tylko na twojej lokalnej maszynie razem z twoją aplikacją. Jeśli maszyna zawiedzie, stracisz wszystkie swoje dane.

A może by tak robić kopię zapasową co minutę lub dwie? I być w stanie automatycznie odzyskać dane z tej kopii zapasowej, gdy aplikacja się uruchamia?

Utworzyłem bibliotekę, która robi właśnie to, nazywa się Bolt Backup i po prostu zmieniając linię inicjalizacyjną BoltDb, automatycznie tworzy kopię zapasową bazy danych na S3, a jeszcze lepiej, gdy uruchomisz aplikację, odzyska ona dane z najnowszej kopii zapasowej.

Możesz to łatwo przetestować, dodając dane do bazy danych Bolt, zabijając aplikację, usuwając plik danych Bolt, a następnie ponownie uruchamiając aplikację. Będzie ona kontynuowana w miejscu, w którym się skończyła, bez względu na to, gdzie ponownie uruchomisz aplikację.

Tutaj znajduje się przykładowa aplikacja wykorzystująca to rozwiązanie, którą możesz wypróbować: https://github.com/treeder/bolt-backup/tree/master/example

Wniosek

Dzięki powyższym prostym koncepcjom możesz odzyskać swoją aplikację w mniej niż 26 minut, a tym samym osiągnąć 4 9’s lub lepszy uptime. Tylko upewnij się, że to wszystko jest zautomatyzowane ze skryptem startowym i automatycznego odzyskiwania bazy danych, jak Bolt Backup biblioteki wspomniano powyżej.

Wartość prostoty może czasami zgubić się, gdy mamy wszystkie podekscytowany o „skali sieci”, ale często można zaoszczędzić sobie dużo czasu i żalu, jeśli zachować rzeczy proste. I dużo pieniędzy.