Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 28

Zaprojektowaliśmy funkcjonalność SimpleBank, która wymaga interakcji wielu usług, kolejki zdarzeń i bramy API. Powiedzmy, że zrobiliśmy też następny krok – zbudowaliśmy te usługi, a teraz dyrektor generalny naciska na nas, abyśmy wprowadzili je do produkcji.

W publicznych chmurach, takich jak AWS, Azure lub GCE, oczywistym rozwiązaniem jest wdrożenie każdej usługi do grupy maszyn wirtualnych. Możemy użyć load balancera w celu równomiernego rozłożenia obciążenia między instancjami każdej usługi lub użyć zarządzanej kolejki zdarzeń, takiej jak AWS Simple Queue Service do rozdziału zdarzeń między usługami.

UWAGA  Dogłębna dyskusja na temat skutecznej automatyzacji i zarządzania infrastrukturą wykracza poza zakres tej książki. Większość dostawców usług w chmurze zapewnia tę możliwość dzięki niestandardowym narzędziom, takim jak AWS CloudFormation lub AWS Elastic Beanstalk. Można również rozważyć użycie narzędzi open source, takich jak Chef lub Terraform.

W każdym razie – skompilowaliśmy kod, załadowaliśmy go na maszyny wirtualne, uruchomiliśmy bazy danych i wypróbowaliśmy niektóre testowe żądania. Zajęło to kilka dni. Na rysunku 2.9 pokazaliśmy naszą infrastrukturę produkcyjną.

Rysunek 2.9. W prostym wdrożeniu mikroserwisów żądania do każdej usługi są równomiernie rozdzielane na wiele instancji uruchomionych na wielu maszynach wirtualnych. Ponadto wiele instancji usługi może subskrybować kolejkę

Przez kilka tygodni nie działało to bardzo źle. Wprowadziliśmy kilka zmian i wdrożyliśmy nowy kod. Ale wkrótce zaczęliśmy wpadać w kłopoty. Trudno było stwierdzić, czy usługi działają zgodnie z oczekiwaniami. Co gorsza, jesteśmy jedynymi w SimpleBanku, którzy wiedzą, jak wydać nową wersję. Jest jeszcze gorzej – człowiek, który napisał usługę obsługi transakcji wyjechał na wakacje na kilka tygodni i nikt nie wie, w jaki sposób usługa została wdrożona. Usługi te miałyby bus factor równy 1, co oznacza, że nie przetrwałyby zniknięcia członka zespołu.

DEFINICJA  Bus factor jest miarą ryzyka wynikającą z umiejętności niedzielonych między członków zespołu. Pochodzi to od wyrażenia „w sytuacji, gdyby zostali potrąceni przez autobus”. Jest to również znane jako truck factor. Im niższa wartość bus factor, tym gorzej.

Coś zdecydowanie poszło nie tak. Przypomnieliśmy sobie, że w ostatniej pracy w GiantBanku zespół zarządzający infrastrukturą zajmował się wydaniami. Należało do niego zgłosić sprawę, chodzić wokół niej, a po kilku tygodniach można było uzyskać to, czego się potrzebowało … a czasami nie, sprawę zatem zgłaszało się ponownie. To też nie wydaje się być właściwym podejściem. W rzeczywistości cieszyliśmy się, że korzystanie z mikroserwisów pozwoli nam zarządzać wdrożeniami.

Można z całą pewnością powiedzieć, że nasze usługi nie były gotowe do produkcji. Uruchamianie mikroserwisów wymaga od zespołu inżynierskiego poziomu wiedzy operacyjnej i radzenia sobie z problemami nie tylko typowymi dla aplikacji monolitycznej. Można powiedzieć, że usługa jest gotowa do produkcji tylko wtedy, jeśli można jej zaufać, że będzie spełniać wymagania produkcyjne.

Jak można być pewnym, że usługa jest godna zaufania? Zacznijmy od listy pytań, które należy wziąć pod uwagę, aby osiągnąć gotowość produkcyjną:

■ Niezawodność – czy nasza usługa jest możliwa do użycia i wolna od błędów? Czy można polegać na procesie wdrażania, aby wdrożyć nowe funkcjonalności bez wprowadzania niestabilności lub wad?

■ 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 do wyzwalania alarmów i budowania pulpitów kontrolujących działanie mikroserwisów.

7

SRE odkryło, że około 70% przestojów spowodowanych jest zmianami w działających systemach.

8

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).