• Статья

Мультитенантная архитектура для SaaS приложений

Что такое мультитенантность (multitenancy)?


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

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

Сейчас очень часто мультитенатность фигурирует совместно с терминов облачные вычисления, но фактически мультитенантность в некотором своем проявлении была актуальной и раньше, например, для хостинг-площадок. Например, SQL Server и IIS позволяют администрировать базы и сайты независимо: когда вы заходите в IIS Management Console удаленного сервера то, вы видите только свои сайты, аналогично для SQL Server – в Management Console вы видите и управляете только своей базой. Это так же можно назвать вариацией мультитенантности – все клиенты хостинга живут на одном веб-сервере или сервере базы данных, но работают только со своими узлами\элементами\данными. Мультитенантность так же является неотъемлемой частью многих ERP и CRM систем (Multi-tenant versus Single-tenant ERP – a comparison).

Для своего SaaS приложения позаботиться о мультитенантности уже предстоит вам, хотя в этом вам могут помочь имеющиеся фичи или готовы компоненты, например, которые предоставляют PaaS-платформы. Вообще говоря, проще сразу проектировать приложение с фокусом на мультитенантность, чем потом приложение «перепроектировать» для ее поддержки.

В чем преимущества мультитенантного подхода?


Кроме мультитенантной архитектуры бывает выделенная архитектура (single-tenant), когда для каждого пользователя предоставляется собственная инфраструктура (это характерно для не SaaS приложений): логические или физические сервера. Для облачных сервисов подобный подход может быть не оправданным, т.к. для каждого подписчика выделяются фиксированные ресурсы, независимо от того, сколько их требуется (а это увеличивает конечную стоимость SaaS подписки для пользователя, в итоге может оказаться, что стоимость решения будет выше, чем у конкурентов). Подобная выделенная архитектура для облачных сервисов может быть оправдана только для premium подписок и т.д. 

Мультитенантная архитектура является кардинальным способом снижения стоимости вычислительных ресурсов и хранилища для SaaS решений: за счет минимально необходимого количества используемых ресурсов (разделяемой инфраструктуры) и их максимальной загрузки. Наиболее ощутимой выгода становится при сочетании мультитенантности и «неограниченного масштабирования» (когда нет необходимости затрачивать дополнительные средства на провиженинг дополнительных ресурсов или добавления новых серверов). Неограниченное масштабирование можно попробовать реализовать своими силами или использовать облачные PaaS платформы. 

Источник: Cloud Computing: Sharpen Your SAAS Smarts Before Committing to the Cloud

И все-таки что выбрать выделенную модель или мультитенантную?


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



Поэтому нет правильного или неправильного ответа на вопрос выбора того или иного подхода, но есть ряд факторов, которые могут повлиять на ваш выбор. Расскажу далее об этих факторах на примере платформы Widows Azure, хотя большинство из них применимы и для других облачных платформ.

