Мониторинг производительности сегментированной мультитенантной Базы данных SQL Azure в мультитенантном приложении SaaS и управление ею

Область применения:База данных SQL Azure

В этом руководстве рассматриваются несколько ключевых сценариев управления производительностью, используемых в приложениях SaaS. Здесь также показано, как использовать генератор нагрузки для моделирования действий в сегментированных мультитенантных базах данных клиента, а также встроенные функции мониторинга и оповещения Базы данных SQL Azure.

SaaS-приложение Wingtip Tickets c мультитенантной БД использует сегментированную мультитенантную модель данных, в которой данные о месте проведения (клиенте) распределяются по идентификатору клиента в нескольких потенциальных базах данных. Как и во многих приложениях SaaS, рабочую нагрузку клиента предсказать невозможно, так как пользователи могут покупать билеты в любое время. Чтобы воспользоваться преимуществами этого типичного шаблона использования базы данных, масштаб баз данных необходимо увеличить и уменьшить для оптимизации затрат на решение. Применяя этот шаблон, важно выполнять мониторинг использования ресурсов базы данных, чтобы обеспечить достаточную загруженность в нескольких потенциальных базах данных. Кроме того, необходимо убедиться, что отдельные базы данных имеют достаточно ресурсов и не превышают ограничения на использование единиц DTU. В этом руководстве рассматриваются способы мониторинга баз данных и управления ими, а также приведены действия, которые необходимо предпринять в случае изменений рабочей нагрузки.

Из этого руководства вы узнаете, как выполнить следующие задачи:

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

Для работы с этим руководством выполните следующие предварительные требования:

• Разверните приложение SaaS-приложение Wingtip Tickets c мультитенантной БД. Вы можете развернуть его менее чем за пять минут, используя инструкцию из статьи Deploy and explore a sharded multi-tenant application that uses Azure SQL Database (Развертывание и изучение сегментированного мультитенантного приложения, использующего Базу данных SQL Azure).
• Установите Azure PowerShell. Дополнительные сведения см. в статье Начало работы с Azure PowerShell.

Общие сведения о шаблонах управления производительностью SaaS

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

Стратегии управления производительностью

• Чтобы избежать необходимости вручную отслеживать производительность, наиболее эффективно настраивать оповещения, которые активируются при удалении баз данных из обычных диапазонов.
• Чтобы управлять краткосрочными колебаниями объемов вычислительных ресурсов базы данных, вы можете масштабировать уровень единиц DTU. Если эти колебания происходят постоянно и их можно предугадать, масштабирование базы данных можно запланировать, и этот процесс будет выполняться автоматически. Например,если рабочая нагрузка незначительная (ночью или на выходных), масштаб можно уменьшить.
• Чтобы управлять длительными колебаниями или изменениями в клиентах, отдельные клиенты можно переместить в другие базы данных.
• Чтобы управлять временным возрастанием нагрузки отдельного клиента, его можно изъять из базы данных и назначить ему индивидуальный объем вычислительных ресурсов. После снижения нагрузки этот клиент можно вернуть в мультитенантную базу данных. Если это известно заранее, клиенты можно переместить заблаговременно. Так вы всегда будете иметь в базе данных необходимые ресурсы и сможете избежать влияния на другие клиенты в мультитенантной базе данных. Если эта необходимость предсказуемая, например из-за увеличения уровня продаж билетов на популярное мероприятие, это поведение управления можно интегрировать в приложение.

На портале Azure доступны встроенные возможности мониторинга большинства ресурсов и создания оповещений. Для базы данных SQL средства мониторинга и создания оповещений доступны в базах данных. Эти встроенные средства относятся к конкретному ресурсу. Их удобно использовать при работе с незначительным количеством ресурсов, но не с большим.

При работе с большим количеством ресурсов можно использовать журналы Azure Monitor. Это отдельная служба Azure, которая предоставляет аналитические сведения на основе журналов, собранных в рабочей области Log Analytics. Журналы Azure Monitor могут собирать данные телеметрии из многих служб и использоваться для выполнения запросов и настройки оповещений.

Получение скриптов и исходного кода для SaaS-приложения Wingtip Tickets c мультитенантной БД

Сценарии для приложения SaaS Wingtip Tickets c мультитенантной базой данных и исходный код этого приложения вы найдете в репозитории GitHub WingtipTicketsSaaS-MultitenantDB. Инструкции по скачиванию и разблокированию сценариев приложения SaaS Wingtip Tickets см. в статье Общие рекомендации по работе с примерами приложений SaaS Wingtip Tickets.

Подготовка дополнительных клиентов

Чтобы полностью продемонстрировать принципы работы мониторинга производительности и управления ею, для работы с этим руководством необходимо несколько клиентов в сегментированной мультитенантной базе данных.

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

