Стоимость гибкой среды Google App Engine, урок за 500 долларов

Я следил за учебником Nodejs в App Engine по гибкому окружению @: https://cloud.google.com/nodejs/getting-started/hello-world

Успешно развернув и протестировав руководство, я изменил код, чтобы немного поэкспериментировать, и успешно развернул его ... а затем оставил его работающим, поскольку это была тестовая среда (не общедоступная).

Через месяц я получаю счет от Google на сумму более 370 долларов!

В деталях транзакции я вижу следующее:

1–31 октября 2017 г. ОЗУ экземпляра Flex App Engine: 5948,774 Гибибайт-часов ([MYPROJECT]) 42,24 доллара США.

1–31 октября 2017 г. Основные часы экземпляра App Engine Flex: 5948,774 часа ([MYPROJECT]) 312,91 доллара США

Каким образом эта тестовая среда с почти 0 запросами потребовала около 6000 часов ресурсов? В худшем случае я бы предположил, что 720 часов непрерывной работы в течение месяца по 0,05 доллара в час обойдутся мне примерно в 40 долларов. https://cloud.google.com/appengine/pricing

Может ли кто-нибудь помочь пролить свет на это? Я не мог понять, зачем понадобилось столько ресурсов?

Спасибо за помощь!

Для получения дополнительных данных это трафик за последний месяц (в основном 0):

И данные экземпляра

ОБНОВЛЕНИЕ: обратите внимание, что я внес одну модификацию в package.json: я добавил nodemon в качестве зависимости и добавил его как часть моего сценария «nmp start». Хотя я сомневаюсь, что это объясняет 6000 часов ресурсов:

  "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 (по умолчанию - без изменений из учебника)

runtime: nodejs
env: flex

После нескольких сеансов связи с Google и часов чтения блогов и просмотра отчетов я наконец (отчасти) нашел объяснение тому, что произошло. Я размещу его здесь со своими предложениями, чтобы другие люди также не стали жертвами этой проблемы.

Обратите внимание: некоторым это может показаться очевидным, но как новый пользователь GAE все это было для меня в новинку.

Короче говоря, при развертывании в GAE и использовании следующей команды « $ gcloud app deploy » он создает новую версию и устанавливает ее по умолчанию, но также, что более важно, НЕ удаляет предыдущую развернутую версию.

Более подробную информацию о версиях и экземплярах можно найти здесь: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine

Итак, в моем случае, не зная об этом, я создал несколько версий своего простого приложения node. Эти версии все еще работают на случай, если потребуется переключиться после ошибки. Но для этих версий также требуются экземпляры, и по умолчанию, если не указано в app.yaml, установлено 2 экземпляра.

Google говорит:

App Engine по умолчанию масштабирует количество запускаемых экземпляров в соответствии с нагрузкой, обеспечивая тем самым постоянную производительность вашего приложения в любое время, сводя к минимуму простаивающие экземпляры и, таким образом, снижая затраты.

Однако, по моему опыту, это не так. Как я сказал ранее, я запустил свое приложение node с помощью nodemon, который, похоже, вызывал ошибки.

В конце концов, следуя руководству и не закрывая проект, у меня было 4 версии, в каждой из которых 2 экземпляра работали полный рабочий день в течение 1,5 месяцев, обслуживая 0 запросов и генерируя множество сообщений об ошибках, и это обошлось мне в 500 долларов.

РЕКОМЕНДАЦИИ, ЕСЛИ ВЫ ЕЩЕ ХОТИТЕ ИСПОЛЬЗОВАТЬ GAE FLEX ENV:

1. Прежде всего, настройте платежный бюджет и оповещения, чтобы вас не удивил дорогой счет, который автоматически взимается с вашей CC: https://cloud.google.com/billing/docs/how-to/budgets

2. В тестовой среде вам, скорее всего, не потребуется несколько версий, поэтому при развертывании используйте следующую команду:
   $ gcloud app deploy --version v1

3. Обновите свой app.yaml, чтобы заставить только 1 экземпляр с минимальными ресурсами:

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. Установить дневной лимит расходов

См. Это сообщение в блоге для получения дополнительной информации: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-f flexible-environment-104fc6736495

Я бы хотел, чтобы некоторые из этих шагов были включены в учебник, чтобы защитить тех, кто пытается учиться и экспериментировать, но это не так.

Google App Engine Flex env может оказаться сложной задачей, если не знать всех этих деталей. Друг указал мне на Heroku, где есть как цены, так и предложения Free / Hobby. Я смог быстро разместить там новое приложение узла, и оно сработало как шарм! https://www.heroku.com/pricing

Выучить этот урок "всего" обошлось мне в 500 долларов, но я надеюсь, что это поможет другим, смотрящим на Google App Engine Flex Env.

Если вы хотите снизить затраты на GAE, НЕ используйте, manual_scalingкак это предлагается в этой статье или принятый ответ!

Самое прекрасное в Google App Engine заключается в том, что он может масштабироваться до сотен машин за миллисекунды в зависимости от спроса. И вы платите только за запущенные экземпляры.

Чтобы иметь возможность оптимизировать свои затраты, вам необходимо понимать различные варианты масштабирования и типы экземпляров:

1. Гибкость движка приложения и стандарт:

Подробности о различиях можно найти здесь , но одно важное отличие, имеющее отношение к этому вопросу:

[Стандарт] предназначен для работы бесплатно или по очень низкой цене, когда вы платите только за то, что вам нужно, и тогда, когда вам это нужно. Например, ваше приложение может масштабироваться до 0 экземпляров при отсутствии трафика.

2. Параметры масштабирования:

• Автоматическое масштабирование: Google масштабирует ваше приложение в зависимости от требований и предоставленной вами конфигурации.
• Масштабирование вручную: масштабирования нет вообще, GAE будет постоянно запускать точное количество запрошенных вами экземпляров (очень вводящее в заблуждение название)
• Базовое масштабирование: оно будет увеличиваться до установленного вами лимита, а также уменьшится через определенное время.

3. Типы инстансов. Существует 2 типа инстансов , и они в основном различаются по времени, необходимому для запуска нового инстанса. Экземпляры класса F (используемые при автоматическом масштабировании) могут быть созданы, когда необходимо, в течение ~ 0,1 секунды, а экземпляры класса B (используемые при ручном масштабировании / базовом) в течение ~ 0,7 секунды:

Теперь, когда вы поняли основы, вернемся к принятому ответу:

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

Это дает команду GAE запускать собственный класс экземпляра ( более затратный ). Очевидно, что это не самый дешевый вариант, потому что вместо него можно использовать тип экземпляра B1 / F1 (у него более низкие характеристики), а также он постоянно запускает экземпляр.

Что было бы дешевым , чтобы выключить случай , когда нет движения. Если вы не возражаете против времени раскрутки ~ 0,1 секунды, вы можете вместо этого использовать следующее:

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)

Это будет подпадать под бесплатные квоты, предоставляемые Google, и не должно вам ничего стоить, если у вас нет реального трафика.

PS: Также настоятельно рекомендуется установить дневной лимит расходов на случай, если вы что-то забыли, или у вас где-то есть дорогостоящие настройки.

У нас был код, развернутый для GAE FE, который полностью сходил с ума из-за каскадного экспоненциального сбоя (возвращенные электронные письма генерировали возвращенные электронные письма и т. Д.), И мы НЕ могли отключить экземпляры GAE, которые были обнаружены. После 4+ часов и более 1 миллиона отправленных писем (Mailgun просто НЕ позволил нам отключить учетную запись. В нем говорилось: «Пожалуйста, подождите до 24 часов, чтобы изменение пароля вступило в силу», а отозванные ключи API ничего не сделали), виртуальная машина redis был остановлен, БД отключена, и весь код сайта уменьшен до одной статической страницы 503 «Не работает»), электронные письма продолжали отправляться.

Я определил, что GAE FE просто не останавливает ни докеры, ни виртуальные машины облачных вычислений (redis), которые находятся под нагрузкой на ЦП. Может никогда! После того, как мы действительно удалили вычислительную виртуальную машину (вместо того, чтобы «просто» остановить ее), электронные письма немедленно прекратились.

Но наша БД продолжала заполняться уведомлениями «не удалось отправить электронную почту» еще до 2 часов, несмотря на то, что приложение GAE сообщало, что 100% версий и экземпляров были «остановлены». В итоге мне пришлось изменить пароль Google Cloud SQL.

Мы продолжали проверять счет, и 7 мошеннических экземпляров продолжали использовать ЦП, поэтому мы отменили карту, используемую в этой учетной записи, и сайт действительно отключился, когда счет был просрочен, но также и мошеннические экземпляры. Нам так и не удалось разрешить ситуацию с поддержкой по электронной почте GAE.

Обновление (30 сентября 2020 г.): Это все еще худший момент в моей 22-летней карьере !! Целая компания из 15 первоклассных гениальных разработчиков не могла придумать, как выключить GAE. Мы знали, что клиенты получают МИЛЛИОНЫ электронных писем, когда один из моих разработчиков не может получить доступ к своей учетной записи GMail. Не мог отключить от сети, не мог выключить. Это был настоящий терминаторский момент!

Это было бы не так уж плохо, если бы MailGun позволил нам фактически отключить доступ к API или изменить пароль, если бы не расходы. Но с точки зрения затрат на GAE это все равно было бы плохо.

Я больше не доверяю серверам, на которых не могу оформить выпуск reboot.

В итоге MailGun снял с нас всего около 50 долларов. Однако GAE ... Если бы я просто предположил: «Хорошо, почта прекратилась, мы можем прекратить», мы могли бы закончить с лишним счетом в 20 000 долларов! Как бы то ни было, он стоил «всего» 1500 долларов . И мы никогда не могли связаться с кем-либо, чтобы оспорить это. Итак, генеральный директор просто съел это.

Также обратите внимание, что если вы по-прежнему хотите, чтобы ваше приложение имело автоматическое масштабирование, но не хотите, чтобы по умолчанию работали как минимум 2 экземпляра постоянно, вы можете настроить свой app.yaml следующим образом:

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

Поскольку никто не упомянул, вот команды gcloud, связанные с версиями

# 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

для сред разработки, где я не возражаю против небольшой задержки, я использую следующие настройки:

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

И если вы используете свой экземпляр больше, чем разрешено бесплатное количество экземпляров серверной части, попробуйте следующее:

instance_class: F1
automatic_scaling:
  max_instances: 1

На панели управления AppEngine следите за экземплярами, обратите внимание на время начала и убедитесь, что по прошествии периода idle_timeout счетчик экземпляров упадет до нуля, и вы увидите сообщение «В этой версии нет развернутых экземпляров».