Федеральная торговая сеть развивает свой интернет-магазин и расширяет набор сервисов для покупателей: совершенствует каталоги на нескольких сайтах, добавляет варианты оплаты и доставки. Для оценки эффективности этих мер интернет-магазин подключен к CRM. Часть данных с сайтов хранится в этой системе, что помогает отслеживать путь покупателя, его удовлетворенность.
В качестве основной СУБД для сайтов и системы выбран Microsoft SQL Server. Надежность работы баз данных обеспечивает отказоустойчивая схема Always on: одна группа доступности из двух баз предназначена для интернет-магазина, вторая группа доступности — для CRM-системы. Все четыре базы данных размещаются в облаке DataLine.
В какой-то момент заказчик заметил рост базы данных и снижение производительности Microsoft SQL Server, это приводило к частой кратковременной недоступности CRM. Специалисты компании-заказчика обратились в DataLine для решения проблемы.
“Потушить пожар” и обеспечить доступность системы. CRM играет важную роль в обслуживании покупателей, поэтому в первую очередь было необходимо быстро восстановить ее работу.
Найти первопричину проблем с производительностью. Сотрудники заказчика развивали свои системы с привлечением сторонней компании-разработчика: ее специалисты помогали реализовать сложную бизнес-логику. Нужно было выяснить, на каком уровне находится проблема, и при необходимости скооперироваться со специалистами компании-подрядчика.
Улучшить производительность с учетом разумного бюджета. Заказчик не хотел просто увеличивать ресурсы по схеме вертикального масштабирования и переплачивать за вычислительные мощности и лицензии. Было важно найти “узкое место” в системе и не допустить появления подобных проблем в дальнейшем.
Аудит баз данных разделили на 2 этапа: сначала быстрый поиск ресурсов для восстановления CRM, потом — глубокий анализ и устранение скрытых долгосрочных проблем.
На быстром этапе администраторы DataLine заметили, что увеличилось число обращений к базе данных со стороны сайтов и CRM. При этом физических ресурсов для их обработки не хватало: все 4 базы находились на одном узле, он работал на пределе возможностей.
Поскольку второй узел использовался только в качестве резерва на случай недоступности первого, его ресурсы можно было привлечь для быстрого решения проблемы.
Чтобы разгрузить систему, специалисты DataLine организовали перекрестную отказоустойчивость по схеме Active-Standby. Две базы CRM оставили на первом узле в роли главных, второй узел указали в качестве запасного. Базы данных интернет-магазина, наоборот, перенесли на второй узел в роли главных, а первый узел остался для них запасным.
Таким образом администраторы разграничили ресурсы CPU и памяти для этих баз и вернули CRM к работе. Вместе с тем одна эта схема не помогла бы решить проблему производительности в долгосрочной перспективе. Нужно было найти фундаментальную причину недоступности системы.
При дальнейшем аудите специалисты обнаружили, что сильнее всего в базе CRM росли три таблицы. В них выборки данных работали нестабильно: отсутствовали индексы, которые нужны для выполнения некоторых запросов. В результате эти запросы выполнялись медленно — до 30 секунд.
Администраторы DataLine обратились к разработчикам со стороны заказчика, чтобы понять бизнес-логику запросов. Оказалось, что в трех таблицах ведется журнал действий с CRM, который нужен для регулярного аудита ИБ. С его помощью специалисты по безопасности делали выборку данных за период, проверяли работу с ценной информацией в CRM, предотвращали утечки и расследовали инциденты.
Но при создании решения для ИБ разработчик не учел, что одновременно с логированием в этой же базе ведется интенсивная вставка данных со стороны сайтов. Команда разработки интернет-магазина отправляла в базу CRM все регистрации новых пользователей. Получался конфликт между выборкой и вставкой:
- если в таблицах не хватает индексов для выборки данных в журнал ИБ, то запросы по аудиту замедляют работу базы;
- если же добавить все необходимые индексы, будет замедляться вставка данных с сайтов: каждая новая запись будет добавляться в нужный индекс, это тоже тратит ресурсы.
Вдобавок ко всему интенсивный рост таблиц аудита не позволял уложиться в сайзинг. За 40 дней база данных выросла с 500 гигабайт до более терабайта. С таким трендом роста каждые 20 дней необходимо добавлять порядка 250 гигабайт места на диске.
Архитекторы DataLine предложили заказчику разделить таблицы для аудитов ИБ на “быстрые” оперативные и “медленные” архивные:
- из быстрой таблицы с интенсивной вставкой нужно было перенести все индексы в медленную таблицу;
- затем команде разработки было необходимо выбрать технологическое окно и настроить регулярный перенос данных из быстрой таблицы в медленную.
Если каждый вечер накопленные за день данные переносятся в архив, то в быстрой таблице остается небольшой набор данных. Это позволяет ИБ-специалистам делать оперативные выборки по быстрой таблице даже без индексов. Для архивных выборок с большим диапазоном дат используется медленная таблица с индексами.
Вместе со специалистами заказчика и компании-подрядчика определились с ролями:
- архитекторы DataLine помогали с очисткой быстрых таблиц и продумывали план восстановления баз данных на случай аварий (DR);
- специалисты компании-разработчика отвечали за логику работы и подключались к написанию DR-плана.
С заказчиком согласовали технологическое окно c 2 ночи до утра, когда перенос данных не повлияет на производительность CRM. Для очистки быстрых таблиц администраторы DataLine запустили тестовое аварийное восстановление базы и удалили индексы из восстановленной реплики БД. Это позволило очистить таблицу без риска для боевой базы и заодно протестировать механизм восстановления для DR-плана.
Затем разработчики компании-подрядчика написали ETL-процесс для ежедневного переноса данных из быстрой таблицы в медленную. После тестирования всей схемы целиком команда была готова перенести данные на боевую площадку.
Оперативную базу разместили на SSD-дисках, а медленную базу с индексами перенесли на SAS-диски. Это позволило немного сэкономить на той части базы, где высокая скорость не так критична.
Специалисты по ИБ в любой момент могут получить из базы информацию для аудита. Их действия не влияют на работу менеджеров с CRM и не замедляют регистрацию пользователей на сайтах.
Наиболее тяжелые таблицы ежедневно переносятся в архив на случай масштабных аудитов.
Для объемных таблиц с архивом используются медленные и недорогие SAS-диски. При этом основная база с интенсивной нагрузкой остается на быстрых дисках.