Архитектура

  1. В мультитенантном приложение вы всегда можете эмулировать выделенный режим (один подписчик), тогда как возможности расширить выделенное приложение до нескольких независимых подписок обычно отсутствует.
  2. Отказоустойчивость. Мультитенатное приложение более уязвимо к сбою экземпляра, чем выделенное приложение. Сбой выделенного развертывания влияет только на клиента, который использует данное приложение, тогда как сбой мультитенатного приложения затронет всех клиентов. 
  3. Уменьшить негативные последствия при сбое можно с помощью нескольких экземпляров мультитенатного приложения или его части. Например, Windows Azure может уменьшить этот риск, позволяя выполнить развертывание нескольких идентичных копий приложения за счет использования нескольких экземпляров ролей (такое подход как раз в полной мере реализует мультитенатную модель с несколькими экземплярами). Windows Azure автоматически распределяет нагрузку по обработке запросов между данными экземплярами ролей, следовательно, приложение должно быть разработано таким образом, чтобы оно корректно функционировало при использовании нескольких экземпляров. Например, если приложение использует состояние сеанса, необходимо убедиться, что каждый экземпляр веб-роли может получить доступ к состоянию. Так же Windows Azure выполняет постоянный мониторинг всех экземпляров ролей и автоматически перезапускает экземпляры при возникновении сбоя.
  4. Для некоторых приложений может быть не целесообразным совместное использование всеми клиентами одного мультитенантного развертывания. Например, может понадобиться сгруппировать клиентов на основе функциональности приложения, которую они используют, а затем оптимизировать каждый экземпляр для каждой из созданных групп. В этом случае вам может потребоваться две или более копии мультитенатного приложения, развернутого даже в различных подписка Windows Azure.
  5. Соглашение об уровне обслуживания (SLA). Вы можете предлагать различные соглашения об уровне обслуживания (SLA) для различных уровней подписки на сервис. Если подписчики с разными соглашениями об уровне обслуживания совместно используют одно мультитенантное развертывание, следует обеспечить самый высокий SLA. 
  6. Правовая и нормативная среда. Для некоторых приложений необходимо учитывать конкретные нормативные или юридические вопросы. Для этого могут потребоваться различия в функциональных возможностях, отображение в пользовательском интерфейсе юридических соглашений, обеспечение отдельных баз данных или областей хранилища для каждого конкретного подписчика, расположение сервиса и хранилища в конкретном географическом регионе. При таких условиях может потребоваться реализовать отдельные мультитенантные развертывания для различных групп пользователей, либо строго выделенный режим для каждой подписки на сервис.
  7. Проверка подлинности и авторизации. Для приложения в облаке может использовать своя собственная система проверки подлинности и авторизации, в этом случае подписчикам приложения потребуется создавать учетные данные для всех пользователей приложения. С другой стороны клиенты могут предпочесть использовать существующую у них систему проверки подлинности и избежать необходимости создавать новые учетные данные для приложения. Второй вариант для мультитенантного приложения означает необходимость поддержки нескольких поставщиков проверки подлинности, а так же может потребовать сопоставление схемы авторизации приложения в облаке со схемой локальной инфраструктуры авторизации. В Windows Azure для настройки проверки подлинности и авторизации используется Access Control Services, с помощью которой можно реализовать аутентификацию формами, через Active Directory, через LiveId, Google, Facebook и др. OpenID провайдерами. Если речь идет об интеграции с Active Directory и настройке федерации между AD подписчика и сервисом, то, скорее всего, это так же может потребовать выделенного развертывания.

