Sytuacja kobiet w IT w 2024 roku
7.12.20166 min
Ringier Axel Springer Tech

DreamLabRingier Axel Springer Tech

Małpa w chmurach- Mechanizm Chaos Monkey w chmurze obliczeniowej DreamLabu

Małpa w chmurach- Mechanizm Chaos Monkey w chmurze obliczeniowej DreamLabu

Co się stanie jeśli w Twojej serwerowni zamieszka małpa? I jak się to ma do stabilności i odporności na awarie? Inżynierowie Netflixa wyszli z założenia że skoro awarie i tak się zdarzają, równie dobrze można spróbować wywoływać je samemu. W ten sposób stworzyli koncepcję Chaos Monkey, która pozwala im na co dzień testować niezawodność i odporność  systemów. Zaintrygowani niezwykłym pomysłem wprowadziliśmy go u siebie i teraz jesteśmy gotowi podzielić się lekcjami z implementacji tego mechanizmu w naszej prywatnej chmurze.


Chmura obliczeniowa w DreamLab


    Budowanie systemów IT w oparciu o chmurę obliczeniową to obecnie standard. Na rynku mamy kilku dużych dostawców gotowych rozwiązań, a użycie chmury jest wyjątkowo proste. Ale tak nie było zawsze, a szczególnie na początku gdy idea raczkowała, wiele rozwiązań nie było do końca określonych, co rusz pojawiały się nowe problemy i wątpliwości, a projektanci musieli na nowo skalibrować swoje spojrzenie na infrastrukturę i tworzone oprogramowanie.
Pomysł stworzenia naszej własnej chmury obliczeniowej zrodził się w 2011 roku. Była to decyzja przełomowa, ze względu na pojawienie się automatyki na wszystkich warstwach architektury - począwszy od fizycznych serwerów, przez warstwę aplikacyjną i bazodanową aż po serwisy frontowe.

iaas-paas-saas.png

Warstwa IaaS (Infrastructure as a Service) dostarcza API do powoływania serwerów wirtualnych. Przykrywa warstwę naszych fizycznych serwerów, ale potrafi też przekazać żądanie do innego dostawcy chmury np. Amazon Web Services, żeby właśnie tam stworzyć serwery wirtualne. Korzystając z API, w łatwy sposób możemy zażądać od IaaS serwera o określonych parametrach i otrzymać go do własnej dyspozycji. Korzysta z tego kolejna warstwa -  PaaS (Platform as a Service), która z kolei na powołanej puli serwerów uruchamia aplikacje. Tu również dostarczamy API, z którego korzystają programiści warstwy wyższej. Ich potrzeby dotyczą uruchomienia lub zatrzymania aplikacji. Takie podejście pozwoliło nam, praktycznie bezszelestnie, wejść w kulturę DevOps. Zespoły produktowe same zarządzają tym co i kiedy mają uruchomione. Z ich perspektywy, aplikacje wdrażane są w chmurze i nie muszą nawet wiedzieć gdzie, na jakim serwerze są uruchomione. Agregacja logów w centralnym miejscu oraz narzędzia zapewniające monitoring są wystarczające do utrzymywania i rozwoju innych usług warstwy PaaS oraz SaaS.


PaaS w powiększeniu

