RWB повысила отказоустойчивость БД с помощью собственной разработки на базе Redis

О компании

RWB – российская технологическая компания, созданная в 2024 году в результате слияния маркетплейса Wildberries и оператора наружной рекламы Russ. Главной целью этого объединения стало построение глобальной цифровой торговой платформы, которая получает преимущества за счет  синергии между логистической инфраструктурой маркетплейса и рекламными возможностями Russ.

Предпосылки проекта

RWB активно развивает собственную ИТ-инфраструктуру: цифровые решения используются для поддержки самых разных направлений ее продуктовой и операционной деятельности. В случаях, когда для цифровой платформы особенно важны скорость отклика, стабильность при высокой нагрузке и предсказуемость работы сервисов, применяется in-memory noSQL СУБД Redis.

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

Главная ценность Redis состоит в том, что эта СУБД разгружает основные хранилища, ускоряет часто повторяющиеся операции и сохраняет стабильность сервисов в периоды повышенного трафика. Это означает более предсказуемую работу цифровых продуктов, меньшую вероятность деградации при пиковых нагрузках.

Redis запускается как systemd-сервисы на виртуальных машинах (VM) во внутреннем облаке компании. Из трех основных схем развертывания СУБД (Single Instance, Redis Sentinel, Redis Cluster) на практике используется две последние. Предполагается, что VM, на которых работают Redis Cluster и Redis Sentinel, должны быть поровну распределены между тремя зонами доступности (Availability Zone, или AZ – физически изолированные, но объединенные каналами связи и логикой управления ЦОДы – прим. ред) и благодаря этому обеспечивать высокую доступность при потенциальном выходе из строя одной из AZ. Для Redis Sentinel это утверждение оказалось справедливым, однако для корректной работы Redis Cluster потребовались доработки.

«Redis Cluster содержит корректные встроенные механизмы защиты от различного рода аварий. Но в multi-AZ-инфраструктуре серверы с Redis могут быть физически распределены по трем зонам доступности, а роли master при этом могут оказаться распределены неравномерно. Если в одной зоне оказывается большинство master-узлов и именно эта зона становится недоступной, у оставшихся узлов может не хватить голосов для автоматического восстановления работы БД. С технической точки зрения это штатное поведение Redis Cluster, но для компании такой сценарий выглядит как риск простоя при, казалось бы, правильно построенной отказоустойчивой архитектуре. Разница между «серверы распределены по зонам» и «кластер действительно устойчив к потере зоны» стала отправной точкой проекта», – объясняет Иван Откидач, DevOps-инженер подразделения DBA (Database Administrator) RWB. 

DevOps-инженер подразделения DBA компании RWB Иван Откидач
Фото: RWB

В компании не нашли готового open source-инструмента, который закрывал бы именно этот класс рисков в нужной модели эксплуатации. Поэтому решение было принято в пользу инхаус-разработки собственного управляющего контура. Было предложено не переписывать Redis и не вмешиваться в его внутреннюю логику, а создать отдельный сервис, который «понимает» инфраструктурную топологию RWB и заранее снижает риск опасных конфигураций.

Решение

Redis Auto Failover (RAF) – это внешний AZ-aware контроллер над Redis Cluster. Его задача – оценивать кластер не только с точки зрения самого Redis, но и с точки зрения инфраструктуры RWB: «понимать», в каких зонах доступности находятся узлы, где сейчас размещены master-роли и насколько текущее распределение безопасно при потере одной зоны доступности. Если сервис видит потенциально опасную топологию, он строит план корректирующих переключений и выполняет их.

С позиции бизнеса RAF можно назвать системой раннего управления риском. Технически на верхнем уровне он работает так: собирает снимок состояния из корпоративного мониторинга и Redis Cluster API, сопоставляет роли узлов с зонами доступности, анализирует распределение master-ролей, формирует предложения по безопасному failover и применяет их строго последовательно. После каждого действия сервис проверяет, что новый master доступен, реплики синхронизированы, задержка репликации находится в допустимых пределах, а итоговое распределение действительно стало более устойчивым. Отдельно были заложены метрики и алерты, чтобы RAF был не «черным ящиком», а наблюдаемым эксплуатационным сервисом.

Ход проекта

Разработка Redis Auto Failover стала полноценным инженерным проектом, состоящим из нескольких этапов: формулировка проблемы, моделирование аварийных сценарий, проверка ограничений Redis Cluster, проектирование безопасной архитектуры, создание сервиса, тестирование его на dev-контуре, развертывание в production-кластерах.

