Cloudflare Workers czy Vercel Functions? Rachunek rośnie z innej metryki

Cloudflare Workers jest łatwiejszy do oszacowania, gdy znasz liczbę wywołań i czas pracy procesora. W Vercel Functions te same dane nie wystarczą: w modelu Fluid Compute znaczenie ma również czas, przez który instancja rezerwuje pamięć. Aplikacja długo czekająca na bazę może więc zużywać mało CPU, a mimo to zwiększać koszt pamięci.

Workers będzie mocnym kandydatem dla krótkich żądań, jeśli kod i jego zależności działają w tym środowisku. Vercel Functions może być prostszym wyborem dla aplikacji zależnej od pełnego Node.js lub istniejącego wdrożenia na Vercel. W obu przypadkach koszt funkcji trzeba oddzielić od dostarczania odpowiedzi użytkownikowi i od opłat za bazę danych.

Za co płaci każda platforma

Cennik Cloudflare Workers podaje przykład 15 mln żądań miesięcznie przy średnio 7 ms CPU na żądanie: łącznie 8 USD, z czego 5 USD to opłata za plan, a po 1,50 USD przypada na żądania i CPU ponad miesięczne pule. Standardowy model rozlicza żądania oraz czas CPU, lecz nie nalicza opłaty za sam czas oczekiwania ani za wychodzący transfer Workers. Trafienie w cache obsługiwany przez Worker nadal liczy się jako żądanie, choć CPU jest naliczany tylko wtedy, gdy kod się wykonuje.

W cenniku Fluid Compute Vercel rozdziela wywołania funkcji, aktywny CPU i pamięć przydzieloną instancji. Na planie Pro wywołania kosztują 0,60 USD za milion, a dla regionu Frankfurt stawki wynoszą 0,184 USD za godzinę CPU oraz 0,0152 USD za GB-godzinę pamięci. CPU przestaje być naliczany podczas oczekiwania na zewnętrzną usługę, natomiast pamięć pozostaje zarezerwowana do zakończenia obsługiwanych żądań. Pro rozlicza te zasoby według użycia; miesięczny kredyt planu może pomniejszyć należność.

Ten sam ruch w dwóch rachunkach

Przyjmijmy hipotetyczną aplikację: 15 mln dynamicznych wywołań miesięcznie, 7 ms aktywnego CPU i 100 ms oczekiwania na bazę przy każdym wywołaniu. Funkcja w Vercel ma przydzielone 2 GB pamięci i działa we Frankfurcie. Średnia treść odpowiedzi ma 10 kB. Na razie zakładamy brak trafień w cache oraz brak równoczesnej obsługi kilku żądań przez jedną instancję. To jawne uproszczenia do porównania metod rozliczania, a nie pomiar działającej aplikacji.

Workers wykonuje w tym scenariuszu łącznie 105 mln ms CPU, więc jego koszt odpowiada przytoczonemu przykładowi: 8 USD miesięcznie za Workers. Czas oczekiwania na bazę wydłuża odpowiedź dla użytkownika, ale nie powiększa tej sumy. Nie obejmuje ona bazy ani innych usług, które aplikacja mogłaby wykorzystywać.

W Vercel same wywołania dają 9 USD. Łączny aktywny CPU to około 29,17 godziny, czyli 5,37 USD przy przyjętej stawce. Jeżeli instancja pozostaje zajęta przez pełne 107 ms każdego żądania, pamięć daje około 891,67 GB-godziny i 13,55 USD. Suma trzech metryk funkcji wynosi zatem 27,92 USD przed kredytem Pro, opłatą za plan i pozostałymi składnikami faktury. Nie jest to cena całej aplikacji ani bezpośredni odpowiednik kwoty Workers, która zawiera już opłatę za jego plan.

Dlaczego oczekiwanie na bazę zmienia wynik

Różnicę tworzy czas życia instancji, a nie dodatkowa praca procesora. W hipotetycznym żądaniu CPU pracuje przez 7 ms, lecz pamięć może pozostać przydzielona także przez 100 ms oczekiwania na bazę. Gdy zapytanie trwa dłużej, część CPU w rachunku Vercel może pozostać taka sama, podczas gdy liczba GB-godzin rośnie. Opóźnienie bazy wpływa zarazem na czas odpowiedzi, niezależnie od tego, jak tanie jest samo czekanie.

Założenie o osobnej instancji dla każdego żądania zawyżałoby pewność takiego szacunku. Fluid Compute pozwala jednej instancji obsługiwać równocześnie kilka wywołań: pamięć jest wtedy naliczana za życie instancji, a nie osobno za pełny czas każdego oczekującego żądania. Przy większej współbieżności część pamięciowa może być niższa niż 13,55 USD; zależy to od rozkładu ruchu i faktycznego czasu pracy instancji. Średni CPU na wywołanie sam nie pozwala jej wyznaczyć.

