Привет! Меня зовут Никита Кречетов, я работаю в команде Datawave в юните DBA в Авито. В этой статье рассказываю, как мы перевели полторы тысячи инстансов Redis на Valkey Cluster, как отказались от ручного решардирования и что это дало разработчикам и бизнесу. Материал будет полезен инженерам, которые ищут практичный опыт миграции на новые базы данных.
Содержание:
Почему мы решили двигаться от Redis Sharded к Valkey Cluster
Valkey Cluster разгружает не только сервера, но и разработчиков
Как мы перевели 1500 инстансов Redis на Valkey за два месяца
Однопоточность без боли: подход Valkey к совместимости и производительности
Вводные
Итак, немного вводных. Мы совместно с командой NoSQL отвечаем за NoSQL-базы данных в Авито. Зона ответственности конкретно нашей команды: ClickHouse, Kafka, Elasticsearch, Redpanda.
Наши пользователи — внутренние команды разработчиков и аналитиков. Если им требуется база данных, они приходят к нам. Но с ростом запросов ручное создание инстансов перестало быть эффективным, и мы начали активно автоматизировать процессы.
Цель проста: дать разработчику возможность создать нужную базу без участия DBA-инженера, чтобы всё работало буквально по одной–двум командам в консоли и при этом поднималось во всех необходимых окружениях.
Почему мы решили двигаться от Redis Sharded к Valkey Cluster
У нас в Авито более 2700 хранилищ Redis, 400 из которых — шардированные инсталляции, которые, в свою очередь, могут включать сотни шардов. Отправной точкой стала смена лицензии Redis: новые версии стали проприетарными, и использовать их внутри компании уже было нельзя. Но реальная проблема лежала глубже.
На тот момент у нас в Авито был Redis Sharded — это по сути несколько независимых инсталляций, данные в которых распределяются с помощью клиентской библиотеки на стороне приложения. При этом, процесс решардирования остается на плечах пользователей.
Такой подход работал, но имел ряд ограничений:
ручное управление данными. При росте нагрузки разработчикам самим приходилось думать, как «распилить» данные между шардами;
рост без автоматизации. Любое масштабирование было связано с ручным решардированием: если мы увеличивали количество инстансов, то данные нужно было переносить из старых шардов в новые.
При уменьшении количества нод та же проблема возникала в обратную сторону — данные надо было возвращать обратно;архитектурные ограничения Redis. Он оставался в основном однопоточным, что становилось узким местом при росте нагрузки и масштабировании.
Поэтому мы искали решение, которое:
Было бы максимально совместимо с текущим использованием Redis.
Поддерживало автоматическое масштабирование.
Развивалось активно и имело комьюнити.
Мы решили рассмотреть Valkey Cluster, он решает эту задачу иначе. Здесь встроен механизм распределения данных по хэш-слотам: каждый слот закрепляется за определённым шардом, а при добавлении или удалении нод данные перераспределяются автоматически. То есть сам кластер знает, какие данные куда должны попасть, и не требует от разработчиков ручного вмешательства.
Valkey поддерживается активным сообществом и постепенно стал стандартной OSS-заменой Redis. По сути, он унаследовал всё лучшее от Redis и сохранил совместимость.
Valkey Cluster разгружает не только сервера, но и разработчиков
С точки зрения бизнеса это значит, что:
разработчики перестают тратить время на рутинное решардирование;
снижается вероятность ошибок, связанных с ручным переносом данных;
база может расти практически бесконечно, а для продукта это означает гибкость и масштабируемость «по требованию».
Стал заметен эффект экономии времени и ресурсов: меньше ручной работы, меньше рисков, выше скорость развития. Сейчас Valkey Cluster в процессе активной адаптации, и мы ожидаем, что это существенно разгрузит и разработчиков, и DBA-инженеров.
Пользователи Valkey Cluster — это, в первую очередь, другие команды разработчиков. У них есть сервисы, которые могут расти по нагрузке, и до этого они должны были сами думать о том, как распределить данные и что делать при масштабировании.
Valkey Cluster снимает эту головную боль: разработчик может просто «расти» — добавлять шард или несколько реплик, не тратя время на перенос данных и не отвлекая DBA-инженеров. Практически неограниченный рост «из коробки» — это то, что делает кластер востребованным продуктом.
Какие альтернативы рассматривали
Фактически мы рассматривали еще два варианта:
DragonflyDB — это аналог Redis (drop-in replacement). Не форк, а полноценная отдельная технология. Однако у неё оказалась неподходящая для наших целей лицензия.
KeyDB и KeyDB Cluster. У KeyDB был мультимастер — возможность писать в любую ноду, а данные синхронизировались между ними. Казалось, что это интересное преимущество: база не блокируется единственной точкой записи. Но в процессе стало ясно, что KeyDB фактически перестал развиваться: несколько лет не выходило обновлений, сообщество затихло. Для нас это означало высокие риски в будущем.
Теоретически мы могли смотреть на другие системы хранения, несовместимые по интерфейсу с Redis. Но на практике это означало бы серьёзную переработку всей интеграции и отказ от привычного API. Для нас это было неприемлемо: важно было сохранить совместимость и при этом добавить автоматическое масштабирование. Поэтому мы сознательно ограничились именно форками Redis.
В результате выбор оказался «без выбора»: формально опций было три, но реально оставался только Valkey Cluster. И сейчас видно, что решение было верным — сообщество действительно сделало Valkey основным OSS-продолжением Redis.
Как мы перевели 1500 инстансов Redis на Valkey за два месяца
Когда Redis закрыл лицензию и дальнейшие обновления стали проприетарными, мы не могли использовать его для построения своей платформы, приняли решение мигрировать на Valkey. К счастью, сам процесс оказался гораздо проще, чем можно было ожидать: Valkey полностью бинарно совместим с Redis. Это значит, что в большинстве случаев достаточно было просто заменить бинарник и перезапустить инстанс.
Миграция проходила поэтапно:
мы брали по одному инстансу, меняли образ Redis на Valkey и перезапускали его;
благодаря совместимости обе системы могли работать параллельно внутри одного кластера — никаких критичных сбоев это не вызывало;
за два месяца мы перевели около полутора тысяч инстансов, и весь процесс прошёл без единого инцидента.
Ключевую роль сыграла платформа DBaaS, на которой развёрнуты наши хранилища:
DBaaS управляет всеми сущностями баз данных и генерирует конфигурации;
при необходимости можно указать, какой именно образ использовать для запуска;
Kubernetes позволил обновлять инстансы через подмену образа — без сложных ручных манипуляций.
Если чуть подробнее о платформе: DBaaS — это «источник правды» о большей части наших баз. Он знает, какие шарды и реплики нужны пользователю, как их распределить по кластерам, и через контроллеры в Kubernetes синхронизирует текущее состояние с целевым. Там же решаются задачи с доступами, секретами, бэкапами. Это целая экосистема сервисов, которая сильно упрощает жизнь DBA и разработчиков.
Были ли сложности? Совсем без них не обошлось. Мы хотели сразу перейти на самую свежую версию Valkey, но под нагрузкой она показывала нестабильное поведение. Пришлось откатиться на более раннюю, но всё равно более новую, чем наш текущий Redis. Тем не менее это никак не повлияло на миграцию: совместимость позволила провести её мягко и безопасно.
Главный вывод: переезд на Valkey — это не сложный и рискованный процесс, а скорее «upgrade без боли». Он не только позволил обновить инфраструктуру и поддерживать её актуальность, но и дал ощутимый прирост производительности за счёт многопоточности Valkey.
Однопоточность без боли: подход Valkey к совместимости и производительности
Одним из весомых аргументов в пользу перехода на Valkey стала производительность. Redis изначально работает в однопоточном режиме: все операции — от обращения к памяти до работы с диском — выполняются последовательно в одном потоке. Это накладывает естественные ограничения на пропускную способность.
Valkey пошёл дальше: он сохранил однопоточность для базовых операций (чтобы не нарушать совместимость и предсказуемость поведения), но вынес часть задач — работу с сетью, ввод-вывод, операции с диском — в отдельные потоки. В результате основной поток разгружается, а система обрабатывает значительно больше запросов в единицу времени.
Valkey в целом показал себя производительнее, подробнее можно почитать в Unlock 1 Million RPS: Experience Triple the Speed with Valkey и Unlock 1 Million RPS: Experience Triple the Speed with Valkey - part 2
Основные моменты, влияющие на производительность:
Улучшили внутренний планировщик задач.
Ускорили I/O модель.
Обеспечили синхронизацию между потоками вместо блокировок.
В наших нагрузочных тестах Valkey показал прирост пропускной способности и стабильности под пиковыми запросами, что стало ещё одним фактором в пользу миграции.
Решардирование без DBA и ручных операций
Главное отличие Valkey Cluster от одиночных инстансов Redis — это управление данными через хэш-слоты. Каждому шардy назначается набор слотов, и именно он отвечает за хранение данных в этой области. Однако сами по себе слоты не умеют «переезжать» при масштабировании. Если в кластер добавляется новая нода, то без дополнительной логики нагрузка на старых нодах останется прежней.
Мы реализовали собственный механизм решардирования, построенный на сети агентов (или сайдкаров). Агенты занимаются не только решардированием, но и поддержанием топологии, связанной с распределением leader-replica, применением изменений конфигурации, доставкой секретов до хранилищ и т.д.
Каждый инстанс Valkey в Kubernetes-поде запускается вместе с агентом.
Агенты делятся на два типа: контроллер и реплика.
Среди контроллер-агентов выбирается лидер, который формирует «целевое состояние» кластера
Для поддержания отказоустойчивости control plane необходимо, чтобы между контроллер-агентами сохранялся консенсус о «целевом состоянии» кластера, для чего все контроллер-агенты являются voter-нодами в Raft-кластере
Дальше каждый реплика-агент с некоторой периодичностью сверяет свою роль, текущее распределение слотов с целевым и постепенно приводит свой инстанс к нужному состоянию: отдаёт лишние слоты, принимает новые, синхронизирует данные.
Так мы добились того, что при добавлении или удалении нод распределение хэш-слотов перестраивается автоматически, без участия DBA-инженеров и разработчиков.
Какие проблемы мы решали, когда запускали Valkey Cluster
Разумеется, реализация не была безболезненной:
синхронизация между нодами. Мы хотели, чтобы они независимо приходили к одному состоянию, но на практике разные процессы выполнялись с разной скоростью. Пришлось продумывать механизмы согласования, чтобы кластер не «расползался»;
отсутствие «умного» failover. Так как мы стремимся к увеличению доступности хранилищ, по умолчанию разворачиваем их инстансы в трех дата центрах. При этом важно распределять leader-ноды равномерно между ними, так как консенсус в кластере основан именно на leader-нодах. Valkey пока не умеет выполнять failover с учетом зон доступности, поэтому пришлось реализовать этот алгоритм самостоятельно;
протокол обмена. Встал вопрос: передавать ли полное состояние кластера или только события («добавилась нода», «удалилась нода», «перенос слотов»). Второй вариант экономит трафик, но требует сложной реализации. На данный момент получилось найти компромисс, при котором мы все ещё можем передавать полное состояние нодами, которым оно надо, отдавая остальным только ту часть, которая пригодится им для управления своим состоянием;
сертификаты. Redis в режиме single не требовал синхронизации сертификатов, а в кластере это стало необходимостью: шарды должны доверять друг другу, иначе они просто не смогут общаться. Мы доработали генерацию и синхронизацию сертификатов, чтобы обеспечить безопасное взаимодействие внутри кластера.
В результате Valkey Cluster стал не просто заменой Redis, а основой для более надёжной и гибкой системы: разработчики теперь могут расти практически «без потолка», не думая о том, как вручную переливать данные между нодами.
Valkey Cluster как продукт на платформе
Мы старались воспринимать Valkey Cluster не просто как ещё одну базу данных, а как полноценный продукт внутри платформы DBaaS. С одной стороны, он похож на привычный Redis, с другой — имеет свои особенности: управление топологией, распределение данных по хэш-слотам, решардирование.
Чтобы интеграция была максимально бесшовной, мы адаптировали наработки из мира Redis. Например, у нас уже существовала платформенная библиотека для работы с Redis, в которую входили метрики, логи и обвязка под внутреннюю инфраструктуру. При переходе на Valkey мы не стали писать всё заново, а переиспользовали подход: библиотека была доработана, чтобы поддерживать новый движок, и стала общей для обоих случаев.
Это не просто техническая оптимизация, а важная часть удобства для пользователей внутри компании: разработчики получают единый интерфейс и не задумываются о том, где именно их данные лежат — в Redis или Valkey. Всё необходимое для мониторинга и эксплуатации уже встроено.
Мы запустили Valkey Cluster, но это только начало
Сейчас Valkey Cluster у нас запущен в формате уверенного MVP. Им уже можно пользоваться, но при этом мы понимаем, что есть ограничения и зоны роста. Из крупных планов:
доработка алгоритмов агентов, чтобы ещё сильнее снизить нагрузку на сеть и ускорить процессы решардирования;
улучшение синхронизации между нодами;
работа над отказоустойчивостью, чтобы приблизиться к состоянию Zero Downtime.
Дальнейшие планы: Zero Downtime
Следующая амбициозная цель — построить систему, которая будет оставаться доступной при любых обстоятельствах:
падение дата-центра;
потеря сетевого сегмента;
проблемы с дисками;
внутренние сбои синхронизации.
Чтобы этого достичь, придётся идти на компромиссы: например, где-то снижать уровень консистентности данных ради гарантированной доступности. Но стратегически это направление выглядит важным: чем меньше рисков простоя, тем надёжнее платформа для внутренних пользователей.
Что в итоге
Для меня работа над Valkey Cluster стала серьёзным опытом. Раньше я не так часто сталкивался с инфраструктурными задачами, а тут пришлось пройти весь путь — от миграции до написания операторов и сайдкаров. По ходу выяснилось, что главная ценность — это слушать боль пользователей: и разработчиков, и DBA-инженеров. Если удаётся правильно собрать и обобщить эти проблемы, получается продукт, который реально экономит время и силы командам.
А у вас был похожий опыт? Делитесь историями в комментариях.
Узнать больше о задачах, которые решают инженеры AvitoTech, можно по этой ссылке. А вот тут мы собрали весь контент от нашей команды — там вы найдете статьи, подкасты, видео и много чего еще. И заходите в наш TG-канал, там интересно!