Модели многотенантности базы данных SaaS

Применимо к: База данных SQL Azure

В этой статье описаны различные модели аренды, доступные для мультитенантного приложения SaaS.

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

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

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

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

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

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

В. Как выбрать подходящую модель аренды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка арендатора

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

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

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

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

База данных 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 пулами, может достичь масштаба миллионов баз данных, что может сделать управление ими затруднительным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перемещение арендаторов

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

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

Пулы

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

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

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

Связанный контент

• Центр архитектуры Azure: веб-приложение для начала разработки SaaS