Transfer i cache poza kosztem funkcji

Tabela cen Vercel wykazuje osobno Fast Data Transfer do użytkownika, Fast Origin Transfer między CDN a funkcją oraz żądania CDN. W wariancie rozliczanym według użycia podaje stawki 0,15 USD za GB transferu do użytkownika, 0,06 USD za GB transferu między CDN a funkcją i 2 USD za milion żądań CDN. Dostępny jest również wariant Flat Rate CDN. Ceny podano w USD bez VAT; sposób naliczenia podatku zależy od danych rozliczeniowych nabywcy.

W naszym uproszczeniu 15 mln odpowiedzi po 10 kB to około 150 GB samej treści. Przy podanych stawkach oznaczałoby to 22,50 USD transferu do użytkowników i 30 USD za żądania CDN. Jeśli każda dynamiczna odpowiedź przechodzi też z funkcji przez CDN, jej treść daje orientacyjnie kolejne 9 USD transferu origin. Razem z 27,92 USD za funkcję otrzymujemy około 89,42 USD rachunku cząstkowego w wariancie według użycia. Rzeczywiste naliczenie uwzględni także przesyłane żądania i narzut HTTP, a zależnie od konfiguracji również inne metryki, kredyt planu, jego opłatę oraz podatek.

Cache zmienia rachunek tylko zgodnie z miejscem, w którym zostaje obsłużone żądanie. Odpowiedź podana przez CDN bez wywołania funkcji ogranicza jej wywołania oraz zużycie CPU i pamięci, lecz nadal wymaga obsługi ruchu przez CDN. Cache użyty dopiero wewnątrz kodu nie usuwa samego wywołania. Dlatego liczba wizyt, liczba żądań CDN i liczba uruchomień funkcji mogą być różnymi wielkościami.

Runtime i położenie bazy

Ograniczenia Vercel Functions wskazują pełne pokrycie API Node.js i możliwość zmiany domyślnego regionu wykonania. To ma znaczenie dla aplikacji używającej zależności Node.js oraz bazy umieszczonej w jednym regionie: funkcję można uruchomić bliżej danych. Nadal trzeba ocenić, czy jej położenie odpowiada także użytkownikom aplikacji.

Dokumentacja zgodności Workers z Node.js odróżnia API obsługiwane w pełni, częściowo i moduły, które można zaimportować, lecz których metody nie działają. Migracja zależy więc od konkretnych metod wywoływanych przez biblioteki i framework, nie od samej obecności pakietu npm. Dostosowanie kodu lub sposobu łączenia z bazą może kosztować więcej pracy niż sugeruje różnica w opłatach za funkcje.

Gdy baza działa w jednym regionie europejskim, wykonanie kodu blisko użytkownika nie gwarantuje szybkiej odpowiedzi. Każde odległe zapytanie do bazy dodaje podróż sieciową; przy kolejnych zapytaniach opóźnienia mogą się kumulować. Regionalna funkcja blisko danych, ograniczenie liczby zapytań albo cache odpowiedzi to różne rozwiązania tego samego problemu, wybierane według wymagań aplikacji dotyczących świeżości danych.

Gdzie przebiega wybór

Najpierw rozstrzyga zgodność kodu. Jeżeli aplikacja potrzebuje API Node.js, których Workers nie obsługuje, i migracja byłaby kosztowna, Vercel Functions ma przewagę niezależną od stawki za CPU. Gdy obie platformy uruchamiają ten sam kod, znaczenia nabiera profil obciążenia: liczba faktycznych wywołań funkcji, aktywny CPU, czas oczekiwania na bazę oraz współbieżność.

Następnie wynik zmienia położenie danych i droga odpowiedzi do użytkownika. Przy krótkim CPU i dużym ruchu model Workers może dać niski, czytelny koszt wykonania, ale baza nadal może dominować w opóźnieniu i osobnych opłatach. W Vercel trzeba doliczyć życie instancji oraz wybrany model CDN. Dla polskiego nabywcy porównanie kończy się na pełnej konfiguracji i kwocie faktury z właściwie naliczonym VAT, a nie na jednej stawce za wywołanie.

Przeczytaj także:

• Cloudflare R2 czy AWS S3? Brak opłat za transfer ma koszt wydajności
• Sentry czy Datadog? Jeden błąd może uruchomić dwa różne rachunki
• Ragas czy DeepEval? Wygodna metryka może nie zgadzać się z człowiekiem