Cena elastycznej wersji środowiska Google App Engine, lekcja o wartości 500 USD

Postępowałem zgodnie z samouczkiem Nodejs w App Engine Flexible env @: https://cloud.google.com/nodejs/getting-started/hello-world

Po pomyślnym wdrożeniu i przetestowaniu samouczka zmieniłem kod, aby trochę poeksperymentować i pomyślnie go wdrożyłem ... a następnie zostawiłem go uruchomionego, ponieważ było to środowisko testowe (nie publiczne).

Miesiąc później otrzymałem rachunek od Google na ponad 370 USD!

W szczegółach transakcji widzę:

1 - 31 października 2017 r. Wystąpienie App Engine Flex Pamięć RAM: 5948,774 Gibibajtogodzin ([MYPROJECT]) 42,24 USD

1–31 października 2017 r. Godziny pracy rdzenia instancji App Engine Flex: 5948,774 godzin ([MYPROJECT]) 312,91 USD

W jaki sposób to środowisko testowe z prawie 0 żądaniami wymagało około 6000 godzin zasobów? W najgorszym przypadku założyłbym, że 720 godzin pracy na pełny etat przez miesiąc przy 0,05 USD za godzinę kosztuje mnie ~ 40 USD. https://cloud.google.com/appengine/pricing

Czy ktoś może pomóc rzucić na to światło? Nie byłem w stanie dowiedzieć się, dlaczego potrzebnych było tak wiele środków?

Dzięki za pomoc!

Aby uzyskać więcej danych, jest to ruch w ciągu ostatniego miesiąca (w zasadzie 0):

I dane instancji

AKTUALIZACJA: Zauważ, że wprowadziłem jedną modyfikację do pliku package.json: dodałem nodemon jako zależność i dodałem go jako część mojego skryptu "nmp start". Chociaż wątpię, aby to wyjaśniało 6000 godzin zasobów:

  "scripts": {
    "deploy": "gcloud app deploy",
    "start": "nodemon app.js",
    "dev": "nodemon app js",
    "lint": "samples lint",
    "pretest": "npm run lint",
    "system-test": "samples test app",
    "test": "npm run system-test",
    "e2e-test": "samples test deploy"
  },

App.yaml (domyślnie - bez zmian w stosunku do samouczka)

runtime: nodejs
env: flex

Po wielu godzinach czytania blogów i przeglądaniu raportów, w końcu (nieco) znalazłem wyjaśnienie tego, co się stało. Wrzucę to tutaj z moimi sugestiami, aby inne osoby również nie padły ofiarą tego problemu.

Uwaga, dla niektórych może się to wydawać oczywiste, ale jako nowy użytkownik GAE wszystko to było dla mnie zupełnie nowe.

Krótko mówiąc, podczas wdrażania do GAE i przy użyciu następującego polecenia „ $ gcloud app deploy ” tworzy nową wersję i ustawia ją jako domyślną, ale co ważniejsze, NIE usuwa poprzedniej wersji, która została wdrożona.

Więcej informacji o wersjach i instancjach można znaleźć tutaj: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine

Więc w moim przypadku, nie wiedząc o tym, stworzyłem wiele wersji mojej prostej aplikacji node. Te wersje nadal działają na wypadek konieczności zmiany po błędzie. Ale te wersje również wymagają instancji, a domyślną, o ile nie określono w pliku app.yaml, są 2 instancje.

Google mówi:

App Engine domyślnie skaluje liczbę uruchomionych i zmniejszonych instancji w celu dopasowania do obciążenia, zapewniając w ten sposób stałą wydajność aplikacji przez cały czas, jednocześnie minimalizując bezczynne wystąpienia, a tym samym zmniejszając koszty.

Jednak z mojego doświadczenia tak się nie stało. Jak powiedziałem wcześniej, pchnąłem moją aplikację węzła z nodemonem, który wydaje się powodować błędy.

W końcu, postępując zgodnie z samouczkiem i nie zamykając projektu, miałem 4 wersje, każda z 2 instancjami działającymi w pełnym wymiarze godzin przez 1,5 miesiąca, obsługujących 0 żądań i generujących wiele komunikatów o błędach, co kosztowało mnie 500 USD.

ZALECENIA, JEŚLI NADAL CHCESZ UŻYWAĆ GAE FLEX ENV:

1. Przede wszystkim skonfiguruj budżet rozliczeniowy i alerty, aby nie zaskoczyć Cię kosztowna faktura, która jest automatycznie naliczana na Twój CC: https://cloud.google.com/billing/docs/how-to/budgets

2. W środowisku testowym najprawdopodobniej nie potrzebujesz wielu wersji, więc podczas wdrażania użyj następującego polecenia:
   $ gcloud app deploy --version v1

