Управление трафиком при работе интернет-магазина в облаке Windows Azure

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

Все эти вопросы возникают в разные периоды работы интернет-магазинов. Это особенно верно во время таких событий, как Киберпонедельник или во время праздников, соотносящихся с вашим бизнесом (например День Святого Валентина для сайтов по продаже и доставке цветов).

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

Тестирование нагрузки

Тестирование нагрузки представляет собой процесс генерации трафика с помощью автоматических инструментов таких как VS.NET Web Load Tests или многих разновидностей Java инструментов. Это должно быть сделано, даже если вы используете уже работающую платформу или продукт. В силу того, что вы наверняка делали дополнительные настройки и доработки в своей ecommerce платформе, вы можете найти много «узких мест» и проблем во время первых двух тестов.


Увеличить

Скриншот показывает наш внутренний нагрузочный тест, сделанный для демо-сайта размещенного на Azure. Вы можете найти этот тест в исходном коде решения по проекту «Performance.FunctionalTests » (примечание: вам понадобится версия VS.NET, которая поддерживает Web Load Tests).
Основные параметры, за которыми необходимо проследить – количество запросов в секунду (Requests/Sec, на скриншоте это 52.6), среднее время загрузки страницы (Avg. Page Time) и нагрузка от пользователей (User Load).
Количество запросов в секунду показывает количество различных пользователей, находящихся на сайте в одно и то же время. 52.6 запросов в секунду означает примерно 205 тысяч запросов в час или около 5 миллионов запросов в день. Конечно, это не реальный сценарий, так как для многих сайтов пики трафика приходятся на определенные часы и нагрузка неравномерна в течение суток.

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

Нагрузка от пользователей – количество одновременных запросов, посылаемых на страницу. Но это не количество обычных ваших пользователей. Обычные пользователи делают определенную задержку между запросами, а в данном тесте автоматические пользователи посылают запросы один за другим без задержек. Данные задержки можно назвать «временем на обдумывание», и этот показатель может быть настроен. Обычно пользователь считается активным, если он/она запрашивает страницу в течение 5 минут (Google Analytics). Обычное значение для «времени на обдумывание» составляет 10-120 секунд, если вы хотите подражать реальному трафику. Мы предпочитаем не устанавливать «время на обдумывание», чтобы получить чистые показатели производительности.

Управление повышенной нагрузкой

Данная конкретная тестовая среда, на которой мы делали наш тест, состояла из одного
малого веб-сервера и одного малого поискового сервера (в Azure малый сервер это 1 ядро, 1.75 Гб памяти виртуальной машины). Большая часть нашей нагрузки приходится на веб-сервер, поэтому давайте посмотрим как мы можем его масштабировать.

Так как наша тестовая среда находится на Azure, давайте попробуем масштабировать сначала ее, а затем снова запустить нагрузочные тесты. Для масштабирования, все, что вам нужно сделать, это войти в Azure, перейти в закладку «Services» и нажать кнопку “scale”. Измените количество серверов с одного до двух, у Azure это займет 1-2 минуты для предоставления дополнительного сервера.


Увеличить

Теперь можно запустить тесты и посмотреть, что произойдет. Как вы могли заметить на скриншоте снизу, количество запросов в секунду возросло в среднем до 83.6 с 284 одновременными пользователями. Показатель времени отклика страницы ведет себя неадекватно во многом из-за ограничения канала на клиентской машине.


Увеличить

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

Также существуют дополнительные настройки масштабирования серверов основанные на различных нагрузках (нагрузка на CPU и Queue load) или просто на расписании, когда вы знаете, в какие часы у вас происходят пиковые нагрузки.

Масштабирование нагрузки на CPU говорит само за себя, и осуществляется, когда нагрузка на процессор достигает определенного порога.
Масштабирование зависимое от очереди (Scaling by Queue) является уникальной возможностью, предоставляемой в Azure, и позволяет вам масштабировать бэкенд-системы, основываясь на количестве элементов в очереди. Это может быть использовано например при обработке заказов или заявок на страхование, особенно когда применяется CQRS (Command–query separation, мы рассмотрим его в дальнейших статьях). Как правило, когда заказ создан, он немедленно становится в очередь для дальнейшей обработки (для авторизации кредитной карты, обработки остатков, передачи заказа в бэкенд-системы и т.д.). Данная очередь может быть маленькой или большой в зависимости от времени дня и сервисов, ответственных за обработку заказа, и может быть очень загруженной или простаивать без дела. В этом случае, вы можете автоматически увеличивать количество серверов для параллельной обработки заказов при высокой нагрузке или уменьшить количество серверов при низкой нагрузке.


Увеличить

Масштабирование по расписанию

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


Увеличить

Доступность

Добавление дополнительного сервера также повышает нашу доступность, например если элемент 0 или 1 ломается, наш сайт все равно работает. Вы всегда должны иметь как минимум два сервера для обеспечения работы сайта, как при разворачивании на собственном оборудовании(используя распределитель нагрузки), так и в Azure.