Aplikacja w chmurach. Na co uważać?

Nic w naszej pracy nie jest WYŁĄCZNIE “proste i przyjemne”. Zawsze kryje się… coś jeszcze. Zwykle nie jest to nic dobrego. I w chmurze także można zrobić sobie kuku. Chmuku?

Teraz możesz mieć swój własny serwer w chmurze całkowicie za darmo, aż na 12 miesięcy. Rozwijaj swoją aplikację, twórz rozwiązania infrastrukturalne i ucz się wykorzystania cloud computingu bez ponoszenia kosztów.
https://www.oktawave.com/pl/freetier

Bezpieczeństwo

Sprawa najważniejsza: musimy upewnić się, że nasze wirtualne środowisko jest odpowiednio zabezpieczone.

Czy taki np. firewall jest od razu zainstalowany i skonfigurowany, czy trzeba to zrobić samemu? Pozostawianie maszynki otwartej na cały świat raczej nigdy nie będzie dobrym rozwiązaniem.

Dobrym pomysłem może być skonfigurowanie prywatnej sieci w chmurowym środowisku. Czy wszystkie serwery muszą być dostępne z zewnątrz? Najprawdopodobniej nie. Więc kompletnie ukryjmy te, które mogą sobie działać w cieniu.

Multi-node

Sam proces tworzenia aplikacji “do chmury” wymaga świadomości programistów. Nie chodzi nawet o to, że nasza usługa będzie od tej pory działała “w cloudzie”, a raczej: że będzie działała na wielu maszynach.

Load balancing

Nie da się skalować aplikacji w nieskończoność, dokładając więcej i więcej żelastwa do jednej maszyny. Na pewnym poziomie konieczne będzie rozproszenie działania systemu pomiędzy wiele węzłów. Wówczas w razie problemów wydajnościowych dokładamy do środowiska kolejną maszynę, i… śmiga dalej.

Odpowiedzialny jest za to load balancer. W najprostszej postaci mechanizm ten działa na zasadzie “round robin” – żądania wysyłane są do dostępnych serwerów po kolei. Dzięki temu ich obciążenie będzie w miarę równomierne, a postawienie nowej maszyny spowoduje zmniejszenie ruchu na dotychczasowych serwerach.

Sesja

Często w aplikacjach webowych symuluje się stanowość poprzez zastosowanie mechanizmu sesji. Domyślna implementacja takiego zachowania to: “połączmy identyfikator użytkownika z danymi w pamięci serwera“. Co jest w tym złego? Że pamięć jednego serwera nie jest kopiowana do pamięci innego serwera.

Możemy podejść do problemu dwojako.

Droga pierwsza, łatwiejsza: zapisujemy sesję w miejscu innym niż pamięć serwera. Może to być albo dedykowana usługa, działająca niezależnie od aplikacji. Może to być baza danych, do której dostęp będą miały wszystkie instancje aplikacji. Albo zewnętrzny cache, mapujący identyfikator sesji użytkownika na obiekt zawierający wszystkie potrzebne informacje. Redis, anyone? Wszystko sprowadza się do użycia odpowiedniej implementacji SessionStateProvidera.

Droga druga, trudniejsza: akceptujemy, że HTTP jest protokołem bezstanowym i nie staramy się udawać, że jest inaczej. Co to oznacza? Ano to, że stan musi być każdorazowo przekazany z klienta do aplikacji. Każda komenda powinna być otoczona odpowiednim zestawem danych, pozwalającym na realizację polecenia bez sięgania do żadnego “symulatora stanu”. Pomóc mogą w tym pyszne ciasteczka, jednak uwaga: przeglądarki różnie definiują maksymalny rozmiar cookies, więc nie zapędzajmy się i trzymajmy tam faktycznie tylko to, co konieczne.

Bazy plikowe i system plików

Uruchomienie aplikacji na kilku serwerach oznacza, że katalog aplikacji również zostanie umieszczony w kilku miejscach ogromu internetu. Czyli: pliki pojawią się w kilku kopiach. Co za tym idzie, musimy zapomnieć o używaniu wygodnej do małych zastosowań, bez-serwerowej bazy danych zapisującej dane w lokalnym pliku.

Plik bazy na jednej instancji aplikacji będzie inny, niż plik bazy na drugiej instancji. Oczywiste, prawda? Niby tak, a jednak musiałem się niegdyś przekonać o tym “the hard way” :). Lepiej od razu przygotować się na prawdziwe, serwerowe rozwiązania bazodanowe.

