Преобразование Web-приложения в мультитенантное решение SaaS

Как быстро превратить Web-приложение в облачное

Вы построили Web-приложение для одного заказчика, но хотите, чтобы оно эффективно работало в облачной среде. Как преобразовать обычное приложение в полноценное мультитенантное облачное SaaS-приложение? Автор на конкретном примере демонстрирует условия и изменения, необходимые для переноса Web-приложения в облако, и показывает, как это сделать. Затем, в качестве бонуса, он предлагает программное обеспечение, разработанное его компанией, которое позволяет применить подход «плагина» для достижения мультитенантности.

Скотт Чейт, вице-президент по продукции, Corent Technology

Скотт Чейт (Scott Chate) имеет опыт разработки программного обеспечения и архитектуры, международных операций и управления компаниями из списка Fortune 500, а в настоящее время занимается другой стороной ИТ-индустрии в коммерческой организации Corent Technology, располагающей инновационной технологией. Работая в сфере менеджмент-консалтинга и разработки продуктов в Oracle, IBM, TransCanada PipeLines и Mercer, научился создавать и внедрять инновационные решения с использованием новых технологий для обеспечения эффективности, управления рисками и использования благоприятных коммерческих возможностей.



17.10.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри Вычисления в облаке: введение в программное обеспечение как услуги

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

Задача в том, чтобы быстро и эффективно преобразовать его в SaaS, сохранив или даже повысив рентабельность компании.

Существует много различий между SaaS- и обычными Web-приложениями, которые нужно принимать во внимание. Одни из них носят технический характер, а другие связаны с изменением бизнес-модели, к которой компания должна адаптироваться при выпуске SaaS.

Сравнение типичного Web-приложения с SaaS

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

Мультитенантность - ключ к успеху SaaS

Соглашение: SaaS требует мультитенантности

Мультитенантность ― необходимое условие успеха поставщика SaaS. — Марк Бениофф, генеральный директор Salesforce

Без мультитенантности успех SaaS невозможен. — Треб Райан, генеральный директор OpSource

Мы достигли феноменально эффективной (низкой) себестоимости вычислений... у нас самая низкая себестоимость SaaS в отрасли (благодаря мультитенантности). — Ларс Далгаард, генеральный директор SuccessFactors

Сегодня ASP пытается взять реванш. Однако при подходе облачного центра обработки данных клиенты по-прежнему разделяются по однтенантной модели, поэтому эксплуатация все еще обходится очень дорого. — Зак Несон, генеральный директор NetSuite. — Наша валовая прибыль превысила 70% (благодаря мультитенантности).

Мультитенантность для нас очень важна... она создает гораздо более эффективную модель. — Тим Уоллес, генеральный директор iPipeline

Мультитенантность ― главная ставка в игре SaaS. — Генри Олсон, бывший генеральный директор Edge Dynamics

Мультитенантность обеспечивает работу всей модели подписки... — Джефф Каплан, генеральный директор THINKStrategies.

Хотя возможность подписываться на приложения удовлетворяет минимальные критерии SaaS, на практике этого недостаточно. SaaS-приложение также должно быть мультитенантным.

Это связано с чисто экономическими факторами. Руководители ведущих SaaS-компаний согласны, что без мультитенантности бизнес SaaS невозможен. (См. врезку).

Мультитенантность ― уровень эффективности SaaS

Основным рычагом повышения эффективности служит мультитенантность, возможность обслуживать разных пользователей приложения таким образом, что каждому из них кажется, что с ним работает только он. Мы привыкли к этой концепции в применении к отдельным пользователям системы, но в среде SaaS она принимает новую форму. В типичном корпоративном SaaS-приложении пользователи ― это группы сотрудников определенного подразделения, которое является арендатором (англ. - tenant). Если бы организация приобрела обычное Web-приложение, то некоторая группа сотрудников пользовалась бы им, а организация стала бы его владельцем. В модели SaaS организация является арендатором, а не владельцем, но пользователями остаются группы сотрудников. Каждый пользователь относится к определенному арендатору (организации), а SaaS предоставляет каждому арендатору возможность распоряжаться своей копией приложения, с которой могут работать его пользователи.

Виртуализация в облаке использует SaaS

