За 1,5 месяца оптимизировали архитектуру инфраструктуры и стабилизировали работу e-commerce сервиса Divan.ru
Контекст
Divan.ru – российская компания, специализирующаяся на производстве и продаже мягкой и корпусной мебели, а также предметов интерьера. Компания столкнулась с нестабильностью работы сервиса, особенно при высоких нагрузках (например, в вечернее время и выходные), что напрямую влияло на продажи. Проблемы возникли из-за наслоения разных архитектурных решений после смены команды разработки, отсутствия документации и неоптимального взаимодействия между бэкендом и базой данных.
Задача
Провести аудит архитектуры инфраструктуры сервиса, выявить корневые причины нестабильности при пиковых нагрузках и предложить решения для их устранения и стабилизации работы.
Столкнулись с похожей задачей? Поможем решить.
Трудности
– Сервис работал нестабильно из-за некорректного взаимодействия бэкенда с системой управления базами данных (СУБД), а также избыточной конфигурации инфраструктуры. Зависающие запросы и неоптимальное количество нод снижали производительность.
– Наличие технического долга и отсутствие документации усложняло анализ и внедрение изменений.
– Тестирование приходилось проводить непосредственно на продакшн-среде, что увеличивало риски.
– Ограничение бюджета и сроков. Необходимо было провести аудит в сжатые сроки, а также уложиться в бюджет, предоставив требуемый результат.
Решения
– За 1,5 месяца выполнили комплексный аудит архитектуры инфраструктуры сервиса. К проекту подключились DevOps-инженер, бэкенд-разработчик и архитектор, которые тесно взаимодействовали с технической командой клиента.
– Организовали серию рабочих сессий с командой клиента, в ходе которых изучили особенности реализации бизнес-логики и выявили проблемные места в коде, приводящие к некорректным запросам к БД.
– Провели детальный анализ работы PostgreSQL-кластера, взаимодействия бэкенда с базой данных, механизмов балансировки нагрузки и мониторинга. Получили полный доступ к продакшн-среде, что позволило точно диагностировать причины нестабильности системы. Клиент предполагал, что проблема связана только с системой управления базами данных (PostgreSQL), но в ходе аудита выяснилось, что ключевая проблема – некорректное взаимодействие бэкенда с БД.
– По результатам аудита сформировали модель текущего состояния системы с выделением ключевых узких мест: бэкенд перегружал базу повторными запросами, Соединения не закрывались и накапливались, кластер из 8 нод был избыточным и неэффективным, при этом взаимодействие компонентов кластера было не настроено должным образом.
– Сократили число серверов в кластере PostgreSQL до оптимального. Это снизило нагрузку на инфраструктуру, упростило сопровождение и повысило надёжность базы данных.
– Совместно с командой клиента перенастроили конфигурации СУБД и внесли улучшения во взаимодействии с бэкендом, после чего сервис стал работать устойчиво, а работа функций стабилизировалась.
– Скорректировали параметры взаимодействия между серверами и кластерными решениями. Это обеспечило стабильную работу кластера и корректное распределение нагрузки.
– Организовали мониторинг и балансировку нагрузки для предотвращения перегрузок.
– Предоставили клиенту решения по оптимизации и масштабированию системы, которые не только подготовили сервис к дальнейшему росту, но и снизили затраты на поддержку инфраструктуры. Разработали целевую архитектуру с рекомендациями по переходу на микросервисы, автоматическому масштабированию и оптимизации CI/CD-процессов. Предложили реконфигурацию кластера PostgreSQL, оптимизацию запросов к БД, а также внедрение мониторинга и балансировки нагрузки. Учли географическое распределение пользователей (Беларусь, Узбекистан, Таджикистан), спроектировав архитектуру для стабильной работы в разных регионах. Подготовили поэтапный план модернизации, чтобы минимизировать сбои при внедрении.
Заинтересовало?
Оставьте контакты, чтобы обсудить решение вашей задачи
Проект
С 2015 года
на рынке
86
фирменных шоурумов
1500+
сотрудников
