Чому п’ять серверів не справлялися з навантаженням: як ми перебудували архітектуру баз даних

Категорія: Database Optimization / Infrastructure / High Load

Технології: Galera Cluster, MySQL, Proxmox VE, ProxySQL, Database Replication, Cloudflare

Автоматизовані боти створювали навантаження, з яким не міг упоратися навіть кластер із п’яти фізичних серверів. Обмежувати трафік через Cloudflare було не можна, оскільки це спричиняло проблеми з доступом для реальних користувачів. Розповідаємо, як ми змінили архітектуру баз даних, упровадили реплікацію та кешування запитів і усунули причину регулярних збоїв без придбання додаткового обладнання.

Проблема: високе навантаження на Galera Cluster

Інфраструктура проєкту складалася з п’яти фізичних серверів із Galera Cluster. Така конфігурація забезпечувала розподілену роботу бази даних, проте з часом проєкт зіткнувся із серйозною проблемою — нестабільністю за інтенсивного автоматизованого трафіку.

Сайт регулярно відвідували боти, які збирали й обробляли опубліковану інформацію. Їхня активність супроводжувалася великою кількістю запитів до бази даних, створюючи значне навантаження на інфраструктуру.

У періоди особливо інтенсивного парсингу база даних переставала справлятися з кількістю звернень, що призводило до збоїв у роботі сервісу.

Чому не можна було просто заблокувати ботів?

Одним з очевидних рішень було обмеження автоматизованого трафіку на рівні Cloudflare.

Однак на практиці такий підхід створював додаткові проблеми. Після запровадження обмежень частина реальних користувачів мала труднощі з доступом до сайту.

Фактично доводилося обирати між зниженням навантаження на інфраструктуру та доступністю сервісу для клієнтів.

Для нас такий компроміс був неприйнятним.

Завдання полягало в тому, щоб забезпечити стабільну роботу бази даних, не обмежуючи доступ користувачів і не блокуючи автоматизовані звернення.

Аналіз: чому масштабування не розв’язувало проблему

Початкова архітектура включала п’ять фізичних серверів, які працювали у складі Galera Cluster.

Під час аналізу ми виявили, що збільшення кількості серверів не давало очікуваного ефекту. Попри розподіл навантаження, інтенсивні запити й далі суттєво навантажували підсистему баз даних.

Проблема полягала не лише в доступних обчислювальних ресурсах, а й у характері звернень до даних.

Автоматизовані системи багаторазово запитували інформацію, для якої не потрібно було щоразу виконувати ті самі операції читання безпосередньо в базі даних.

Це означало, що просте додавання серверів не усувало основної причини перевантаження.

Ми вирішили відмовитися від подальшого нарощування ресурсів і змінити саму архітектуру обробки запитів.

Рішення: віртуалізація, реплікація та кешування

Замість придбання додаткового обладнання ми перерозподілили наявні ресурси інфраструктури.

Із п’яти фізичних серверів два вивели з початкового кластера та перепрофілювали для розміщення окремих баз даних.

1. Розгортання віртуальної інфраструктури на Proxmox VE

На двох виділених фізичних серверах установили гіпервізор Proxmox VE.

На кожному сервері створили по чотири віртуальні машини — загалом вісім віртуальних машин для роботи з базами даних.

На першому фізичному сервері розмістили чотири незалежні бази даних з інформацією, до якої найактивніше зверталися автоматизовані системи.

На другому фізичному сервері розгорнули відповідні репліки цих баз даних.

Таким чином, кожна з чотирьох баз отримала окрему репліку на іншому фізичному сервері.

Взаємодію між екземплярами баз даних організували через локальну мережу.

2. Розділення операцій запису та читання

Наступним етапом стало розділення операцій запису та читання.

Застосунок записував дані в бази на першому фізичному сервері. Зміни передавалися до відповідних реплік другого сервера за допомогою механізму реплікації.

Для клієнтських звернень передбачили доступ лише на читання.

Це дозволило відокремити операції зміни даних від інтенсивного потоку запитів, що виникав під час автоматизованого збору інформації.

У результаті навантаження розподілялося між окремими екземплярами баз даних, а операції запису були відокремлені від основного потоку клієнтських запитів на рівні доступу.

3. Кешування SELECT-запитів через ProxySQL

Ключовим елементом нової архітектури стало впровадження ProxySQL.

Ми налаштували кешування SELECT-запитів, щоб зменшити кількість повторних звернень безпосередньо до баз даних.

У разі повторного виконання відповідного запиту ProxySQL міг повертати результат із кешу, не передаючи запит серверу бази даних.

Це особливо важливо для проєктів, які регулярно відвідують автоматизовані системи: боти можуть багаторазово запитувати однакову інформацію, навіть якщо самі дані не змінилися.

Завдяки кешуванню значна частина повторюваних запитів перестала створювати додаткове навантаження на сервери баз даних.

Водночас автоматизований трафік і далі обслуговувався, а потреба запроваджувати обмеження через Cloudflare відпала.

Результат: стабільна робота без додаткового обладнання

Після впровадження нової архітектури вдалося усунути перевантаження баз даних, яке раніше призводило до збоїв у роботі проєкту.

Основні результати:

• Зниження навантаження на бази даних. Повторювані SELECT-запити почали обслуговуватися з використанням кешу ProxySQL.
• Стабільна робота сервісу. Після зміни архітектури повторних збоїв бази даних, пов’язаних із попереднім перевантаженням, не спостерігалося.
• Збереження доступності для користувачів. Не довелося обмежувати автоматизований трафік через Cloudflare, зачіпаючи реальних відвідувачів.
• Розділення операцій. Запис даних і клієнтські запити на читання отримали окремі механізми обробки.
• Оптимізація наявних ресурсів. Рішення реалізували на наявному обладнанні без придбання додаткових фізичних серверів.

Замість подальшого збільшення потужності інфраструктури ми змінили підхід до зберігання та обробки даних.

П’ять фізичних серверів початкової конфігурації перерозподілили: три залишилися в основному кластері, а два стали основою окремої віртуалізованої інфраструктури з чотирма парами реплікованих баз даних.

Такий підхід дозволив усунути попередні вузькі місця й забезпечити стабільну обробку запитів.

Висновок: правильна архітектура важливіша за кількість серверів

Цей проєкт став прикладом того, що високе навантаження не завжди потребує придбання потужнішого обладнання.

Навіть розподілена інфраструктура може мати проблеми з продуктивністю, якщо під час проєктування архітектури не враховано характер запитів.

У нашому випадку поєднання віртуалізації, реплікації та кешування дозволило розв’язати проблему на рівні організації роботи з даними.

Головним результатом стало ефективніше використання наявних ресурсів, а не збільшення кількості серверів.

Маєте проблеми з продуктивністю серверів або баз даних?

Високе навантаження, повільні запити та нестабільна робота застосунків не завжди означають, що вашій інфраструктурі бракує потужності.

Іноді достатньо знайти вузьке місце та правильно перерозподілити навантаження.

Команда inSave Hosting допомагає діагностувати проблеми продуктивності, оптимізувати бази даних і проєктувати серверну інфраструктуру з урахуванням реальних потреб проєкту.

Зв’яжіться з нами, щоб обговорити ваше завдання та знайти оптимальне технічне рішення.