Управление жизненным циклом приложения

  1. Ведение базы кода. Для компаний-разработчиков ведение отдельных баз кода для различных клиентов сопряжено с увеличением расходов на поддержку и обслуживание, а так же с проблемами при отслеживании того, какие клиенты какую версию используют. Это может привести к появлению ошибок, которые приведут к дополнительным затратам. Мультитенатная система с одним логическим развертывание гарантирует одну базу кода для всего приложения. Вы можете по-прежнему поддерживать одну базу кода с выделенной моделью с несколькими развертываниями, но может появиться желание (с долгосрочными последствиями) разветвить код для различных клиентов. В некоторых сценариях, где существует потребность в тонкой настройке приложений, несколько баз кода могут быть приемлемым вариантом, но, прежде чем выбрать этот путь, необходимо изучить возможность применения пользовательских конфигураций или пользовательских бизнес-правил на уровне стандартной настройки системы (например, через интерфейс). Если должно быть несколько баз кода, то приложение должно быть структурировано таким образом, чтобы пользовательский код ограничивался только минимально необходимым числом пользовательских компонентов.
  2. Обновления приложения. Мультитенантное приложение позволяет одновременно распространить обновления на всех клиентов. Этот подход означает, что обновляется только один логический экземпляр, что позволяет уменьшить усилия по обслуживанию. Кроме того, у вас есть уверенность, что все клиенты используют последнюю версию приложения, что упрощает поддержку. 
  3. Например, домены обновления (Update Domain) Windows Azure упрощают этот процесс, позволяя распространять обновления на несколько экземпляров роли без остановки приложения. Если у клиента есть операционные процедуры или программное обеспечение, привязанные к конкретной версии приложения, то любые обновления должны быть скоординированы с клиентом.
  4. Для сокращения рисков, связанных с обновлением приложения, вы можете реализовать процедуру последовательного обновления: на первой фазе происходит обновления приложения для небольшой группы пользователей, на второй фазе, если с новой версией не возникло никаких сложностей, обновления распространяются на оставшихся пользователей.
  5. Мониторинг приложения. Мониторинг одного развертывания приложения проще, чем мониторинг нескольких развертываний. В выделенной модели с несколькими развертываниями для любого нового экземпляра роли необходимо устанавливать настройки среды мониторинга, в результате чего увеличивается сложность всего процесса. Если будет решено использовать последовательное обновление, мониторинг будет также более сложным, поскольку необходимо одновременно отслеживать две версии приложения и использовать данные мониторинга для оценки стабильности версии приложения.
  6. Использование сторонних компонентов. Если будет решено использование мультитенантную архитектуру, необходимо оценить насколько хорошо в таком режиме будут работать сторонние компоненты. Что убедиться, что сторонний компонент может работать в мультитенантной архитектуре, возможно, потребуется выполнить некоторые дополнительные действия.
  7. Провиженинг тестового доступа и новых клиентов. Провиженинг области для нового клиента или инициализация бесплатного пробного использования службы в значительной степени упрощается, если данный процесс предполагает только изменение конфигурации. Для выделенной модели требуется развернуть новый экземпляр приложения для каждого клиента, включая тех, которые используют бесплатную пробную версию. Хотя этот процесс вы можете автоматизировать, это будет значительно сложнее, чем изменение или создание данных конфигурации в мультитенантном приложении.


Windows Azure позволяет сделать процесс провиженинга автоматическим (провиженинг сервисов, сертификатов, хранилища и т.п.), для этого необходимо использовать REST Service Management API. Программная реализация всех необходимых действий очень актуальна, т.к. позволяет пользователям зайти на портал, нажать кнопку «попробовать» и получить через несколько минут временную подписку (trial), созданную специально для них. Так же это актуально при размещении приложения в Marketplace’ах, когда пользователи могут сначала попробовать приложение, а потом его приобрести и продолжить использование – и никаких звонков или писем службу поддержки.

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

  1. URL-адреса для доступа к приложению. По умолчанию Windows Azure предоставляет каждому приложению DNS-имя следующего вида <имя-приложения>.cloudapp.net. В случае выделенного развертывания вы можете использовать запись CNAME для сопоставления DNS-имени подписчика (например, contoso.com) с приложением. В мультитенантном приложение вы можете использовать схемы адресации следующего вида: http://.cloudapp.net// или опять же с применение CNAME и Host Header. Например, можно сопоставить mydomain.ru c http://<имя-мультитенатного-приложения>.cloudapp.net, где по Host Header определить запрашиваемый тенант. Такой подход позволяет скрыть от пользователя тот факт, что это мультитенантное приложение, т.к. обращение идет по уникальному URL адресу, выбранному для тенанта. Немного сложнее становится ситуация, когда доступ должен быть по HTTPS.
  2. Настройка приложения клиентом. Разрешение клиентам загружать собственный код увеличивает риск сбоя приложения, потому что снижается уровень контроля выполняемого приложением кода. Поэтому многие SaaS поставщики накладывают ограничение на использование пользовательского кода в мультитенантных приложениях (т.к. сбой повлияет на всех пользователей). В большинстве случаев это просто запрещено, иногда код разрешен, но его функциональные возможности сильно урезаны. Разрешение клиентам загружать код или скрипты также увеличивает риски, связанные с безопасностью приложения.

