Файл: Учебнопрактическое пособие Владимир 2021.pdf

51 образом организовать взаимодействие с нижележащей инфраструкту- рой (IaaS). Разработчики загружают свой программный код на плат- форму, которая обеспечивает автоматическое масштабирование при- ложения в зависимости от нагрузки. Слой PaaS основывается на стан- дартизованном интерфейсе, предоставляемом слоем IaaS, который виртуализует базовые вычислительные ресурсы и предоставляет стандартный интерфейс для разработки приложений, функциониру- ющих на слое SaaS.
Программное обеспечение как сервис(SaaS)
SaaS – это программное обеспечение, которое предоставляется по принципу «оплата по мере использования» и управляется удаленно одним или несколькими поставщиками. SaaS – это наиболее замет- ный слой облачных вычислений, так как именно он представляет ре- альную ценность для конечного пользователя и обеспечивает реше- ние его задач.
С точки зрения пользователя, основным достоинством SaaS яв- ляется цеж-новое преимущество перед «классическим» ПО. Оплата
SaaS осуществляется по модели «оплата по мере использования», что означает отсутствие необходимости инвестиций в собственную аппа- ратную и программную инфраструктуру.
Типичный пользователь SaaS не может контролировать базовую инфраструктуру, будь это программная платформа, на которой SaaS основано (PaaS) или же непосредственно аппаратная инфраструкту- ра(IaaS). Однако поставщик SaaS обязан проработать взаимодействие данных слоев, потому что они необходимы для работы системы.
Например, SaaS-приложение может быть разработано на базе суще- ствующей платформы и исполняться на инфраструктуре, предостав- ленной сторонней компанией. Работа с платформами и/или инфра- структурой как с сервисом является очень привлекательной с точки зрения поставщиков SaaS, так как это может уменьшить в разы от- числения на используемые лицензии или затраты на инфраструктуру.
Это также позволяет им сосредоточиться на тех областях, в которых

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

53 ленные ограничения на методы разработки и предоставления прило- жения.
2.
Представление: интерфейс, через который пользователь производит взаимодействие с облаком. Этот компонент обеспечивает получение входных данных и предоставление информации конечно- му пользователю. Наиболее типичным методом реализации представ- ления является веб-приложение, обеспечивающее взаимодействие с пользователем посредством веб-браузера. В последнее время все ча- ще используются все возможности предоставления пользователю удобного интерфейса работы независимо от устройства, с которого он выходит в Интернет. Это влечет за собой разработку отдельных поль- зовательских интерфейсов для мобильных устройств (смартфонов, планшетов) которые могут представлять собой как отдельные интер- нет-страницы, так и полноценные мобильные приложения, взаимо- действующие с облаком посредством API.
3.
Информация: источники данных, обеспечивающие рас- пределенное хранение структурированных или неструктурированных, статических или динамически-изменяющихся данных. Пользователь- ская информация в облачных системах может достигать огромных объемов. Классические SQL базы данных уже не дают удовлетвори- тельных результатов по скорости обработки. Более того, облачным платформам часто приходится обрабатывать связанные структуры данных (графы, деревья) что становится очень тяжело при использо- вании SQL-подхода и реляционных баз данных. В связи с этим, в по- следние несколько лет стали активно развиваться альтернативные
«NoSQL» системы управления базами данных (колоночные СУБД, такие как Hadoop; документно-ориентированные СУБД, такие как
CouchDB и MongoDB) и альтернативные подходы к обработке сверх- больших объемов информации. Наиболее известной реализацией та- кого подхода является фреймворк MapReduce, представленный ком- панией Google. Он используется для параллельных вычислений над очень большими (несколько петабайт) наборами данных в компью- терных кластерах.

