Почему пять серверов не справлялись с нагрузкой: как мы перестроили архитектуру баз данных
Как мы устранили перегрузку 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 сократил число повторных запросов к ним. Эти изменения вместе устранили узкое место, которое сохранялось в прежней конфигурации.
При похожих симптомах полезно начинать с характера запросов и схемы доступа. Только после этого становится понятно, нужны ли новые ресурсы или существующие можно использовать эффективнее.
Испытываете проблемы с производительностью серверов или баз данных?
Если база перегружается, а добавление ресурсов даёт всё меньший эффект, разберём запросы и устройство инфраструктуры. Проверим, где повторяется работа и можно ли разделить чтение, запись и кеширование. По результатам предложим изменения под нагрузку вашего проекта.