Тонкости разработки в облаках

Мультитенантность (multitenancy)  — возможность изолированно обслуживать разных пользователей, например подписчиков SaaS, в рамках одного сервиса. В основе этого подхода лежат два критерия: разделение физических и логических ресурсов, а также изоляция. Мультитенантность часто упоминается вместе с облаками — для решения вопроса миграции приложений и данных в распределенные ИТ-инфраструктуры, поддерживающие масштабируемые облака любых типов. Суть мультитенантности хорошо иллюстрируют дороги общего пользования —общий для всех водителей ресурс. В «немультитенантной» модели для каждого автомобиля надо было бы прокладывать свою дорогу, что гарантирует фиксированную пропускную способность, но влечет существенные затраты.

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

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

Модели мультитенантности

На рис. 1 представлены возможные уровни мультитенантности: инфраструктуры (System Infrastructure), данных (Data Platform), прикладной платформы (Application Platform) и логики приложения (Application Logic).

Рис. 1. Уровни мультитенантности

Выделенная архитектура (Shared Nothing/Isolated Tenancy). В этой модели каждый пользователь, сервис (тенант) имеет выделенные ресурсы для всего стека (от слоя инфраструктуры до слоя приложения), и, по сути, это традиционный хостинг. Добавление нового тенанта обычно осуществляется вручную и может требовать закупки или использования нового оборудования, операционной системы и лицензии на нее и т. п. Примерами такой модели могут служить SAP Sales OnDemand, Microsoft Dedicated Hosted Exchange Server и Oracle CRM On Demand Private Edition, хотя крупные производители стараются сейчас отходить от данной модели к модели SaaS.

Разделяемое оборудование (Shared Hardware). В этой модели физическая инфраструктура общая для всех или группы тенантов, а все остальные ресурсы, как и для предыдущей модели, являются выделенными — например, виртуальные машины выделяются из общего пула. В отличие от предыдущей модели здесь имеется динамическая составляющая выделения ресурсов, например, по требованию может быть автоматически создана дополнительная виртуальная машина. Такая модель может быть более эффективна, но при этом минимальной единицей масштабирования и разделения является виртуальная машина, а это достаточно большая логическая сущность. Для того чтобы миграция существующих приложений в облако с опорой на такую модель была оправданна, необходимо, чтобы приложение умело равномерно распределять нагрузку между несколькими экземплярами виртуальных машин. Например, многие СУБД имеют ограничения на масштабирование за счет распределения по нескольким серверам, поэтому может потребоваться модификация приложения под такую модель. Сложные корпоративные приложения, которые изначально спроектированы как распределенные, не сохраняют состояние «локально» (stateless) и требуют существенных мощностей для функционирования, могут быть хорошими кандидатами для миграции в данную модель  —  они изначально проектировались с расчетом на горизонтальное масштабирование. Примерами такой модели могут служить Microsoft Windows Azure и Amazon EC2.

Разделяемая операционная система (Shared OS). Данная модель подразумевает, что тенанты выделяются или располагаются в рамках одного экземпляра ОС. По сравнению с предыдущей моделью, выделяется не виртуальная машина, а процесс в пределах разделяемой виртуальной машины (рис. 2). При этом в данной модели больше гибкости — ресурсы выделяются на более высоком логическом уровне. Такой подход требует меньше времени — создать новый независимый процесс проще, чем создать отдельную виртуальную машину. Примерами такой модели могут служить Google App Engine, Heroku, Parallels Virtuozzo Containers и Windows Azure (Web Sites, Mobile Service).

Рис. 2. Мультитенантность на уровне инфраструктуры: выделенная виртуальная машина (слева) или выделенный процесс в пределах разделяемой виртуальной машины (справа)

Разделяемый слой данных (Shared Database/Storage). В данной модели тенанты разделяют между собой одно логическое хранилище, но запускаются в выделенной области других ресурсов. При этом физически данные разных тенантов могут располагаться на одном физическом сервере СУБД и дисковой подсистеме. Дополнительные объемы для хранения данных выделяются автоматически и по требованию. Архитектура такой модели обычно включает изоляцию нереляционных данных на основе некоторого ключа, а реляционных — на основе логической базы. Поэтому при миграции приложений с реляционной структурой существенных доработок обычно не требуется. Примеры такой модели: Windows Azure (SQL Database, Table Storage, BLOB Storage), Google App Engine (App Engine Datastore, Google Cloud SQL, Google Cloud Storage), Amazon AWS (Relational Database Service, Simple Storage Service).

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

Повсеместное разделение (Shared Everything). Эта модель фактически объединяет в себе две предыдущие: разделяемый слой приложений (Shared Container) и разделяемый слой данных (Shared Database/Storage). За логическую изоляцию данных отвечает сервис-контейнер, а облачная платформа предоставляет функциональность логической изоляции данных, что упрощает разработку решений. Можно уверенно сказать, что данная модель позволяет наиболее быстро создавать новые тенанты. Поэтому сейчас приложения, рассчитанные на тысячи и сотни тысяч пользователей, обычно ориентируются на такую модель. Примерами могут быть Apprenda, Rackspace Cloud Sites и Salesforce.com.

