Чому п’ять серверів не справлялися з навантаженням: як ми перебудували архітектуру баз даних
Як ми усунули перевантаження Galera Cluster: 8 ВМ на Proxmox, реплікація MySQL і кешування SELECT через ProxySQL без придбання нових серверів.
Технології: Galera Cluster, MySQL, Proxmox VE, ProxySQL, Cloudflare
Проблема: високе навантаження на Galera Cluster
Проєкт працював на п’яти фізичних серверах із Galera Cluster. Коли боти активно збирали опубліковану інформацію, кількість звернень до бази різко зростала. У такі періоди база переставала справлятися, і сервіс давав збої.
Ресурси вже були розподілені між кількома серверами, проте схема обробки запитів не витримувала характерного для проєкту навантаження. Потрібно було з’ясувати, яку роботу система повторює і де її можна скоротити.
Чому не можна було просто заблокувати ботів?
Обмеження трафіку через Cloudflare здавалося швидким способом розвантажити базу. На практиці разом з автоматизованими зверненнями обмеження зачіпали й реальних відвідувачів: у частини користувачів виникали проблеми з доступом до сайту.
Нам потрібно було зберегти доступність сервісу та продовжити обслуговувати цей трафік. Тому роботу перенесли всередину інфраструктури — до маршрутизації запитів, реплікації та кешування результатів.
Аналіз: чому масштабування не розв’язувало проблему
Аналіз показав, що додавання серверів не усувало причину перевантаження. Автоматизовані системи багато разів запитували ту саму інформацію, змушуючи базу знову виконувати схожу роботу з читання даних.
Ми вирішили інакше використати наявне обладнання. Частину даних і клієнтські запити на читання можна було обслуговувати окремо, а результати повторюваних SELECT-запитів — віддавати з кешу. Це стало основою нової архітектури.
Рішення: віртуалізація, реплікація та кешування
Із п’яти фізичних серверів два вивели з початкового кластера та виділили під віртуалізовану інфраструктуру. Решта три залишилися в основному кластері. Нових фізичних серверів для цього рішення не купували.
Схема за матеріалами кейсу. Це ілюстрація архітектури, а не тест продуктивності.
1. Розгортання віртуальної інфраструктури на Proxmox VE
На двох виділених вузлах установили Proxmox VE та створили по чотири віртуальні машини на кожному. На першому розмістили чотири незалежні бази з даними, які найчастіше запитували автоматизовані системи. На другому розгорнули їхні репліки.
Загалом отримали вісім ВМ і чотири пари «база — репліка», причому учасники кожної пари перебували на різних фізичних серверах. Обмін даними між ними організували локальною мережею.
2. Розділення операцій запису та читання
Застосунок записував зміни в бази на першому вузлі. Механізм реплікації передавав ці зміни відповідним екземплярам на другому, а клієнтські звернення отримали доступ лише на читання.
Так ми розділили зміну даних і потік запитів, пов’язаний зі збиранням інформації. Інтенсивне читання почали обслуговувати окремі екземпляри баз, розподіляючи роботу між ними.
3. Кешування SELECT-запитів через ProxySQL
Перед базами налаштували ProxySQL із кешуванням SELECT-запитів. Якщо результат відповідного повторного запиту вже був у кеші, його можна було повернути без нового звернення до сервера бази даних. Для ботів, які багато разів запитували однакову інформацію, це змінювало шлях обробки.
У результаті частина повторного читання перестала доходити до баз. Автоматизовані звернення продовжували обслуговуватися, а обмежувати їх через Cloudflare більше не було потреби.
Результат: стабільна робота без додаткового обладнання
Після зміни архітектури попереднє перевантаження перестало спричиняти збої бази даних. Повторювані запити обслуговувалися через кеш, операції запису й читання були розділені, а користувачі зберегли доступ до сайту без додаткових обмежень Cloudflare.
Рішення залишилося в межах початкового парку: три сервери в основному кластері та два вузли Proxmox із вісьмома ВМ. Ефект отримали завдяки перерозподілу навантаження та скороченню повторної роботи.
- 8 віртуальних машин на 2 наявних вузлах
- 4 пари «база даних / репліка»
- Повторні SELECT-запити обслуговуються з кешу
Схема за матеріалами кейсу. Це ілюстрація архітектури, а не тест продуктивності.
Висновок: правильна архітектура важливіша за кількість серверів
У цьому проєкті п’яти серверів виявилося достатньо після перегляду обробки даних. Віртуалізація дала окремі екземпляри баз, реплікація розділила їхні ролі, а ProxySQL скоротив кількість повторних запитів до них. Разом ці зміни усунули вузьке місце попередньої конфігурації.
За схожих симптомів корисно починати з характеру запитів і схеми доступу. Лише після цього стає зрозуміло, чи потрібні нові ресурси, чи наявні можна використати ефективніше.
Маєте проблеми з продуктивністю серверів або баз даних?
Якщо база перевантажується, а додавання ресурсів дає дедалі менший ефект, розберемо запити та інфраструктуру. Перевіримо, де повторюється робота і чи можна розділити читання, запис та кешування. За результатами запропонуємо зміни під навантаження вашого проєкту.