Citilink
cover

Как увеличить
надежность
и доступность
каталога товаров

«Ситилинк» — один из крупнейших электронных дискаунтеров с широким ассортиментом и большой сетью магазинов и складов. На 2020 год оборот онлайн-продаж у компании составил 132,7 млрд рублей, что делает ее третьей по величине в России.

Scroll

Задача

В 2010 году все данные «Ситилинка» о товарных позициях, включая их наличие на складе и цену, хранили в реляционной базе данных. Для доступа к ней использовали монолитный сервис на PHP-фреймворке Symfony. Год от года нагрузка росла, и реляционная база данных перестала справляться с нагрузкой.

Долгое время в «Ситилинке» использовали систему кэширования. Она снижала нагрузку на базу данных при чтении и записи. Однако система постоянно усложнялась, нужно было инвалидировать кэш и гарантировать целостность данных на случай перегрузки. В определенный момент размер кэша достиг 100 ГБ, и стало выгоднее не кэшировать данные, а хранить их в in-memory базе данных.

Объяснить такой рост данных и всю сложность в планировании архитектуры могут четыре основных фактора:

  1. Расширяющийся ассортимент. Объем данных растет на 50–100% ежегодно.
  2. Постоянное обновление цен. Ежедневно в базе данных обновляют 20 миллионов цен на весь ассортимент. Перерасчет выполняется хотя бы раз в день автоматически по ассортименту во всех регионах, а также несколько раз в день выборочно вручную по переменному количеству позиций.
  3. Постоянное обновление и запрос данных о доступности товаров: компания продает товары через сайт, терминалы в торговых залах, единый контактный центр и маркетплейсы.
  4. Рост трафика на сайте ежегодно составляет 30–50%. Необходимо выдерживать нагрузку до 2 млн записей в минуту.

Требования

Высокая доступность даже при потере одного из ЦОДов

Низкие накладные расходы на запуск экземпляра: один разработчик может за одну минуту развернуть новый экземпляр

Простое масштабирование и контейнеризация

Нагрузка до 2 млн записей в минуту и до 40 тыс. чтений в минуту

Решение

Решение

Схема
обращения к данным

Решение

Решение

icon

Разработчики протестировали многие СУБД. Часть не соответствовала ACID, у других была сложная и запутанная архитектура. В 2018 году в рамках пробной эксплуатации применили Tarantool в режиме master-master репликации. После этого команда попыталась внедрить Tarantool как монолитную замену уже применявшейся СУБД. Но тестирование показало, что использовать Tarantool как монолитное решение в высоконагруженной системе неэффективно. Поэтому разработчики пошли следующим путем.

Решение

icon

  1. Создали свой DBaaS на базе Tarantool, чтобы ускорить развертывание новых экземпляров базы данных.
  2. Начали использовать в 2019 году Tarantool в качестве базы данных для всех новых проектов.
  3. Запустили «распил» монолитного сервиса на микросервисы с переносом данных из реляционной базы данных в отдельные экземпляры Tarantool.

Основная особенность Tarantool в «Ситилинке» — master-master репликация. Этот метод репликации на Tarantool встречается сравнительно редко, однако у него есть два ключевых преимущества.

Схема
обращения к данным

Решение

icon

Первое преимущество: высокая доступность системы в случае отказа сервера или целого ЦОДа. «Ситилинк» хранит свои данные в двух ЦОДах. В каждом из них есть несколько серверов для запуска баз данных. На каждом сервере может быть несколько экземпляров Tarantool — это зависит от объема данных в каждом. На случай отказа у каждого экземпляра базы данных в первом ЦОДе всегда есть реплика во втором ЦОДе.

Второе ключевое преимущество master-master репликации Tarantool состоит в том, что она позволяет быстро и легко собрать систему с сине-зеленым развертыванием (blue-green deployment). При таком развертывании трафик незаметно для пользователей постепенно переносится со старой версии приложения или сервиса на новую.

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

icon icon icon
Scroll

Результаты

3 сек

Время полного обновления каталога 3 секунды вместо 10-30 минут.

<30 мс

Менее 30 мс. задержка предоставления данных

70

70 экземпляров баз данных. Под самые высоконагруженные сервисы

Без кэша

Без кэширования, проще код, актуальнее данные

1 мин

Одна минута вместо двух недель. Time-to-market с переходом на DBaaS

10×

Рост доступности

Получить консультацию

Заказать демо