Особенность современного ритейла – трудно прогнозируемый трафик, например, в период распродаж и акций, которые зачастую проводятся накануне праздников. Выделяются средства на маркетинг, определяется дата, запускается рекламная кампания. За сутки до часа Х по метрикам можно наблюдать, как растет трафик на сайте. Покупатели добавляют товары в избранное, наполняют корзины. Распродажа стартует, а сайт неожиданно «падает», платежи не проходят. Первая линия поддержки едва справляется с обращениями. У СЕО не умолкает телефон, клиенты оставляют гневные отзывы. В результате вместо подсчета прибыли, которая уходит к конкурентам, ритейлер вынужден устраивать разбор полетов. Почему ИТ-инфраструктура не выдерживает пиковых нагрузок в случае наплыва онлайн-покупателей?
За неудавшиеся сутки распродажи, по некоторым данным, от 70 до 90 клиентов уходят к конкурентам, корреляция их возврата составляет менее 20%. Потери компании в сфере электронной коммерции за этот же период оцениваются в 1 млн руб.
Для штатной стабильной работы ИТ-ландшафт должен быть готов к высоким нагрузкам, возникающим зачастую спонтанно. Не всегда понятно, от чего они зависят, заметил, открывая вебинар «Как ритейлу подготовить IT-инфраструктуру к пиковым нагрузкам», менеджер проектов компании Selectel Кирилл Кошурин. Он напомнил, что провайдер Selectel помогает клиентам решать бизнес-задачи и создавать надежную инфраструктуру для проектов любого уровня сложности. В портфеле компании свыше 50 готовых решений. К услугам более 30 тыс. клиентов компании возможности шести дата-центров провайдера в Москве, Санкт-Петербурге и Ленинградской области, а также партнерской площадки в Новосибирске.
О вариантах подготовки инфраструктуры к повышенным нагрузкам рассказал проектный менеджер компании ITSumma Евгений Трифонов. На протяжении 17 лет ITSumma разрабатывает архитектурные решения, обеспечивает техническое сопровождение ИТ-инфраструктуры в формате 24/7. За этот период накоплен большой опыт в виде тысяч распродаж, «пройденных» с клиентами на их инфраструктуре, а также партнерских маркетинговых акций, в частности, «черных пятниц».
Барьеры на пути запросов
Случаи, когда неожиданно «падает» сайт, не проходят платежи, – не редкость. Прежде чем искать ответ на вопрос, что делать, Евгений Трифонов акцентировал внимание на пути запроса пользователя на любой современной веб-архитектуре: CDN/WAF/балансировщик – Nginx – РНР – FPM/Apache – база данных – внешние API.
База данных в этой цепочке – один из наиболее важных пунктов для ритейла, «живущего» на «Битрикс». Как показывает практика, 90% падений системы связано с базой данных («то самое узкое горлышко»). Если это звено не справляется с запросами, начинается каскадная деградация системы прямо во время инцидента (товар в корзину не добавить, заказ не оформить).
За внешними API в упомянутой цепочке скрываются партнеры, платежные системы, службы доставки, СМС-шлюзы. Если с ними что-то пошло не так, клиент сталкивается с бесконечным циклом оплаты и не может рассчитаться за товар или услугу.
Одна из основных проблем бизнеса во время организации всевозможных акций – медленные запросы к базе данных (могут заблокировать остальные). Все усугубляется тем, что выгрузки запускаются в пиковое для инфраструктуры время.
Вторая проблема – монолитная архитектура. Когда и база данных, и веб, и тестовая среда для разработки размещены на одном сервере, они начинают конкурировать за ресурсы. Использование подобного ландшафта характерно для начинающих ритейлеров. Если в такой инфраструктуре отказывает что-то одно, «падает» сразу все.
Третья проблема – антипаттерны в архитектуре и неоптимальная конфигурация серверов (вместо обработки заказов РНР собирает архивы). В момент пиковой нагрузки все процессы заняты, клиент «ловит» ошибки.
К числу других не менее актуальных проблем относятся зависимость от внешних сервисов, DDоS, отсутствие мониторинга, лимиты ОС. По словам эксперта, DDоS-атаки нередко совпадают с пиковыми нагрузками. Есть основания полагать, что это следствие грязной конкурентной игры в бизнес-среде.
Алгоритм решения
Способы решения указанных проблем эксперт представил на конкретном кейсе в ритейле. Специалисты компании ITSumma помогли клиенту создать более стабильную конкурентоспособную архитектуру.
Для этого они разделили среды на два независимых сервера (с возможностью переключения на запасной), оформили защищенный канал доступа к инфраструктуре, подключили мониторинг 24/7 с техподдержкой. Теперь деградация ресурса видна задолго до его падения, оповещения приходят заранее, пока клиенты не пострадали. Ритейлер узнает о происходящем не от покупателей, а от системы мониторинга, что позволяет сделать правильный выбор в ситуации пиковой нагрузки.
В ходе реализации этого проекта были настроены автобэкапы (восстановление занимает 15 минут), а также контроль релизов, обеспечены регулярные обновления безопасности.
В итоге бизнес получил управляемую и отказоустойчивую инфраструктуру – ритейлер перестал зависеть от одного сбоя, вызывавшего каскадное падение.
Может показаться, что при создании ИТ-ландшафта, о котором шла речь в этом кейсе, не были предусмотрены банальные вещи. Но, по словам Кирилла Кошурина, ничего удивительного в том, что инфраструктура не готова к пиковым нагрузкам, нет. Ведь она формируется и разрастается постепенно (от одного сервиса), пока не столкнется с высокой нагрузкой. Эксперты рекомендуют заранее подготовиться к подобному развитию событий, чтобы проблема с выносливостью ИТ-ландшафта не дала о себе знать внезапно.
К такому выводу и опыту компании приходят не сразу, особенно если учитывать распределение обязанностей в рамках модернизации инфраструктуры, заметил Евгений Трифонов. Стратегические решения, как правило, принимаются СТО, СЕО, собственником бизнеса. И пока до них дойдет информация о том, что действительно нужно что-то изменить, оптимизировать, происходит, как правило, не один инцидент. Как говорят в таких случаях, на ошибках учатся.
Принципы повышения устойчивости
В ходе вебинара эксперты отметили принципы, которых стоит придерживаться в рамках модернизации и повышения устойчивости инфраструктуры в ритейле.
Первый принцип – многослойная защита (от наплыва ботов, DDoS-атак, перегрузок). Из него вытекает второй – «разделяй и властвуй». Благодаря управлению потоками можно перенаправить нагрузку к разделенным серверам. Наличие полноценных двух контуров позволит серверам для клиентов и для баз данных не конкурировать за ресурсы.
ProxySQL помогает распределять запросы к базе данных. Примерно 80% производительности можно обеспечить за счет того, что легкие запросы будут перенаправляться в резервную базу, разгружая основную для заказов. Наряду с этим стоит настроить автоматическую синхронизацию как условие быстрого переключения.
Эксперты систематизировали практики, которые дают эффект.
Что можно успеть в ограниченное время?
В ходе вебинара эксперты рассказали, что можно успеть, когда до пиковых нагрузок остается немного времени, например, какие меры дадут эффект за несколько дней или две-четыре недели до начала сезона акций.
За несколько дней до распродажи можно заняться вертикальным масштабированием, добавить CPU/RAM, иными словами, нарастить мощность сервера, чтобы он выдерживал большее количество одновременных запросов. Можно прибегнуть к гигиене логов: отключить debug (для экономии гигабайт дисковой памяти), настроить удаление старых логов, их ротацию, ограничить скорость для ботов, дав приоритет реальным клиентам. На период пиковой нагрузки можно обойтись без индексации ботом Google или «Яндекс», так как трафик в период распродаж, других акций уже есть, и затем ее возобновить.
Ориентируясь на эти рекомендации, за несколько дней можно стабилизировать текущую систему и получить запас прочности на ближайшую пиковую нагрузку.
При наличии в команде ритейлера дополнительных сил (двух-трех сотрудников) за две недели до распродажи можно вынести БД на отдельный сервер, заняться масштабированием stateless-слоя, добавить сервер, резервную базу данных с репликацией, настроить защиту от штормов (как предохранитель).
Если чтение будет осуществляться с резервной базы, то нагрузка основной понизится на 30–50%. Воспользовавшись таким набором рекомендаций, можно не только стабилизировать систему, но и значительно ее усилить, создав запас на будущее.
За короткий срок (условные две-четыре недели) полностью трансформировать архитектуру не получится – на это уйдет от трех до шести месяцев. Глубокая оптимизация кода, как и оптимизация запросов к базе, тоже требует значительного внимания и времени. Kubernetes, о котором сейчас часто говорят, может оказаться сложным и долгосрочным вариантом, который не всем подходит.
Таким образом, за короткий период времени до начала сезона (два-три дня) можно рассчитывать только на стабилизацию инфраструктуры. За две-три недели реально ее усилить и сформировать резерв для использования в дальнейшем (не только в период пиковых нагрузок). Трех-шести месяцев будет достаточно для построения конкурентной архитектуры.
Светлана Иванова, Connect
