Redis Cluster: де ламається масштабування під навантаженням
Одиночний інстанс упирається в три стіни майже одночасно. Пам'ять обмежена розміром однієї машини: коли набір даних підходить до ліміту maxmemory, вмикається політика витіснення — і під ніж ідуть ключі, які ніхто не планував втрачати.
Поруч другий ефект: фонове збереження з fork на великому обсязі заморожує обробку команд на сотні мілісекунд, і це видно на графіку затримок, а не в логах.
Гарячі ключі добивають інакше. Лічильник, сесія, довідник, до якого звертаються всі запити, живе в одному потоці — скільки б ядер не було, навантаження лягає на одне.
Розкласти такий ключ по репліках не допомагає: запис все одно йде в майстер, а читання з реплік віддає розсинхрон і застарілі значення.
Переповнення пам'яті відчувається як каскад, а не як відмова. Витіснення перемикається з ключів із терміном дії, що спливає, на довільні, частина запитів починає ходити в базу напряму, її затримки зростають, і на піку відвалюється вже все. Плюс нестача пам'яті йде в swap — час відповіді вимірюється секундами, але формально сервіс живий.
Ловиться це в той момент, коли пік навантаження збігається із записом: одне вузьке місце тягне за собою решту, а відкат до попереднього стану ніде взяти. Саме тому масштабування redis планують заздалегідь, а не за фактом аварії.
Нижче розбираємо, як це закривається переходом на Redis Cluster: шардуванням за слотами, розділенням гарячих ключів і передбачуваною поведінкою при відмові вузла.
Що дає кластер: зростання за вузлами та відмова без простою
У Redis Cluster простір ключів розбито на слоти, і кожен майстер відповідає за свою частку. Поки ключі розподілені рівномірно, додавання вузлів піднімає стелю за операціями майже пропорційно — упор іде з одного процесу в мережу і в узгодженість між вузлами.
Схему ключів перевіряємо до масштабування: гарячі ключі та операції одразу за кількома слотами з'їдають приріст швидше, ніж додаються вузли. Це той випадок, коли горизонтальне масштабування бази упирається не в залізо, а в модель даних.
Відмовостійкість кластера тримається на репліках: у кожного майстра є копія, і при його падінні решта майстрів голосуванням піднімають репліку.
З експлуатації йде цілий клас відмов — падіння одного вузла більше не зупиняє запис і не потребує ручного підйому з резервної копії з втратою останніх операцій.
Час відновлення скорочується з десятків хвилин ручної роботи до автоматичного перемикання за секунди. Вікно, в якому запис недоступний, стискається, а клієнти самі перечитують топологію і продовжують роботу без втручання чергового.
Пропускна здатність зростає ще й за рахунок реплік: читання розходиться по копіях, якщо застосунок до цього готовий.
Перед змінами знімаємо заміри — операцій за секунду, затримка на 95-му процентилі, частка відмов, закритих автоматикою, — і повторюємо їх після, щоб зростання було вимірюваним, а не заявленим.
Redis Cluster чи реплікація: порівняння режимів роботи
Реплікація і кластер закривають різні задачі, тому вибирають їх за профілем даних, а не за «потужністю». Реплікація тиражує один і той самий набір на кілька вузлів: зростають відмовостійкість і пропускна здатність читання, але не обсяг. Кластер додає шардування — дані розкладаються по вузлах, і запис теж масштабується.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Реплікація з ручним розділенням ключів | Обсяг вміщається на один вузол, застосунок сам знає, куди писати | Стеля за пам'яттю вузла, перемикання ролей зовнішнім арбітром, логіка розділення живе в коді застосунку |
| Кластер з автоматичним розподілом слотів | Дані не вміщаються на вузол, потрібен запис на всі майстри | Операції з кількома ключами потребують спільного тегу, частина команд недоступна, перебалансування дає сплески затримок |
| Гібрид: кластер, репліки та окремий контур читання | Важкі звіти та вивантаження не повинні бити по бойових вузлах | Складніший супровід, потрібно стежити за лагом реплікації та узгодженістю |
| Шардування на боці застосунку | Потрібен повний контроль над розміщенням ключів | Маршрутизація та ребаланс — на застосунку, зміна топології потребує плану міграції |
Практичний критерій простий: якщо дані перестають вміщатися в пам'ять вузла або запис упирається в один майстер — реплікація задачу не вирішує. Зворотна помилка трапляється не рідше: кластер на невеликих обсягах приносить обмеження за командами і складність супроводу без виграшу.
Розбираємо, як вибирати режим під навантаження і профіль даних і як закласти перехід між ними без перерви в роботі.
Етапи впровадження: від аудиту до передачі в експлуатацію
Впровадження кластера починається не зі встановлення, а з аудиту профілю навантаження: знімаємо статистику за командами, співвідношення читань і записів, розмір значень, час життя ключів і добові піки.
Ці дані визначають, скільки вузлів реально потрібно, де пройде межа між гарячими та холодними даними і які ключі не можна розносити по різних вузлах без втрати атомарності операцій.
- Аудит навантаження. Збираємо профіль трафіку за повний цикл — робочі години, нічні вікна, піки звітності. Фіксуємо частку важких операцій, обсяг робочого набору і запас за пам'яттю на кожному вузлі.
- Схема розділення даних. Проєктуємо розкладку ключів за сегментами: вибираємо шаблон іменування, виключаємо гарячі ключі, перевіряємо, що пов'язані структури потрапляють в один вузол. На цьому кроці визначаємо кількість сегментів і запас на зростання.
- Топологія та відмовостійкість. Розкладаємо основні й резервні вузли по різних зонах доступності, щоб відмова стійки не забирала пару цілком. Налаштовуємо кворум, таймаути та поведінку клієнтів при перемиканні.
- Розгортання та міграція. Піднімаємо конфігурацію, переносимо дані без зупинки сервісу: поступове перемикання читань, потім записів, з контролем розбіжностей на кожному кроці.
- Перевірка відмовостійкості. Гасимо вузли по одному і групами, заміряємо час перемикання і втрати записів, перевіряємо поведінку застосунку під навантаженням. Окремо проганяємо сценарій повернення вузла в стрій.
- Передача в експлуатацію. Віддаємо моніторинг із порогами, алерти на деградацію, регламент планових робіт і документацію за схемою розділення — команда замовника далі веде кластер сама.
Порядок кроків не випадковий: кожен наступний спирається на дані попереднього, тому проблеми ловляться до виведення в продуктив, а не в момент піку.
Що залишається у вас: конфігурації, схеми, регламенти
Після здачі кластера ви не залишаєтесь із чужим репозиторієм і усними поясненнями.
Комплект передаємо цілком у ваш контур контролю версій, будь-які правки далі проходять через рев'ю: за ним ваша команда сама піднімає стенд з нуля, вводить новий вузол і відновлює дані після відмови майстра — без звернення до нас.
- Конфігурації всіх вузлів: робочі файли з увімкненим кластерним режимом, таймаутами, лімітами пам'яті та політикою витіснення ключів, з коментарями — чому вибрано саме це значення і що зламається при його зміні.
- Карта топології: розподіл слотів за майстрами, прив'язка реплік, мережеві зони та точки відмови на одній схемі, яку можна показати черговій зміні.
- Політики доступу: розмежування за ACL — що читає і пише кожен сервіс, окремі облікові записи для моніторингу та адміністративних операцій, порядок ротації паролів.
- Скрипти резервного копіювання: зняття знімків з реплік за розкладом, перевірка цілісності, вивантаження за межі кластера і регулярне тестове відновлення.
- Регламент обслуговування: планове перемикання майстра, додавання вузла, перерозподіл слотів і оновлення без простою — з вікнами та критеріями готовності.
- Порядок дій при інциденті: що дивитися першим, як відрізнити вузол, що відмовив, від мережевої деградації, коли втручатися вручну, а коли дочекатися автоматичного перемикання.
- Документація за кластером: архітектурні рішення і чому вони такі, журнал змін, чек-ліст приймання, за яким ви приймаєте роботу.
Кейс: як кластер прибрав відмови при піковому навантаженні
Один інстанс Redis тримав і кеш, і черги задач, і сесії користувачів. На піку — розпродаж, масова розсилка, ранковий вхід у застосунок — потік операцій зростав утричі, вузол упирався в стелю, і разом з ним ставали сценарії, які до кешу стосунку не мають. Для клієнта це виглядало не як «повільно», а як «не працює».
Розбір показав три вузькі місця: пам'ять під дані з фрагментацією, обробка команд на одному ядрі та повна відсутність реплік. Запасного вузла не було — при виході процесу сервіс не піднімався сам, черговий робив це вручну.
Що змінили
Розгорнули кластер з кількох основних вузлів з репліками, розклали ключі за слотами і винесли черги на окрему групу вузлів, щоб важкі операції не витісняли користувацькі сесії.
Клієнтські бібліотеки перевели в режим роботи за топологією кластера: при зміні основного вузла з'єднання перебудовується без правок у застосунку.
Метрики до і після
- Частка відмов при піковому навантаженні: 12% запитів до нуля — недоступних операцій на піку не залишилося.
- Час відновлення після виходу вузла: ручні 30-40 хвилин до автоматичного підйому репліки і перемикання за секунди.
- Стеля за операціями: єдиний вузол перестав бути обмежувачем — додавання вузла збільшує пропускну здатність кратно.
- Поведінка сервісу при втраті вузла: замість повної відмови — коротка деградація і перечитування частини ключів з бази.
Що робити, якщо застосунок уже працює з одиночним сервером?
Одиночний сервер упирається не у відмови, а в стелю: робочий набір займає пам'ять, репліка рятує від падіння, але не дає місця під зростання. Поки запас є, перехід відкладають, а коли він закінчується — переносять у поспіху, в найневдаліший момент. Тому міграцію планують заздалегідь і проводять без зупинки сервісу.
Спочатку інвентаризація: які ключі живуть довго, де операції зачіпають кілька ключів одразу, які структури не можна рознести по вузлах. Мультиключові команди і скрипти потребують, щоб пов'язані ключі лежали на одному вузлі, — інакше їх переписують на спільні хеш-теги. Це єдина частина переходу, яка справді потребує правок у коді застосунку.
Дані переносимо у фоні: знімаємо дамп з одиночного сервера, заливаємо його в кластер, розкладаючи ключі за діапазонами слотів. Далі вмикаємо подвійний запис — застосунок пише і в старий інстанс, і в кластер, а читає поки зі старого. Перенесення йде на живій системі, а розбіжність копій не перевищує затримки однієї операції.
Цілісність перевіряємо звіркою ключів і значень за вибіркою, потім пускаємо тіньовий потік читання на кластер і зіставляємо відповіді з одиночним сервером.
Поки розбіжності є, перемикання не робимо: зворотна сумісність клієнтів забезпечена — вони вже вміють слідувати перенаправленням між вузлами, але працюють за старою адресою.
План відкату — прапорець у конфігурації: він повертає читання на одиночний сервер, який залишається прогрітим і отримує всі записи.
Якщо після перемикання зростає частка помилок або час відповіді, прапорець знімається за секунди, і сервіс продовжує працювати на попередньому контурі.
Технічні сумніви: відмова вузлів, переїзд і сумісність
Перед передачею кластера розбираємо те, що найчастіше спливає на прийманні: поведінку при втраті вузла, обсяг правок у застосунку, вимоги до мережі і що залишається на нашій стороні після здачі.
Що станеться при втраті вузла?
На кожен майстер налаштовано репліку, і слоти переназначаються автоматично за секунди: клієнт отримує перенаправлення і повторює запит. Дані зберігаються, якщо репліка встигла синхронізуватися, тому вузли розводимо по різних зонах відмови.
Чи доведеться правити код?
Актуальні драйвери працюють з кластером, тому правки в коді зводяться до конфігурації: список вузлів замість однієї адреси, режим кластера, таймаути та повтори.
Окремо перевіряємо операції одразу за кількома ключами — поза одним слотом вони не проходять, такі місця переводимо на хеш-теги.
Які вимоги до мережі?
Вузлам потрібна пряма зв'язність за службовим портом і рівна затримка: обмін станом іде постійно, і втрати пакетів спричиняють хибні вибори майстра. Фіксуємо статичні адреси, виключаємо трансляцію між вузлами, пороги перевірки здоров'я ставимо із запасом.
Що входить в обслуговування після передачі?
Віддаємо конфігурацію, карту слотів і регламент типових операцій: додавання вузла, плановий переїзд, відновлення з копії, оновлення по одній репліці. Інженери замовника проганяють сценарії на стенді разом з нами, тому далі розширення йде власними силами.
Обговорімо задачу: що потрібно для старту та оцінки
Оцінка проєкту з розгортання Redis Cluster займає тим менше часу, чим точніші вхідні дані. Нижче — те, що потрібно від вас, щоб ми повернулися з планом робіт і строками, а не з уточнювальними питаннями через тиждень.
- Профіль навантаження: операцій за секунду на піку і в середньому, частка читання і запису, типовий розмір значення — від цього залежить кількість вузлів і запас за пам'яттю.
- Поточна схема: одиночний екземпляр, майстер з репліками чи вже кластер, які застосунки та клієнтські бібліотеки до нього підключені.
- Очікуване зростання: як навантаження й обсяг даних зміняться за пів року — закладаємо запас, щоб не перебудовувати конфігурацію одразу після запуску.
- Вікно обслуговування: коли допустима коротка перерва в записі, а коли перехід має пройти непомітно для користувачів.
- Вимоги до відновлення: допустимий час простою при відмові вузла і допустима втрата останніх записів.
- Інфраструктура та доступи: скільки машин доступно, чи є розподіл за зонами, хто з боку замовника приймає зміни і які права потрібні нашим інженерам.
У відповідь ви отримуєте план робіт за етапами, схему розміщення вузлів з правилами відмовостійкості та сценарій переходу, прив'язаний до вашого вікна обслуговування.
Чим раніше узгоджені вікно і вимоги до відновлення, тим нижчий ризик, що перенесення даних доведеться планувати двічі.