С точки зрения среды внедрения проект развивался внутри DBA/DevOps-направления RWB, которое отвечает за эксплуатацию Redis и других NoSQL-хранилищ. Продукт должен был учитывать существующий мониторинг, тонкости инфраструктуры, регламенты эксплуатации и поведение клиентских сервисов при переключении master-ролей.

По мнению Ивана Откидача, сложность проекта состояла не только в программировании: «В таких задачах написать работающий код недостаточно: нужно доказать, что автоматизация не сделает ситуацию хуже. Любое переключение master-ролей – чувствительная операция, которая даже в graceful-режиме может дать короткое окно деградации. Поэтому RAF должен был быть консервативным: проверять состояние кластера до действия, выбирать минимально рискованный сценарий, выполнять переключения последовательно, контролировать replication lag и обязательно верифицировать результат после каждого шага».

Важно подчеркнуть, что проект не подразумевал отдельного крупного финансового вложения в закупку внешнего продукта для внедрения. Созданное решение опирается на существующую инфраструктуру, мониторинг, внутреннее облако, Redis Cluster API и стандартные механизмы failover.

Результат проекта. Главные преимущества внедренного решения

В ИТ-инфраструктуре компании появился инструмент, который заранее снижает вероятность тяжелого отказа Redis Cluster при потере зоны доступности. RAF не отменяет природу Redis Cluster и не делает failover абсолютно бесшовным, но он переводит проблему из режима «мы узнаем об опасной топологии во время аварии» в режим «мы видим риск заранее и управляем им контролируемо». Для бизнеса «управляемая кратковременная деградация» гораздо лучше, чем длительный простой критичных сервисов в непредсказуемый момент.

Для DevOps- и DBA-подразделений эффект выражается в снижении ручной нагрузки и повышении предсказуемости эксплуатации. До появления такого инструмента подобный риск требовал бы регулярных ручных проверок, экспертной оценки топологии и высокой скорости реакции в стрессовой ситуации. RAF стандартизирует эту работу: он видит риск, объясняет причину, предлагает корректирующее действие, выполняет его через безопасный сценарий и даёт команде прозрачные метрики результата.

«Когда критичный инфраструктурный слой становится более устойчивым, компания снижает вероятность простоев, защищает пользовательские сценарии, повышает качество внутренних сервисов и уменьшает потенциальные потери от аварий. Мы оцениваем потенциальную экономию от внедрения сервиса на сумму до 200,9 млн рублей в год: предотвращенный простой стоит дешевле, чем аварийное восстановление, компенсация последствий деградации и потеря эффективности продуктовых команд», – добавляет Иван Откидач.

Redis Auto Failover в контексте развития Data-сервисов RWB

Для RWB проекты в области баз данных, Big Data и инфраструктурной автоматизации — часть технологического фундамента, который позволяет бизнесу масштабироваться. Такие решения напрямую связаны с устойчивостью клиентских сервисов, скоростью запуска новых продуктов и качеством внутренних процессов.

«Мы видим, что рынок управления данными всё больше движется в сторону автоматизации, предсказуемости и снижения операционных рисков. Для крупного бизнеса уже недостаточно просто хранить данные и поддерживать базы в рабочем состоянии: важно заранее понимать, где может возникнуть сбой, как он повлияет на сервисы и какие действия можно выполнить автоматически, без ручного вмешательства», – говорит Иван Откидач.

Redis Auto Failover — пример того, как инфраструктурная команда переводит управление базами данных из реактивного режима в проактивный: заранее выявляет рискованную конфигурацию и снижает вероятность простоя.

Как отдельную тенденцию эксперт выделяет рост роли Big Data, AI и AIOps. Компании всё активнее используют данные не только для аналитики, но и для автоматизации процессов, рекомендаций, поиска, модерации, прогнозирования нагрузки и оптимизации затрат. В этой логике базы данных и инфраструктура становятся основой для скорости, качества и масштабируемости бизнеса.

«В целом такие проекты в ИТ-стратегии RWB помогают превращать технологии в конкурентное преимущество. Надежные базы данных, автоматизация, Big Data и AI дают компании возможность быстрее развивать продукты, эффективнее использовать ресурсы и поддерживать стабильную работу платформы даже при высоких нагрузках», – резюмирует он.