Sandeep Dinesh
następnie
czerwiec 28, 2016 · 4 min Czytaj
trzy proste kroki, aby obniżyć koszty podczas prototypowania z aplikacji silnika Elastyczne środowisko
Jeśli kiedykolwiek korzystałeś z aplikacji silnika Google, wiesz, że jest to jeden z najszybszych sposobów, aby dostać się od pomysłu do działającego prototypu., Dopóki przestrzegasz ograniczeń piaskownicy, nie musisz konfigurować serwerów, instalować pakietów ani wykonywać żmudnych zadań DevOps, które Cię spowalniają.
wraz z wprowadzeniem elastycznego środowiska App Engine (wcześniej znanego jako zarządzane maszyny wirtualne), Google zniosło wiele ograniczeń piaskownicy i dodało więcej wbudowanych środowisk uruchomieniowych, w tym węzeł.js i Ruby. Możesz nawet dostosować wszystko, określając swój własny plik Dockerfile!
Zobacz porównanie tutaj.
jednak ta elastyczność ma swoją cenę., Elastyczne środowisko jest wolniejsze we wdrażaniu i nie może być skalowane tak szybko, jak Standardowe środowisko. Domyślne wdrożenie to również przesada przy tworzeniu prototypów.
największą różnicą moim zdaniem jest brak „skali do zera.”W standardzie App Engine, jeśli nikt nie korzysta z Twojej aplikacji, wszystko się wyłącza. W momencie, gdy użytkownik odwiedza, App Engine uruchamia instancję w milisekundach, aby obsłużyć nowe żądanie. W połączeniu z dużą warstwą bezpłatną nie musisz się martwić o koszty infrastruktury dla prototypów., Obecnie Elastyczne środowisko potrzebuje co najmniej jednego wystąpienia uruchomionego do obsługi ruchu i nie ma wolnej warstwy.
przyjrzyjmy się kilku najlepszym praktykom tworzenia prototypów w elastycznym środowisku, które może zminimalizować koszty.
aktualizacja 2019: zdecydowanie polecam używanie Cloud Run zamiast App Engine Flex dla większości zadań. Moim zdaniem, łączy najlepsze z App Engine Standard (pay per use, scale to zero) Z App Engine Flex (elastyczność, pliki Dockerfiles). Jedyną dużą zaletą Flex jest większe rozmiary wystąpień.,
uruchamiamy węzeł.aplikacja js na elastycznym środowisku App Engine. Domyślna aplikacja.yaml wygląda mniej więcej tak:
runtime: nodejs
env: flex
wdrożyć go za pomocą polecenia gcloud:
$ gcloud app deploy
Po wdrożeniu aplikacji możemy sprawdzić sekcję „Instances” w silniku aplikacji, aby zobaczyć, co następuje:
domyślnie uruchamia dwa N1-standardowe-1 VMs., Ma to na celu zapewnienie większej niezawodności.
przyjrzyjmy się miesięcznemu kosztowi tego wdrożenia. Skonfigurowałem to domyślne wdrożenie w kalkulatorze cen Google Cloud tutaj.
to ponad 80 zł miesięcznie!
chociaż ta cena byłaby w porządku, gdybyś obsługiwał ruch produkcyjny, jest to dość śmieszne na etapie prototypowania.
Krok pierwszy: zmniejsz liczbę wystąpień
możemy obniżyć koszty o połowę, uruchamiając jedną instancję zamiast dwóch. Aby to zrobić, włącz skalowanie ręczne (nie potrzebujesz automatycznego skalowania dla prototypu) i ustaw instancje na 1., Więcej o skalowaniu można przeczytać tutaj.
zmodyfikuj aplikację.yaml:
runtime: nodejs
env: flex
manual_scaling:
instances: 1
to obniży nasz koszt z około $80 do $40! Nieźle!