W tym artykule zebrano kilka ogólnych szablonów, które pomagają inżynierom pracować z dużymi usługami, które obsługują miliony użytkowników.
Z doświadczenia autora, to nie jest wyczerpująca lista, ale rzeczywiście skuteczne porady. Zacznijmy więc.
Przetłumaczone przy wsparciu .
Poziom podstawowy
Poniższe działania są stosunkowo proste do wdrożenia, ale zapewniają wysoką wartość zwrotną. Jeśli jeszcze ich nie podjąłeś, będziesz zaskoczony znacznymi poprawami.
Infrastruktura jako kod
Pierwsza część porad polega na wdrożeniu infrastruktury jako kodu. Oznacza to, że musisz mieć programowy sposób wdrażania całej infrastruktury. Brzmi skomplikowanie, ale tak naprawdę mówimy o następującym kodzie:
Wdrożenie 100 maszyn wirtualnych
- z Ubuntu
- 2 GB RAM na każdą
- będzie miało następujący kod
- z takimi parametrami
Możesz śledzić zmiany w infrastrukturze i szybko do nich wracać przy użyciu systemu zarządzania wersjami.
Mój nowoczesny ja mówi, że można użyć Kubernetes/Docker, aby zrobić to wszystko, i ma rację.
Ponadto, automatyzację można zapewnić za pomocą Chef, Puppet lub Terraform.
Ciagła integracja i dostarczanie
Aby stworzyć skalowalną usługę, ważne jest posiadanie potoku budowy i testów dla każdego pull-requesta. Nawet jeśli test jest najprostszy, przynajmniej gwarantuje, że kod, który wdrażasz, się kompiluje.
Za każdym razem na tym etapie odpowiadasz na pytanie: Czy moja kompilacja będzie się kompilować i przechodzić testy, czy jest ważna? To może wydawać się niskim progiem, ale rozwiązuje wiele problemów.
Nie ma nic piękniejszego niż widzieć te zaznaczenia
Dla tej technologii możesz rozważyć Github, CircleCI lub Jenkins.
Load balancery
Więc chcemy uruchomić load balancer, aby przekierowywać ruch, i zapewnić równą obciążenie na wszystkich węzłach lub działanie usługi w przypadku awarii:
Load balancer zwykle dobrze pomaga w rozdzielaniu ruchu. Najlepszą praktyką jest redundantne zbalansowanie, aby nie mieć pojedynczego punktu awarii.
Zwykle load balancery są konfigurowane w tym chmurze, którego używasz.
RayID, ID korelacji lub UUID dla zapytań
Czy kiedykolwiek napotkałeś błąd w aplikacji z komunikatem podobnym do tego: „Coś poszło nie tak. Zachowaj ten identyfikator i prześlij go do naszego wsparcia technicznego”?
Unikalny identyfikator, correlation ID, RayID lub jakakolwiek jego wersja — to unikalny identyfikator, który pozwala śledzić zapytanie przez cały jego cykl życia. Umożliwia to śledzenie całej drogi zapytania w logach.
Użytkownik wysyła zapytanie do systemu A, następnie A łączy się z B, które łączy się z C, zapisuje w X, a następnie zapytanie wraca do A.
Gdybyś zdalnie połączył się z maszynami wirtualnymi i próbował śledzić drogę zapytania (a także ręcznie powiązać, jakie wywołania mają miejsce), zwariowałbyś. Posiadanie unikalnego identyfikatora znacznie ułatwia życie. To jedna z najprostszych rzeczy, które można zrobić, aby zaoszczędzić czas w miarę wzrostu serwisu.
Poziom średni
Tutaj porady są trudniejsze od poprzednich, ale odpowiednie narzędzia ułatwiają zadanie, zapewniając zwrot z inwestycji nawet dla małych i średnich firm.
Centralne zarządzanie logami
Gratulacje! Rozwinąłeś 100 maszyn wirtualnych. Następnego dnia dyrektor generalny przychodzi i skarży się na błąd, który napotkał podczas testowania usługi. Przekazuje odpowiedni identyfikator, o którym mówiliśmy wcześniej, ale musisz przeszukiwać logi 100 maszyn, aby znaleźć tę, która spowodowała błąd. A musisz to znaleźć przed jutrzejszą prezentacją.
Chociaż brzmi to jak zabawna przygoda, lepiej upewnić się, że masz możliwość przeszukiwania wszystkich logów z jednego miejsca. Rozwiązałem problem centralizacji logów dzięki wbudowanej funkcjonalności stosu ELK: wspiera zbieranie logów z możliwością przeszukiwania. To naprawdę pomoże w znalezieniu konkretnego logu. Jako bonus możesz tworzyć wykresy i inne tego typu zabawne rzeczy.
Funkcjonalność stosu ELK
Agenci monitoringu
Teraz, gdy Twoja usługa jest uruchomiona, musisz upewnić się, że działa bez zakłóceń. Najlepszym sposobem, aby to zrobić, jest uruchomienie kilku agentów, które pracują równolegle i sprawdzają, czy działa i są wykonywane podstawowe operacje.
Na tym etapie sprawdzasz, czy uruchomiona kompilacja działa dobrze i funkcjonuje normalnie.
Dla małych i średnich projektów polecam Postman do monitorowania i dokumentowania API. Jednak ogólnie należy upewnić się, że masz sposób na wykrycie awarii i otrzymanie powiadomienia na czas.
Automatyczne skalowanie w zależności od obciążenia
To bardzo proste. Jeśli masz maszynę wirtualną obsługującą zapytania, a jej pamięć zbliża się do 80% zajętości, możesz albo zwiększyć jej zasoby, albo dodać więcej maszyn wirtualnych do klastra. Automatyzacja tych operacji doskonale nadaje się do elastycznej zmiany mocy w odpowiedzi na obciążenie. Zawsze musisz jednak uważać, ile pieniędzy wydajesz i ustawić rozsądne limity.
W większości usług chmurowych możesz skonfigurować automatyczne skalowanie, używając większej liczby serwerów lub bardziej wydajnych serwerów.
System eksperymentów
Dobrym sposobem na bezpieczne wdrażanie aktualizacji jest możliwość przetestowania czegoś dla 1% użytkowników przez godzinę. Oczywiście widziałeś takie mechanizmy w działaniu. Na przykład Facebook pokazuje częściowym odbiorcom inny kolor lub zmienia rozmiar czcionki, aby zobaczyć, jak użytkownicy reagują na zmiany. Nazywa się to testowaniem A/B.
Nawet wprowadzenie nowej funkcji można uruchomić jako eksperyment, a następnie określić, jak ją wprowadzać. Zyskujesz również możliwość 'cofnięcia' lub zmiany konfiguracji na bieżąco w przypadku funkcji, która powoduje pogorszenie jakości usługi.
Zaawansowany poziom
Oto porady, które są dość trudne do wdrożenia. Prawdopodobnie będziesz potrzebować nieco więcej zasobów, dlatego małym lub średnim firmom trudno będzie sobie z tym poradzić.
Wdrażania w trybie blue-green
To, co nazywam 'sposobem wdrażania erlangu'. Erlang stał się szeroko stosowany, gdy pojawiły się firmy telefoniczne. Do routingu połączeń telefonicznych zaczęto stosować przełączniki programowe. Głównym zadaniem oprogramowania tych przełączników było unikanie zrywania połączeń podczas aktualizacji systemu. Erlang ma doskonały sposób na ładowanie nowego modułu bez przerywania działania poprzedniego.
Ten krok zależy od dostępności load balancera. Załóżmy, że masz wersję N swojego oprogramowania, a następnie chcesz wdrożyć wersję N+1.
Możesz po prostu zatrzymać usługę i wdrożyć następną wersję w dogodnym dla twoich użytkowników czasie, co spowoduje pewien okres przestoju. Ale załóżmy, że masz naprawdę surowe warunki SLA. Tak, SLA 99,99% oznacza, że możesz być offline tylko przez 52 minuty rocznie.
Jeśli naprawdę chcesz osiągnąć taki poziom, potrzebne są dwa jednoczesne wdrożenia:
- aktualne (N);
- następna wersja (N+1).
Wskazujesz load balancerowi, aby przekierował procent ruchu na nową wersję (N+1), podczas gdy ty aktywnie monitorujesz regresje.
Tutaj mamy zielone wdrożenie N, które działa normalnie. Próbujemy przejść do następnej wersji tego wdrożenia.
Najpierw wysyłamy naprawdę mały test, aby sprawdzić, czy nasze wdrożenie N+1 działa przy niewielkiej ilości ruchu:
Na koniec mamy zestaw automatycznych kontrol, które w końcu uruchamiamy, aż nasze wdrożenie zostanie zakończone. Jeśli jesteś bardzo, bardzo ostrożny, możesz także zachować swoje wdrożenie N na zawsze na szybki rollback w przypadku złej regresji:
Jeśli chcesz przejść na jeszcze bardziej zaawansowany poziom, pozwól, aby wszystko w wdrożeniu blue-green działało automatycznie.
Wykrywanie anomalii i automatyczne łagodzenie skutków
Mając zunifikowane logowanie i dobre zbieranie logów, możesz już stawiać wyższe cele. Na przykład proaktywnie prognozować awarie. W monitorach i logach śledzone są funkcje i budowane są różne wykresy - i można przewidzieć, co może pójść nie tak:
Dzięki wykrywaniu anomalii zaczynasz analizować pewne wskazówki, które podaje usługa. Na przykład wzrost obciążenia CPU może sugerować, że twardy dysk ulega awarii, a wzrost liczby zapytań oznacza, że trzeba się skalować. Tego rodzaju dane statystyczne pozwalają uczynić usługę proaktywną.
Otrzymując takie analizy, możesz skalować się w dowolnym kierunku, proaktywnie i reaktywnie zmieniając charakterystyki maszyn, baz danych, połączeń i innych zasobów.
To wszystko!
Ta lista priorytetów pozwoli Ci uniknąć wielu problemów, gdy rozwijasz usługi chmurowe.
Autor oryginalnego artykułu zaprasza czytelników do pozostawiania komentarzy i wnoszenia zmian. Artykuł jest udostępniany jako open source, autor przyjmuje pull requesty .
Co jeszcze przeczytać na ten temat:
Źródło: habr.com
