Почему пять серверов не справлялись с нагрузкой: как мы перестроили архитектуру баз данных

Категория: 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 помогает диагностировать проблемы производительности, оптимизировать базы данных и проектировать серверную инфраструктуру с учётом реальных потребностей проекта.

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