Jak wspomniałem wcześniej, warstwa PaaS również wystawia API. Klikając w panel WWW, programista może wskazać repozytorium kodu gdzie znajduje się jego aplikacja, określić liczbę instancji i nacisnąć “Wdrażaj”. W tym momencie do działania przechodzi automatyka warstwy PaaS. W pierwszej fazie, uruchamiany jest proces przygotowania paczki z aplikacją. Pobierane są źródła aplikacji, instalowane zależności, weryfikowana poprawność poprzez uruchomienie testy jednostkowe i następnie całość archiwizowana, a dalej archiwum wysyłane jest na usługę składowania plików S3/Ceph. Tak przygotowany pakiet może zostać pobrany bezpośrednio lub poprzez sieć Torrent. Samym uruchomieniem aplikacji zajmuje się już kolejny komponent - PaaS Agent. To aplikacja która jest instalowana na każdym serwerze wirtualnym uzyskanym od warstwy IaaS. Agent cyklicznie raportuje jakie aplikacje są uruchomione na jego serwerze i sprawdza w centrali czy jakiejś instancji nie brakuje. Jeśli tak, to rozpoczyna proces pobierania brakującej aplikacji i ją uruchamia. Sama centrala to tzw. Scoreboard - serce automatyki PaaS. To tu wpada żądanie programisty, żeby aplikacja została uruchomiona w 10 instancjach. O uruchomienie tych 10 instancji rywalizują wszyscy Agenci z wolnymi zasobami. Podobnie wygląda sytuacja z wyłączeniem instancji, w Scoreboard widziane jest to jako ich nadmiarowa ilość i Agenci pobiorą zadania zatrzymania. Sam Scoreboard jest prostą listą rankingową, która zapewnia jedynie elementarną synchronizację i mechanizm adresowania aplikacji do grup serwerów. Jego utrata nie jest problemem - dane bieżące szybko zostaną odtworzone na podstawie raportów wysyłanych przez Agentów.
scoreboard.png

Uruchomione aplikacje są wpinane do szyny komunikacyjnej, która umożliwia komunikację aplikacji między sobą oraz przyjmowanie ruchu z zewnątrz. Dodatkowo, jeden z komponentów warstwy utrzymuje pewną pulę serwerów wirtualnych na których uruchamiane są aplikacje. Aktualnie mamy około dwóch tysięcy serwerów typu m1.small (wg nomenklatury Amazon EC2). Serwery oparte są o Ubuntu 16.04, a ich docelową konfigurację (np. instalacja wymaganych pakietów) zapewnia Salt Stack. Całość monitorowana przy użyciu Usługi monitoringu MaaS, która opiera się na projektach Disthene oraz Grafana.


Aplikacje w PaaS


Aplikacje powstające w DreamLab pracują zgodnie z nowoczesną ideą mikroserwisów. Pracują asynchronicznie, co pozwala nam uzyskać wysoką wydajność pojedynczej instancji. Dodatkowo, nasze aplikacje są bezstanowe, co oznacza że wszystkie dane operacyjne składowane są w bazach danych czy usługach takich jak kolejki albo w usłudze przechowywania plików S3/CEPH. Takie podejście pozwala nam uruchamiać i zatrzymywać aplikacje bez szkody dla naszych klientów.
Aplikacje są automatycznie wpinane do load-balancera, co ułatwia komunikację między aplikacjami i wystawianie API aplikacji do użytkowników zewnętrznych.
Technologie z których korzystamy do budowy aplikacji to głównie NodeJS oraz Python. W przypadku tego drugiego, pracujemy korzystając z wersji 3.5 oraz Tornado Web Server. Wybór Tornado wynikał z chęci pisania asynchronicznych aplikacji jeszcze zanim pojawił się natywny moduł asyncio.
Do izolowania aplikacji uruchomionych na tym samym serwerze wykorzystujemy mechanizm cgroups. Programista dostaje monitoring działania swojej aplikacji generowany na podstawie logów (określa jakie zdarzenia w logach mają być zliczane) oraz wewnętrzne takie jak wykorzystanie zasobów procesora i pamięci.


Małpie figle