54 4.
Идентификация: информация об основных потребителях облачных ресурсов, используется для оптимизации и подстройки об- лака под их задачи.
Большинству приложений требуется уметь отличать пользова- телей друг от друга для предоставления релевантной информации.
Такая информация имеет первостепенную значимость для облачной платформы, так как на нее завязаны большие объемы пользователь- ских данных, и при этом необходимо обеспечить ее максимальную доступность в рамках системы, т.к. процедура авторизации должна проходить максимально быстро. Также, необходимо обеспечить про- зрачную авторизацию пользователя во всех сервисах одной облачной платформы, чтобы не требовалось каждый раз вводить имя пользова- теля и пароль заново. В связи с распределенной природой облачных сервисов необходимо обеспечить высочайший уровень безопасности при работе с пользовательской информацией.
5.
Интеграция: инфраструктура, упрощающая обмен инфор- мацией и исполнение задач в распределенной вычислительной среде.
Высокая степень декомпозиции сервисов позволяет достичь макси- мальной эффективности и гибкости выполнения облачных приложе- ний, так как появляется возможность загрузки сразу нескольких вы- числительных машин при исполнении одной пользовательской зада- чи. В связи с этим появляется необходимость организации обмена информацией и исполнения задач в распределенных вычислительных средах. В рамках этого компонента необходимо обеспечить макси- мальную производительность и безопасность процесса обмена дан- ными между сервисами. Далее, необходимо обеспечить совмести- мость форматов данных и разработать механизмы синхронного и асинхронного взаимодействия с унаследованным ПО. На более высо- ком уровне необходимо обеспечить слабосвязанность программных компонентов и убедиться в отсутствии узких мест в программной ар- хитектуре системы.
6.
Масштабируемость: гибкость методов предоставления ре- сурсов, обеспечивающая поддержку выделения дополнительных ин- формационных ресурсов при возрастании нагрузки на приложение.

55
При этом необходимо учитывать не только возможность кратковре- менного увеличения нагрузки на приложение но и планировать дол- госрочное увеличение производительности системы в результате по- стоянного прироста аудитории. В обоих случаях, необходимо обеспе- чить декомпозицию облачного приложения на отдельные модульные компоненты, которые могут быть распределены на несколько вычис- лительных устройств.
7.
Монетизация: учет и биллинг ресурсов, затраченных на исполнение пользовательских задач. Это ключевой компонент мно- жества коммерческих приложений. Для организации качественного биллинга облачных платформ необходимо организовать сбор и предоставление полноценной информации о всевозможных ресурсах, затрачиваемых на решение пользовательских задач. Также, необхо- димо обеспечить пользователю возможность удобной и быстрой оплаты затраченных ресурсов.
8.
Внедрение: процесс разработки нового облачного прило- жения, который включает в себя разработку, тестирования и внедре- ние в эксплуатацию. На этапе разработки облачного приложения требуется совсем небольшой объем вычислительных ресурсов, кото- рый значительно увеличивается при переходе к этапу нагрузочного тестирования и внедрения в эксплуатацию.
При этом очевидно, что применение готовой облачной инфра- структуры позволяет значительно сократить издержки на разработку и внедрение высоко масштабируемого приложения, так как оплата использованных информационных ресурсов производится на основе модели коммунальных вычислений и не требует значительных инве- стиций в собственную инфраструктуру. Это позволяет минимизиро- вать начальные затраты и сконцентрировать финансирование на все- стороннем тестировании приложения.
Но, не смотря на все перечисленные достоинства, необходимо оценить все возможные недостатки модели облачных вычислений, как то сложности организации репликации данных между сервисами, сложность отката на предыдущие версии при появлении неожидан- ных ошибок в процессе внедрения, необходимость аккуратного и все-

56 стороннего тестирования разработанных сервисов на совместимость данных и слаженность работы приложения.
9.
Функционирование: мониторинг и поддержка приложе- ний, находящихся в стадии эксплуатации. Приложение, которое за- пущено в эксплуатацию, необходимо администрировать, что может оказаться чрезвычайно сложной задачей, если учесть большое число отдельных сервисов, составляющих облачное приложение. В связи с этим необходимо обеспечить интеграцию процессов администриро- вания и управления сервисами в виде единого «центра управления сервисами». Параллельно, в него можно включить мониторинг нагрузки приложения, панель управления пользовательскими задача- ми и т.п.
Все вышеперечисленные компоненты облачного приложения должны быть запланированы с самого начала разработки для обеспе- чения высокого уровня масштабируемости и автоматизации.
Достоинства и недостатки облачных вычислений
Как ранее было описано, облачные вычисления ориентированы на предоставление информационных ресурсов на трех уровнях: уровне инфраструктур (IaaS), уровне платформ (PaaS) и уровне про- граммного обеспечения (SaaS).
Предоставляя интерфейсы ко всем трем различным уровням, облака взаимодействуют с тремя различными типами потребителей.
1. Конечные пользователи, которые используют SaaS-решения через веб-браузер, или же какие-либо базовые ресурсы инфраструк- турного слоя которые предоставляются посредством слоя.
2. Корпоративные потребители, которые могут использовать все три слоя: IaaS – для того, чтобы расширить собственную про- граммно-аппаратную инфраструктуру или получить дополнительные вычислительные ресурсы по требованию; PaaS – для того, чтобы иметь возможность запуска собственных приложений в облаке; SaaS
– для получения возможностей тех приложений, которые уже доступ- ны в облаке.

