Всем привет! В данной статье я расскажу о том, как наша компания смогла сэкономить за счет внедрения Azure SQL Elastic Pool. Дополнительно будут примеры Azure REST API для энумерации SQL Servers, для энумерации SQL databases и для получения метрик.
Самые пытливые в конце статьи узнают сэкономленную величину. Те же кому лень читать могут сразу посмотреть исходники
Azure SQL Elastic Pool
Продублирую ссылку на замечательную документацию от Microsoft. Если вкратце - за счет чего мы можем сэкономить? - за счет объединения нескольких баз в один пул - при этом ресурсы пула базы будут тратить сообща.
Если посмотреть расценки, то увидим, что ресурсы для пула eDTU стоят дороже, чем ресурсы для одиночной базы DTU (например 100 DTU обойдутся в 147 долларов в месяц, а 100 eDTU уже в 220). Отсюда следует простой вывод - если у вас есть база с более-менее равномерной нагрузкой - то, нет смысла добавлять ее в пул. И наоборот - если есть куча баз, с неравномерной нагрузкой и пиками разнесенными по времени - то они идеально подойдут для объединения в пул.
Встает вопрос - а как же узнать суммарную нагрузку для всех баз с одного сервера? В портале, в данный момент времени можно посмотреть график DTU для одной базы - но, к сожалению, отсутствует возможность посмотреть на суммарный график, который нам так нужен. Зовем на помощь Azure REST API.
Энумерация и получение метрик
Для работы с Azure нам потребуются следующие параметры. Сначала напишем код для получения токена. Затем получим для нашей подписки все сервера. После этого для нужного нам сервера получим список баз. Также напишем код для получения метрик.
Добавим логику, которая будет сохранять метрики за последние несколько дней на диск в форме, удобной для последующей визуализации.
Внимание: В нашем случае все базы используют DTU Purchase Model, именно поэтому здесь вычитывается метрика dtu_used. Если вы используете для баз данных vCore Purchase Model, то для оценки нагрузки потребуются другие метрики (например cpu_percent). Список доступных метрик для разных ресурсов Azure можно посмотреть здесь. Данный метод более-менее универсальный - для других ресурсов, метрик также должен подойти.
Визуализация даных в Power BI
Реализуется просто. Открываем в Power BI данный шаблон. Скармливаем ему json полученный на предыдущем шаге и получаем графики такого вида (на картинке сервер с ~90 базами). На верхней картинке показано среднее по среднему за час, на нижнем среднее по максимуму за час. Для максимально точных результатов при вычитке метрик я использовал минимальный интервал в одну минуту (соответсвенно, каждое среднее за час считается по 60 значениям)
По графикам мы видим, что нагрузка данного типа отлично подходит для пула - много слабонагруженных баз с нечастыми пиками (см аналогичную картинку в документации).
Прикинем экономию - имеем порядка 90 баз данных по 10DTU каждая (итого 1260$ в месяц) Всю эту нагрузку мы можем перенаправить на пул размером в 50eDTU (110$ в месяц).
Итого на одном серваке - экономия в 1100$ каждый месяц - неплохо. Но перед переходом на пул нужно проанализировать лимиты (так как базы слабонагруженные с вероятностью 99.9% их будет более чем достаточно) и не забыть про самую важную часть -
Тестирование
Если вы не можете на момент работы с ресурсами полностью остановить нагрузку на базы данных, то я настоятельно советую убедиться на DEV\QA среде, что такие операции как:
Добавление базы в пул
Удаление базы из пула
Скейлинг пула вверх
Скейлинг пула вниз
Не приводят к негативным последствиям для продукта.
Процесс миграции
Если тестирование прошло успешно, можно начать миграцию. Я рекомендую постепенный подход. Сначала на DEV среде закинули часть самых слабонагруженных баз в пул, понаблюдали несколько дней за нагрузкой в пуле, за поведением системы. Затем можно добавить оставшиеся базы, снова понаблюдать. Если на DEV среде все ок - по тому же принципу выполняем миграцию на QA и только потом на проде.
Так же имеет смысл выставить ограничение DTU per database как минимум в два раза меньше чем размер пула. Не помешает создать алерты на пуле - они должны срабатывать, когда нагрузка близка к максимальной для пула.
Итоги
У нас в компании несколько серверов в разных средах (DEV\QA\STG\PRD\PRDWEU) с большим количеством баз. За счет простого перехода с одиночных баз на пулы мы стали экономить ~8000$ в месяц. При этом с производительностью все хорошо - в качестве иллюстрации на картинке ниже пул с 86 базами. Нагрузку на пул мониторить одно удовольствие - здесь как раз показывается уже суммарный график по всем базам
Если у вас похожая инфраструктура - много слабонагруженных баз с редкими пиками, я настоятельно советую поизучать тему Azure SQL Elastic Pool.
Всем спасибо!