Прошло десять лет с тех пор, как Amazon запустила EC2. Облако очень реально. Тысячи систем работают в облаке.
Мультиарендность - это ключевая концепция, связанная с облаком с самого начала. Это позволяло нескольким недоверчивым сторонам делиться ресурсами, давая им иллюзию собственного пространства. Лучшим примером этой идеи является многоквартирный комплекс, в котором каждому арендатору предоставляется его собственное пространство, при этом совместно используются такие ресурсы, как сантехника, общие помещения, охрана, техническое обслуживание и т. Д. Для того, чтобы многопользовательская аренда была полезной, стоимость ресурсов на одного арендатора должна быть меньше, чем стоимость владения исключительно собственным ресурсом (домом).
Мультитенантное приложение в облаке должно управлять тремя типами ресурсов: выполнение OLTP, хранилище данных и выполнение пакета OLAP (аналитика). Например, представьте себе приложение, в котором есть веб-приложение или мобильное приложение. Приложение будет иметь набор сервисов, обеспечивающих серверную часть для приложения, базу данных и систему для обработки его аналитики. Поскольку современные архитектуры построены с использованием серверов без сохранения состояния, отдельных баз данных и отдельных систем аналитики, мы можем решать вопросы мультитенантности отдельно для каждого аспекта данных, выполнения и аналитики. Давайте исследуем каждый из этих аспектов и обсудим методы их поддержки.
Выполнение Мультитенантность
Облако может реализовывать совместное использование на разных уровнях.
- Дайте каждому арендатору свою машину.
- Дайте каждому арендатору собственную виртуальную машину
- Дайте каждому арендатору свой контейнер (например, докер)
- Разрешить нескольким клиентам использовать один и тот же процесс (например, JVM)
По мере продвижения по списку каждый получает больше ресурсов, но меньше изоляции (безопасности). Платформы IaaS (инфраструктура как услуга) обеспечивают второй уровень в приведенном выше списке. Поставщикам PaaS и SaaS следует выбирать из 2–3.
Одно из ключевых преимуществ Облака, если это сделано правильно, заключается в том, что пользователь «платит только за то, что он использовал». По сути, нет никаких затрат на доступность, вы платите только в том случае, если она используется. Для IaaS, такого как AWS, это предоставляется почти бесплатно, поскольку он совместно использует оборудование между пользователями через виртуальные машины.
Однако «Платите за то, что используете» не бесплатно для PaaS и SaaS. Предположим, облачный провайдер XCloud имеет 1 миллион пользователей, которые развернули свои приложения PaaS / SaaS в XCloud.
В данный момент активными будут только несколько сотен или тысячи этих приложений. Однако мы не знаем, какие приложения. Поэтому, когда пользователь неожиданно пришел в XCloud для AppY, нам нужно иметь возможность его обслуживать. У нас есть два варианта.
- Держите хотя бы один экземпляр каждого приложения работающим
- Загрузите приложение быстро, когда появится пользователь.
Вариант первый действительно расточительный. Думайте, что AppY - это Gmail, а Google не хочет постоянно запускать виртуальную машину для каждой учетной записи Gmail. Если они сохранят один экземпляр для каждого запущенного пользователя, им будет сложно позволить пользователям платить только тогда, когда используется приложение.
В этом разница между виртуальными машинами и контейнерами или мультиарендностью процессов. Для загрузки виртуальных машин требуются секунды или минуты, и если ваше приложение не действительно простое, вы не сможете загрузить его достаточно быстро, чтобы обслуживать только что пришедшего пользователя. Обычно вам нужно вернуться к пользователю менее чем через десять секунд.
Эту проблему решают такие контейнеры, как docker. Это легкие виртуальные машины, которые загружаются за миллисекунды. Думая о примере Gmail, неудивительно, что контейнеры пришли из Google, поскольку у них такая же проблема. Стоит отметить, что использование docker не гарантирует, что ваше приложение запустится быстро, и вы вполне можете испортить его в коде вашего приложения. Однако при тщательном кодировании часто можно попасть в цель. Следовательно, контейнеры устраняют основные накладные расходы, добавленные инфраструктурой.
Еще один интересный момент, который следует отметить, заключается в том, что именно по этой причине микросервисы и системы на основе докеров так заинтересованы во времени запуска. Если ваша система может загружаться достаточно быстро, чтобы обслуживать пользователя, это приведет к значительной экономии затрат, поскольку вам не нужно постоянно поддерживать работу экземпляра для каждого приложения. Более того, это также значительно упростит алгоритмы автомасштабирования, поскольку тогда алгоритму не нужно прогнозировать нагрузку и поддерживать буфер запущенных экземпляров для подсчета времени запуска.
Сравнивая контейнеры и многопользовательскую среду в процессе (уровень 4 в нашем списке), последнее может быть еще более эффективным. Мы проделали большую работу в области [1,2]. Однако в ретроспективе совместное использование процесса выглядит пугающим, так как вам нужно быть уверенным, что программист платформы не допустил ошибки. Кроме того, изоляция производительности затруднена в многопользовательской среде внутри процесса.
Похоже, что облачные вычисления решили использовать мультиарендность на основе контейнеров для исполнения, золотую середину. Контейнеры обеспечивают приемлемую производительность и изоляцию. Оглядываясь назад, можно сказать, что это разумный выбор.
Наконец, есть гораздо более простое решение, которое в некоторых случаях работает.
Стоит отметить, что если ваши серверы не имеют состояния, что имеет место в большинстве корпоративных развертываний, то вы вообще можете обойтись без мультитенантности. Если сервер не имеет состояния и может просмотреть запрос, определить арендатора и вовремя выполнить то, что требуется для этого клиента, то вам не нужна мультитенантность. Вместо этого вы можете запустить пул серверов, общих для всех клиентов, и назначать по одному каждому приложению по мере поступления пользователей. Для данных вы можете использовать многопользовательскую базу данных, как описано в следующем разделе. Если это решение возможно, оно значительно снизит сложность вашей архитектуры.
Мультитенантность данных
После перезапуска как виртуальные машины, так и контейнеры теряют свои диски. Следовательно, многопользовательские серверы с отслеживанием состояния, такие как базы данных, брокер сообщений и т. Д., Намного сложнее, чем запускать их в контейнере. Один из вариантов - использовать смонтированные диски, такие как S3 или блочные устройства. Однако это могло быть медленным. Для большинства приложений нам необходимо использовать систему баз данных, которая работает на соответствующем оборудовании.
Даже помимо оборудования нам необходимо совместно использовать хранилище между арендаторами. Есть несколько вариантов. В статье Мультитенантная архитектура данных подробно описаны эти варианты, за исключением следующего варианта № 5, которого на момент написания не существовало.
- Сервер базы данных на каждого арендатора
- База данных на каждого арендатора (один и тот же сервер используется несколькими арендаторами)
- Стол на арендатора
- Стол, общий для арендаторов
- Многопользовательские базы данных
Подход №1 и №2, совместное использование сервера базы данных или базы данных, приемлем в настройке IaaS, но непомерно дорог для настройки PaaS или SaaS. Например, нецелесообразно хранить миллион баз данных по одной на каждого арендатора.
Подход №3, предусматривающий предоставление таблицы на каждого арендатора, лучше, чем подход №1 и №2, но все же недопустимый, если мы говорим о миллионе арендаторов.
Подход №4, в котором одна таблица используется многими арендаторами, обеспечивает необходимую производительность. Однако все клиенты должны использовать одну и ту же схему с этим методом, что приемлемо для большинства сценариев PaaS и SaaS. Так же, как и внутрипроцессная мультиарендность, для изоляции нам нужно быть уверенным, что программисты системы баз данных не допустили никаких ошибок. Однако легче проверить фильтрацию SQL, чем проверять код Java или C ++, используемый во внутрипроцессной мультитенантности.
Пятый подход (например, Oracle теперь имеет сервер базы данных с несколькими арендаторами) предоставит лучшее из всех миров. При тщательной реализации он может обеспечить уровень №4 или лучшую производительность и изоляцию на уровне базы данных. Хотя мы должны быть уверены, что разработчик РСУБД не совершит ошибки, я считаю, что внутри РСУБД больше шансов справиться с изоляцией. Более того, разработчики баз данных, вероятно, будут лучше разбираться в предметной области, что позволит им лучше выполнять свою работу.
Аналитика Мультитенантность
Благодаря Big data все должно иметь аналитику. Для большинства приложений SaaS аналитика стала конкурентным преимуществом. Требования к мультитенантности для Analytics отличаются от сценариев использования OLTP, которые мы рассматривали до сих пор. Реализация их в среде PaaS или SaaS требует ответов на несколько проблем.
Аналитика включает сбор данных, хранение данных, выполнение анализа и обеспечение контролируемого доступа к результатам. Облачные провайдеры могут сделать следующее, чтобы упростить сбор данных.
- Добавить инструменты для отслеживания транзакций
- Предоставьте операторы сборщика данных, которые пользователи могут размещать в своих приложениях.
- Предоставьте API приемника данных (например, REST / JSON API), в котором пользователи могут публиковать события.
Каждый метод должен отслеживать информацию о клиенте и пользователе с каждым событием.
В остальном решения для хранения, анализа и сбора данных переплетаются друг с другом. На мой взгляд, ответ зависит от нескольких вопросов о том, что нужно пользователю.
- Все ли арендаторы используют одну и ту же схему? Могут ли они определять свои собственные типы событий?
- Нужна ли пользователям изоляция данных на уровне пользователя или они могут жить с изоляцией на уровне клиента?
- Нужно ли пользователям и арендаторам запускать свои собственные запросы (анализ) или они могут жить с заранее подготовленными запросами?
Исходя из этих требований, решения меняются. Давайте посмотрим на каждое решение.
Использовать пространство суперсемента
Если PaaS управляет генерацией данных, анализом данных и представлением окончательных результатов, то система может помещать данные в супертенантное хранилище и самостоятельно обрабатывать разрешения. Хотя это может показаться скучным решением, это обычный вариант использования для большинства приложений SaaS, которые предоставляют пользователям заранее подготовленную аналитику и ничего больше. Если пользователи хотят провести собственный анализ, система может предложить способ экспорта их данных.
Общие таблицы, отфильтрованные по столбцу
Как и в случае с хранилищем данных, если все пользователи могут использовать один и тот же набор таблиц (схему), то мы можем хранить данные, просто добавляя столбцы пользователя и клиента в таблицу. Это работает очень хорошо. Однако присвоение права собственности на результаты данных, вычисленных путем анализа, сопряжено с некоторыми трудностями. Следовательно, логика анализа (например, задания Hadoop) должна разрешать владение каждой записью путем добавления данных о праве собственности как части записи данных. Еще одно преимущество заключается в том, что с помощью этого метода PaaS может запускать один набор аналитических запросов один раз для всех данных, разделенных с помощью операторов «группировать по».
Собственная площадь арендатора
Предоставление личного пространства каждому арендатору является наиболее гибким. Он предоставляет конечному пользователю большую часть контроля. У каждого арендатора может быть своя собственная схема и свои собственные аналитические запросы.
Как обычно, за эту гибкость нужно платить. Это дорого по нескольким причинам.
- Если арендаторов много, предоставление таблицы базы данных для каждого арендатора является проблемой, если вы используете обычные базы данных, поскольку они не предназначены для обработки миллионов таблиц или баз данных. Как обсуждалось ранее, одним из решений является использование исходной многопользовательской базы данных (например, Oracle 12). В противном случае PaaS потребуется обрабатывать множество серверов баз данных и таблицы разделов между этими серверами, что будет очень сложно.
- В отличие от более раннего метода, когда SaaS может запускать одно задание аналитики для обработки данных по всем арендаторам (например, разделенным с использованием «группировки по»), наличие собственного пространства арендатора потребовало бы задания аналитики для каждого арендатора. Часто запуск аналитической работы сопряжен со значительными накладными расходами. Следовательно, в отличие от выполнения одного задания, выполнение множества заданий будет значительно медленнее. В этой конфигурации SaaS требуется гораздо больший вычислительный кластер. Еще одна проблема заключается в том, что пользователи могут выполнять тяжелую работу, которая будет перегружать кластер и замедлять работу других. Следовательно, SaaS необходим способ ограничения вычислительной мощности, используемой одним арендатором.
Можно создать гибридное решение, в котором SaaS предоставляет общую схему для общих данных и предоставляет собственное пространство арендатора для данных, определяемых пользователем. PaaS может взимать с пользователей дополнительную плату за личное пространство и тем самым ограничивать количество пользователей. В любом случае стоимость будет пропорциональна данным, сгенерированным арендатором, и структура затрат должна быть соответствующим образом скорректирована.
Заключение
После десяти лет облачных вычислений в облаке работают тысячи систем. В этой статье исследуется мультиарендность, ключевая идея в облаке. Мультиарендность - это возможность запускать несколько арендаторов (пользователей) в одной системе. Реализуя мультитенантность, облако может выбирать между несколькими уровнями изоляции - от совместного использования одного и того же оборудования с использованием виртуальных машин до совместного использования одного и того же процесса с помощью умного программирования. Мы узнали, как создать мультитенантное приложение. Мультитенантное приложение в облаке должно управлять тремя типами ресурсов: выполнение, хранилище данных и выполнение пакетов OLAP (аналитика). Мы изучили каждый из них и увидели, что выполнение приближается к контейнерам, а базы данных - к многопользовательским базам данных. Кроме того, в статье обсуждались несколько решений для поддержки мультитенантной аналитики.
использованная литература
- Милинда Патираж, Сринат Перера, Санджива Вираварана, Индика Кумара, Многопользовательская архитектура для выполнения бизнес-процессов, 9-я Международная конференция по веб-сервисам (ICWS), 2011 г.
- Афкхам Азиз, Сринат Перера, Димуту Гамаге, Руван Линтон, Прабат Сиривардана, Димуту Лиларатн, Санджива Вираварана, Пол Фримантл, Мульти-тенантное промежуточное ПО SOA для облачных вычислений, 3-я Международная конференция по облачным вычислениям, Флорида, 2010 г.
Надеюсь, это было полезно, если вам понравился этот пост, вы также можете найти следующий интересный.
Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.
Чтобы узнать больше, прочтите нашу страницу о нас, поставьте лайк / напишите нам в Facebook или просто tweet / DM @HackerNoon.
Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!