57 3. Разработчики и независимые поставщики программного обеспечения, разрабатывающие приложения, которые предоставля- ются в виде облачных SaaS-решений. Обычно, эта категория пользо- вателей напрямую взаимодействует со слоем PaaS, и уже через него, опосредованно, со слоем IaaS.
С точки зрения пользователя, основное достоинство облачных вычислений – это модель оплаты ресурсов по мере их использования.
Отсутствует необходимость предварительных инвестиций в инфра- структуру: нет необходимости инвестиций в лицензионное ПО, от- сутствует необходимость инвестиции в аппаратную инфраструктуру и связанные с этим затраты на обслуживание и персонал. Таким обра- зом, капитальные затраты превращаются в текущие расходы.
Покупатели облачных сервисов используют только тот объем информационных ресурсов, который им на самом деле необходим, и оплачивают только тот объем информационных ресурсов, которыми они реально воспользовались. В то же время, они пользуются такими достоинствами облачных вычислений как масштабируемость и гиб- кость. Облачные вычисления позволяет легко и быстро предоставить необходимые вычислительные ресурсы по требованию.
Тем не менее, существуют некоторые недостатки модели облач- ных вычислений, которые вытекают из одной очевидной особенности
– облака обслуживают сразу множество различных клиентов. Пользо- ватель облачной платформы не знает, задачи каких пользователей бу- дут исполняться на том или ином сервере, входящем в облачную ин- фраструктуру. Типичное облако является внешним по отношению к внутренней инфраструктуре любой компании, то есть находится вне зоны ответственности администраторов и служб безопасности компа- нии-потребителя. В то время как для отдельного потребителя это может быть несущественным, крупные компании уделяют этому во- просу очень большое значение Пользователю приходится полагаться на обещания поставщика облачных решений в вопросах надежности, производительности и качества обслуживания инфраструктуры обла- ка. Использование облаков также сопряжено с высокими рисками

58 безопасности и защиты конфиденциальной информации. Это связано с двумя факторами:
1) необходимость загрузки и получения данных из облака;
2) хранение данных производится на базе удаленных хранилищ, в связи с чем владельцу информации приходится полагаться на гаран- тии поставщика облачных решений, что несанкционированного до- ступа к данным не произойдет. Более того, использование облаков требует определенных инвестиций в интеграцию собственной инфра- структуры и приложений в облако. В настоящее время нет стандартов для интерфейсов IaaS, PaaS и SaaS. В связи с этим выбор поставщика облачных решений становится довольно рискованным занятием.
В связи с этим, необходимо всегда учитывать риски, связанные с использованием облаков. В каждом отдельном случае необходимо внимательно взвесить все потенциальные выгоды и угрозы при пере- ходе на облачную платформу. Также, необходимо решить какие дан- ные и какая обработка может производиться на базе «облачного аут- сорсинга», а какие данные лучше никогда не выводить за рамки ло- кальной сети организации.

59 ных средств, предназначенных для накопления, ведения и использо- вания информации. В свою очередь, распределенная база данных
(РБД) определяется как интегрированная БД, физически размещаемая на нескольких территориально распределенных компьютерах сети.
Для таких систем характерными являются следующие функции:

Накопление, обновление и хранение данных в географиче- ски удаленных узлах сети;

Логическая интеграция территориально распределенных данных, процессов обработки, обновления и поиска информации;

Обеспечение автоматического взаимодействия между ло- кальными базами данных в процессе исполнения запросов и решения задач пользователей.
Управление выполнением основных функций ИС осуществляет комплекс программных средств, который включает систему управле- ния распределенными базами данных (СУРБД) в качестве основного компонента, а также сетевую операционную систему, систему разгра- ничения доступа и др.
Под СУРБД понимают систему, реализующую принцип логиче- ской интеграции данных, физически распределенных между различ- ными взаимосвязанными компьютерами. К основным функциям
СУРБД можно отнести анализ и распределение запросов, а также управление их прохождением.
Следует отметить, что реализация концепции распределенных
БД обеспечивает независимость программ по отношению к распреде- лению данных в вычислительной сети. Это означает, что пользова- тель может иметь доступ к любым данным сети в пределах своих полномочий как к собственной локальной базе данных. В этом кон- тексте существенный интерес представляет рассмотрение различных способов распределения данных по узлам сети для обеспечения эф- фективного доступа к ним.
Стратегии распределения данных по узлам компьютерной сети могут классифицироваться по различным признакам. К основным из них можно отнести наличие дублирования информации и количество узлов, содержащих копии данных. В соответствии с указанными