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:
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:
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
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:
Nie lepszy monitoring
Wybrano metrykę, która decydowała o skalowaniu aplikacji
Metryką to było zużycie CPU (w jednostce czasu)
Błąd:
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:
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:
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:
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:
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ć)
... i dużo dużo więcej.