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

А.В. Лаврентьев

ОПТИМИЗАЦИЯ МНОГОКОМПОНЕНТНЫХ ПРИЛОЖЕНИЙ В СРЕДЕ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ С НЕСКОЛЬКИМИ ПРОВАЙДЕРАМИ

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

Ключевые слова: мультиоблако, многокомпонентное приложение, теория массового обслуживания, линейное программирование, локальный поиск.

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

© Лаврентьев А.В., 2014

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

Конечно, имеются классические модели, разработанные с целью предсказания поведения статичных систем и ориентированные на постоянные во времени параметры, такие как уровень рабочей нагрузки, конфигурацию оборудования и показатели качества. Например, Palladio Component Model1 (далее - PCM) и Palladio Bench. PCM - предметно-ориентированный язык для описания архитектуры приложений и ресурсов и анализа нефункциональных требований, но он ориентирован на промышленные системы, оценка качества может быть проведена только для пиковых нагрузок, и у него ограниченная поддержка облачных архитектур. В противоположность этому облачно-ориентированные системы динамичны. В них для оценки качества и стоимости требуется учитывать параметры, крайне зависимые от времени (эластичность облачных архитектур подразумевает значительные суточные колебания ресурсов, поддерживающих выполняемые задачи). Следует иметь в виду, что помимо анализа цен и качества, присутствует проблема быстрого и эффективного анализа пространства возможных облачных конфигураций в автоматическом или полуавтоматическом режиме.

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

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

Расширение языка Palladio Component Model для описания среды облачных вычислений

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

Для примера рассмотрим приложение Apache Open For Business (далее - OfBiz). Рис. 1 и 2 показывают всю необходимую информацию об этом приложении с помощью UML-подобного описания.

Рис. 1. Структура приложения OfBiz

Диаграмма пользовательской активности

?

