Трафик вырос – сайт упал
Крупная сеть японских ресторанов с доставкой привлекала до 500 тыс. пользователей в месяц.
Но накануне 8 марта сайт не выдержал наплыва и «упал» — заказы сорвались, бизнес понёс убытки, а репутация пострадала.
Причина — устаревшая инфраструктура.
Что пошло не так?
- Ненадежный механизм балансировки в конфигурации базы данных и мастер-мастер репликация приводили к частым сбоям. Слейвы на каждом бэкенде требовали большого объема дискового пространства, а добавление новых бэкенд-серверов – внушительных затрат.
- Отсутствовала общая система деплоя приложений. Вместо нее работала самописная система деплоя через веб.
- Не хватало инструментов для сбора логов. Было сложно расследовать инциденты, особенно в системе заказов.
- Отсутствовал мониторинг бизнес-показателей. Своевременно фиксировать снижение или полное отсутствие заказов было невозможно.
Наше решение
Во-первых, оптимизировали текущую инфраструктуру: стабилизировали работу приложений и организовали комфортную среду разработки для нового API и сайта. На это ушло 57 дней.
- Отстроили CI/CD, внедрив пайплайны и конвейер.
- Стабилизировали работу кластера MySQL. Отказались от плавающего IP в пользу прокси-сервера, где между мастерами контролируемо переключается апстрим.
- Выделили два отдельных сервера под слейвы (работу с ними также организовали через прокси-сервер).
- Замониторили заказы на уровне запросов в БД. Любое отклонение от нормы – в меньшую или большую сторону – сразу давало повод для начала расследования.
- Сформировали на уровне логов метрики для мониторинга внешних взаимодействий – в частности, с системой управления заказами.
- Произвели донастройку всех систем до стабильной и быстрой работы: тюнинг MySQL, обновление версий PHP.
- Помогли внедрить систему кэширования на базе Redis, что тоже способствовало снижению нагрузки на БД.
Наше решение
Во-вторых, организовали безболезненный перенос инфраструктуры проекта в новый дата-центр – с дополнительными сервисами, нужными клиенту. Миграцию провели в несколько итераций за 160 дней.
- Создали реверс-прокси серверы в новом ДЦ. Они же выступали в качестве точек доступа в систему для администраторов (так как обладают public ip)
- Запустили все инфраструктурные сервисы – логирование и CI/CD. С помощью Consul организовали удобный, управляемый и надежный сервис взаимодействия между приложениями клиента.
- Перенесли в новый дата-центр БД, Redis и брокер очередей – RabbitMQ.
- Настроили приложения, организовали через внутренний DNS взаимодействия между приложением и БД/Redis/RabbitMQ/внешними сервисами. Подключили механизмы CI/CD.
- Внедрили решение, позволяющее удобно управлять настройками – через веб-интерфейс. Оно было основано на Hashicorp vault (в качестве бэкенда для него выступил Consul).
- Переключили сервисы на новый ДЦ.
Почему это сработало?
На миграцию инфраструктуры (а до этого, как правило, ее оптимизацию) сегодня приходится почти половина инфраструктурных проектов ITSumma. Это решение позволяет «убить трех зайцев», повысив:
- стабильность – количество моментов, когда сайт недоступен для пользователей, значительно сокращается;
- наблюдаемость – инциденты решаются быстрее, можно успеть предотвратить недоступность сайта или быстро с ней справиться;
- скорость процесса разработки – новые фичи появляются на сайте чаще.
Рекомендации
Надежность и доступность сайта и приложений критически важны для всех компаний, работающих онлайн. Если в момент пиковой нагрузки (скажем, накануне 14 февраля или 8 марта, когда каждый второй хочет заказать роллы или суши), ваш сайт «лежит», вы теряете очень много денег. А еще – лояльность и доверие клиентов.
Что мы советуем?
- Выявите такие «пики»: это самый рискованный момент для вашего бизнеса. Убедитесь, что инфраструктура проекта способна их выдерживать.
- Готовьтесь к сезонным или искусственным (например, распродажи) нагрузкам заранее. Меры, принятые за месяц-два до «даты Х», существенно снизят риски падения сайта.
- Если падение все же произошло, не оставляйте это просто так. Проанализируйте его, чтобы не допустить подобного в следующий раз.
На какие «ред-флаги» обратить внимание?
- Сайт тормозит или падает при пиковых нагрузках.
- Сайт падает по вине хостинга чаще, чем раз в полгода.
- Долгое время простоя при инцидентах. Несколько часов – это много.
- Долгое время релиза новых фич или отката на старую версию.
- Негибкая и долгая разработка.
Хотите проверить устойчивость своего проекта прямо сейчас? Пишите. Мы pпроведем первичный аудит.
Схема новой инфраструктуры
Примененные технологии
Результат
- Сайт стал лучше выдерживать пиковые нагрузки. В праздничные дни, когда RPS достигает пика в 550 единиц, он не падает и не теряет заказы.
- Месячная аудитория сайта за два года саппорта ITSumma выросла вдвое – с 500 тысяч до миллиона пользователей.
- У команды появилась полностью автоматизированная среда разработки, CI/CD.
Упомянутые услуги
Ответим на заявку в ближайшие 24 часа. А еще мы можем проконсультировать вас по телефону +7 800 555-91-99, электронной почте info@itsumma.ru или в Telegram-чате.
