Настройка Redis Cluster: горизонтальное масштабирование с нуля

Redis Cluster: где ломается масштабирование под нагрузкой

Одиночный инстанс упирается в три стены почти одновременно. Память ограничена размером одной машины: когда набор данных подходит к лимиту maxmemory, включается политика вытеснения — и под нож идут ключи, которые никто не планировал терять. Рядом второй эффект: фоновое сохранение с fork на большом объёме замораживает обработку команд на сотни миллисекунд, и это видно на графике задержек, а не в логах.

Горячие ключи добивают иначе. Счётчик, сессия, справочник, к которому обращаются все запросы, живёт в одном потоке — сколько бы ядер ни было, нагрузка ложится на одно. Разложить такой ключ по репликам не помогает: запись всё равно идёт в мастер, а чтение с реплик отдаёт рассинхрон и устаревшие значения.

Переполнение памяти ощущается как каскад, а не как отказ. Вытеснение переключается с ключей с истекающим сроком на произвольные, часть запросов начинает ходить в базу напрямую, её задержки растут, и в пике отваливается уже всё. Плюс нехватка памяти уходит в swap — время ответа измеряется секундами, но формально сервис жив.

Ловится это в тот момент, когда пик нагрузки совпадает с записью: одно узкое место тянет за собой остальные, а откат к предыдущему состоянию негде взять. Именно поэтому масштабирование redis планируют заранее, а не по факту аварии. Ниже разбираем, как это закрывается переходом на Redis Cluster: шардированием по слотам, разделением горячих ключей и предсказуемым поведением при отказе узла.

Что даёт кластер: рост по узлам и отказ без простоя

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

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

Отказоустойчивость кластера держится на репликах: у каждого мастера есть копия, и при его падении остальные мастера голосованием поднимают реплику. Из эксплуатации уходит целый класс отказов — падение одного узла больше не останавливает запись и не требует ручного подъёма из резервной копии с потерей последних операций.

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

Пропускная способность растёт ещё и за счёт реплик: чтение расходится по копиям, если приложение к этому готово. Перед изменениями снимаем замеры — операции в секунду, задержка на 95-м процентиле, доля отказов, закрытых автоматикой, — и повторяем их после, чтобы рост был измеримым, а не заявленным.

Redis Cluster или репликация: сравнение режимов работы

Репликация и кластер закрывают разные задачи, поэтому выбирают их по профилю данных, а не по «мощности». Репликация тиражирует один и тот же набор на несколько узлов: растут отказоустойчивость и пропускная способность чтения, но не объём. Кластер добавляет шардирование — данные раскладываются по узлам, и запись тоже масштабируется.

Практический критерий простой: если данные перестают помещаться в память узла или запись упирается в один мастер — репликация задачу не решает. Обратная ошибка встречается не реже: кластер на небольших объёмах приносит ограничения по командам и сложность сопровождения без выигрыша. Разбираем, как выбирать режим под нагрузку и профиль данных и как заложить переход между ними без перерыва в работе.

Этапы внедрения: от аудита до передачи в эксплуатацию

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

1. Аудит нагрузки. Собираем профиль трафика за полный цикл — рабочие часы, ночные окна, пики отчётности. Фиксируем долю тяжёлых операций, объём рабочего набора и запас по памяти на каждом узле.
2. Схема разделения данных. Проектируем раскладку ключей по сегментам: выбираем шаблон именования, исключаем горячие ключи, проверяем, что связанные структуры попадают в один узел. На этом шаге определяем число сегментов и запас на рост.
3. Топология и отказоустойчивость. Раскладываем основные и резервные узлы по разным зонам доступности, чтобы отказ стойки не уносил пару целиком. Настраиваем кворум, таймауты и поведение клиентов при переключении.
4. Развёртывание и миграция. Поднимаем конфигурацию, переносим данные без остановки сервиса: постепенное переключение чтений, затем записей, с контролем расхождений на каждом шаге.
5. Проверка отказоустойчивости. Гасим узлы по одному и группами, замеряем время переключения и потери записей, проверяем поведение приложения под нагрузкой. Отдельно прогоняем сценарий возврата узла в строй.
6. Передача в эксплуатацию. Отдаём мониторинг с порогами, алерты на деградацию, регламент плановых работ и документацию по схеме разделения — команда заказчика дальше ведёт кластер сама.

Порядок шагов не случаен: каждый следующий опирается на данные предыдущего, поэтому проблемы ловятся до вывода в продуктив, а не в момент пика.

Что остаётся у вас: конфигурации, схемы, регламенты

После сдачи кластера вы не остаётесь с чужим репозиторием и устными пояснениями. Комплект передаём целиком в ваш контур контроля версий, любые правки дальше проходят через ревью: по нему ваша команда сама поднимает стенд с нуля, вводит новый узел и восстанавливает данные после отказа мастера — без обращения к нам.