( Log in j

60%

Проверка статуса заказа

Поиск объектов

Проверка наличия

( Log out ) 6

Диаграмма действия (обработчик запросов)

9

«Внутреннее действие» Персонализация объекта Потребность в ресурсах CPU = 100

«Внешнее действие» Проверка наличия

«Вызов внешнего действия» Оплата

Диаграмма действия (база данных)

?

«Внутреннее действие» Обработка доступности продукта Потребность в ресурсах CPU = 10

Диаграмма действия (сервис оплаты)

i

«Внутреннее действие» Проверка кредитной карты Потребность в ресурсах CPU = 10

6

Рис. 2. Примеры диаграмм действия для приложения OfBiz

OfBiz - промышленное приложение с открытым исходным кодом, разработанное Apache Software Foundation и используемое множеством компаний. Оно обладает широкой функциональностью, требуемой для таких систем, как ERP, CRM, SCM или электронная коммерция. Приложение для электронной коммерции является хорошим кандидатом для реализации в облачной среде из-за высокой интерактивности с потенциально большим количеством пользователей.

Левая диаграмма рис. 2 показывает обычное поведение пользователей при работе с этим приложением. В данном примере 60 % пользователей используют приложение для оформления покупки некоторого продукта, в то время как оставшиеся 40 % проверяют статус доставки продукта, заказанного ранее. Входящая рабочая нагрузка представлена в виде количества запросов в секунду. Расширение для языка PCM позволяет задать рабочую нагрузку отдельно для каждого из 24 часов. Все запросы, сформированные пользователями, обрабатываются компонентом <Обработчик запросов>. Поведение функционала <Проверка наличия> описывается диаграммой деятельности, соответствующей обработчику. Для выполнения запроса Front End виртуальной машине требуются внутренние вычисления (например, для получения цены продукта), влияние которых на физические ресурсы хоста обозначено <Потребность в ресурсах CPU>, и взаимодействие с некоторыми компонентами, расположенными на Back End. В нашем примере запрос обращается к компоненту <База данных> для проверки доступности выбранного продукта и к компоненту <Сервис оплаты> для проверки корректности информации о кредитной карте, введенной пользователем. Рис. 1 демонстрирует размещение компонентов между виртуальными машинами.

Стандартный PCM позволяет разработчикам приложений создавать диаграммы на основе подобной информации и получать из них модель многоуровневой сети очередей (Layered Queuing Network2 (далее - LQN)). Оценка качества может быть получена из модели LQN аналитически или посредством имитации с помощью LQNS3 (Layered Queuing Network Solver) - типового инструмента для решения таких моделей. Предполагаем, что размещение компонентов на вычислительных уровнях (например, Back End и Front End) уже было осуществлено разработчиком и не будет меняться в течение оптимизационного процесса. LQN модели позволяют получить множество оценок качества; в этой работе будут использованы время ответа и стоимость.

Двухшаговый гибридный алгоритм оптимизации

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

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

В данной работе рассматривается метод двухшаговой гибридной оптимизации, позволяющий решить проблему распределения ресурсов в облачной среде. Первый шаг состоит в решении проблемы частично-целочисленного линейного программирования, в которой качество обслуживания развертываемого решения вычисляется посредством M/G/1-PS модели очередей. Такая модель позволяет вычислить среднее время ответа на запрос в закрытой форме. Цель данного шага в том, чтобы быстро определить аппроксимированное начальное решение, которое в дальнейшем будет улучшено посредством алгоритма локального поиска на шаге 2. Цель шага 2 в том, чтобы итеративно улучшать начальную конфигурацию облачной среды, рассматривая различные альтернативы. Алгоритм локального поиска основан на модели LQN, которая позволяет провести более точную оценку параметров качества обслуживания. Рис. 3 и 4 показывают поток работ в процессе оптимизации для шага 1 и шага 2 соответственно. Как было сказано ранее, приложение описывается диаграммами на языке PCM с соответствующим расширением. Информация, хранящаяся в этих диаграммах, используется как входная информация оптимизационной модели, которая является основной целью данной работы. С целью дальнейшего улучшения результаты оптимизации затем обрабатываются алгоритмом локального поиска на основе модели LQN.

РСМ

Расширение

Оптимизационная модель (основанная на МО)

Начальное решение

Провайдер1

Провайдер2

ПровайдерN

Рис. 3. Рабочий поток шага 1 оптимизации на основе модели М/О/1

Начальное решение (XML)

Провайдер1

Провайдер2

ПровайдерN

I

Локальный принтер для провайдера1

С

р

Локальный принтер для провайдера2

р

дЛ

для провайдераЫ

LQNS

Конечное решение (XML)

Провайдер1

Провайдер2

ПровайдерN

Рис. 4. Рабочий поток шага 2 оптимизации с помощью локального поиска

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

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

Рис. 5 демонстрирует модель иерархического распределения нагрузок в мультиоблачной5 среде, которая состоит из нескольких отдельных облаков, предоставляемых различными провайдерами. В каждом облаке размещены идентичные копии приложения. Пользовательский запрос поступает на первый внешний балансировщик нагрузок, который определяет, какому провайдеру P будет адресован конкретный запрос (здесь и далее в работе под облачным провайдером понимается именно IaaS провайдер). Затем балансировщик нагрузок выбранного провайдера определяет сегмент облачной системы, который будет обрабатывать запросы. Сегмент, с точки зрения рассматриваемой задачи, может быть представлен в виде уровней (например, Front End и Back End, как в примере OfBiz). На каждом уровне запросы обрабатываются некоторым количеством виртуальных машин. Общая рабочая нагрузка обозначается (запросов в секунду).

Пользователи взаимодействуют с приложением, формируя запросы. Множество возможных запросов обозначим K. Более того, каждый класс запросов характеризуется вероятностью его выполнения ak и множеством компонентов, его поддерживающих (т. е. расположенных на пути выполнения). Наконец, будем предполагать, что запросы обрабатываются согласно политике PS6 (processor sharing), типичной политике планирования в веб-приложениях, которая равномерно распределяет нагрузку между всеми виртуальными машинами в пуле. Требования к качеству обслуживания в модели представлены задаваемым разработчиком приложения ограничением на среднее время ответа {R}k для множества классов K.

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

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

Совокупная входящая рабочая нагрузка

V Рабочая нагрузка,

перенаправленная к провайдеру р

<} Локальный менеджер рабочей нагрузки

Вычислительный сегмент

Рис. 5. Модель иерархического распределения рабочей нагрузки

Модель оптимизации на основе M/G/1

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

mi* Хе/ 2Рег Xer cp. v. ZP .'.v,t (1)

При условии:

У > f, Vp e p

ZjpeP P 1 >

4pep

2v£VpWPiV = "V VP e P' V e 1 ,

, v * Z, , , v ,,, Vp e p, Vi e I, Vv e v, , Vi e t , (4)

, , , v , . * Nwp, i, v , Vp e p, Vi e I, Vv e , Vi e t , (5)

