Существует ли облачный сервис, который позволяет пробуждать ВМ / контейнер при входящем TCP-соединении? - PullRequest
Новая
       71

Существует ли облачный сервис, который позволяет пробуждать ВМ / контейнер при входящем TCP-соединении?

0 голосов
/ 12 декабря 2018

Я хотел бы разместить сетевой сервер, который обрабатывает запросы короткими пакетами.Он должен работать нечасто, пока клиенты к нему подключены.Поддержание виртуальной машины в режиме 24/7 в случае, если клиент подключается, расточительно.

Существует ли служба в общедоступном облачном провайдере (например, AWS, GCP, Azure и т. Д.), Которую можно настроить для пробуждения / запускаВМ (или какая-либо форма экземпляра контейнера с пользовательскими двоичными файлами), когда на определенном порту есть входящее TCP-соединение?

Существуют облачные службы, которые при необходимости запускают контейнеры или виртуальные машины по запросу.происходят события (созданные объекты, очереди сообщений, вызов REST API, доступ по http / https).Но я не могу найти ничего для обработки общих сетевых событий TCP-соединения.

Примеры использования:

  • почтовый сервер с низким трафиком, который должен выполнять работу только при подключении клиента через IMAP или при входящемпочта через SMTP.
  • виртуальная машина разработки, которая возобновляется, когда разработчик подключается по SSH.

Я бы предпочел рецепт AWS, но, возможно, есть варианты у других облачных провайдеров.Может быть, какой-то сервис балансировки нагрузки?Я готов заплатить небольшой штраф за задержку в несколько секунд за его пробуждение.

1 Ответ

0 голосов
/ 12 декабря 2018

Если вы контролируете код на стороне клиента, вы можете разделить взаимодействие на две части.Первый отправляет запрос к конечной точке HTTP, поддерживаемой лямбда-функцией.Функция раскрутит виртуальную машину / контейнер и ответит клиенту адресом сервера.Оттуда клиент может продолжать работать как обычно.

Поскольку вы платите только за конечную точку HTTP за фактический вызов, вы ничего не платите, пока она не используется.

В качестве альтернативы это возможносоздать группу автоматического масштабирования AWS с минимальным числом экземпляров и максимумом 1. Поскольку у вас иногда будет нулевое число экземпляров, показатель, который вы отслеживаете для автоматического масштабирования, не может основываться на экземплярах EC2.Поэтому вам нужен AWS Elastic Load Balancer (ELB) перед вашей группой автоматического масштабирования.ELB публикует метрики в AWS CloudWatch, и ваша группа масштабирования должна использовать эти метрики с использованием политики динамического масштабирования.

На этом этапе вы должны спросить себя, не дешевле ли просто сохранить один наноэкземпляр, работающий в режиме 24x7, ипроще - https://aws.amazon.com/about-aws/whats-new/2015/12/introducing-t2-nano-the-smallest-lowest-cost-amazon-ec2-instance/

...