• Конфигурации всех узлов: рабочие файлы с включённым кластерным режимом, таймаутами, лимитами памяти и политикой вытеснения ключей, с комментариями — почему выбрано именно это значение и что сломается при его смене.
• Карта топологии: распределение слотов по мастерам, привязка реплик, сетевые зоны и точки отказа на одной схеме, которую можно показать дежурной смене.
• Политики доступа: разграничение по ACL — что читает и пишет каждый сервис, отдельные учётки для мониторинга и административных операций, порядок ротации паролей.
• Скрипты резервного копирования: снятие снимков с реплик по расписанию, проверка целостности, выгрузка за пределы кластера и регулярное тестовое восстановление.
• Регламент обслуживания: плановое переключение мастера, добавление узла, перераспределение слотов и обновление без простоя — с окнами и критериями готовности.
• Порядок действий при инциденте: что смотреть первым, как отличить отказавший узел от сетевой деградации, когда вмешиваться вручную, а когда дождаться автоматического переключения.
• Документация по кластеру: архитектурные решения и почему они такие, журнал изменений, чек-лист приёмки, по которому вы принимаете работу.

Кейс: как кластер убрал отказы при пиковой нагрузке

Один инстанс Redis держал и кэш, и очереди задач, и сессии пользователей. На пике — распродажа, массовая рассылка, утренний вход в приложение — поток операций вырастал втрое, узел упирался в потолок, и вместе с ним вставали сценарии, которые к кэшу отношения не имеют. Для клиента это выглядело не как «медленно», а как «не работает».

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

Что изменили

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

Метрики до и после

• Доля отказов при пиковой нагрузке: 12% запросов до нуля — недоступных операций на пике не осталось.
• Время восстановления после выхода узла: ручные 30-40 минут до автоматического подъёма реплики и переключения за секунды.
• Потолок по операциям: единственный узел перестал быть ограничителем — добавление узла увеличивает пропускную способность кратно.
• Поведение сервиса при потере узла: вместо полного отказа — короткая деградация и перечитывание части ключей из базы.

Что делать, если приложение уже работает с одиночным сервером?

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

Сначала инвентаризация: какие ключи живут долго, где операции затрагивают несколько ключей сразу, какие структуры нельзя разнести по узлам. Мультиключевые команды и скрипты требуют, чтобы связанные ключи лежали на одном узле, — иначе их переписывают на общие хеш-теги. Это единственная часть перехода, которая действительно требует правок в коде приложения.

Данные переносим в фоне: снимаем дамп с одиночного сервера, заливаем его в кластер, раскладывая ключи по диапазонам слотов. Дальше включаем двойную запись — приложение пишет и в старый инстанс, и в кластер, а читает пока из старого. Перенос идёт на живой системе, а расхождение копий не превышает задержки одной операции.

Целостность проверяем сверкой ключей и значений по выборке, затем пускаем теневой поток чтения на кластер и сопоставляем ответы с одиночным сервером. Пока расхождения есть, переключение не делаем: обратная совместимость клиентов обеспечена — они уже умеют следовать перенаправлениям между узлами, но работают по старому адресу. План отката — флаг в конфигурации: он возвращает чтение на одиночный сервер, который остаётся прогретым и получает все записи. Если после переключения растёт доля ошибок или время ответа, флаг снимается за секунды, и сервис продолжает работать на прежнем контуре.

Технические сомнения: отказ узлов, переезд и совместимость

Перед передачей кластера разбираем то, что чаще всего всплывает на приёмке: поведение при потере узла, объём правок в приложении, требования к сети и что остаётся на нашей стороне после сдачи.

Придётся ли править код?

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

Какие требования к сети?

Узлам нужна прямая связность по служебному порту и ровная задержка: обмен состоянием идёт постоянно, и потери пакетов вызывают ложные выборы мастера. Фиксируем статические адреса, исключаем трансляцию между узлами, пороги проверки здоровья ставим с запасом.

Что входит в обслуживание после передачи?

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

Обсудим задачу: что нужно для старта и оценки

Оценка проекта по развёртыванию Redis Cluster занимает тем меньше времени, чем точнее вводные данные. Ниже — то, что нужно от вас, чтобы мы вернулись с планом работ и сроками, а не с уточняющими вопросами через неделю.

• Профиль нагрузки: операций в секунду в пике и в среднем, доля чтения и записи, типичный размер значения — от этого зависит число узлов и запас по памяти.
• Текущая схема: одиночный экземпляр, ведущий с репликами или уже кластер, какие приложения и клиентские библиотеки к нему подключены.
• Ожидаемый рост: как нагрузка и объём данных изменятся за полгода — закладываем запас, чтобы не перестраивать конфигурацию сразу после запуска.
• Окно обслуживания: когда допустим краткий перерыв в записи, а когда переход должен пройти незаметно для пользователей.
• Требования к восстановлению: допустимое время простоя при отказе узла и допустимая потеря последних записей.
• Инфраструктура и доступы: сколько машин доступно, есть ли разделение по зонам, кто со стороны заказчика принимает изменения и какие права нужны нашим инженерам.

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