Мне нравится Lambda за ее универсальность и гибкость. Список сервисов, которые могут его вызывать постоянно растет, что позволяет им брать на себя рабочие нагрузки, для которых традиционно требовался EC2 или, в последнее время, контейнеры. Одним из самых последних дополнений к этому списку является Балансировщик нагрузки приложений.

Когда в ноябре 2018 года было сделано объявление, я был заинтригован, узнав больше о вариантах использования этих двух сервисов, работающих вместе. Признаюсь, я изо всех сил пытался найти для него надежный реальный пример использования и обнаружил, что в Интернете мне задают похожие вопросы. После некоторых размышлений и дальнейших исследований варианты использования стали проясняться. Варианты вращаются вокруг возможности начать замену компонентов серверного приложения без необходимости реализовывать беспорядочные и сложные решения.

Прежде чем я продолжу, вам нужно понять, как работают балансировщики нагрузки приложений по сравнению с традиционными балансировщиками нагрузки (ELB Classic). ALB имеет два дополнительных компонента:

  • Целевые группы. Целевая группа используется для объединения групп серверов, которые выполняют одинаковые операции.
  • Прослушиватели: они получают запросы на подключение для определенного порта и протокола (например, 80 / HTTP или 443 / HTTPS) и состоят из ряда правил. Правила традиционно основаны на пути и могут направлять трафик к определенным целевым группам.

В реальном сценарии представьте, что у нас есть сайт онлайн-продажи билетов, который получает большой трафик и должен гарантировать, что клиенты, покупающие билеты, не пострадают от тех, кто заходит на сайт для просмотра доступных мест. Мы могли бы создать две целевые группы, группу A и B. Используя правила, трафик для / кассового обслуживания может направляться в группу B, а затем все остальное направляется в группу A. Концепция относительно проста.

После этого вот некоторые из моих мыслей и сценариев использования лямбда-функции за ALB:

  • У вас есть традиционное серверное приложение, которое также имеет веб-API. Этот API встроен в общее монолитное приложение, и вы хотите его разбить, чтобы улучшить процессы выпуска и масштабируемость.
  • У вас есть традиционное серверное приложение, которое отображает некоторые HTML-страницы. Эти страницы важны, но не обязательно должны находиться на серверах или в монолитном приложении, поэтому вы хотите их разделить.
  • У вас есть традиционное серверное приложение с несколькими статическими активами. Вы хотите сохранить их на S3, чтобы сэкономить на затратах на EBS, но у вас нет возможности легко изменить архитектуру приложения.

Теперь вы знаете теорию, давайте попробуем!

Пачкаем руки

Я собираюсь использовать для этого Serverless Framework и .NET - это должно быть так же легко для понимания любым, кто может читать CloudFormation или шаблон SAM с C # в качестве среды выполнения. Шаги так же легко переносятся в Консоль! Я также предполагаю, что был создан общедоступный VPC.

Начнем с создания новой службы:

sls create --template aws-csharp --path LambdaALB

Мне нравится постепенно развертывать компоненты, когда я работаю над новым PoC, чтобы увидеть, что работает, а что нет, поэтому первые компоненты, которые я собираюсь создать в разделе ресурсов файла serverless.yml, следующие:

  • Группа безопасности, которая разрешает трафик на порт 80.
  • Балансировщик нагрузки приложений
  • Целевая группа (без целей)
  • Слушатель

Теперь у нас есть балансировщик нагрузки, который никуда не направляет трафик. Раньше вам приходилось запускать несколько экземпляров EC2 и назначать их целевой группе, но теперь я собираюсь создать три лямбда-функции для сценариев, упомянутых ранее.

Определение для каждой функции обычное, однако вместо традиционного события HTTP будет использоваться событие ALB. Необходимо определить слушателя (со ссылкой на созданный ранее) вместе с приоритетом и путем для ответа на запросы.

В моем репозитории GitHub есть немного более подробный код, но вот пример очень простого кода для ответа на запрос от ALB. Ключевым моментом здесь является ссылка на пакет ApplicationLoadBalancerEvents и возврат ApplicationLoadBalancerResponse, в противном случае вы получите ошибку шлюза 502 от вашего ALB.

Теперь у нас есть базовый код, давайте развернем то, что мы уже сделали, и посмотрим на результат - успех!

Меня всегда заинтриговала структура событий, которая вызывает лямбда-функции. Это особенно полезно, если вы используете путь, метод, строки запроса или любую другую информацию из события для выполнения определенных действий из вашей лямбда-функции.

Хорошо - теперь у нас должно быть три URL-адреса, на примере моего балансировщика нагрузки (замените мой URL-адрес вашим):

  • Страница HTML: http://lambd-loadb-mzay8zovkhl7-1612334130.ap-southeast-2.elb.amazonaws.com/

  • API: http://lambd-loadb-mzay8zovkhl7-1612334130.ap-southeast-2.elb.amazonaws.com/api/

  • Активы S3: http://lambd-loadb-mzay8zovkhl7-1612334130.ap-southeast-2.elb.amazonaws.com/assets/200.jpg

Мне особенно нравится последнее решение по выгрузке статических ресурсов на S3. Самое лучшее в этом решении - вам не нужно менять свое приложение! Код, хотя и грубый и требует некоторой доработки, относительно прост, но умен. Он берет путь из запроса и извлекает объект из корзины S3 с тем же ключом. Просто помните, что этот метод делает доступным для всех ваше ведро, поэтому не храните там ничего приватного!

Заключение

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

Мне было бы интересно услышать другие варианты использования, с которыми вы, возможно, столкнулись, не стесняйтесь комментировать или писать мне в Twitter или LinkedIn!

Ссылки: Репозиторий GitHub