3. Zaktualizuj plik app.yaml, aby wymusić tylko 1 wystąpienie przy minimalnych zasobach:

runtime: nodejs
env: flex

# This sample incurs costs to run on the App Engine flexible environment.
# The settings below are to reduce costs during testing and are not appropriate
# for production use. For more information, see:
# https://cloud.google.com/appengine/docs/flexible/nodejs/configuring-your-app-with-app-yaml
manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10

4. Ustaw dzienny limit wydatków

Zobacz ten post na blogu, aby uzyskać więcej informacji: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-f flexible-environment-104fc6736495

Żałuję, że niektóre z tych kroków nie zostały uwzględnione w samouczku, aby chronić tych, którzy próbują się uczyć i eksperymentować, ale tak nie było.

Środowisko Google App Engine Flex może być trudne, jeśli nie znasz wszystkich tych szczegółów. Znajomy wskazał mi Heroku, w którym ustalono zarówno ceny, jak i oferty Free / Hobby. Udało mi się szybko umieścić tam nową aplikację dla węzłów i zadziałało to cudownie! https://www.heroku.com/pricing

Ta lekcja kosztowała mnie „tylko” 500 dolarów, ale mam nadzieję, że pomoże to innym, którzy przyjrzą się Google App Engine Flex Env.

Jeśli chcesz obniżyć koszty GAE, NIE używaj manual_scalingzgodnie z sugestią w tym artykule lub zaakceptowaną odpowiedzią!

Piękną rzeczą w Google App Engine jest to, że można go skalować w górę iw dół do setek maszyn w ciągu milisekund w zależności od zapotrzebowania. Płacisz tylko za uruchomione instancje.

Aby móc zoptymalizować koszty, musisz zrozumieć różne opcje skalowania i typy instancji:

1. Flex silnika aplikacji a standard:

Szczegółowe informacje na temat różnic można znaleźć tutaj , ale jedną ważną różnicą dotyczącą tego pytania jest:

[Standard jest] Przeznaczony do działania za darmo lub po bardzo niskich kosztach, gdzie płacisz tylko za to, czego potrzebujesz i kiedy tego potrzebujesz. Na przykład aplikacja może być skalowana do 0 wystąpień, gdy nie ma ruchu.

2. Opcje skalowania:

• Automatyczne skalowanie: Google skaluje Twoją aplikację w zależności od zapotrzebowania i podanej konfiguracji.
• Skalowanie ręczne: w ogóle nie ma skalowania, GAE będzie przez cały czas uruchamiać dokładnie liczbę wystąpień, o które prosiłeś (bardzo mylące nazewnictwo)
• Skalowanie podstawowe: będzie skalowane w górę, aby ograniczyć ustawione przez Ciebie ustawienia, a także zmniejszy się po pewnym czasie

3. Typy instancji: Istnieją 2 typy instancji i zasadniczo różnią się one czasem potrzebnym do uruchomienia nowej instancji. Instancje klasy F (używane w automatycznym skalowaniu) można tworzyć, gdy zajdzie taka potrzeba w ciągu ~ 0,1 sekundy, a wystąpienia klasy B (używane w skalowaniu ręcznym / podstawowym) w ciągu ~ 0,7 sekundy:

Teraz, gdy zrozumiałeś podstawy, wróćmy do zaakceptowanej odpowiedzi:

manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10

To nakazuje GAE, aby cały czas uruchamiał niestandardową klasę instancji ( bardziej kosztowną ). Oczywiście nie jest to najtańsza opcja, ponieważ zamiast tego można użyć instancji typu B1 / F1 (ma niższe specyfikacje), a także stale uruchamia instancję.

Jaki byłby najtańszy jest wyłączenie wystąpienie kiedy nie ma ruchu. Jeśli nie przeszkadza Ci ~ 0,1 sekundy czasu rozpędzania się, możesz zamiast tego zrobić to:

instance_class: F1
automatic_scaling:
  max_instances: 1 (--> you can adjust this as you wish)
  min_instances: 0 (--> will scale to 0 when there is no traffic so won't incur costs)

Będzie to mieściło się w ramach bezpłatnych limitów oferowanych przez Google i nie powinno Cię nic kosztować, jeśli nie masz prawdziwego ruchu.

PS: Zaleca się również ustawienie dziennego limitu wydatków na wypadek, gdybyś zapomniał o czymś działającym lub gdzieś masz kosztowne ustawienia.

Kod wdrożony w GAE FE absolutnie zwariował z powodu kaskadowego, wykładniczego błędu (odesłane e-maile, wygenerowane odesłane e-maile itp.) I NIE mogliśmy wyłączyć instancji GAE, które były błędne. Po ponad 4 godzinach i ponad milionie wysłanych e-maili (Mailgun po prostu NIE pozwolił nam wyłączyć konta. Komunikat „Poczekaj do 24 godzin, aż zmiana hasła zacznie obowiązywać”, a unieważnienie kluczy API nic nie dało), maszyna wirtualna redis został zatrzymany, baza danych wyłączona, a cały kod witryny zredukowany do pojedynczej statycznej strony 503 „Wyłączony z powodu konserwacji”), e-maile były nadal wysyłane.