M»*w* - - *{M} p 'Vp e v e 1, (6)

2veV Sp, vzp,c v , > GpXс, Vp e p, Vk e k, Vc e c, Vi e t, (7)

^^ ve ^

ZvFv (l - {R}k,CSp,V )Zp,ic ,V,t ^ Vk,CGp,k,C,t Wk.c

Vp e p, Vk e Vc e c, Vt e t , (8)

I^ V = ,Vt e T , (9)

vP л, <v, Vp e p, Vt e г, (10)

V * xp \, Vp e ^ Vi e t , (11)

zMv>i e n0, Vp e p, Vi e I, Vv e Vt e t , (12)

wMv e {0,1}, Vp e p, Vi e /, Vv e Vp, (13)

* e {0,1}, Vp e p , (14)

(2) (3)

Gp к c t = А У У

акр

кУк, c

p,kc " Zj Zj .. . (15)

t CEIc кEK Г'к, С

Табл. 1 содержит множество индексов оптимизационной модели, табл. 2 - список параметров и табл. 3 описывает переменные решения.

Множества индексов

Таблица 1

г ег Временной интервал

1 е I Пул ресурсов

р е Р Провайдер

V е V Р Тип виртуальных машин провайдера р

к е К Класс запросов

С е с Компонент

Таблица 2 Параметры модели

Лг Входящая рабочая нагрузка в момент г

а, к Процент запросов класса к в рабочей нагрузке

У Минимально допустимый процент запросов, перенаправляемых провайдеру р

Рк,С Вероятность обработки компонентом с класса запросов к

№р;о,к,с Максимальная интенсивность обработки запросов класса к компонентом с, поддерживаемым виртуальными машинами типа о провайдера р

ик Множество компонентов, обрабатывающих запросы класса к

I С Множество компонентов, размещенных на том же пуле ресурсов, что и с

с г Цена единственной виртуальной машины типа о провайдера р в момент времени г

м р,о Память виртуальных машин типа о провайдерар

