Как обработать 13 тысяч заказов в сутки. Новая архитектура, RabbitMQ, PHP7 и Кластер

• История создания интернет-магазина и сервиса доставки блюд японской кухни MYBOX
• Мобильные приложения
• Программа лояльности. Майбаксы и Экстра-Майбаксы
• Новая карта доставки заказов
• Новый дизайн и UX всех инструментов MYBOX
• Рост посещаемости, многоканальные продажи и работа в праздники
  • RabbitMQ
  • Новая архитектура мобильных приложений
  • Оптимизация кода сайта и структура изменений
• Когда в коде оптимизировать нечего… пора заняться сервером
  • Почему PHP7?
  • Зачем кластер?
• Итоги большой оптимизации – “запас прочности” на будущий рост

История создания интернет-магазина и сервиса доставки блюд японской кухни MYBOX

С 2015 года ИНТЕРВОЛГА решила много задач по развитию сайта федеральной сети доставки блюд японской и паназиатской кухни — MYBOX, о чем мы неоднократно писали:

• Эталонный кейс по веб-интеграции

• Теория и практика перевода сайта mybox.ru на адаптив

• Разработка бизнес– процессов для компании "МБ– ГРУПП"

• Геозависимость цен и условий доставки в интернет– магазине на Яндекс.Картах

• Ускорение загрузки нагруженного сайта на Битриксе или зачем программисту знать как работает mySQL

На разработке сайта mybox.ru мы не остановились. Бизнес растет и ставит все новые задачи. Очень интересно работать в таких условиях – всегда есть много новых идей, которые приносят пользу бизнесу клиента.

Одной из первых серьезных “точек роста” для сети стали мобильные приложения. Это бодрые нативные приложения, тесно интегрированные с системой учета, доставкой, логистикой и колл-центром.

Мобильные приложения

Количество мобильного трафика росло –  было решено разработать мобильные приложения.

Это устранило сразу несколько проблем –  дало пользователям дополнительную, гибкую платформу для заказов и повысило конкурентоспособность сети MYBOX.

Программа лояльности. Майбаксы и Экстра-Майбаксы

В 2017 году была запущена программа лояльности “Happy Box” –  бонусная система накопления баллов (Майбаксов) для оплаты до 50% заказа. Использовать Майбаксы можно при любой форме заказа: на кассах торговых точек MYBOX, при оплате в мобильном приложении или на сайте, а также в контакт– центре.

Это была крайне интересная и технически сложная задача – требовалось объединить логику работы 2 мобильных приложений, касс, колл-центра и собственно интернет-магазина.

После введения программы лояльности выросла доля покупателей, которые вводят логин и пароль.Это позволило аналитикам MyBOX получить больше информации о клиентах и структуре их спроса.
А годная аналитика — основа окупаемости маркетинга.

Авторизация и индивидуальный подход к каждому клиенту за счет персональных предложений и скидок дали прирост потока заказов и клиентов – как постоянных, так и новых.

В 2018 году программа лояльности уже работала в полную силу, а MYBOX имел поток постоянных клиентов, стабильно пользующихся услугами сети.

Рост интереса пользователей к сайту – результат комплексного подхода и многих видов работ.

Мало сделать форму авторизации и пообещать бонусы.
Все инструменты должны быть просты и удобны для клиента

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

Новая карта доставки заказов

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

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

Новое решение сделало систему доставки интуитивно понятной и уменьшило нагрузку на колл-центр (это кстати одна из важнейших метрик при автоматизации – какая доля заказов обработана полностью автоматически).

Новый дизайн и UX всех инструментов MYBOX

Работы над графикой вела прекрасная группа дизайнеров TopFloat Евгения Маскаева. Верстку и применение всех страниц делала команда проекта под руководством Василия Шевякова и Ольги Семироговой.

В сумме потребовалось несколько сотен часов верстки и кода.

В результате за несколько месяцев было обновлено 250 (!) видов страниц, уведомлений, представлений товаров и акций. Тут нужно сказать отдельное спасибо на редкость системному маркетологу Игорю Киму, e-commerce-директору MYBOX.

В результате выросла конверсия всех инструментов и – счастье клиента. Ради такого стоило постараться.