1. В интегрированной среде сценариев PowerShell откройте скрипт …\Learning Modules (Модули для обучения)\Performance Monitoring and Management (Мониторинг производительности и управление ею)\Demo-PerformanceMonitoringAndManagement.ps1. Не закрывайте этот скрипт, так как он еще понадобится в рамках этого руководства.
2. Чтобы выбрать скрипт подготовки пакета клиентов, задайте параметр $DemoScenario = 1.
3. Нажмите клавишу F5 для запуска скрипта.

Скрипт за несколько минут развернет 17 клиентов в мультитенантной базе данных.

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

Моделирование использования ресурсов во всех базах данных клиентов

Предоставляется скрипт Demo-PerformanceMonitoringAndManagement.ps1 для моделирования рабочих нагрузок, выполняющихся в мультитенантных базах данных. Нагрузка создается с помощью одного из доступных сценариев нагрузки:

Демонстрация	Сценарий
2	Создание нагрузки с обычной интенсивностью (около 30 DTU)
3	Создание нагрузки с более длительными пиками на клиента
4	Создание нагрузки с интенсивным использованием единиц DTU при пиках на клиента (около 70 DTU)
5	Создание нагрузки высокой интенсивности (около 90 DTU) на отдельном клиенте, а также нагрузки с обычной интенсивностью на все клиенты

Генератор нагрузки применяет искусственную нагрузку на ЦП каждой базы данных клиента. Он запускает задание в каждой базе данных клиента, которое периодически вызывает хранимую процедуру, за счет чего создается нагрузка. Уровень (в единицах DTU), продолжительность и интервалы нагрузки во всех базах данных отличаются, что позволяет моделировать непредсказуемую активность клиента.

1. В интегрированной среде сценариев PowerShell откройте скрипт …\Learning Modules (Модули для обучения)\Performance Monitoring and Management (Мониторинг производительности и управление ею)\Demo-PerformanceMonitoringAndManagement.ps1. Не закрывайте этот скрипт, так как он еще понадобится в рамках этого руководства.
2. Чтобы создать нагрузку с обычной интенсивностью, задайте параметр $DemoScenario = 2.
3. Нажмите клавишу F5, чтобы применить эту нагрузку ко всем клиентам.

SaaS-приложение Wingtip Tickets c мультитенантной БД является приложением SaaS, а реальная нагрузка в приложениях SaaS обычно непредсказуема и возникает время от времени. Для ее моделирования генератор нагрузки создает случайную нагрузку, распределенную во всех клиентах. Чтобы появился шаблон нагрузки, необходимо несколько минут, поэтому генератор нагрузки должен работать около 3–5 минут. Затем можно приступить к отслеживанию нагрузки в разделах ниже.

Важно!

Генератор нагрузки выполняется как ряд заданий в новом окне PowerShell. Если сеанс закрыть, генератор нагрузки останавливается. Генератор нагрузки остается в состоянии job-invoking, в котором он создает нагрузку на любого из новых клиентов, подготовленных после запуска генератора. Нажмите клавиши CTRL+C, чтобы остановить вызов новых заданий и выйти из скрипта. Генератор нагрузки продолжит работу, но только в имеющихся клиентах.

Мониторинг использования ресурсов на портале Azure

Чтобы отслеживать использование ресурсов, которое приводит к применению нагрузки, откройте портал в мультитенантной базе данных, tenants1содержащую арендаторы:

1. Откройте портал Azure и перейдите на серверtenants1-mt-<USER>.
2. Прокрутите вниз и найдите базы данных и выберите арендаторы1. В этой сегментированной мультитенантной базе данных содержатся все клиенты, созданные ранее.

Ознакомьтесь с диаграммой DTU.

Настройка оповещений производительности в базе данных

Чтобы настроить оповещение в базе данных, которое активируется при использования >75 % ресурсов, сделайте следующее:

1. tenants1 Откройте базу данных (на сервереtenants1-mt-<USER>) на портале Azure.

2. Выберите "Правила генерации оповещений", а затем нажмите кнопку +Добавить оповещение:

   

3. Укажите имя, например High DTU.

4. Задайте следующие значения:

   • "Метрика": "Процент DTU";
   • "Условие": "Больше";
   • "Пороговое значение": 75;
   • "Период": "За последние 30 минут".

5. Добавьте адрес электронной почты в поле "Дополнительные электронные письма администратора" и нажмите кнопку "ОК".

   

Увеличение масштаба загруженной базы данных

Если общий уровень нагрузки базы данных достиг предела и используется 100 % единиц DTU, снижается производительность базы данных и возможно уменьшение времени отклика на запрос.