Специализированная мультитенантность (Custom Multitenancy). Логика мультитенантности и изоляции может быть реализована программно и на уровне бизнес-логики без использования специальных контейнеров или разделяемого слоя данных. Обычно это связано с тем, что приложение разрабатывалось в тот момент, когда платформы IaaS и PaaS не были еще широко распространены или не предлагали удобных возможностей для создания мультитенантных систем. Данная модель (проработка мультитенантности силами пользователя) очень трудозатратна, а учитывая появление множества платформ PaaS, имеющих встроенные средства и сервисы, позволяющие реализовать разделение ресурсов с сохранением принципов изоляции, подобную модель рекомендуется избегать. Примеры: Google Apps Premier Edition и Microsoft Dynamics — эти продукты обеспечивают мультитенантность, но за счет собственной логики, а не средствами независимых сервисов или компонентов.

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

Мультитенантная архитектура — кардинальный способ снижения стоимости вычислительных ресурсов и хранилища для приложений за счет оптимизации предоставления ресурсов и их максимальной загрузки. Наиболее ощутимой выгода становится при сочетании мультитенантности и неограниченного масштабирования, которое можно, например, обеспечить на базе облачных PaaS. По мнению ряда обозревателей, за счет большей утилизации ресурсов и серверов получаемая прибыль для мультитенантной системы оказывается значительно выше (рис. 3). Однако простая виртуализация с ростом количества клиентов требует больше затрат, чем система с мультитенантной архитектурой (рис. 4).

Рис. 3. Зависимость числа серверов приложений от количества пользователей для традиционной архитектуры (красная линия) и мультитенантной (синяя линия)

Рис. 4. Зависимость итоговой цены решения от количества клиентов для двух моделей

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

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

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

Рис. 5. Уровни мультитенантности: от выделенной архитектуры до модели shared everything

Разработка приложений

Мультитенантные приложения должны обеспечивать: изоляцию данных, рабочей области и выполнения; независимое администрирование тенантов; возможности адаптации тенанта к конкретным условиям работы (внесение изменений в интерфейс и бизнес-логику); независимый контроль версий приложения для различных тенантов; независимый журнал событий и возможность восстановления для различных тенантов; точное отслеживание и учет использования ресурсов в пределах тенанта; динамическое выделение ресурсов для тенанта; горизонтальное масштабирование в реальном времени; избыточность для поддержки прозрачной горячей миграции в случае сбоя. Часть этих свойств может обеспечиваться провайдерами облаков, например, изоляция рабочей области находится в компетенции провайдеров Windows Azure, Heroku и т. п. Для построения мультитенантного приложения разработчикам лучше взять за основу уже существующую облачную платформу (Windows Azure, Amazon AWS, Salesforce, Heroku и т. п.). Вместе с тем часть свойств нужно будет реализовать пользователям, которым при разработке мультитенантных приложений следует учитывать ряд факторов.

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

Соглашение об уровне обслуживания. Иногда требуется предлагать различные соглашения об уровне обслуживания (Service Level Agreement, SLA) для различных уровней подписки на приложение или сервис. Если подписчики с разными соглашениями совместно используют одно мультитенантное развертывание, то всем им следует обеспечить самый высокий SLA. Для мультитенантных приложений требуется мониторинг (как внутренний, так и доступный клиенту), позволяющий отслеживать показатели сервиса для каждого тенанта и соотносить их с заявленным SLA. Аналогично и облачный провайдер, на платформе которого строится решение, должен предоставлять данные по соблюдению SLA — соглашение об уровне обслуживания, заявленное разработчиком приложения, зависит от SLA провайдера.

Управление доступом и проверка подлинности. Мультитенантное приложение означает, что сервисом могут пользоваться организации с достаточно разнородными требованиями, включая управление доступом и проверку подлинности. Например, можно создать собственную изолированную систему проверки подлинности для мультитенантного приложения, предложить интеграцию с существующими системами клиентов или другими системами (Microsoft Account/LiveID, Facebook, Google и т. п.). Последний подход технически более сложен, но и более востребован. Если для приложения используется своя собственная система проверки подлинности и авторизации, то подписчикам приложения потребуется создавать учетные данные для всех его пользователей. С другой стороны, клиенты могут предпочесть использовать существующую у них систему проверки подлинности и избежать необходимости создания новых учетных данных. Все это для мультитенантного приложения означает необходимость поддержки средств нескольких поставщиков проверки подлинности, а также может потребовать сопоставления схемы авторизации приложения в облаке со схемой локальной инфраструктуры авторизации. Скорее всего, надо будет также реализовать управление доступом на основе заявок, а это означает, что при разработке приложения необходимо либо выбирать провайдера PaaS, у которого сервис для работы с заявками понимает соответствующие протоколы, либо создавать сервис и реализовывать протоколы самостоятельно.

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

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

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

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

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

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

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

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

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

Расширяемость и масштабируемость

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

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

Финансы

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

Для выделенного приложения можно просто определить итоговую сумму для каждого клиента, однако некоторые затраты здесь будут фиксированы (их нельзя избежать). Например, оплата за использование вычислительных ресурсов в режиме 24x7 или базы данных даже при отсутствии  операций  загрузки либо нулевом объеме хранимой информации может сделать начальную стоимость сервиса слишком высокой для небольших компаний. В мультитенантной архитектуре фиксированные затраты можно разделить между клиентами, но затраты на одного пользователя рассчитать не так просто, и для определения объемов ресурсов, потребляемых каждым клиентом, потребуется в приложение добавить дополнительный код. Более того, клиенты захотят каким-то образом отслеживать свои затраты, поэтому биллинг необходимо сделать максимально прозрачным, а также реализовать механизм доступа клиентов к этим данным.

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

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

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

Наталья Ефимцева (natale@microsoft.com) — эксперт по технологиям разработки программного обеспечения, Microsoft (Москва).