Mechanizm Chaos Monkey, czyli celowe wprowadzenie stanu awarii do systemu został zaproponowany przez firmę Netflix. Idea jest prosta - skoro awaria może się przytrafić, a my twierdzimy że jesteśmy na nią odporni to ... nie czekajmy - tylko sami wywołajmy taką awarię. Zatem wpuszczamy wirtualną małpę do serwerowni, a ona  widząc wiele interesujących guziczków i kabli zaczyna swoje harce. Jeśli systemy są projektowane z myślą o wysokiej dostępności i odporności na awarię, powinny być w stanie się przed tym obronić. Małpa jest rodzajem testu integracyjnego dla tych mechanizmów. 
Nasze najważniejsze systemy mają być odporne na awarie, dlatego od początku towarzyszyła nam chęć zaadoptowania ChaosMonkey w naszej chmurze. Można powiedzieć, że pierwsza wersja tego mechanizmu opierała się na określonym czasie życia serwera wirtualnego. Czas ten był stosunkowo krótki od 4 - 6 godzin. Takie cykliczne powoływanie serwerów w miejsce tych wygaszanych i idąca za tym konieczność ponownego uruchamiania działających aplikacji zapewniała nam ciągły test systemu i weryfikowała odporność na awarię pojedynczego czy też grupy serwerów wirtualnych. Mieliśmy pewność, że działa tworzenie serwerów wirtualnych oraz że aplikacje są bezstanowe i potrafimy je ponownie uruchomić na innym serwerze. Przy tym komforcie wyjątkowo proste staje się zarządzanie fizycznymi serwerami bez ciężkich mechanizmów jak Live-Migration. Wystarczy że w innym miejscu powołamy nowe serwery wirtualne i na nich uruchomimy aplikacje.

diagram-rotacja.png

Niestety takie podejście jest obarczone dwoma problemami. Pierwszy to koszt powołania serwera wirtualnego - to nie dzieje się za darmo i jest obciążające na warstwie IaaS. Ciągle rosnąca chmura, duża prędkość powoływania serwerów rzędu kilkunastu na minutę zaczynała sprawiać problemy wydajnościowe. Drugim problemem było to, że pewne błędy czy problemy w aplikacjach nie były zauważalne od razu, np. wycieki pamięci. Zwykle dowiadywaliśmy się o tym dopiero w przypadku problemów w warstwie IaaS lub PaaS, gdy zatrzymywaliśmy wymianę serwerów i tym samym restarty aplikacji. Nagle okazywało się, że inne systemy działają gorzej, właśnie przez długo działające aplikacje.
Naszym kolejnym podejściem była implementacja mechanizmu Chaos Monkey - zamiast cyklicznej wymiany serwerów robimy to zupełnie losowo. Podobnie jak NetFlix realizujemy dwa główne scenariusze. Losowego zniszczenia serwera wirtualnego, co skutkuje utratą kilku uruchomionych na nim instancji, oraz lżejszy scenariusz - zatrzymania losowo wybranej instancji aplikacji. Częstotliwość działania scenariuszy dobieramy tak, żeby testować odporność na awarię, a jednocześnie żeby nie był to proces zbyt zasobożerny.  

diagram-chaos-monkey.png

Takie podejście powoduje że serwer może działać kilka minut lub kilka dni. Podobnie z aplikacjami, działają tak długo jak nie trafi na daną instancję małpa, która po prostu ją zatrzyma. Mechanizmy, które posiada warstwa PaaS, takie jak wykrywanie brakujących instancji aplikacji lub serwerów wirtualnych są ciągle testowane, a nieprzewidywalność działania małpy dodatkowo pozwoliła nam przybliżyć się do realiów prawdziwych awarii.


Podsumowanie


W dzisiejszych czasach budowanie systemów IT jest znacznie prostsze niż kiedyś. Automatyzacja uruchamiania serwerów i aplikacji pozwala nam na pracę w kulturze DevOps, a także prowadzenie procesów ciągłej integracji i wdrożeń. Ale to nie wszystko - warstwa PaaS dba także o to, żeby powstałe systemy były odporne na awarię. Tytułowa małpa ciągle płata figle aplikacjom i serwerom, a dzieje się to bez wyjątków, także w godzinach największego ruchu na serwisach. Jeśli system jest na to odporny, możemy spać spokojnie. Prawdziwa awaria, np. fizycznego serwera nie jest dla nas problemem, a nawet więcej - nie jest nawet zauważona na wyższych warstwach naszej chmury.


Tomasz Prus
PaaS Platform KRK

<p>Loading...</p>