Мониторинг производительности сегментированной мультитенантной Базы данных 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. Прокрутите вниз, найдите базу данных и щелкните tenants1. В этой сегментированной мультитенантной базе данных содержатся все клиенты, созданные ранее.

диаграмма базы данных

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

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

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

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

  2. Щелкните Правила оповещения, а затем выберите + Добавить оповещение:

    Добавление оповещения

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

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

    • "Метрика": "Процент DTU";
    • "Условие": "Больше";
    • "Пороговое значение": 75;
    • "Период": "За последние 30 минут".
  5. Добавьте адрес электронной почты в поле Additional administrator email(s) (Дополнительные адреса электронной почты администратора) и нажмите кнопку ОК.

    настройка оповещения

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

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

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

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

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

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

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

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

Вернитесь к колонке 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. Чтобы создать нормальную нагрузку с высокой нагрузкой на отдельный клиент (около 90 DTU), задайте для параметра $DemoScenario значение 5.
  3. Задайте значение $SingleTenantName = Salix Salsa
  4. Чтобы выполнить скрипт, нажмите клавишу F5.

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

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

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

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

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

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

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

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

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

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