Дизайн Google Cloud Platform для приложения с сохранением состояния

Question

Использование: наше требование - запускать сервис непрерывно каждые несколько минут. Эта служба читает значение из хранилища данных и обращается к опубликованному URL c, используя это значение из хранилища данных (с сохранением состояния). Этот сервис не имеет Front End. Никто не будет иметь доступ к этой услуге публично. Новое значение сохраняется в хранилище данных в результате ответа от URL. Для работы необходим только один сервер.

Нам нужно выбрать один из следующих вариантов для нашего варианта использования.

1. Compute Engine (IaaS -> мы не хотим поддерживать инфраструктуру для этого простого приложения с состоянием)
2. Kubernetes Engine (все еще чувствуя себя излишним)
3. App Engine: PaaS-> App Engine обычно используется для мобильных приложений, игр, веб-сайтов. App Engine предоставляет URL-адрес с веб-адресом. Это правильный выбор для нашего варианта использования? Если мы выберем движок приложения, можно ли остановить url движка приложения publi c? Кроме того, поскольку один экземпляр будет постоянно работать в ядре приложения, что является экономически эффективным - стандартным или гибким?
4. Облачные функции -> Управляемый событиями (выглядит не подходящим для нашего приложения)
5. Google Cloud Scheduler-> Мы думали, что можем использовать облачный планировщик + облачные функции. Но во время простоя рабочие места ставятся в очередь. В нашем случае после сбоя может быть запущен только один сервер / экземпляр / задание.

Спасибо!

Answer 1

после сбоя может быть запущен и запущен только один сервер / экземпляр / задание

Ограничение параллелизма функции облака достаточно? Если это так, вы можете сделать это:

gcloud functions deploy FUNCTION_NAME --max-instances 1 FLAGS...

https://cloud.google.com/functions/docs/max-instances

Я также рекомендую взглянуть на Google Cloud Run, это серверная платформа docker , он может быть ограничен максимум 1 экземпляром, отвечающим на максимум 1 запрос одновременно. Для этого также потребуется Cloud Scheduler, который отправляет к нему регулярные HTTP-запросы.

Если обе службы настроены с максимальным параллелизмом 1, только один сервер / экземпляр / задание будет запущен, но после простоев задания могут быть запланировано, как только другой финал sh. Если это проблематично c, добавьте поле даты и времени lastRun в строку задания хранилища данных и не запускайте его, если оно слишком недавно, или отключите повторную попытку облачного планировщика, как сказано здесь:

Триггер HTTP облачных задач Google - Как отключить повтор