Разница между обычным Web-приложением и приложением SaaS с поддержкой облака затрагивает два главных способа использования вычислительной емкости в современной ИТ-индустрии:

  • мультитенантность (о которой говорилось выше) и
  • виртуализацию оборудования.

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

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

Теперь рассмотрим основные шаги, позволяющие преобразовать более традиционное Web-приложение в SaaS-приложение.


Преобразование Web-приложений в SaaS

Чтобы преобразовать Web-приложение в приложение SaaS, нужно выполнить семь условий.

  1. Приложение должно поддерживать мультитенантность.
  2. Приложение должно поддерживать определенный уровень самообслуживания при регистрации.
  3. Должен быть предусмотрен механизм подписки и выставления счетов.
  4. Приложение должно предоставлять возможность эффективного наращивания ресурсов.
  5. Должны быть предусмотрены функции контроля, настройки и управления приложением и арендаторами.
  6. Должен существовать механизм поддержки уникальных идентификаторов и проверки подлинности пользователей.
  7. Должен существовать механизм поддержки определенного уровня настройки под каждого арендатора.

Рассмотрим каждый пункт подробнее.

Поддержка мультитенантности

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

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

Существует несколько уровней мультитенантности (как показано на рисунке к следующему списку).

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

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

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

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

Самообслуживание при регистрации

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

Подписка и биллинг

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

Наращивание ресурсов и управление приложением

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

Кроме того, необходимо предоставить функции администрирования и управления приложением для мониторинга, настройки и управления приложением и всеми арендаторами.

Идентификация пользователей и проверка подлинности

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

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

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

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

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

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

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


Вопросы производительности

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

Горизонтальное/вертикальное масштабирование

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

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

Кластеризация баз данных

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

География, секционирование и синхронизация

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

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

Отдельные базы данных

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

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

Выравнивание нагрузки

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

Емкость ― не единственное требование

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


Вопросы безопасности

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

Большинство архитектур SaaS-приложений предусматривает меры защиты данных, которые, как минимум, не позволяют одному арендатору видеть данные другого. Однако:

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

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

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


Выбор набора технологий

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

Соображения операционной системы

Операционная система в Web-приложениях, вероятно, имеет наименьшее отношение к пользователям, потому что они работают через браузер. Однако существуют финансовые и технические соображения, которые нужно учитывать:

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

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

Базы данных

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

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

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

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

Способность поддерживать такую кластеризацию в облачной среде может повлиять на выбор базы данных. Например, DB2 может быть выбрана за ее способность работать на различных ОС, которые обеспечивают вертикальную масштабируемость, и за гибкость выбора способа наращивания с использованием кластеризации множества экземпляров и избыточности. Так, кластер DB2 HADR (High Availability Disaster Recovery) можно настроить в облаке.

Сервер приложений

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

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

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

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


Гибкость ― ключ к технологической эволюции

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

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

В оставшейся части статьи я воспользуюсь инструментом Corent Multi-Tenant Server™, чтобы с минимальными усилиями выполнить пример преобразования Web-приложения Java™ с открытым исходным кодом для учета предоставленных услуг и выставления счетов в мультитенантную SaaS-версию.


Автоматическая "SaaS'ификация" приложения с помощью Corent Multi-Tenant Server

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

Corent Multi-Tenant Server позволяет применить другой подход с использованием промежуточного слоя для обеспечения необходимой мультитенантности (сохраняя инвестиции в существующий код). Я опишу четыре шага, необходимых для преобразования в мультитенантную SaaS-версию jBilling, популярного Web-приложения Java с открытым исходным кодом, которое служит типичным представителем класса однотенантных приложений.

Шаг 1. Преобразование схемы базы данных в абстрактную модель

Типичный набор компонентов Web-приложения выглядит как на рисунке 1; приложение взаимодействует с базой данных, часто через уровень персистентности данных, такой как Hibernate.

Рисунок 1. Типичный набор компонентов Web-приложения в облаке
Типичный набор компонентов Web-приложения в облаке

Для преобразования приложения в мультитенантное нужно переработать базу данных, добавив поля для управления идентификационными данными арендаторов, необходимыми для фильтрации данных по арендаторам.

Для чтения схемы существующей базы данных приложения используется программа SaaS-Factory™. Она создает модель этой базы данных, который впоследствии применяется для генерирования новой базы данных в MySQL с дополнительным полем TenantID в таблицах. На этом этапе создаются несколько дополнительных таблиц, включая таблицу с информацией об арендаторах, которые используются программой Multi-Tenant Server.