Рост посещаемости, многоканальные продажи и работа в праздники

Усилия маркетинговой команды MYBOX и всех ИТ-подрядчиков обеспечили рост числа клиентов во всех каналах. Маркетологи работали над имиджем, качали рекламу, программисты развивали сайт, программу лояльности и мобильные приложения.

Рынок доставки еды развивается быстрыми темпами, а это значит, что число клиентов, сложность логики сайта и как следствие — нагрузка на сервер — все время растут.

Мы все время мониторим нагрузку на все виды ресурсов и следим чтобы она была “в зеленой зоне”.

Приведем только 1 число: в начале 2018 года вечером в любую пятницу единственный сервер сайта обрабатывал до 60 запросов в секунду от пользователей и всех видов обмена.

Это было уже на грани допустимого, запасов ресурсов почти не было.

Большинство опрошенных нами разработчиков нагруженных интернет-магазинов указали
что 20 программных страниц в секунду — более чем приличный результат. Больше и не надо.

Самые насыщенные дни в году для бизнеса доставки еды — 14 февраля и 8 марта. Даже в новогодний период нет таких пиков.

Чтобы сервис выстоял в очередной “шторм заказов”, было решено провести большую реформу обменов.

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

RabbitMQ

На сайт и в учетную систему внедрили менеджер очередей RabbitMQ как систему для гарантированного обмена сообщениями между несколькими системами. Стоит отдельно поблагодарить команду разработки ERP под руководством Владимира Федянова за идею применения RMQ и Сергея Иванова за помощь в настройке.

RabbitMQ удобен тем, что сохраняет заказ до тех пор пока сервер не подключится, и не заберет сообщение из очереди. Таким образом мы исключили потерю заказов. Постепенно мы перевели все виды обмена (а их более 10) “на Кролика”. Это сделало работу с двумя нагруженными (и все время меняющимися) системами надежнее.

Для гарантии поверх сервиса очередей был построен простой мониторинг, позволяющий видеть расхождения в потоке изменений данных и оперативно “досылать” сообщения при наличии коллизий.

Новая архитектура мобильных приложений

Вторым заходом мы полностью переработали архитектуру связки “Учетная система” — “Сайт” — “Мобильное приложение”.

Дело в том что не вся информация, нужная для мобильных приложений и сайта, присутствует в ERP MYBOX. В частности, до реформы понятие “наличие в городе”, “коробка паназии”, “зоны доставки" и изображения товаров существовали на сайте и запрашивались с него мобильными приложениями.

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

Была проведена огромная реформа (одновременно с выпуском модных и быстрых МП версии 20), в результате которой в учетной ERP-системе хранится вся первичная информация, а на сайте и в МП она обновляется строго тогда, когда нужно.

Оптимизация кода сайта и структура изменений

Одновременно с применением нового дизайна на сайте была выполнена глубокая оптимизация кода. Это помогло ускорить загрузку страниц сайта.

Сайт MYBOX показывает, какие блюда доступны в 250+ точках выдачи, расположенных более чем в сотне городов. В одном только Волгограде таких точек — 16. Причем, нужно понимать, что дважды в минуту идет обновление статусов заказов через веб– сервисы, а обновление наличия товаров в меню — практически непрерывно. Мы много раз “по логам” видели как, например, вечером субботу кто-то из сотрудников MYBOX меняет меню.

Кроме того, дважды в год MYBOX радикально обновляет меню: стандартное, японское и паназиатское. Меняется и состав позиций “по выбору”, например —  салаты, десерты и другое.

А это значит, что обновляются все позиции каталога: ингредиенты, добавки, цены, описания блюд, фото. Обновление меню происходит одновременно во всех городах и затрагивает, в том числе, зоны доставки.  

Когда в коде оптимизировать нечего… пора заняться сервером

Оптимизация кода — основной путь, позволяющий значительно увеличивать производительность, но и у него есть пределы. Несмотря на все архитектурные изменения и проведенный рефакторинг рост популярности MYBOX требовал от ИТ-систем способности переваривать все большую нагрузку.

Да и пиковые нагрузки порой не так легко предсказывать — например во время weekend’ов и праздничных дней в некоторые часы мы фиксировали резкое, пиковое увеличение количества запросов на 50% от прогнозного.

