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

В 2010 году все данные «Ситилинка» о товарных позициях, включая их наличие на складе и цену, хранили в реляционной базе данных. Для доступа к ней использовали монолитный сервис на PHP-фреймворке Symfony. Год от года нагрузка росла, и реляционная база данных перестала справляться с нагрузкой. Долгое время в «Ситилинке» использовали систему кэширования. Она снижала нагрузку на базу данных при чтении и записи. Однако система постоянно усложнялась, нужно было инвалидировать кэш и гарантировать целостность данных на случай перегрузки. В определенный момент размер кэша достиг 100 ГБ, и стало выгоднее не кэшировать данные, а хранить их в in-memory базе данных. Объяснить такой рост данных и всю сложность в планировании архитектуры могут четыре основных фактора: 1. **Расширяющийся ассортимент.** Объем данных растет на 50–100% ежегодно. 2. **Постоянное обновление цен.** Ежедневно в базе данных обновляют 20 миллионов цен на весь ассортимент. Перерасчет выполняется хотя бы раз в день автоматически по ассортименту во всех регионах, а также несколько раз в день выборочно вручную по переменному количеству позиций. 3. **Постоянное обновление и запрос данных о доступности товаров:** компания продает товары через сайт, терминалы в торговых залах, единый контактный центр и маркетплейсы. 4. **Рост трафика на сайте** ежегодно составляет 30–50%. Необходимо выдерживать нагрузку до 2 млн записей в минуту.

- Высокая доступность даже при потере одного из ЦОДов - Низкие накладные расходы на запуск экземпляра: один разработчик может за одну минуту развернуть новый экземпляр - Простое масштабирование и контейнеризация - Нагрузка до 2 млн записей в минуту и до 40 тыс. чтений в минуту

Разработчики протестировали многие СУБД. Часть не соответствовала ACID, у других была сложная и запутанная архитектура. В 2018 году в рамках пробной эксплуатации применили Tarantool в режиме master-master репликации. После этого команда попыталась внедрить Tarantool как монолитную замену уже применявшейся СУБД. Но тестирование показало, что использовать Tarantool как монолитное решение в высоконагруженной системе неэффективно. Поэтому разработчики пошли следующим путем. 1. **Создали свой DBaaS** на базе Tarantool, чтобы ускорить развертывание новых экземпляров базы данных. 2. **Начали использовать в 2019** году Tarantool в качестве базы данных для всех новых проектов. 3. **Запустили «распил» монолитного сервиса** на микросервисы с переносом данных из реляционной базы данных в отдельные экземпляры Tarantool. Основная особенность Tarantool в «Ситилинке» — master-master репликация. Этот метод репликации на Tarantool встречается сравнительно редко, однако у него есть два ключевых преимущества.

**Первое преимущество**: высокая доступность системы в случае отказа сервера или целого ЦОДа. «Ситилинк» хранит свои данные в двух ЦОДах. В каждом из них есть несколько серверов для запуска баз данных. На каждом сервере может быть несколько экземпляров Tarantool — это зависит от объема данных в каждом. На случай отказа у каждого экземпляра базы данных в первом ЦОДе всегда есть реплика во втором ЦОДе. **Второе** ключевое преимущество master-master репликации Tarantool состоит в том, что она позволяет быстро и легко собрать систему с сине-зеленым развертыванием (blue-green deployment). При таком развертывании трафик незаметно для пользователей постепенно переносится со старой версии приложения или сервиса на новую. **В итоге** решение позволяет легко выдерживать нагрузку до 2 млн записей в минуту и поддерживать каталог товаров в актуальном состоянии в любой момент времени.