Архитектура слоя данных

  1. Защита данных от других тенантов (подписчиков). Риск случайного или злонамеренного раскрытия данных в мультитенантной модели выше. Трудно убедить клиента, что его личные данные в безопасности, если клиент знает, что приложение физически используется совместно с другими клиентами. Однако качественная архитектура приложения, которая логически изолирует данные каждого клиента, должна обеспечить требуемый уровень защиты. Подобная архитектура может использовать следующие подходы (более подробно подходы описана в хабросттье Multi-tenant Архитектура Данных):

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


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

    Windows Azure Tables и BLOB’s позволяют реализовать различные уровни изоляции данных на уровне: отдельных аккаунта, таблиц, партиций и контейнеров. SQL Azure реализует изоляцию за счет отдельных: база данных, федерации базы данных или серверов. Например, мы можем создать мобильное приложение, которое сохраняет данные в BLOB хранилище. В этом случае мы можем создать для каждого пользователя отдельный BLOB контейнер и назначить соответствующие права на этот контейнер (т.е. не публичный доступ).

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


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

  4. Масштабируемость архитектуры данных. Горизонтальное партиционирование позволяет масштабировать хранилище данных. Для достижения масштабируемости SQL Azure можно перенести данные отдельных клиентов в новый экземпляр SQL Azure.

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

  5. Финансовые вопросы

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

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

    Модуль Cloud Ninja Metering Block для Windows Azure: позволяет снимать метрики использования ресурсов для каждого тенанта, имеет встроенный портал отображения отчетов для клиентов.

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

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

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

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

    2. Управление затратами приложения. Для SaaS приложений на платформе Windows Azure текущие затраты можно разделить на фиксированные и переменные. Например, если тариф для вычислительных ресурсов равен $0,02 (Extra Small экземпляр), то стоимость круглосуточного выполнения двух вычислительных узлов (для избыточности и отказоустойчивости) за один месяц — это фиксированная сумма, примерно равная $28,8 долларам. Если это мультитенантное приложение, то все клиенты разделяют между собой эти расходы. Чтобы уменьшить стоимость на одного клиента, попытайтесь набрать максимальное возможное количество пользователей для совместного использования приложения без отрицательного воздействия на производительность приложения. 

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

    • повышать текущие мощности, используя более производительные вычислительные ресурсы;
    • или применить масштабирование путем добавления дополнительных экземпляров.


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

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

    Выводы

    1. Мультитенантность должна быть продумана как с бизнес точки зрения, так и с технической.
    2. Мультитенантность не должна бросаться в глаза, т.е. у подписчиков и их клиентов должно создаваться впечатление, что они работают с кастомизированной\персонифицированной площадкой (например, тоже DNS имя). Хотя мне кажется, что это просто вопрос психологии и внешнего воспристия.
    3. Мультитенантное SaaS приложение позволяет сделать стоимость решения ниже для клиентов, т.е. повысить его максимально конкурентно способным.
    4. Для построения мультитенатного SaaS приложения необходимо выбрать облачного провайдера. Для этого подходя в большей степени PaaS платформы.
    5. Автоматизируйте процесс провиженинга тенанта, чтобы пользователи легко могли попробовать SaaS приложение (буквально в один клик).

    Ресурсы

    • Gartner Reference Architecture for Multitenancy, 2010
    • Cloud Computing: Sharpen Your SAAS Smarts Before Committing to the Cloud, 2010
    • Busting Myths of On-Demand: Why Multi-Tenancy Matters, 2007
    • Облачная платформа Microsoft, А.Федоров, Д.Мартынов
    • Multi-Tenant Data Strategies for Windows Azure – Part 1
    • Multi-Tenant Data Strategies for Windows Azure – Part 2
    • Identifying the Tenant in Multi-Tenant Azure Applications — Part 1
    • Identifying the Tenant in Multi-Tenant Azure Applications — Part 2
    • Identifying the Tenant in Multi-Tenant Azure Applications — Part 3

Автор статьи:  Наталья Ефимцева.