Как мы не устаем повторять, главное преимущество ИНТЕРВОЛГИ в том, что мы работаем комплексно и не перескакиваем с задачи на задачу, пока не убедимся, что предыдущая выполнена как следует.

Мы уверены что нужно сначала навести полный порядок в программном коде и лишь потом масштабировать железо и менять конфигурацию операционной системы. Иначе получается как в грустной пословице – “тушить пожар бензином”.

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

Почему PHP7?

Причин несколько:

1. PHP7 имеет значительное преимущество в скорости перед предшествующими версиями — что 3, что 5.6 версии по скорости работали примерно на одном уровне. “Теоретически” при переходе на PHP7 работа программного кода сайта ускоряется в 2 раза.

2. Летом 2019 года Битрикс прекращает поддержку php5.6.

Мы опустим описание довольно длинного забега по подготовке сайта к обновлению ядра 1С-Битрикс, которое на проектах такого масштаба выполняется не часто. Нужно было проверить на тестовой сборке работу всех сценарием обмена и страниц работы с заказами. Напомню, обменов более 10 видов, а страниц почти 300.

На этот важный технический шаг ушло около 30 часов работы, и – мы справились.

Итогом этих манипуляций стал прирост производительности в 30%. Не в 2 раза, так как огромную долю времени ресурсов составляет не PHP, а выполнение файловых операций и запросы к БД.

Зачем кластер?

ИНТЕРВОЛГА уже писала, практически все крупные проекты, магазины, соц сети работают более чем на одном сервере что объясняется большой посещаемостью. Высокая посещаемость — высокая нагрузка.

Этим мы и занялись в конце 2018 года: переводом сайта MYBOX на кластер.

Мы уже писали подробную статью о том, что такое MASTER–SLAVE кластер и зачем он нужен.

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

Вообще говоря, сборка кластера на базе технологий Bitrix Framework это довольно тривиальная задача, если не учитывать особенности проекта:

• огромный размер сайта и базы данных;

• нетиповая структура кеша (что впоследствии усложнило работу репликации);

• очень большая доля изменений в данных;

• работа сервисов практически в режиме 24х7 (последняя касса закрывается в 3-00, а офис начинает работать рано утром).

Работы по кластеру приходилось вести только рано утром, и на каждую итерацию было всего несколько часов свободного от нагрузки времени.

В конце ноября началось тестирование развертки кластера в “песочнице”. Добавление серверов и работа над кластером пришлась как раз под новый год, а закончилась, с успехом, хотя и не без борьбы, пережив самый буйный день в году — 14 февраля.

Расскажем подробности. Мы взяли два сервера — основной (MASTER) и дублирующий (SLAVE), который будет подчиняться ему. SLAVE был близок по характеристикам к основному.

Создание кластера начинается с MASTER– ноды, где располагается MASTER– база MySQL, и с которой происходит настройка кластера и всех входящих в него узлов.

Следующий шаг — создание SLAVE– ноды. В роли балансировщика выступил модуль “веб-кластер” 1С-Битрикс. Он позволил распределить нагрузку на два сервера, передавая запросы к базам данных — основной и копии на SLAVE.

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

Пробный запуск...

В качестве пробы была запущена репликация базы в “песочнице” — синхронизация содержимого копий объекта на чистой виртуальной машине (без основного набора данных). Репликацию удалось завести с первого раза. Это — преждевременно — вселило уверенность.

… и репликация развалилась

Перед переносом кластера с хостинга на хостинг были остановлены обмены с внешними системами (все 10), чтобы избежать рассинхронизации данных в базах при выгрузке изменений.

“Оживление сервера” — настройка репликации Битрикса, вылавливание скриптов, которые подключались не к тем сетевым интерфейсам (что неизбежно, если у вас их несколько), отслеживание перезаписанных скриптами настроек iptables, которые ломают обмены.

Работа двигалась. И... на последнем шаге Мастера Репликации Битрикса копирование развалилось. Попробовали еще — и снова тот же результат.

