Как мы помогли ритейлеру выяснить причину недоступности CRM и восстановили работу системы

Мы провели аудит базы данных и нашли противоречия в работе тех элементов, за которые отвечают разные команды. Новое решение устранило конфликт и восстановило быструю работу.

Как мы помогли ритейлеру выяснить причину недоступности CRM и восстановили работу системы

Задача

Федеральная торговая сеть развивает свой интернет-магазин и расширяет набор сервисов для покупателей: совершенствует каталоги на нескольких сайтах, добавляет варианты оплаты и доставки. Для оценки эффективности этих мер интернет-магазин подключен к CRM. Часть данных с сайтов хранится в этой системе, что помогает отслеживать путь покупателя, его удовлетворенность.

В качестве основной СУБД для сайтов и системы выбран Microsoft SQL Server. Надежность работы баз данных обеспечивает отказоустойчивая схема Always on: одна группа доступности из двух баз предназначена для интернет-магазина, вторая группа доступности — для CRM-системы. Все четыре базы данных размещаются в облаке DataLine. 

В какой-то момент заказчик заметил рост базы данных и снижение производительности Microsoft SQL Server, это приводило к частой кратковременной недоступности CRM. Специалисты компании-заказчика обратились в DataLine для решения проблемы.

Что нужно было сделать
  • “Потушить пожар” и обеспечить доступность системы. CRM играет важную роль в обслуживании покупателей, поэтому в первую очередь было необходимо быстро восстановить ее работу.

  • Найти первопричину проблем с производительностью. Сотрудники заказчика развивали свои системы с привлечением сторонней компании-разработчика: ее специалисты помогали реализовать сложную бизнес-логику. Нужно было выяснить, на каком уровне находится проблема, и при необходимости скооперироваться со специалистами компании-подрядчика.

  • Улучшить производительность с учетом разумного бюджета. Заказчик не хотел просто увеличивать ресурсы по схеме вертикального масштабирования и переплачивать за вычислительные мощности и лицензии. Было важно найти “узкое место” в системе и не допустить появления подобных проблем в дальнейшем.

Как решили задачу
Провели экспресс-аудит

Аудит баз данных разделили на 2 этапа: сначала быстрый поиск ресурсов для восстановления CRM, потом — глубокий анализ и устранение скрытых долгосрочных проблем. 

На быстром этапе администраторы DataLine заметили, что увеличилось число обращений к базе данных со стороны сайтов и CRM. При этом физических ресурсов для их обработки не хватало: все 4 базы находились на одном узле, он работал на пределе возможностей. 

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

Разграничили ресурсы для CRM и сайтов

Чтобы разгрузить систему, специалисты DataLine организовали перекрестную отказоустойчивость по схеме Active-Standby. Две базы CRM оставили на первом узле в роли главных, второй узел указали в качестве запасного. Базы данных интернет-магазина, наоборот, перенесли на второй узел в роли главных, а первый узел остался для них запасным.  

Таким образом администраторы разграничили ресурсы CPU и памяти для этих баз и вернули CRM к работе. Вместе с тем одна эта схема не помогла бы решить проблему производительности в долгосрочной перспективе. Нужно было найти фундаментальную причину недоступности системы.

Продолжили анализ на уровне запросов

При дальнейшем аудите специалисты обнаружили, что сильнее всего в базе CRM росли три таблицы. В них выборки данных работали нестабильно: отсутствовали индексы, которые нужны для выполнения некоторых запросов.  В результате эти запросы выполнялись медленно — до 30 секунд.  

Администраторы DataLine обратились к разработчикам со стороны заказчика, чтобы понять бизнес-логику запросов. Оказалось, что в трех таблицах ведется журнал действий с CRM, который нужен для регулярного аудита ИБ. С его помощью специалисты по безопасности делали выборку данных за период, проверяли работу с ценной информацией в CRM, предотвращали утечки и расследовали инциденты.

