Rozwiązania serverless i model scale-to-zero

Serverless odwraca ten układ. Twój kod czeka bezczynnie, dopóki nie przyjdzie żądanie, wykonuje się, zwraca odpowiedź i kończy pracę. Rozliczenie opiera się na czasie wykonania i liczbie wywołań. Kiedy nic się nie dzieje, koszt zbliża się do zera.

Przy systemie o nierównym ruchu ta różnica jest znacząca. Narzędzie wewnętrzne używane w godzinach pracy, sklep o wyraźnej sezonowości, raport uruchamiany dwa razy dziennie, API dostające dziesięć tysięcy żądań w ciągu godziny i nic aż do jutra. Wszystkie te przypadki na klasycznym serwerze spędzają większość życia bezczynnie.

Sprawdza się, gdy obciążenie jest nierówne albo trudne do przewidzenia, gdy praca jest z natury zdarzeniowa i gdy w przeciwnym razie trzeba by wymiarować infrastrukturę pod szczyt, który zdarza się rzadko. Znika też przy okazji cała kategoria pracy: nie ma systemu operacyjnego do łatania ani planowania pojemności, w którym można się pomylić.

Sprawdza się źle przy stałym, dużym ruchu. Jeśli Twój system obsługuje wyrównane obciążenie przez całą dobę, rozliczenie za wywołanie sumuje się do kwoty wyższej niż koszt zarezerwowanej instancji. Kiepsko pasuje też do długo trwających procesów, zadań wymagających dużo pamięci przez dłuższy czas oraz aplikacji, które muszą trzymać stan pomiędzy żądaniami.

Zanim to zarekomendujemy, patrzymy na Twój faktyczny ruch. Przeniesienie stale obciążonej aplikacji na serverless to dobry sposób na jednoczesne podniesienie złożoności i kosztów.

Pierwsza to zimne starty. Gdy funkcja nie była niedawno wywoływana, platforma musi ją najpierw wczytać, co dokłada opóźnienie do pierwszego żądania. Wielkość tego opóźnienia zależy od środowiska uruchomieniowego, zależności i samej platformy. Przy przetwarzaniu w tle nikt tego nie zauważy. Przy stronie, na którą czeka klient, trzeba to zmierzyć i ograniczyć.

Druga to połączenia do bazy danych. Klasyczna aplikacja otwiera pulę połączeń i korzysta z nich wielokrotnie. Serverless tworzy wiele krótko żyjących środowisk wykonawczych, z których każde chce własnego połączenia, a baza, która czuła się dobrze przy pięćdziesięciu, nie zniesie pięciuset. Da się to rozwiązać poolerem połączeń albo bazą zbudowaną pod ten wzorzec, ale trzeba to rozstrzygnąć świadomie już na etapie projektu.

Przeniesienie całości naraz rzadko jest właściwą odpowiedzią. Praktyczniejsza droga to wyciągnięcie tych fragmentów, które mają najbardziej nierówne obciążenie, i uruchomienie ich w modelu serverless, zostawiając stabilny rdzeń tam, gdzie jest. Przetwarzanie obrazów, generowanie raportów, obsługa webhooków, zadania cykliczne i wszystko wyzwalane z kolejki to zwykle dobrzy kandydaci na początek, bo mają naturalnie zdarzeniowy charakter i są już zazwyczaj odseparowane od reszty kodu.

Daje Ci to korzyść kosztową tam, gdzie jest największa, a zmianę utrzymuje w ryzach. Szybko pokazuje też, czy ten model odpowiada Twojemu zespołowi, co warto wiedzieć przed przeniesieniem na niego głównej aplikacji.

Limity współbieżności, maksymalne czasy wykonania i alerty budżetowe ustawiamy jako część wdrożenia, a nie po pierwszej nieprzyjemnej fakturze. Limity dobieramy tak, żeby realny wzrost został obsłużony, a zachowanie wymykające się spod kontroli zatrzymane. O przekroczeniu ustalonego progu wydatków dowiadujesz się wtedy, gdy do niego dochodzi, a nie na koniec miesiąca.