Мультитенантные шаблоны клиента в базе данных SaaS

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

В этой статье описываются модели аренды, доступные для приложений SaaS с поддержкой нескольких клиентов.

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

A. Понятия и терминология SaaS

В модели "Программное обеспечение как услуга (SaaS)" компания не продает лицензии на свое программное обеспечение. Вместо этого каждый из пользователей платит компании аренду, что делает их ее клиентами.

В обмен на осуществление арендных платежей каждый клиент получает доступ к компонентам приложения SaaS и возможность хранить свои данные в системе SaaS.

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

• Однопользовательская модель. В каждой базе данных хранятся данные только одного арендатора.
• Мультитенантная модель. В каждой базе данных хранятся данные нескольких арендаторов, с дополнительной защитой конфиденциальности данных.
• Доступны также гибридные клиентские модели.

Б. Как выбрать соответствующую клиентскую модель

Как правило, клиентская модель не влияет на функции приложения, но влияет на другие аспекты решения в целом. Для оценки каждой модели используются критерии ниже.

• Масштабируемость.

  • число клиентов;
  • хранилище на клиент;
  • хранилище в статистической обработке;
  • рабочая нагрузка.

• Изоляция арендаторов: изоляция данных и производительность (ограничивает влияние рабочих нагрузок разных арендаторов друг на друга).

• Стоимость каждого арендатора: затраты на базу данных.

• Сложность разработки:

  • изменения схемы;
  • изменения запросов (требуемые шаблоном).

• Сложность эксплуатации:

  • Мониторинг производительности и управление ею.
  • Управление схемами.
  • восстановление клиента;
  • Аварийное восстановление.

• Возможность настройки: простота персонализации схем на уровне арендатора или класса арендаторов.

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

В. Изолированное однотенантное приложение с однотенантной базой данных

Изоляция на уровне приложения

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

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

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

Управление со стороны поставщика

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

D. Мультитенантное приложение с однотенантной базой данных

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

Настройка клиента

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

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

Эластичные пулы

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

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

Масштабирование операций для однотенантной базы данных

База данных SQL Azure предлагает множество функций управления, разработанных для управления большим количеством (свыше 100 000) баз данных. Эти функции делают вероятный шаблон однотенантной базы данных.

Предположим, что в системе имеется база данных с 1000 клиентов — только одна база данных. У базы данных может быть 20 индексов. Если система выполнит преобразование для получения 1000 однотенантных баз данных, количество индексов возрастет до 20 000. В Базе данных SQL Azure при автоматической настройке по умолчанию включаются функции автоматического индексирования. С помощью автоматического индексирования выполняется управление всеми 20 000 индексами и их текущими операциями создания и удаления. Эти автоматические действия применяются в отдельной базе данных и не координируются или ограничиваются подобными действиями в других базах данных. Автоматическое индексирование неодинаково обрабатывает индексы в базах данных с разными нагрузками. Такой тип настройки управления индексами был бы крайне неэффективным для масштабирования однотенантной базы данных, если задача по такому управлению должна была бы выполняться вручную.

Ниже приведены другие функции управления, которые поддерживают масштабирование:

• встроенные резервные копии;
• обеспечение высокой доступности; Каждый набор масштабирования помещает свои виртуальные машины в группу доступности с 5 доменами сбоя (FD) и 5 доменами обновления (UD) для обеспечения доступности (дополнительные сведения о доменах сбоя и обновления см.
• шифрование дисков;
• телеметрия производительности.

автоматизация

Операции управления можно выполнять с помощью скриптов и реализовывать через модель DevOps. Их даже можно автоматизировать и реализовывать в приложении.

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

Д. Мультитенантное приложение с мультитенантными базами данных

Другой доступный шаблон — хранение нескольких клиентов в мультитенантной базе данных. Экземпляр приложения может иметь любое количество мультитенантных баз данных. Схема мультитенантной базы данных должна иметь один или несколько столбцов идентификаторов клиентов, чтобы можно было выборочно извлечь данные из любого соответствующего клиента. Кроме того, схеме может потребоваться несколько таблиц или столбцов, используемых только подмножеством клиентов. Однако статический код и эталонные данные сохраняются только раз и совместно используются всеми клиентами.

Потеря изоляции клиента

Данные: мультитенантная база данных по необходимости "жертвует" изоляцией арендаторов. Данные нескольких клиентов совместно хранятся в одной базе данных. Во время разработки запросы никогда не должны предоставлять данные из более чем одного клиента. База данных SQL поддерживает безопасность на уровне строк, чтобы запрос возвращал только данные из области действия конкретного арендатора.

Обработка: мультитенантная база данных предоставляет совместный доступ к вычислительным ресурсам и ресурсам хранения для всех арендаторов. Вы можете отслеживать всю базу данных, чтобы наблюдать за ее работой. Тем не менее система Azure не имеет встроенной функции мониторинга или контроля использования этих ресурсов отдельным клиентом. Таким образом, мультитенантная база данных повышает риск возникновения "шумных соседей", где рабочая нагрузка одного активного клиента влияет на производительность других клиентов в этой базе данных. С помощью дополнительного мониторинга на уровне приложения можно отслеживать производительность на уровне клиента.

Низкая стоимость

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

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

Е. Мультитенантное приложение с отдельной мультитенантной базой данных

Самый простой шаблон мультитенантной базы данных использует отдельную базу данных для размещения данных всех клиентов. По мере добавления дополнительных клиентов база данных масштабируется и, соответственно, увеличивается объем хранилища и вычислительных ресурсов. Даже такая масштабируемость является ограниченной. Тем не менее к тому моменту, когда будет достигнут предел масштабируемости, управление базой данных станет очень трудоемким процессом.

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

G. Мультитенантное приложение с сегментированными мультитенантными базами данных

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

Управление сегментами

Сегментирование усложняет проектирование и эксплуатационное управление. Для поддержки сопоставления между клиентами и базами данных требуется каталог. Кроме того, процедуры управления необходимы для управления сегментами и заполнения клиента. Например, должны быть разработаны процедуры для добавления и удаления сегментов, а также перемещения данных клиента между сегментами. Способом масштабирования является добавление нового сегмента и его заполнение новыми клиентами. В других случаях можно разделить плотно заполненный сегмент на два менее заполненных сегмента. После перемещения нескольких клиентов или прекращения их использования можно объединить менее заполненные сегменты. Так можно достичь более экономически выгодного использования ресурсов. Клиенты также можно перемещать между сегментами, чтобы распределять рабочую нагрузку.

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

Небольшими базами данных проще управлять

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

Идентификатор клиента в схеме

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

Эластичный пул для сегментов

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

H. Гибридная модель сегментированной мультитенантной базы данных

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

Перемещение клиентов

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

Гибридная модель оптимальна, когда присутствуют большие различия в отношении потребностей ресурсов в идентифицируемых группах клиентов. Предположим, что клиенты, доступные в бесплатной пробной версии, не гарантируют такой же высокий уровень производительности, как клиенты в подписке. Политика для клиентов на этапе бесплатной пробной версии должна храниться в мультитенантной базе данных, которая совместно используется всеми клиентами бесплатной пробной версии. Когда клиент бесплатной пробной версии подписывается на базовый уровень служб, его можно переместить в другую мультитенантную базу данных с меньшим количеством клиентов. Подписчик, который платит за уровень служб Premium, можно переместить в собственную новую базу данных с одним клиентом.

Пулы

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

I. Сравнение клиентских моделей

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

Измерения	Автономное приложение	Однотенантная база данных	Сегментированная мультитенантная база данных
Масштабирование	Средняя 1–100	Очень высокая 1–100 000	Неограниченная 1–1 000 000
Изоляция клиентов	Очень высокая	Высокая	Низкая. За исключением одноэлементного клиента (одного в базе данных MT).
Стоимость на базу данных для каждого клиента	Высокая. Размер зависит от пиков.	Низкая. Используются пулы.	Наименьшая. Для небольших клиентов в базах данных MT.
Мониторинг производительности и управление ею	Только для каждого клиента	Общая статистическая обработка + для каждого клиента	Статистическая обработка. Для каждого клиента только для одноэлементных экземпляров.
Сложность разработки	Низкий	Низкий	Средняя из-за сегментирования.
Сложность эксплуатации	Варьируется от низкой до высокой. Отдельные клиенты — низкая, высокая при масштабировании.	Варьируется от низкой до средней. Сложность зависит от масштабирования.	Варьируется от низкой до высокой. Сложное управление отдельным клиентом.

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

• Разверните и изучите мультитенантное приложение SaaS, в котором используется отдельная База данных SQL Azure для каждого клиента.

• Знакомство с SaaS-приложением Wingtip Tickets для размещения клиентов в службе "База данных SQL Azure"