Но при создании решения для ИБ разработчик не учел, что одновременно с логированием в этой же базе ведется интенсивная вставка данных со стороны сайтов. Команда разработки интернет-магазина отправляла в базу CRM все регистрации новых пользователей. Получался конфликт между выборкой и вставкой: 

  • если в таблицах не хватает индексов для выборки данных в журнал ИБ, то запросы по аудиту замедляют работу базы;
  • если же добавить все необходимые индексы, будет замедляться вставка данных с сайтов: каждая новая запись будет добавляться в нужный индекс, это тоже тратит ресурсы.

Вдобавок ко всему интенсивный рост таблиц аудита не позволял уложиться в сайзинг. За 40 дней база данных выросла с 500 гигабайт до более терабайта. С таким трендом роста каждые 20 дней необходимо добавлять порядка 250 гигабайт места на диске.

Обратились к лучшим практикам работы с базами

Архитекторы DataLine предложили заказчику разделить таблицы для аудитов ИБ на “быстрые” оперативные и “медленные” архивные: 

  • из быстрой таблицы с интенсивной вставкой нужно было перенести все индексы в медленную таблицу; 
  • затем команде разработки было необходимо выбрать технологическое окно и настроить регулярный перенос данных из быстрой таблицы в медленную. 

Если каждый вечер накопленные за день данные переносятся в архив, то в быстрой таблице остается небольшой набор данных. Это позволяет ИБ-специалистам делать оперативные выборки по быстрой таблице даже без индексов. Для архивных выборок с большим диапазоном дат используется медленная таблица с индексами.

Реализовали новую схему и продумали DR-план

Вместе со специалистами заказчика и компании-подрядчика определились с ролями: 

  • архитекторы DataLine помогали с очисткой быстрых таблиц и продумывали план восстановления баз данных на случай аварий (DR);
  • специалисты компании-разработчика отвечали за логику работы и подключались к написанию DR-плана.

С заказчиком согласовали технологическое окно c 2 ночи до утра, когда перенос данных не повлияет на производительность CRM. Для очистки быстрых таблиц администраторы DataLine запустили тестовое аварийное восстановление базы и удалили индексы из восстановленной реплики БД. Это позволило очистить таблицу без риска для боевой базы и заодно протестировать механизм восстановления для DR-плана. 

Затем разработчики компании-подрядчика написали  ETL-процесс для ежедневного переноса данных из быстрой таблицы в медленную. После тестирования всей схемы целиком команда была готова перенести данные на боевую площадку. 

Оперативную базу разместили на SSD-дисках, а медленную базу с индексами перенесли на SAS-диски. Это позволило немного сэкономить на той части базы, где высокая скорость не так критична. 

Что получил клиент
СRM работает быстрее и стабильнее

Специалисты по ИБ в любой момент могут получить из базы информацию для аудита. Их действия не влияют на работу менеджеров с CRM и не замедляют регистрацию пользователей на сайтах.

Продуктивная база растет медленнее

Наиболее тяжелые таблицы ежедневно переносятся в архив на случай масштабных аудитов.

Не нужно платить в 2 раза больше за дисковое пространство

Для объемных таблиц с архивом используются медленные и недорогие SAS-диски. При этом основная база с интенсивной нагрузкой остается на быстрых дисках.

Запрос консультации по услуге "Базы данных в облаке (DBaaS)"

Есть похожая задача? Хотите попробовать услугу "Базы данных в облаке (DBaaS)"?

Оставьте заявку — мы свяжемся и обсудим, чем можем вам помочь

Базы данных в облаке (DBaaS)
  • Аутсорсинг вопросов по администрированию СУБД, ОС, физической и виртуальной инфраструктуры.
  • Гарантированная доступность сервиса по SLA: 99,96 % для одиночного и 99,98 % для кластерного решения.
  • В услугу включено резервное копирование с регулярной проверкой восстановления копий.
  • Возможность размещения БД в облаке, аттестованном по 152-ФЗ.

Другие кейсы

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

Хранение данных

В рамках сервиса DBaaS помогли клиенту ускорить базу данных на MS SQL Server и оптимизировали потребляемые ресурсы.

Хранение данных

За счет открытого API создатели VR для клиник быстро перенесли хранение медицинских данных в аттестованное облако DataLine и выполнили требования 152-ФЗ. 

Работа с персональными данными (152-ФЗ), Хранение данных