Mikroserwisy w akcji. Отсутствует
Skalowalność – czy znamy zapotrzebowanie usługi na zasoby i wydajność infrastruktury? Jak utrzymamy responsywność podczas obciążenia?
■ Przejrzystość – czy można obserwować usługę w trakcie działania przez dzienniki i metryki? Jeśli coś pójdzie nie tak, to czy ktoś zostanie powiadomiony?
■ Odporność na awarie – czy udało się zabezpieczyć pojedyncze punkty awarii? Jak poradzimy sobie z awarią innej zależnej usługi?
Na tym wczesnym etapie życia aplikacji mikroserwisowej musimy wprowadzić trzy podstawowe zasady:
■ kontrolowanie pod względem jakości i zautomatyzowane wdrożenia,
■ odporność,
■ przejrzystość.
Przyjrzyjmy się, w jaki sposób te podstawy pomogą rozwiązać problemy napotkane przez SimpleBank.
2.5.1. Kontrolowane pod względem jakości i zautomatyzowane wdrożenia
Stracimy dodatkową szybkość rozwoju, jaką możemy uzyskać dzięki mikroserwisom, jeśli nie będziemy mogli ich szybko i niezawodnie wprowadzić do produkcji. Ból niestabilnych wdrożeń – takich jak wprowadzenie poważnego błędu – uniemożliwia szybki rozwój.
Tradycyjne firmy często dążą do stabilności przez wprowadzenie (często biurokratycznych) procesów kontroli i zatwierdzania zmian. Są one przeznaczone do zarządzania i ograniczania zmian. To nie jest nierozsądny impuls – jeśli zmiany wprowadzają najwięcej błędów7, kosztują firmę tysiące (a nawet miliony) dolarów wydanych na opłacenie wysiłków inżynierów, dochodzą jeszcze straty z powodu utraconych przychodów – powinniśmy ściśle kontrolować te zmiany.
W architekturze mikroserwisowej to nie zadziała, ponieważ system będzie w stanie ciągłej ewolucji; to ta wolność powoduje namacalne innowacje. Ale aby zapewnić, że wolność nie doprowadzi do błędów i przestojów, musimy móc zaufać procesowi rozwojowemu i wdrażania. Aby umożliwić taką swobodę, musimy także zminimalizować wysiłek potrzebny do wydania nowej usługi lub zmiany istniejącej. Możemy osiągnąć stabilność przez standaryzację i automatyzację:
■ powinniśmy zestandaryzować proces rozwoju – powinniśmy przejrzeć zmiany w kodzie, napisać odpowiednie testy i utrzymywać kontrolę wersji kodu źródłowego; mamy nadzieję, że nikogo to nie dziwi!
■ powinniśmy zestandaryzować i zautomatyzować proces wdrażania – powinniśmy dokładnie zweryfikować dostarczanie zmian w kodzie do produkcji oraz spowodować, aby wymagało to minimalnej interwencji ze strony inżyniera; to jest strumień wdrażania.
2.5.2. Odporność
Zapewnienie odporności oprogramowania w obliczu awarii jest skomplikowanym zadaniem. Infrastruktura stanowiąca podstawę naszych systemów jest z natury nieprzewidywalna; nawet jeśli nasz kod jest doskonały, połączenia sieciowe nie będą działać, a serwery ulegną awarii. W ramach projektowania usługi należy się zastanowić, w jaki sposób ona i jej zależności mogą zawieść, i proaktywnie działać, aby uniknąć lub zminimalizować wpływ tych scenariuszy awarii.
W tabeli 2.2 przeanalizowano potencjalne obszary ryzyka w systemie wdrożonym przez SimpleBank. Widać, że nawet stosunkowo prosta aplikacja mikroserwisowa wprowadza kilka obszarów potencjalnego ryzyka i złożoności.
Tabela 2.2. Obszary ryzyka w aplikacji mikroserwisowej SimpleBanku
UWAGA Rozdział 6 zawiera omówienie technik maksymalizacji odporności usługi.
2.5.3. Przejrzystość
Zachowanie i stan mikroserwisu powinny być obserwowalne – w każdej chwili powinniśmy móc określić, czy usługa jest zdrowa i czy przetwarza zadania w sposób, jakiego oczekujemy. Jeśli coś ma wpływ na kluczowe wskaźniki – powiedzmy umieszczenie zlecenia na giełdzie trwa zbyt długo – to powinno zostać wysłane ostrzeżenie do zespołu inżynierów.
Zilustrujemy to przykładem. W zeszłym tygodniu nastąpiła awaria w SimpleBanku. Klient zadzwonił i powiedział, że nie może składać zleceń. Szybko się okazało, że miało to wpływ na wszystkich klientów – dla żądań do usługi tworzenia zleceń upłynął limit czasu. Na rysunku 2.10 pokazano możliwe punkty awarii w ramach tej usługi.
Rysunek 2.10. Osiągnięcie limitu czasu usługi może być spowodowane kilkoma podstawowymi przyczynami: problemami z siecią, problemami z wewnętrznymi zależnościami usługi – takimi jak bazy danych – lub nieoczekiwanym zachowaniem innych usług
Było jasne, że pojawił się poważny problem operacyjny – brakowało logowania, aby dokładnie określić, co poszło nie tak i gdzie wszystko się rozpadło. Dzięki ręcznym testom udało się wyizolować problem – nie odpowiadała usługa obsługi transakcji na rachunku. Tymczasem klienci nie mogli składać zleceń przez kilka godzin. Nie byli z tego powodu zadowoleni.
Aby uniknąć takich problemów w przyszłości, musimy dodać uzupełniające instrumentarium do naszych mikroserwisów. Gromadzenie danych na temat aktywności aplikacji – na wszystkich warstwach – ma kluczowe znaczenie do zrozumienia obecnego i przeszłego operacyjnego zachowania aplikacji mikroserwisowej.
Przede wszystkim SimpleBank powinien stworzyć infrastrukturę do agregowania podstawowych dzienników generowanych przez nasze usługi, wysyłając je do serwisu, który pozwoli na ich oznaczanie i wyszukiwanie8. Na rysunku 2.11 widać to podejście. W ten sposób, następnym razem gdy usługa zawiedzie, zespół inżynierów będzie mógł wykorzystać te dzienniki do zidentyfikowania punktu, w którym system uległ awarii, i zdiagnozować problem dokładnie tam, gdzie wystąpił.
Rysunek 2.11. Na każdej instancji instalujemy agenta do gromadzenia dzienników. Przesyła on dane dzienników aplikacji do centralnego repozytorium, tam można je indeksować, przeszukiwać i analizować
Ale niewystarczające rejestrowanie nie było jedynym kłopotem. To było żenujące, że SimpleBank zidentyfikował problem dopiero wtedy, gdy zadzwonił klient. Firma powinna otrzymywać alarmy bezpośrednio, aby zapewnić, że każda usługa spełnia swoje obowiązki i cele.
W takich przypadkach powinniśmy mieć w najprostszej postaci powtarzające się sprawdzanie pulsu każdej usługi, aby móc powiadomić zespół, jeśli usługa całkowicie przestanie reagować. Poza tym zespół powinien zobowiązać się do operacyjnych gwarancji dla każdej usługi. Na przykład w przypadku krytycznej usługi możemy oczekiwać 95% odpowiedzi na żądania w czasie krótszym niż 100 ms z 99,99% dostępnością usługi. Nieosiągnięcie tych progów powinno spowodować wysłanie alarmów do właścicieli usług.
Budowanie mechanizmu dokładnego monitorowania aplikacji mikroserwisowej jest złożonym zadaniem. Poziom głębokości monitorowania, który zastosujemy, będzie ewoluować wraz ze wzrostem złożoności systemu oraz liczby usług. Oprócz metryk operacyjnych i dzienników, które opisaliśmy, dojrzałe rozwiązanie do monitorowania mikroserwisów będzie uwzględniało metryki biznesowe, śledzenie międzyusługowe i metryki infrastruktury. Jeśli chcemy zaufać naszym usługom, musimy nieustannie pracować nad ich zrozumieniem.
UWAGA W części 4 omówimy szczegółowo monitorowanie oraz to, jak korzystać z narzędzi takich jak Prometheus
SRE odkryło, że około 70% przestojów spowodowanych jest zmianami w działających systemach.
Istnieje kilka zarządzalnych usług do agregacji dzienników, w tym Loggly, Splunk i Sumo Logic. Możemy również uruchomić tę funkcjonalność, korzystając ze znanego zbioru narzędzi ELK (Elasticsearch, Logstash, Kibana).