Краткосрочным решением является увеличение масштаба базы данных для предоставления дополнительных ресурсов или удаление клиентов из мультитенантной базы данных (перемещение их из мультитенантной базы данных в автономную).

При долгосрочных повышениях нагрузки мы советуем оптимизировать использование индексов и запросов, чтобы улучшить производительность базы данных. В зависимости от конфиденциальности приложения к проблемам с производительностью рекомендуется масштабировать базу данных до достижения 100 % использования DTU. А оповещения позволяют предупредить об этом событии заранее.

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

1. Задайте $DemoScenario = 3, создайте нагрузку с более длительными и частыми всплесками для каждой базы данных, чтобы увеличить интенсивность статистической нагрузки в базе данных, не изменяя пиковую нагрузку, необходимую для каждого клиента.
2. Нажмите клавишу F5, чтобы применить эту нагрузку ко всем базам данных клиента.
3. Перейдите tenants1 в базу данных на портале Azure.

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

1. Чтобы увеличить масштаб базы данных, выберите ценовую категорию (DTU масштабирования) на странице параметров.
2. Установите ползунок DTU в положение 100.
3. Нажмите кнопку "Применить" , чтобы отправить запрос для масштабирования базы данных.

Вернитесь к колонке tenants1>Обзор, чтобы просмотреть диаграммы мониторинга. Следите за эффектом предоставления базы данных с большим количеством ресурсов (хотя с несколькими клиентами и случайной нагрузкой не всегда легко увидеть окончательно до тех пор, пока вы не будете работать в течение некоторого времени). Посмотрев на диаграммы, примите во внимание следующее: предельное значение на верхней диаграмме теперь составляет 100 единиц DTU, а на нижней — по прежнему 50 DTU.

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

подготовка нового клиента в собственной базе данных.

Сегментированная мультитенантная модель позволяет выбрать, подготавливать ли новый клиент в мультитенантной базе данных вместе с другими клиентами или подготавливать его в собственной базе данных. Подготовка арендатора в отдельной базе данных обеспечивает его изоляцию, позволяя управлять производительностью и аварийным восстановлением для этого арендатора независимо от других и так далее. Например, вы можете поместить клиентов с бесплатной пробной версией или обычных клиентов в мультитенантную базу данных, а клиентов с подписками уровня "Премиум" — в отдельные базы данных. Изолированными базами данных с одним клиентом также можно управлять коллективно в эластичном пуле для оптимизации затрат на ресурсы.

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

1. В среде сценариев PowerShell откройте ...\Learning Modules\ProvisionTenants\Demo-ProvisionTenants.ps1файл .
2. Изменение $TenantName = "Salix Salsa" и $VenueType = "dance".
3. Задайте $Scenario = 2, подготовьте клиента в новой базе данных с одним клиентом.
4. Нажмите клавишу F5 для запуска скрипта.

Скрипт подготавливает этот клиент в отдельной базе данных, регистрирует базу данных и клиент в каталоге, а затем открывает страницу событий клиента в браузере. Обновите страницу концентратора событий и вы увидите, что Salix Salsa добавлен как место проведения.

Примечание.

Восстановление из мультитенантных баз данных в один клиент невозможно.

Управление производительностью отдельной базы данных

Если нагрузка отдельного клиента в мультитенантной базе данных постоянно высокая, это может влиять на ресурсы в базе данных и другие клиенты. Если эта активность не прекращается в течение некоторого времени, клиент можно временно изъять из базы данных и поместить в его собственную мультитенантную базу данных. Это позволяет настроить для клиента необходимые дополнительные ресурсы и полностью изолирует его от других клиентов.

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

1. ...\Demo-PerformanceMonitoringAndManagement.ps1 Откройте скрипт.
2. Set $DemoScenario = 5, Generate a normal load plus a high load on a single tenant (приблизительно 90 DTU).
3. Задайте $SingleTenantName = Salix Salsa.
4. Чтобы выполнить скрипт, нажмите клавишу F5.

Перейдите на портал Azure и перейдите к обзору salixsalsa>, чтобы просмотреть диаграммы мониторинга.

Другие шаблоны управления производительностью

Самостоятельное масштабирование клиента

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

Масштабирование базы данных по расписанию в соответствии с шаблонами использования

Если показатель общего использования клиента можно спрогнозировать, реализуйте масштабирование базы данных по расписанию с помощью службы автоматизации Azure. Например, после 18:00 масштаб базы данных можно уменьшить, а в рабочие дни в 06:00 обратно увеличить.

Дальнейшие действия

Из этого руководства вы узнаете, как выполнить следующие задачи:

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

Дополнительные ресурсы

• Служба автоматизации Azure