{{м}р,1 Ограничение памяти для пула ресурсов 1 провайдера р

Максимальное допустимое среднее время ответа для запросов класса к в компоненте с

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

Таблица 3

Целевые переменные

X р Двоичная переменная, равная 1, если выбран провайдер р, и 0 в противном случае

ЛР, Количество запросов в секунду, перенаправляемых провайдеру р во временном интервале г

Двоичная переменная, равная 1, если тип виртуальных машин V используется в пуле ресурсов 1 провайдера р, и 0 в противном случае

Количество виртуальных машин типа V в пуле ресурсов 1 в момент времени г

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

Для каждого пула ресурсов:

- условия (13) и (3) гарантируют, что будет выбран только один тип виртуальных машин;

- условие (12) задает целочисленность количества виртуальных машин;

- условие (4) гарантирует не пустое множество виртуальных машин, а (5) их гомогенность;

- условия (2) и (14) определяют, что будут выбраны хотя бы ¥ облачных провайдеров;

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

Наконец, (6) и (8) представляют ограничения на память и время ответа соответственно, в то время как (7) является условием равновесия для модели М/О/1.

Как было обсуждено ранее, для оценки среднего времени ответа облачного приложения мы моделируем каждый пул ресурсов как очередь М/О/1. Так или иначе, в общем запрос класса & обрабатывается более чем одним компонентом. Пусть Л н = а&Л ( - входящая рабочая нагрузка во время г для класса запроса &, перенаправляемая провайдеру р, и Лр & с ¿ = рк сЛр & г - интенсивность входного потока запросов класса & в компонент с. Время ответа для запросов класса & может быть получено как:

Rkt = 2 а * = I Pkcc-^i—-, (16)

cEUk cEUk 2 2 P,k,c,t

ZjCEI^Zjk

cEIc ¿J k EK ,, z

^p, v ,k , cP, ic, v,t

где Uk - множество компонентов, обрабатывающих запрос k, Ic отражает множество компонентов, которые размещены на той же виртуальной машине, что и с. Другими словами, среднее время ответа получено суммированием времени, потраченного запросом на каждый компонент, умноженным на вероятность того, что запрос действительно будет обработан компонентом. Заметим, что время ответа для компонента с во время t зависит от типа и количества виртуальных машин в этот момент в пуле, в котором расположен этот компонент.

С целью упрощения уравнения (16) рассмотрим тип виртуальных машин с наименьшей скоростью CPU и, приняв его за опорный, вычислим интенсивность обслуживания для каждого класса и компонента ^kc. Тогда интенсивность обслуживания для остальных типов виртуальных машин может быть выражена через интенсивность обслуживания опорного как:

№p,v,k,c - №k,cSp,ic - №k,c 2 Sp.vwp,ic,v

(17)

где Б - отношение скоростей между опорным типом и типом V провайдера р, в то время как ¡с - индекс пула ресурсов, в котором размещен компонент с.

Пусть грН - количество виртуальных машин некоторого типа (только один тип может быть выбран согласно (3)) для пула ресурсов I во время £ Тогда выполняются следующие соотношения:

£р,и = ^ 2р■ ' • у •' , (18)

1

vEVp

№p,v,k,cZp,ic,v,t №k,cS p,icZp,ic,t №k,c ^ Sp,vZp,ic,v,t

(19)

Время ответа для запроса к, обрабатываемого компонентом с, поддерживаемым виртуальными машинами типа V, из предположения М/С/1 может быть вычислено как:

veVp

Кк,с,г = '

(20)

р,к,с,г

РксЯр^

к,с Р,'сР,'с,г

Через замену (17) и (19) в (16) мы можем записать следующее ограничение на время ответа для класса к.

Кк.г = 1 рк,сКк,с,г = 1

Рк.с

1

Ик.А

1 -

р .'

8 7

р, 'с^р. 'с.'

1 1

' Рк. с

• {КУк . (21)

Уравнение (21) нелинейно из-за присутствия Б г ,г в знаменателе. С целью получения линейной модели, которая ' могла бы быть эффективно решена с помощью соответствующего программного обеспечения (например СРЬБХ), разобьем его на множество более строгих условий, задающих ограничения на время ответа для каждого компонента, обрабатывающего запрос.

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

I -

дт * *

Ркл

0, если иначе. И пусть:

если с принадлежит пути, или

(22)

сВП

сеи

1

Г

к

с.и

{К}к, с = тш Ч, с, А

(23)

Вместо использования ограничения (20) для времени ответа введем семейство ограничений:

{Я}^ = {*Ь,с (24)

и после нескольких простых алгебраических преобразований получим ограничение (8).

Наконец, условие (7) представляет собой условие равновесия для модели М/С/1, полученное из условия (20). Оно гарантирует, что знаменатель в (20) будет больше нуля.

Алгоритм локального поиска

Теперь опишем алгоритм локального поиска, используемый на следующем шаге гибридной метаэвристической оптимизации для повышения качества полученных результатов. Основным отличием между двумя оптимизационными процессами является то, что локальный поиск основан на модели ЬЦМ, являющейся более комплексной и точной, чем модель М/С/1, используемая в оптимизационной проблеме на предыдущем шаге. Другое отличие заключается в том, как алгоритм локального поиска просматривает пространство возможных альтернатив. Он использует эвристический подход, который разбивает проблему на два уровня, определяя типы виртуальных машин на верхнем уровне и их количество на нижнем.

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

Заключение

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

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

Примечания

Cm.: Becker S., Koziolek H., Reussner R. The Palladio Component Model for Model-driven Performance Prediction // Journal of Systems and Software. 2009. Vol. 82 (1). P. 3-22.

Cm.: Neilson J.E., Woodside C.M., Petriu D.C., Majumdar S. Software Bottlenecking in Client-server Systems and Rendezvous Networks // IEEE Transactions on Software Engineering. 1995. Vol. 21 (9). P. 776-782.

Franks G., Hubbard A., Majumdar S., Neilson J., Petriu D., Rolia J., Woodside M. A Toolset for Performance Engineering and Software Design of Client-server Systems // Performance Evaluation. 1996. Vol. 24. P. 1-2.

Cm.: Birke R., Chen L.Y., Smirni E. Data Centers in the Cloud: A Large Scale Performance Study // Proceedings of the 5th IEEE International Conference on Cloud Computing. Honolulu, 2012. P. 336-343.

Cm.: Celesti A., Tusa F., Villari M., Puliafito A. How to Enhance Cloud Architectures to Enable Cross-Federation - Cloud Computing (CLOUD) // Proceedings of the 3rd IEEE International Conference on Cloud Computing. Miami, FL, 2010. P. 337-345.

Cm.: Kleinrock L. Time-shared Systems: A Theoretical Treatment // Journal of the ACM. 1967. Vol. 14 (2). P. 242-261.

2

3

4

5