Рисунок 2. Создание схемы базы данных MetaModel
Создание схемы базы данных MetaModel

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

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

Шаг 2. Расширение процесса аутентификации пользователей

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

Corent Multi-Tenant Server

Corent Multi-Tenant Server позволяет нашим клиентам быстро преобразовать существующие однотенантные Web-приложения в полностью мультитенантные SaaS-решения, совместимые с облаком без необходимости переписывать их. Corent предлагает наиболее эффективный и рентабельный подход к обеспечению мультитенантности. Этот плагин промежуточного ПО представляет собой безопасное, масштабируемое решение, которое существенно снижает стоимость доставки услуг.

Оно позволяет выбрать предпочтительный набор технологий, используя наиболее подходящие ОС, сервер базы данных и сервер приложений. Благодаря гибкой архитектуре ulti-Tenant Server можно выбрать способ развертывания SaaS-приложения, на своем оборудовании или в облаке любого типа. Это позволяет развертывать SaaS-приложения в качестве коммунальных услуг или как приложения Private SaaS™, которые предоставляют услуги ограниченной аудитории, такой как сотрудники крупного предприятия, подразделения которого становятся арендаторами.

Multi-Tenant Server содержит модуль SaaS-Cockpit™ для организации, администрирования и контроля учетных записей SaaS и модуль SaaS-Factory™ для настройки под каждого арендатора и расширения возможностей SaaS-приложения. Комплекс решений Corent значительно ускоряет преобразование SaaS-приложений.

В настоящее время Corent и IBM® предлагают ограниченному числу избранных кандидатов бесплатное преобразование для "доказательства концепции", помогая конвертировать Web-приложения в мультитенантное решение SaaS, работающее в облаке IBM SBDT, и оценить это решение.

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

Существует много способов добиться этого; выбор зависит от реализации приложения. Если в качестве контейнера сервлетов приложения используется Tomcat, можно применить метод аутентификации, управляемой контейнером, чтобы инициировать бизнес-правило, запускающее Multi-Tenant Server для поиска TenantID пользователя. Иначе, можно воспользоваться фильтром сервлетов для обнаружения и последующей настройки локальной переменной потока TenantID. В нашем примере с jBilling приложение управляет аутентификацией непосредственно, проверяя свои таблицы пользователей. Поэтому в метод, используемый для расширенной аутентификации, внесены некоторые простые изменения, добавляющие в код аутентификации процессы поиска сведений об арендаторе пользователя, хранящиеся в новых таблицах.

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

Шаг 3. Настройка соединения с базой данных

Corent Multi-Tenant Server основан на сервис-ориентированной архитектуре с использованием базы данных MetaModel (см. Шаг 1). Она используется в качестве уровня абстракции для моделирования исходной базы данных приложения, и связи базы данных приложения, вместо фактической базы данных, переадресуются к абстракции MetaModel. Это делается путем простой перенастройки JDBC-соединения jBilling для доступа к базе данных MetaModel, вместо фактической базы данных MySQL. Для приложений, использующих библиотеки Hibernate, применяется Hibernate-диалект Corent.

В результате этих изменений вызовы базы данных приложений также переадресуются к базе MetaModel. Эти события SQL перехватывает Corent Agile Controller™, который передает их в Corent ADBC™ (Agile DataBase Connector). ADBC принимает SQL-оператор, как если бы он был передан приложением в базу данных MetaModel, и анализирует его, а затем добавляет критерии фильтрации TenantID того пользователя, чей сеанс передал SQL-оператор (например, TenantID = <myTenantID>). Это гарантирует постоянное строгое соблюдение требований защиты данных в общей базе данных. Даже при подключении внешнего приложения, такого как ReportWriter, данные, которые оно "видит", по-прежнему ограничены данными соответствующего арендатора. Так как мы знаем, кто вошел в систему, независимо от приложения, мы знаем и то, к какому арендатору он относится, и применяем нужные фильтры.

