Разминка автоматизированного балансировщика нагрузки AWS

Автоматизируйте балансировщик нагрузки AWS, чтобы избежать проблем с резкими скачками трафика

Скорее всего, вы уже использовали AWS Load Balancer. Если у вас небольшой или постоянный трафик, вы можете поверить, что это работает как по волшебству, не сталкиваясь с реальностью, что, как и в любой другой системе, за ней стоят машины, которые могут выйти из строя.

С другой стороны, если вы столкнулись со сценарием, когда ваш трафик может увеличиться в 10 раз почти мгновенно, вы, вероятно, столкнулись с ужасной ошибкой 500, исходящей от самого балансировщика нагрузки.

Это именно то, с чем мы сталкивались при создании приложения для сброса кроссовок в прошлом.

Каждый раз, когда у нас случалось «событие сброса», трафик сервера увеличивался в 100 раз менее чем за минуту, что приводило к тому, что балансировщику нагрузки AWS требовалось время для масштабирования. Во время масштабирования большинство пользователей не могли использовать приложение.

Так что решение казалось очевидным, давайте предварительно прогреем наш балансировщик нагрузки и покончим с этим!

К сожалению, AWS не предоставляет автоматизированного способа сделать это, и вы вынуждены поднимать билет каждый раз, когда вам нужно разогреться для определенного мероприятия.

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

Нам нужно было это как-то автоматизировать, и схему нашего решения можно увидеть здесь:

• За 30 минут до отметки времени каждого события асинхронный процесс начинает отправлять события в SQS.
• Каждое отдельное сообщение SQS запускает одну функцию Lambda.
• Каждая лямбда генерирует заранее определенный объем трафика
• Последовательность Фибоначчи использовалась в качестве ориентира для увеличения количества сообщений, которые должен создавать сервер (наконец-то хороший повод использовать рекурсивную функцию Фибоначчи для чего-то полезного!).
• Поскольку эти сообщения создаются параллельно, AWS выделяет одну функцию Lambda для обработки каждого отдельного сообщения SQS.
• Балансировщик нагрузки начинает получать добавочный трафик, что вынуждает его развертывать дополнительные узлы за кулисами, что приводит к увеличению пропускной способности.

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

Пример Python того, как лямбда-код будет выглядеть в Python:

Развертывание можно автоматизировать с помощью serverless.js, скрипта yaml:

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

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

Дальнейшее чтение:

Как это все звучит? Есть что-нибудь, что вы хотели бы, чтобы я расширил? Дайте мне знать ваши мысли в разделе комментариев ниже (и нажмите аплодисменты, если это было полезно)!

Оставайтесь с нами для следующего поста. Следите, чтобы не пропустить!