Объяснение простое — всему виной разногласия в путях config-файлов (файл web.config — это XML-документ. В нем хранится информация о параметрах поставщиков состояний сеансов, членства, определяются ссылки на страницы ошибок) различных приложений, например, системы мониторинга Munin. Проблема была решена вручную путём ручной корректировки всех конфигурационных файлов.

Сборка кластера в итоге заняла около 8 часов 3 наших специалистов. Для такого огромного и нетривиального проекта — немного.

Многосайтовость и кластер

В идеале, и это прописано в документации, Битрикс поддерживает многосайтовость в случае кластера. На сервере расположено несколько веб-проектов Майбокс, а на кластер мы собирались переводить только один — главный сайт.

Хотя на чистой виртуальной машине все работало с первого раза, но на реальном сервере MYBOX конфигуратор кластера Битрикс запретил запуск репликации из-за второй БД на том же сервере.

Штудирование документации не помогло, хотя у Битрикс есть несколько узконаправленных курсов, ни один из них подобный вопрос не описывал. Увы, тех поддержка тоже оказалась не в силах помочь.

Чтобы не биться в закрытую дверь, пришлось убрать песочницы и перенести дополнительные сайты на отдельный сервер. Это привело к потере еще одного дня

Итак, в теории, многосайтовость на Битрикс-кластере возможна, если вы ее реализуете — напишите нам, как.

Тормоза транзакций при копировании таблицы b_cache_tag и первичный ключ

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

Оказалось что b_cache_tag (таблица управляемого кеша Битрикс) не имела первичного ключа — Primary Key (PK), подтверждающего их уникальность. При реплицировании этой таблицы связанные с ней транзакции начинали тормозить.

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

Как решать такую проблему? Обновлением таблицы — нельзя.

Остановить сайт — тоже, таблица весит около 1,5 Гб. Таблица огромная, значит добавление первичного ключа в нее вызывает конфликты при копировании данных, кластер разваливается.

В попытке сохранить целостность кластера, несколько пунктов репликации пришлось пропустить.

Мы добавили ключ в b_cache_tag, ситуация исправилась, но из–за пропущенных транзакций возникло расхождение между таблицами. Кластер, предсказуемо, развалился снова.

Разработчики в который раз вручную вычистили конфликтующие в скопированной таблице первичные ключи и исправили параметр автоинкремента добавленного ключа.

Возня с таблицами кеша на обеих нодах кластера потребовала еще несколько дней экспериментов и несколько часов работы. Вопрос в чем конкретно проблема с первичным ключом — открыт до сих пор.

Мониторинг кластера

Для того, чтобы отлавливать возможные ошибки на кластере, мы написали скрипт, который периодически запускается и, если произошла ошибка, сообщает об этом в Telegram и через СМС– сообщения. Это позволяет оперативно реагировать и устранять неполадки.

В общем, репликация, балансировка, логи, оповещения "если что не так" — все как нужно.

Итоги большой оптимизации – “запас прочности” на будущий рост

Смена архитектуры, перевод всех видов обмена на RabbitMQ, сборка кластера и миграция на PHP7 завершены. Мы потратили на это несколько месяцев и очень довольны результатом. Сервер обрабатывает больше запросов чем когда-либо, а время обработки запросов на минимуме. Думается, мы готовы к двукратному росту посещаемости — хоть завтра.

Команда MYBOX получила уверенность в работе системы, клиенты – безупречно выполненные заказы, а ИНТЕРВОЛГА положила в копилку опыт масштабного рефакторинга огромного проекта и запуска кластера.

Если вы планируете провести подобное мероприятие, заполните форму и мы подготовим для вас план по переводу на кластер.

Главное помнить — на любую задачу найдется подходящее решение, стоит только захотеть и обратиться к профессионалам.

P.S. Эта статья, как и проект – результат работы многих людей. Благодарим Алексея Шкарупа, Ольгу Семирогову, Дмитрия Мамонтова, Василия Шевякова и Андрея Сентебова за вклад в оптимизацию и ее описание.

Запускаем бесконтактную доставку в интернет-магазине на Битрикс
Архитектура веб-проекта для тяжелых вычислений
Ускоряем работу с интернет-заказами в 1С:ERP: нетиповые статусы заказа покупателя и автоматическое обновление