Манипуляции с SQL-операторам выполняются после того, как они были представлены в базе данных MetaModel, и арендатор пользователя известен, поэтому Corent Agile Controller может перехватывать и выполнять сложные операции, включая поиск процессов и конфигураций соответствующего арендатора. Поэтому можно выполнять определенные действия по каждому арендатору и даже предоставлять разные соединения с базой данных, так что один арендатор будет использовать базу данных DB2, несмотря на то, что все остальные работают с базой данных MySQL. Или один из арендаторов может производить дополнительные SQL-манипуляции для ограничения данных, которые могут извлекать пользователи, записями, введенными не более чем 90 дней назад. Все эти настройки по арендаторам можно выполнить посредством механизма Agile Rules Engine™, встроенного в Multi-Tenant Server, без каких-либо изменений в коде исходного приложения.

Рисунок 3. Структура настроек под арендатора
Структура настроек под арендатора

Все преобразование приложения jBilling было выполнено всего с несколькими незначительными изменениями в приложении, главным образом относящимися к расширению процесса аутентификации с включением в информацию о сеансе данных об арендаторе и переадресации соединения с базой данных на Multi-Tenant Server. Вот сводка всех изменений, внесенных в jBilling.

  • Оригинальное приложение
    • Количество исходных файлов: 897 (Java и jsp)
    • Общее число строк кода: 76621
  • Преобразованное приложение
    • Количество добавленных исходных файлов: 2 (стандартный шаблон)
    • Измененных строк кода: менее 100
    • Изменения в бизнес логике приложения: нет

Преобразование jBilling заняло менее недели, включая всю работу по анализу и подготовке с целью выявления мест, где необходимо изменить код. Многие из этих изменений были простым повторением изменения одной строки в серии Java-программ для доступа к JDBC, которые не потребуется, если используется уровень персистентности базы данных, такой как Hibernate.

Шаг 4. Развертывание нового мультитенантного SaaS-приложения в облаке

Теперь SaaS-Factory можно использовать для развертывания SaaS-приложения на указанном сервере, в том числе в облаке.

После выбора серверов приложений и баз данных создается целевая база данных (например, MySQL на Windows®-сервере, как для нашего приложения jBilling), и готовое приложение Multi-Tenant Server развертывается как набор .WAR-файлов на выбранном сервере приложений. Multi-Tenant Server работает с любым современным контейнером сервлетов J2EE и сертифицирован для WebSphere Application Server.

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

SaaS-Factory может сгенерировать и установить дополнительное приложение SaaS-Cockpit™, которое предоставляет эти базовые мультитенантные услуги. Оно имеет доступ к той же базе данных MetaModel, что и основное приложение, и окна администрирования для создания арендаторов, назначения учетных записей Tenant Administrator и настройки основных параметров всевозможных конфигураций приложения для каждого арендатора. Существуют также средства администрирования для мониторинга и отчетности по арендаторам и их пользователям. Поскольку одна из общих характеристик SaaS-приложений ― необходимость отслеживать подписки арендаторов и выставлять счета, предоставляются средства биллинга или интеграции с внешними биллинговыми системами.

Рисунок 4. Структура для развертывания нового SaaS-приложения в облаке
Структура для развертывания нового SaaS-приложения в облаке

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

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

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

  • конфигурации DB2 HADR (High Availability Disaster Recovery) обеспечивают постоянную готовность и некоторое выравнивание нагрузки путем использования вторичного режима базы данных только для чтения;
  • технология IBM pureScale и Tivoli System Automation (TSA) позволяют создать кластерную среду базы данных с несколькими узлами, которые распределяют между собой обрабатываемую нагрузку, но это налагает дополнительные ограничения по конфигурациям оборудования и ОС.

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

Рисунок 5. Архитектура развертывания SaaS для масштабируемых надежных облачных операций
Архитектура развертывания SaaS для масштабируемых надежных облачных операций

Наблюдается тенденция к предоставлению возможностей, которые позволяют приложению бесперебойно работать даже после автономной реорганизации данных, модернизации схемы, обновления версии и существенных изменений нагрузки. Технология IBM PureScale переносится из мира z System на AIX® и Linux® и предоставляет такие возможности по управлению емкостью и обеспечению безотказной работы, какие ранее были доступны лишь в среде мэйнфреймов ЭВМ.


Заключение

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

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

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Технология Java, Open source, Information Management
ArticleID=840966
ArticleTitle=Преобразование Web-приложения в мультитенантное решение SaaS
publish-date=10172012