Cloud Native

How I Learned to Stop Worrying and Love the Cloud

Licencja Creative Commons

Nazywam się Maciej i jestem programistą

Przez 11 lat pisałem aplikacje webowe

Niektórych nie muszę się nawet wstydzić

Teraz zajmuję się zagadnieniami związanymi z orkiestracją zadań w systemach rozproszonych

Czyli okolicami: Kubernetesa, Mesosa, OpenStacka etc

Od czterech lat pracuję z aplikacjami uruchamianymi w chmurze

Zacząć należy od przyjęcia definicji chmury

Chmura, to infrastruktura i sposób umożliwiania swobodnego dostępu do błyskawicznie dostarczanych zasobów obliczeniowych pochodzących ze współdzielonej puli

(wolne tłumaczenie z angielskiej Wikipedii®)

Kluczem w tej definicji jest słowo współdzielonej

Chmura może być publiczna, może być prywatna, ale nie jesteśmy w niej sami

Bo tak jest taniej

Dalej to już będzie tylko historia wtop

Stan

Aplikacja zapisywała pliki na wolumenie sieciowym

Wolumen mógł być montowany tylko w jednym punkcie

Wolumen powinien być odmontowany w chwili zatrzymywania maszyny wirtualnej

Czasami nie był

Błędy:

  • jedna instancja aplikacji
  • niemożność zamontowania wolumenu po awarii
Rozwiązanie
dedykowana usługa odpowiedzialna za przechowywanie plików

Wincyj stanu!

Aplikacja wymagała regularnego uruchamiania zadań

Czyli korzystała z crona, który czyta pliki

Pliki z lokalnego dysku

Wybierano więc mastera!

Dokładniej: wybierano go co minutę na każdej instancji

Sposób wyboru pozostawiał wiele do życzenia...

Błędy:

  • możliwość nieprawidłowego (nie)uruchomienia zadań
Rozwiązanie
serverless, scheduler w klastrze

Uruchamianie instancji

Wzrastał ruch i aplikacja musiała się skalować

Dodanie nowej instancji do load balancera trwało

10 (słownie: dziesięć) minut

Aplikacja, oczywiście, przez 10 minut nie działała

Błędy:

$ apt-get update && apt-get dist-upgrade && reboot && deploy.sh
Rozwiązanie
odpowiednie obrazy startowe instancji

Monitoring

Aplikacja udostępniała usługę po pewnym protokole

Health check aplikacji otwierał połączenie TCP na wskazanym porcie

Jeśli to się udało - uznawał aplikację za działającą

Aplikacja nigdy nie wysłałaby żadnych danych

Stojące przed nią proxy pozwalało otworzyć połączenie

Błędy:

  • monitoring niedostosowany do potrzeb
Rozwiązanie
użycie prawdziwego żądania jako health checka, wystawienie dedykowanego endpointu

Nie lepszy monitoring

Wybrano metrykę, która decydowała o skalowaniu aplikacji

Metryką to było zużycie CPU (w jednostce czasu)

Błąd:

  • celem jest maksymalizowanie zużycia CPU
Rozwiązanie
Application Performance Metrics

Vendor Lock

Aplikacja opierała się o usługę dostarczaną przez AWS

Usługa była instancją aplikacji open source

Pewnego dnia okazało się, że AWS ograniczył możliwości konfiguracji

Zmiana spowodowała zatrzymanie replikacji bazy danych

Błąd:

  • użycie istniejącej, ale nieudokumentowanej funkcjonalności
Rozwiązanie
utrzymywanie klastra wolnej aplikacji na własną rękę

Utrzymanie obrazów

Obrazy startowe instancji były utrzymywane ręcznie

Ludzie popełniają błędy, więc bywały one uszkodzone

W razie potrzeby nagłej aktualizacji brakowało procedury

Bywało, że wkradał się chaos

Błąd:

  • brak automatyzacji
Rozwiązanie
automatyzacja procesu tworzenia i aktualizacji obrazów

Utrzymanie środowiska

Kolejne składowe środowiska były dodawane ręcznie

Aplikacja korzystała z rosnącej liczby zewnętrznych zależności

Nie było miejsca, w którym można było znaleźć ich konfigurację

Nie można było odtworzyć środowiska w razie awarii

Nie można było łatwo stworzyć środowiska testowego

Błąd:

  • brak automatyzacji
Rozwiązanie
automatyzacja procesu tworzenia i modyfikacji środowiska

Jedna instancja

Uruchamiano jedną instancję aplikacji

W przypadku nieudanego wdrożenia powodowało to całkowitą jej niedostępność

Podobny problem miał miejsce w przypadku awarii instancji, AZ albo regionu

Błąd:

  • brak konfiguracji zapewniającej HA
Rozwiązanie
umożliwienie horyzontalnego skalowania aplikacji

1. Automatyzuj

2. Monitoruj

3. Zapewniaj wysoką dostępność

4. Testuj powyższe

5. Regularnie powtarzaj testy

6. Nie nadużywaj usług w chmurze publicznej

28 lutego 2017 roku miała miejsce poważna awaria S3 w regionie us-east-1

Lej po bombie był głęboki i szeroki

Ludzki błąd (ustawienie złej zmiennej dla ansiblowego playbooka) spowodował niedostępność usługi

W efekcie problemy dotknęły inne amazonowe usługi (EC2, EBS, Lambdę) w kluczowym regionie

Jeden z klientów, Spire Labs, opublikował posta opisującego reakcję ich systemu

Kubernetes najspokojniej w świecie przemigrował wszystkie usługi do innego regionu

Pamiętajcie, że to nie jest magia

Prawidłowe skonfigurowanie jakiegokolwiek schedulera wymaga niemałego wysiłku

Ale tak właśnie powinna działać chmura

7. Używaj schedulera

Bardzo dziękuję wszystkim twórcom, których dzieła wykorzystałem w tej prezentacji

(oraz tym, którzy w inny sposób pomogli ją na czas przygotować)

https://twitter.com/iwankgb, https://github.com/iwankgb