Как устоять в пиковых нагрузках: кейс онлайн-магазина и to-do list для архитектора решений

Одна из ключевых ИТ-задач онлайн-ритейлеров – это обеспечение устойчивости магазинов к пиковым нагрузкам во время распродаж и других периодов повышенного спроса. В крупных интернет-магазинах нагрузки во время акций Black Friday или Prime day предсказуемы, поэтому инфраструктуру к ним можно подготовить. Но бывают и неожиданные периоды активности, например, после успешной маркетинговой кампании. Как обеспечить отказоустойчивость системы во время пиковых нагрузок в облаке AWS, рассказывают архитектор решений AWS Сергей Курсон и архитектор решений AWS Softline Андрей Фирсов.

Как помогают сервисы AWS?

Задача

У заказчика была развернута классическая on-premise архитектура со множеством узких мест. После нескольких падений на пиковой загрузке заказчик обратился в AWS, чтобы подготовиться к «Черной пятнице». Требовалось создать инфраструктуру, устойчивую к резкому росту количества запросов. Главными требованиями были минимальная задержка, среднее число запросов порядка 20-30 тыс. в минуту и отсутствие падений.

Запросы обрабатывались на большом «монолитном» приложении .NET с минимальным набором внешних сервисов. Узким местом было то, что статический контент (изображения, видео, скрипты) раздавался с отдельной машины, которая никак не масштабировалась.

Решение

Было принято решение переносить инфраструктуру в облако «как есть», методом Lift&Shift. Миграция этим способом позволяет не переделывать архитектуру – приложения просто перемещаются на виртуальные машины, в данном случае EC2.

В начале переноса данных в облако случилось падение одной из зон в AWS, но потери данных удалось избежать, потому что все, что переехало, было в другой зоне. Тем не менее этот случай показал, что необходимо как можно скорее разделить приложение на несколько зон доступности (AZ) для отказоустойчивости. Далее команда проекта сразу же запустила Application Balancer, так как он автоматически масштабирует нагрузки.

Следующим шагом был подбор необходимых типов инстансов. Сначала выбрали инстансы T – недорогие и универсальные, с базовым уровнем производительности и возможностью ее увеличения с помощью механизма Burst, который потребляет CPU кредиты. Дело в том, что как только кредиты заканчиваются, производительность опускается на отметку 20-40% (в зависимости от типа инстанса). Этот режим работы не подходит для нагруженного сайта с долговременными нагрузками, поэтому необходимо было взять компьютеры с надежной производительностью – типа С. Также поставили ElasticSearch для отказоустойчивости в кластере на нескольких зонах доступности.

Для доставки статического контента использовали Amazon CloudFront, что позволило добавить механизм кэширования и разгрузить вычислительные ресурсы. Отдельной проблемой стало долгое масштабирование и деплой обновлений, потому что релизы могли проходить до нескольких раз в сутки. Ситуацию исправили, добавив деплой через Code-сервисы, в частности CodeDeploy, и подключив DevOps практики.

Финальные шаги выглядели следующим образом: базы данных переехали на Amazon RDS и Managed ElasticSearch. Для упрощения масштабирования, бэкапов и мониторинга баз данных начали использовать RDS. Позднее был добавлен Connection Pooler, который позволил разгрузить ресурсы базы данных, требовавшиеся для установления новых соединений.

Для развертывания был добавлен полезный механизм Blue Green, который позволяет вручную переключать две версии: на случай, если требуется сделать мгновенный откат или из двух версий подходит только одна. Для борьбы с DDOS, ботами и другими угрозами Web Application Firewall установили на CloudFront. Изначально, поскольку CloudFront отдавал содержимое с балансировщика, из-за небольшой ошибки по невнимательности установка WAF на балансере привела к блокировке IP CloudFront. Автоматизация в таких случаях очень важна – например, благодаря тонкой настройке масштабирования можно влиять на инфраструктуру буквально в течение разговора, корректируя метрики на единицы процентов и количество машин во флоте. Но нужно стремиться к максимальной автоматизации как можно большего количества процессов на основании правильных метрик и предварительного масштабирования, согласованного с маркетингом.

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

Подготовка к пиковым нагрузкам

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

Памятка по аудиту устойчивости систем

С какими внешними сервисами взаимодействует система, и какие есть ограничения?

Какие ограничения имеют внутренние приложения и сервисы?

Какие лимиты аккаунта AWS на конкретный ресурс установлены и нужно ли их увеличивать?

Используются ли балансировщики, и правильно ли они настроены?

Используется ли автомасштабирование, и правильно ли оно срабатывает?

Для каких сервисов можно включить автомасштабирование, а для каких нет?

На какие сервисы нагрузка возрастает пропорционально пользовательской активности?

Правильно ли подобраны тип и количество инстансов?

Каков прогноз увеличения использования дискового пространства, и какие нужны работы по увеличению объема дисков?

Каковы ограничения на уровне баз данных и лимиты приложений?

Что делать?

Внешние сервисы

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

Лимиты

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

Узкие места

Проведение нагрузочного тестирования на копии production системы помогает выявить узкие места в модулях приложения и в узлах инфраструктуры.

Автомасштабирование

Нужно уточнить, включено ли автомасштабирование для ваших сервисов и есть ли сервисы, которые необходимо будет масштабировать. Важно подобрать тип инстанса с запасом, если нужно, запланировать время на обслуживание. Использование AWS Managed Services и EC2 AutoScaling позволяет проделать эти работы с минимальным временем простоя либо без него.

Сеть

Нередко многие выбирают тип инстанса только по параметрам CPU и Memory, но в моменты высокой нагрузки по трафику могут начаться проблемы, которые сложно отследить. Обратите внимание на тип инстанса со стороны пропускной способности сети – Network. Для разных серий и типов инстансов пропускная способность может быть от очень низкой до 100Гбит/с.

Пользовательская активность

Можно выделить сервисы, которые больше подвержены нагрузке при пользовательской активности. Здесь можно посмотреть на график изменения CPU, Network, Memory в течение светового дня.

Мониторинг

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

Логи и метрики

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

Безопасный и быстрый деплой новых версий

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

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