Wykracza to zresztą poza bazy danych. Sercem problemu jest tak naprawdę założenie, że system plików jest do naszej dyspozycji. Owszem, jest, ale tylko do momentu, w którym zaczynamy go modyfikować. Czytać: można. Pisać: nie. Dlaczego? Bo zapisze się tylko na jednej instancji. Która dodatkowo może w każdej chwili zniknąć.

Chcesz oglądać swoje… logi?

Jeśli już przy systemie plików jesteśmy: jak Twoja aplikacja informuje cały piękny świat o tym, co się w niej aktualnie dzieje? Albo: co się stało, że się… zepsuło? Logi, prawda?

Ano właśnie, logi. Jak, gdzie? Tutaj plik /logs/<date>_<hour>.txt nie przejdzie! Z tego samego powodu, który poznaliśmy już wcześniej. Tak zapisany tekst nie jest transferowany na inne maszyny w środowisku. Więc pozostaje bazka, albo na przykład ElasticSearch.

Przy okazji: zachęcam do zerknięcia na biblioteczkę Serilog. O “semantic logging” jeszcze się kiedyś rozpiszę, ale w tym kontekście Serilog się przyda, bo umie słać informacje do Elastika.

Mikro-skalowalność

W poprzednim artykule wspomniałem pobieżnie o skalowalności. Czy to takie proste do osiągnięcia?

Oczywiście, że nie. Tylko jedna rzecz jest prosta do osiągnięcia w IT w naszych okolicznościach przyrody: tytuł Senior Developera :).

Skalowanie jednej wielkiej aplikacji zawsze będzie wyzwaniem. Jak zatem podejść do tego problemu? Poradziłbym: trochę z drugiej strony. Pomóc może rozbicie jednej wielkiej aplikacji na wiele aplikacji mniejszych. Mikroserwisy? Zwał jak zwał, ale… tak.

Z mikroserwisami jest jak z Yeti: ktoś podobno gdzieś kiedyś widział, ale… nie przeżył. Mówi się o tym dużo, pisze jeszcze więcej. Jak to się ma do chmury?

Gdy uporamy się z faktami i mitami, które wokół mikroserwisów urosły, okaże się, że to nic innego jak stare dobre SOA – Service Oriented Architecture. Tylko ubrane w bardziej kolorowe fatałaszki. Wspomożemy się dodatkowo DDD – Domain Driven Design – i jesteśmy gotowi do drogi. Zamiast jednej uber-aplikacji wdrożymy cały zestaw serwisów, a okaże się, że być może tylko mała ich część faktycznie potrzebuje skalowania? Może sam frontend – to, co najbliższe użytkownikowi – trzeba wspomóc dodatkową mocą obliczeniową, a cała reszta doskonale sobie radzi?

Bardzo zachęcam do poeksplorowania tego zagadnienia i zastanowienia się nad fizycznymi granicami, które można w procesie postawić. Nie jest to proste (a co gorsza: nie ma jednego uniwersalnego rozwiązania), ale może okazać się, że łatwiej jest zwiększyć wydajność grupy usług, niż jednego GOD-service.

Regiony

Koniecznie trzeba zwracać uwagę na konkretne miejsce na świecie, w którym składowane będą dane. Czyli: region. Jest to istotne z dwóch powodów.

Pierwszy to: prawo. Niektóre dane nie mogą być przechowywane poza terenem Unii Europejskiej.

Powód drugi: wydatki. Kiedyś wdrożyłem w chmurze portalik działający dość prymitywnie: co X sekund pobierał całą zawartość (niewielkiej, ok 250MB) bazki do pamięci i operował na takim lokalnym cache. To wystarczało. Ale jakież było moje zdziwienie, gdy w zakładce “koszty” zobaczyłem ogromne jak na taką pierdołę kwoty!

Okazało się, że aplikację webową zainstalowałem na terenie UE, a bazę danych bezmyślnie wyklikałem w… USA. Przez własną głupotę zatem płaciłem za transfer ok 1GB danych na minutę. Szczęśliwie dość szybko zauważyłem to niedopatrzenie, przeniosłem bazę do miejsca działania aplikacji i koszty zniknęły.

Uff.

Pułapki

Chmura nie jest rozwiązaniem magicznym, które nie sprawi żadnych problemów. Natkniemy się na wiele wyzwań, z którymi trzeba sobie poradzić. Niejednokrotnie wiązać się to będzie z dziwnym zachowaniem aplikacji, z kosztami, zarwanymi nockami i rwaniem włosów z głowy. Czyli: programistyczna codzienność.

W zamian, oprócz satysfakcji, dostajemy jednak środowisko, które daje o wiele większe możliwości niż to, czym paraliśmy się do tej pory.