С вопросом контроля нагрузки для IT-проектов компании разбираются по-разному: одни ее не измеряют и не оптимизируют, пока все не упадет, другие же пытаются предотвратить проблему (боль premature optimization). Третий, самый опасный случай, – проектируют систему без учета роста. Но что предпринять, если сайт не выдержит количества посетителей или база данных упадет? Дмитрий Волошин, СТО и сооснователь международного маркетплейса репетиторов Preply, дает рекомендации по выбору приложений для управления трафиком и советует, что делать, чтобы рост нагрузки не застал врасплох.
Многие из тех, кто разрабатывал сайты для продажи товара и услуг, рано или поздно столкнулись с проблемой падения сайта при слишком большом количестве запросов пользователей. Причиной может стать низкая мощность сервера, географическая удаленность баз данных или резкий рост нагрузки. Иногда сайт специально нагружают ботнеты недобросовестных конкурентов, чтобы причинить существенный финансовый урон бизнесу. Потому важно изначально позаботиться о мониторинге нагрузки, а также о плане “Б”, если нагрузка вырастет в разы. Где бы ни скрывалась проблема, время на ее решение будет ограничено, а последствия могут стать глобальными.
Методом проб и ошибок мы определили оптимальные варианты, которые помогут избежать потери трафика на период отладки:
- Измеряйте нагрузку, пока ее мало. Системы контроля и мониторинга производительности и трафика на сайте помогают следить за динамикой роста нагрузки на сайте. Мы работаем с NewRelic – с его помощью вовремя выявляем и реагируем на ухудшение показателей быстродействия на разных уровнях: от базы данных и серверов до js-рендерингом. NewRelic мониторит не только веб-, но и мобильные приложения. Полезно иметь различные представления логов сервера. В Preply мы сначала использовали Sentry для логирования, а когда логов стало больше – перешли на использование самого популярного стека ElasticSearch+Logstash+Kibana. В этой триаде ElasticSearch – хранилище данных, где можно делать full-text search, Logstash – сервер обработки, фильтрации и трансформации логов из различных систем, а Kibana – инструмент визуализации. В ELK стеке мы визуализируем географию запросов по логам nginx, и, если видим, что к нам начинает идти трафик из Сенегала – то проверяем, не атака ботнета ли это. Другой пример – это просмотр страниц с 500 кодами ошибки или проверка запросов, которые теряются на уровне прокси-сервера nginx. Также советую установить любой инструмент для информирования о downtime сервера через SMS, так как скорость реакции очень важна.
- Предусмотрите горизонтальное масштабирование проекта. Если скачок нагрузки уже произошел, то обычно у команды практически нет времени на определение причины, поэтому важно всегда иметь возможность замасштабировать мощности горизонтально – просто покупайте их. Для масштабирования серверов приложения мы используем Amazon Elastic Beanstalk с контейнеризацией приложения через Docker. Инструмент позволяет автоматически добавлять новые сервера при увеличении нагрузки одним кликом. Владельцу площадки достаточно загрузить код Elastic Beanstalk и приложение само выполнит полное развертывание – от выделения ресурсов до самостоятельного мониторинга своей работоспособности.
Переживать о контроле ресурсов AWS не придется – доступ будет открыт в любое время. Более того в AWS есть очень гибкие правила и можно настроить load balancer, чтобы он автоматически добавлял новые сервера, когда старые не выдерживают нагрузки. У нас при малых нагрузках запущено 2-3 сервера приложений, но когда происходит резкий скачок или прайм-тайм, их количество автоматически увеличивается до 6-8.
Для баз данных отлично подходит еще один продукт Amazon с опцией Multi-Zone Replication – RDS. Он обеспечивает быстрый доступ к базам из разных регионов, что важно для владельцев международных проектов, поскольку всплески трафика постоянно возникают из стран, где проводятся маркетинг-активности. В других IaaS-системах есть похожие продукты, надбавка цены за использование которых с лихвой компенсирует спокойный сон технической команды во время роста нагрузок.
- Проектируйте архитектуру с учетом роста. Есть известное правило, что при росте нагрузки в 10 раз система переписывается с нуля, но этого можно избежать, если спроектировать саму архитектуру системы с учетом того, что рано или поздно придется обрабатывать больше запросов.
Краткий чек-лист того, что однозначно облегчит работу с нагрузками в будущем:
- кеширование, настроенное с возможностью перенесения на отдельный сервер или кластер, например Memcached;
- предоставление статики (картинки, js и т.д.) через хороший международный CDN;
- использование read replicа баз данных для доступа к базам только на чтение, индексация;
- асинхронность для задач, которые могут занять неопределенное количество времени (отправка писем через third-party SMTP-сервер или запросы в API со слабым SLA), для нас хорошо работает стек RabbitMQ+Celery.
Если ваша команда не контролировала процент потребления ресурсов сервером и уведомлений от хостера не поступало – это не значит, что система работает нормально и можно отложить вопрос с нагрузкой в долгий ящик. Куда проще уже сегодня установить несколько проверенных временем приложений для контроля нагрузок, тогда проблему с блокировкой доступа к онлайн-площадке можно избежать, ведь предупрежден – значит вооружен.
Автор: Дмитрий Волошин, CTO и сооснователь Preply