Ustaliłem, że GAE FE po prostu nie kończy ani dokerowanych maszyn wirtualnych, ani maszyn wirtualnych Cloud Compute (redis), które są obciążone przez procesor. Może nigdy! Gdy faktycznie usunęliśmy maszynę wirtualną Compute (zamiast „tylko” ją zatrzymać), wiadomości e-mail natychmiast się zatrzymały.

Jednak nasza baza danych nadal była wypełniona powiadomieniami „nie można wysłać wiadomości e-mail” przez kolejne 2 godziny, mimo że aplikacja GAE zgłaszała 100% wersji i instancji jako „zatrzymanych”. W końcu musiałem zmienić hasło Google Cloud SQL.

Ciągle sprawdzaliśmy rachunek, a 7 nieuczciwych instancji nadal zużywało procesor, więc anulowaliśmy kartę używaną na tym koncie, a witryna faktycznie przestała działać, gdy rachunek był zaległy, ale tak samo jak te nieuczciwe. Nigdy nie byliśmy w stanie rozwiązać tej sytuacji z pomocą e-mailową GAE.

Aktualizacja (30 września 2020 r.): To wciąż najgorszy moment w mojej 22-letniej karierze !! Cała firma składająca się z 15 genialnych twórców cracków nie mogła wymyślić, jak wyłączyć GAE. Wiedzieliśmy, że klienci otrzymywali MILIONY e-maili, gdy jeden z moich programistów nie mógł uzyskać dostępu do jej konta Gmail. Nie można go odłączyć, nie można go wyłączyć. To był niezły moment "Terminatora"!

Nie byłoby tak źle, gdyby nie wydatki, gdyby MailGun pozwolił nam faktycznie wyłączyć dostęp do API lub zmienić hasło. Ale w GAE nadal byłoby to kiepskie pod względem kosztów.

Nie ufam już serwerom, z którymi nie mogę rebootkorzystać.

Ostatecznie MailGun naliczył nam tylko około 50 USD. Jednak GAE ... Gdybym po prostu założył: „OK, poczta zatrzymana, możemy przestać”, moglibyśmy otrzymać nadwyżkę w wysokości 20 000 $! W tej chwili kosztował „tylko” 1500 dolarów . I nigdy nie mogliśmy skontaktować się z nikim, aby to zakwestionować. Więc dyrektor generalny po prostu to zjadł.

Pamiętaj również, że jeśli nadal chcesz, aby Twoja aplikacja miała automatyczne skalowanie, ale nie chcesz, aby domyślnie działały przez cały czas minimum 2 instancje, możesz skonfigurować app.yaml w następujący sposób:

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

Ponieważ nikt nie wspomniał, oto polecenia gcloud związane z wersjami

# List all versions
$ gcloud app versions list

SERVICE  VERSION.ID       TRAFFIC_SPLIT  LAST_DEPLOYED              SERVING_STATUS
default  20200620t174631  0.00           2020-06-20T17:46:56+03:00  SERVING
default  20200620t174746  0.00           2020-06-20T17:48:12+03:00  SERVING
default  prod             1.00           2020-06-20T17:54:51+03:00  SERVING

# Delete these 2 versions (you can't delete all versions, you have to have at least one remaining)
$ gcloud app versions delete 20200620t174631 20200620t174746

# Help
$ gcloud app versions --help

w środowiskach deweloperskich, w których nie przeszkadzają mi małe opóźnienia, używam następujących ustawień:

instance_class: B1
basic_scaling:
  max_instances: 1
  idle_timeout: 1m

A jeśli używasz instancji częściej niż z bezpłatnego limitu instancji backendu, wypróbuj następujące rozwiązania:

instance_class: F1
automatic_scaling:
  max_instances: 1

Na pulpicie nawigacyjnym AppEngine obserwuj wystąpienia, zanotuj czas rozpoczęcia i obserwuj, aby upewnić się, że po przekroczeniu okresu idle_timeout liczba wystąpień spadnie do zera i zostanie wyświetlony komunikat „Ta wersja nie ma wdrożonych instancji”.