To the issue of optimizing cloud computing based on their cost

The paper offers an approach to the architectural settings of parallel computing on the cloud platform, which allows in semi-automatic mode to perform optimization of a parallel program with the goal function of minimum cost of computations. To solve the optimization problem, it is proposed to use l...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2021
Автори:	Doroshenko, А.Yu., Novak, O.S.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Інститут програмних систем НАН України 2021
Теми:	cloud platforms parallel calculations optimization methods linear programming cost of computations UDC 004.4'24
Онлайн доступ:	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/435
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Problems in programming
Завантажити файл:

Репозитарії

Problems in programming

id	pp_isofts_kiev_ua-article-435
record_format	ojs
resource_txt_mv	ppisoftskievua/ca/7d9aa06b4cf13c91d36cd7cacf0af0ca.pdf
spelling	pp_isofts_kiev_ua-article-4352024-04-26T22:46:30Z To the issue of optimizing cloud computing based on their cost До питання оптимізації хмарних обчислень з урахуванням їх вартості Doroshenko, А.Yu. Novak, O.S. cloud platforms; parallel calculations; optimization methods; linear programming; cost of computations UDC 004.4'24 хмарні платформи; паралельні обчислення, методи оптимізації; лінійне програмування; вартість обчислень УДК 004.4'24 The paper offers an approach to the architectural settings of parallel computing on the cloud platform, which allows in semi-automatic mode to perform optimization of a parallel program with the goal function of minimum cost of computations. To solve the optimization problem, it is proposed to use linear programming and an available software solver, which with the help of the method of branches and boundaries in semi-automatic mode selects the value of the architecture parameters of the program configuration which significantly affect the cost of calculations. Therefore, the method of auto-tuning developed by the authors earlier is generalized and spread to the complex of services performed on the cloud platform. An analytical test was conducted on the model of cloud multiprocessor cluster, which presents the possibility of significantly reducing the cost of cloud computing due to the optimizations carried out.Prombles in programming 2020; 4: 14-21 В роботі запропоновано підхід до архітектурних налаштувань паралельних обчислень на хмарній платформі, що дозволяє в напівавтоматичному режимі здійснити оптимізацію паралельної програми з цільовою функцією мінімуму вартості обчислень. Для розв’язання оптимізаційної задачі використано лінійне програмування і доступний програмний солвер, який за допомогою методу гілок і границь в напівавтоматичному режимі підбирає значення архітектурних параметрів конфігурації програми, що істотно впливають на вартість обчислень. Таким чином узагальнено попередній метод автотюнінгу, що розроблявся авторами раніше, та поширено його на випадок комплексу сервісів, що виконуються на хмарній платформі. Проведено аналітичне випробування розробленої системи на моделі хмарного мультипроцесорного кластеру, що показує можливість суттєвого скорочення вартості хмарних обчислень внаслідок проведених оптимізацій.Prombles in programming 2020; 4: 14-21 Інститут програмних систем НАН України 2021-01-25 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/435 10.15407/pp2020.04.014 PROBLEMS IN PROGRAMMING; No 4 (2020); 14-21 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2020); 14-21 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2020); 14-21 1727-4907 10.15407/pp2020.04 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/435/439 Copyright (c) 2021 PROBLEMS IN PROGRAMMING
institution	Problems in programming
baseUrl_str	https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date	2024-04-26T22:46:30Z
collection	OJS
language	Ukrainian
topic	cloud platforms parallel calculations optimization methods linear programming cost of computations UDC 004.4'24
spellingShingle	cloud platforms parallel calculations optimization methods linear programming cost of computations UDC 004.4'24 Doroshenko, А.Yu. Novak, O.S. To the issue of optimizing cloud computing based on their cost
topic_facet	cloud platforms parallel calculations optimization methods linear programming cost of computations UDC 004.4'24 хмарні платформи; паралельні обчислення методи оптимізації; лінійне програмування; вартість обчислень УДК 004.4'24
format	Article
author	Doroshenko, А.Yu. Novak, O.S.
author_facet	Doroshenko, А.Yu. Novak, O.S.
author_sort	Doroshenko, А.Yu.
title	To the issue of optimizing cloud computing based on their cost
title_short	To the issue of optimizing cloud computing based on their cost
title_full	To the issue of optimizing cloud computing based on their cost
title_fullStr	To the issue of optimizing cloud computing based on their cost
title_full_unstemmed	To the issue of optimizing cloud computing based on their cost
title_sort	to the issue of optimizing cloud computing based on their cost
title_alt	До питання оптимізації хмарних обчислень з урахуванням їх вартості
description	The paper offers an approach to the architectural settings of parallel computing on the cloud platform, which allows in semi-automatic mode to perform optimization of a parallel program with the goal function of minimum cost of computations. To solve the optimization problem, it is proposed to use linear programming and an available software solver, which with the help of the method of branches and boundaries in semi-automatic mode selects the value of the architecture parameters of the program configuration which significantly affect the cost of calculations. Therefore, the method of auto-tuning developed by the authors earlier is generalized and spread to the complex of services performed on the cloud platform. An analytical test was conducted on the model of cloud multiprocessor cluster, which presents the possibility of significantly reducing the cost of cloud computing due to the optimizations carried out.Prombles in programming 2020; 4: 14-21
publisher	Інститут програмних систем НАН України
publishDate	2021
url	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/435
work_keys_str_mv	AT doroshenkoayu totheissueofoptimizingcloudcomputingbasedontheircost AT novakos totheissueofoptimizingcloudcomputingbasedontheircost AT doroshenkoayu dopitannâoptimízacííhmarnihobčislenʹzurahuvannâmíhvartostí AT novakos dopitannâoptimízacííhmarnihobčislenʹzurahuvannâmíhvartostí
first_indexed	2024-09-16T04:07:57Z
last_indexed	2024-09-16T04:07:57Z
_version_	1818568473814499328
fulltext	Інструментальні засоби і середовища програмування © А.Ю. Дорошенко, О.С. Новак, 2020 14 ISSN 1727-4907. Проблеми програмування. 2020. № 4 УДК 004.4'24 https://doi.org/10.15407/pp2020.04.014 А.Ю. Дорошенко, О.С. Новак ДО ПИТАННЯ ОПТИМІЗАЦІЇ ХМАРНИХ ОБЧИСЛЕНЬ З УРАХУВАННЯМ ЇХ ВАРТОСТІ Запропоновано підхід для архітектурних налаштувань паралельних обчислень на хмарній платформі, що дозволяє в напівавтоматичному режимі здійснити оптимізацію паралельної програми з цільовою функцією мінімуму вартості обчислень. Для розв’язання оптимізаційної задачі використано лінійне програмування, що дозволяє підбирати значення архітектурних параметрів конфігурації програми, що істотно впливають на вартість обчислень. Проведено аналітичне випробування розробленого підходу на моделі хмарного мультипроцесорного кластеру, що показує можливість суттєвого скорочення вар- тості хмарних обчислень внаслідок проведених оптимізацій. Ключові слова: хмарні платформи, паралельні обчислення, методи оптимізації, лінійне програмування, вартість обчислень. Вступ Хмарні обчислення на сьогодні ста- ли однією з найпопулярніших розподі- лених обчислювальних парадигм. Вони виступають моделлю для забезпечення зручного доступу до мережі та надійного пулу настроюваних обчислювальних ресурсів [1, 2]. Постачальники хмарних обчислень пропонують широкий спектр послуг на різ- них рівнях: інфраструктурному, платформ- ному та сервісному (відповідно, IaaS, PaaS та SaaS). Еластичність є важливою харак- теристикою, яка відрізняє хмарні об- числення від інших розподілених обчис- лювальних моделей. Функція еластичності дозволяє хмарним платформам ефективно обробляти різні навантаження, не пору- шуючи нормального стану програми. Вона означає не тільки те, що процеси підгото- вки та розподілу ресурсів можуть бути ре- алізовані автоматично та динамічно, але також і можливість гнучкої оцінки еконо- мічних показників роботи хмарних систем, таких як вартість обчислень [3]. Користувачі платять за хмарний сервіс, виходячи з потужності та часу ви- користання послуг на базі інфраструктури постачальника. Оскільки хмарні сервіси стають все більш і більш популярними, це привертає величезну увагу лідерів поста- чальників хмарної інфраструктури, таких як Microsoft, Google і Amazon, спонукаючи їх до роботи із все більш централізованими центрами обробки даних. Сучасний хмар- ний центр обробки даних оснащений значною кількістю обчислювального обла- днання, тому навіть розміщення віртуаль- них контейнерів по реальним серверам вже саме по собі являє собою дуже складну оп- тимізаційну задачу [4]. Крім того, все це обладнання споживає значну кількість електроенергії, що спричиняє різке зрос- тання експлуатаційних витрат на хмарні дата-центри, які звичайно перекладаються на споживачів хмарних сервісів. Велике енергоспоживання дата-центрів веде також до збільшення викидів вуглекислого газу (СО2) та погіршення якості навколишнього середовища. Таким чином, зниження енер- госпоживання хмарними дата-центрами і, залом, оптимізація хмарних обчислень є актуальною задачею для розробників хма- рних сервісів. У попередніх роботах авторів [5–6] розроблявся метод самоналаштування (ав- тотюнінгу) паралельних програм на цільо- ву платформу, націлений на досягнення максимальної швидкодії конкретної прик- ладної програми на конкретну архітектуру обчислювальної системи. У цій роботі запропоновано уза- гальнений підхід для самоналаштування паралельних обчислень на хмарній плат- формі, що дозволяє в напівавтоматичному режимі здійснити оптимізацію потоку па- ралельних завдань з цільовою функцією мінімуму вартості обчислень. Як буде по- казано далі, для розв’язання оптимізацій- ної задачі може бути використано лінійне програмування, що дозволяє у напівавто- Інструментальні засоби і середовища програмування 15 матичному режимі підбирати значення параметрів конфігурації програми які істо- тно впливають на вартість обчислень. 1. Проблема оптимізації вартості обчислень Оптимізація вартості обчислень – складна задача, яка вимагає від експерта глибоких знань як про предметну область, так і про реальну систему, на якій задача буде виконуватись. А враховуючи те, що сучасна система може складатися з сотень серверів і досить широкого набору прог- рамних засобів – дуже швидко кількість необхідних знань починає перевищувати реальний обсяг даних, яким може оперува- ти людина. Навіть якщо таку систему було ко- лись налаштовано – майже завжди цього не достатньо. Хоча в світі існують системи, які безперервно і майже без оновлень пра- цювали десятками років – це рідше виклю- чення, аніж правило. Швидкі темпи розви- тку програмних та апаратних засобів приз- водять до того, що вже через короткий час може з'явитись необхідність оновити сис- тему, щоб вона працювала і за меншу ціну. А крім того, відбувається розширення мо- жливостей і збільшення навантаження на систему. І тоді система, оптимізована під існуюче колись навантаження, просто пе- рестає справлятися з поточним наванта- женням, що призводить до необхідності щоразу оптимізувати систему – вже під нові умови її роботи. Таким чином, для досягнення максимальної ефективності оптимізація системи повинна бути не оди- ничною задачею, а постійним процесом який має тривати впродовж всього циклу розвитку та супроводу системи. Для вирішення проблеми постійно- го процесу вдосконалення налаштування системи на вхідний потік задач на сьогодні просувається ідея безсерверних (serverless) обчислень [7], тобто, ідея такої хмарної архітектури, яка передбачає використання абстрагованих обчислювальних потужнос- тей без явного зазначення кількості та ха- рактеристик обладнання, що використову- ється. Такий підхід просувається як «сріб- ляна куля», що здатна вирішити усі про- блеми. Проте виявляється, що у реальному житті вона не працює, окрім відносно не- великих проектів, де ціна інфраструктури не йде у порівняння з ціною роботи експе- ртів. І як тільки постає питання оптимізації ціни хмарної інфраструктури – постає питання як це зробити найкраще. Окрім найбільш очевидного «менше обчислень – менша ціна» існує ще велика кількість проміжних варіантів того, як мо- жна масштабувати систему, від викорис- тання можливостей тільки апаратних пла- тформ (що частіше і відбувається у реаль- ній практиці користувачів) до зменшення алгоритмічної складності програм, що ре- алізують функціональні специфікації при- кладної задачі. Як приклади можна приве- сти горизонтальне масштабування невели- ких контейнерів ECS/EKS у Amazon (ана- логічна технологія, але з іншою назвою, є і в інших постачальників хмарної інфра- структури), а також використання так зва- них точкових екземплярів (spot instances) чи переніс частини обчислень у хмарні функції (Azure functions чи Amazon Lambda) [7]. І хоча кожен з цих кроків мо- же потребувати значної додаткової роботи, на великих масштабах економія від таких оптимізацій може буди досить значною. Але у цьому випадку складності додає той факт, що зазвичай відсутня можливість тонкого налаштування кожного з контей- нерів, тому вибирати доводиться з набору типових конфігурацій. Наприклад, для алгоритму що потребує 4vCPU та 8 RAM, є можливість використовувати EC2 в AWS розміром a1.xlarge з ціною 57$/місяць, але вже при необхідності в 5 vCPU доведеться використовувати a1.2xlarge з надлишковою потужністю (бо це вже 8 vCPU та 16 RAM) і вартістю в 104$/місяць [8]. А враховуючи, що зазвичай потужність vCPU пропорцій- на розміру контейнера, ручний підбір кон- фігурації, яка за мінімальну вартість зможе обробляти необхідну кількість даних, – надто складний і тривалий процес. Виходячи з вищенаведеного, можна зробити висновок, що для оптимізації сис- теми недостатньо тільки оптимізувати ал- горитм вирішення прикладної задачі. Для максимальної ефективності потрібно пра- вильно підбирати інфраструктуру та опти- мізувати алгоритм саме під цю інфрастру- Інструментальні засоби і середовища програмування 16 ктуру. І тут ми отримуємо класичну пробле- му – для того щоб оптимізувати алгоритм, нам спочатку потрібно зрозуміти, де і як він буде виконуватись, а для того щоб оптимізу- вати інфраструктуру, потрібно знати скільки саме ресурсів нам буде необхідно. Саме для вирішення цієї проблеми ми можемо ефективно використовувати метод автотюнінгу. Як механізми оптимі- зації з необхідним параметром такі тюнери можуть модифікувати вихідний код алго- ритму використовуючи правила перепису- вання/підстановки [9]. А вже маючи інфо- рмацію про правила заміни які може роби- ти система автотюнінгу (і як вони вплива- ють на ефективність системи відносно іншої конфігурації) – виникає можливість підібрати оптимальну конфігурацію. За допомогою подальшого вдосконалення правил автотюнера можна покращувати результат самоналаштування. 2. Пропонований підхід Налаштування мультисервісної сис- теми на її оптимальну за вартістю роботу – надто складна наукова та інженерна про- блема, щоб її вирішувати у всій її складно- сті. Тому тут найчастіше застосовують евристичні методи, що на жаль не вирішу- ють проблему і вимагають високої кваліфі- кації персоналу. Натомість при спрощеному поданні системи у вигляді незалежних ланок (у випадку, коли це взагалі можливо) (див. рис. 1) вирішення цієї задачі можна звести до розв'язання модифікованої класичної задачі про рюкзаки за умови, що треба мінімізувати загальну вартість рюкзаків, необхідних для збору усіх речей. Це кла- сична NP-повна задача з добре відомими підходами до вирішення. Зважаючи на відносно невелику кількість наявних варі- антів, у даному випадку для вирішення цієї задачі є можливість навіть не будувати специфічний солвер (програма-розв’язувач задач), а використати лінійне програму- вання з використанням існуючого солвера. Хоча такі програмні продукти загалом і поступаються специфічним алгоритмам, але завдяки своїй універсальності вони допомагають досить швидко якщо і не вирішити задачу повністю, то хоча б отри- мати наближений результат [10,11]. У на- шому випадку було використано саме python-mip солвер з використанням coin-or [12]. Він використовує підхід гілок і гра- ниць щоб отримати гарантовано оптима- льне рішення для заданої моделі. Рис. 1. Ланка архітектури для обробки даних мультисервісної платформи, здатна до горизонтального масштабування Інструментальні засоби і середовища програмування 17 Тобто, в нашому випадку задача зводиться до мінімізації виразу c c c C S P   при обмеженні, що ( , ) ( , ) , a c a c a A c C S T L     де A – набір алгоритмів, С – набір можли- вих конфігурацій інфраструктурної одини- ці, T – швидкодія, P – набір вартостей сер- вісів, L – мінімально необхідна швидкодія, S – кількість інфраструктурних одиниць. Тепер, маючи набір можливих кон- фігурацій інфраструктури та декілька оп- тимізованих для запуску алгоритмів, мо- жемо знайти оптимальну конфігурацію для навантаження системи. 3. Експеримент Як експеримент розглянута ланка типового рішення, яка представляє набір з декількох сервісів поміж декількох черг. Розбивши велику задачу на декілька таких ланок ми отримуємо досить просту для моніторингу та масштабування систему, яка в свою чергу може витримувати значне навантаження. Тобто, навіть маючи десят- ки-сотні сервісів для обробки даних, ми можемо аналізувати пропускні можливості системи за допомогою динаміки кількості даних, що проходять через черги. Це особ- ливо корисно коли потрібно порівняти загальну пропускну спроможність до та після якихось змін у налаштування окре- мих сервісів. А оскільки ланка сервіс-черга зазвичай не є вузьким місцем системи, то ми отримуємо можливість горизонтально- го масштабування системи без збільшення її складності. В табл. 1 наведено список усіх дос- тупних для експерименту контейнерів: де ram, cpu i network – величини що харак- теризують відносну кількість доступних контейнеру ресурсів. Як вже було сказано, у нас відсутня можливість точно налашто- вувати розміри усіх характеристик кон- тейнера, тому для порівняння ми викорис- товуємо коефіцієнти відносно найменшого з доступних контейнерів. Тобто, cpu = 2 означає, що vCPU у цьому контейнері має приблизно у 2 рази більшу потужність, ніж у контейнері мінімального розміру. Саме по цій причині всі подальші розрахунки наведені в умовних одиницях. Таблиця 1. Можливі конфігурації контейнерів. ціна назва ram cpu network 1 d_0 1 0.8 1.2 2 d_1 2 1.8 2.2 3 d_2 3 2.8 3.2 4 d_3 4 3.8 4.2 5 d_4 5 4.8 5.2 1 r_0 1.2 0.72 1.2 2 r_1 2.3 2.72 2.2 3 r_2 3.4 4.72 3.2 1 c_0 0.9 0.96 1.2 2 c_1 2.9 2.06 2.2 3 c_2 4.9 3.16 3.2 1 n_0 0.9 0.72 1.68 2 n_1 1.8 1.62 3.68 3 n_2 2.7 2.52 5.68 Окремо слід уточнити причини ви- користаного позначення контейнерів. Хоча й кількість варіантів розміру контейнера обмежена, але зазвичай компанії надають досить велику кількість можливих конфі- гурацій (у тому числі і специфічних для досить вузького кола задач). Тому склала- ся така практика, що формат назви являє собою поєднання префіксу, що характери- зує тип контейнера, і суфіксу, що характе- ризує його розмір (як у вищенаведеному прикладі з AWS EC2 a1.xlarge та a1.2xlarge). Саме такий підхід до позна- чень використаний і тут. В нашому випад- ку маємо типи d (default), r (ram), c (cpu) та n (network) та декілька розмірів для кожно- го з них. Тобто, r_0 означає мінімальний розмір контейнера із збільшеною кількіс- тю операційної пам’яті. Інструментальні засоби і середовища програмування 18 Тоді, маючи 2 алгоритми (а1 та а2) що вирішують нашу задачу різними спо- собами (та з різним споживанням ресурсів) ми можемо запустити солвер і знайти оп- тимальну конфігурацію для навантаження 2500 одиниць (табл. 2). Як можна побачи- ти – найдешевше необхідного результату можливо досягти використовуючи другий алгоритм на 833 контейнерах типу c_0 (мінімальній розмір, збільшена потужність cpu) та 1 контейнеру d_0 (звичайний кон- тейнер мінімального розміру). Зважаючи, що окрім оптимізації ін- фраструктури ми ще й використовуємо автотюнінг для оптимізації (прискорення) обчислювальних алгоритмів, ми не може- мо виключати, що в нас ще є можливість оновити тюнер таким чином, щоб покра- щити один з параметрів ціною деякого погіршення іншого. Тому є сенс додатково розглянути ще й можливість модифікацій характерис- тик алгоритму, коли погіршення значення одного параметру відбувається для покра- щення іншого. Тоді можна враховувати можливість автотюнера модифікувати ал- горитм (використовуючи правила підста- новки) при пошуку оптимальної конфігу- рації контейнерів. У цьому випадку, наша модель буде модифікована як ' n n na a a  ,  ' , , ,n n n na cpu ram network n N  ,  ' , , ,n n n na cpu ram network n N      , ne a e D   , 0 ne a e   , де D – максимальна можлива величина модифікації (табл. 3). Таблиця 2. Доступні конфігурації алгоритму ціна алг ram cpu net d_0 d_1 d_2 d_3 d_4 r_0 r_1 r_2 c_0 c_1 c_2 n_0 n_1 n_2 0 a1 0.1 0.2 0.7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 834 a2 0.3 0.3 0.4 1 0 0 0 0 0 0 0 833 0 0 0 0 0 Таблиця 3. Приклад найвигіднішої модифікації ціна алг ram cpu net d_0 d_1 d_2 d_3 d_4 r_0 r_1 r_2 c_0 c_1 c_2 n_0 n_1 n_2 0 а1 0.2 0.1 0.7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а2 0.1 0.1 0.8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а3 0.2 0.2 0.6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а4 0.1 0.3 0.6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а5 0.2 0.4 0.4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а6 0.2 0.3 0.5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а7 0.4 0.2 0.4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а8 0.3 0.2 0.5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 а9 0.4 0.3 0.3 0 0 0 0 0 0 0 0 0 1 1 0 0 0 699 а10 0.3 0.4 0.3 0 0 0 0 0 0 0 233 0 0 0 0 0 0 Інструментальні засоби і середовища програмування 19 Як можна побачити, для досягнення мінімальної ціни нам необхідно одночасно використовувати декілька версій алгорит- му, які будуть оптимізовані по різних па- раметрах. Тобто, використавши алгоритм a9 (зі зниженим на 25 % навантаженням на мережевий канал, та збільшенням необхід- ної пам'яті на 20 %) розгорнутий на двох контейнерах типу с_1 та c_2 одночасно з a10 (зі зниженим на 25 % навантаженням на мережевий канал та збільшеним на 20 % навантаженням на процесор) на 233 кон- тейнерах типу r_2 ми зможемо досягти зменшення загальної вартості на 15.5 %. Як наслідок, можна зробити висновок про наявність вузького місця такої конфігурації і його локалізації. Наприклад, в даному випадку це необхідна ширина мережевого каналу. Ще одним цікавим моментом є ви- користання пріоритетів характеристик для подальшої оптимізації. Це дозволяє оціни- ти очікуваний результат від оптимізацій різного типу. По перше, це дозволяє в першу чергу оптимізувати ті частини системи, де результат оптимізацій буде найбільш помітним. По друге – це дозво- ляє оцінити доречність подальших оптимі- зацій взагалі. У цьому випадку наші обме- ження на зміни будуть модифіковані до наступних: ne a e D   . Тобто, при D = 0.1, ми отримаємо (табл. 4), що відповідає зменшенню загальної вартості на 18.2 % при умові зменшення навантаження мережу на 25 %. Висновки В роботі запропоновано підхід до архітектурних налаштувань паралельних обчислень на хмарній платформі, що до- зволяє в напівавтоматичному режимі здій- снити оптимізацію паралельної програми з цільовою функцією мінімуму вартості обчислень. Для розв’язання оптимізацій- ної задачі використано лінійне програму- вання і доступний програмний солвер, який за допомогою методу гілок і границь в напівавтоматичному режимі підбирає значення архітектурних параметрів конфі- гурації програми, що істотно впливають на вартість обчислень. Таким чином узагальнено поперед- ній метод автотюнінгу, що розроблявся авторами раніше, та поширено його на випадок комплексу сервісів, що викону- ються на хмарній платформі. Проведено аналітичне випробу- вання розробленої системи на моделі хма- рного мультипроцесорного кластеру, що показує можливість суттєвого скорочення вартості хмарних обчислень внаслідок проведених оптимізацій. Таблиця 4. Приклад найвигіднішого напрямку оптимізації ціна алг ram cpu net d_0 d_1 d_2 d_3 d_4 r_0 r_1 r_2 c_0 c_1 c_2 n_0 n_1 n_2 0 а1 0.1 0.1 0.7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а2 0.1 0.2 0.6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а3 0.2 0.3 0.4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 а4 0.3 0.2 0.4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 682 а5 0.3 0.3 0.4 0 0 0 0 0 0 0 341 0 0 0 0 0 0 Інструментальні засоби і середовища програмування 20 Література 1. Duan Yucong, Fu Guohua, Zhou Nianjun, Sun Xiaobing, Narendra Nanjangud, Hu Bo (2015). "Everything as a Service (XaaS) on the Cloud: Origins, Current and Future Trends". 2015 IEEE 8th International Conference on Cloud Computing. IEEE. P. 621–628. doi:10.1109/CLOUD.2015.88 2. Singh Jatinder, Powles Julia, Pasquier, Thomas, Bacon Jean (July 2015). "Data Flow Management and Compliance in Cloud Computing". IEEE Cloud Computing. 2(4). P. 24–32. doi:10.1109/MCC.2015.69 3. Zelenyuk V. (2013). "A scale elasticity measure for directional distance function and its dual: Theory and DEA estima- tion". European Journal of Operational Research. 228(3). P. 592–600. doi:10.1016/j.ejor.2013.01.012 4. Azizi S., Shojafar M., Abawajy J. and Buyya R. "GRVMP: A Greedy Randomized Algorithm for Virtual Machine Placement in Cloud Data Centers," in IEEE Systems Journal, doi: 10.1109/JSYST.2020.3002721. 5. Anatoliy Doroshenko, Pavlo Ivanenko, Ol- eksandr Novak, and Olena Yatsenko, A Mixed Method of Parallel Software Auto- Tuning Using Statistical Modeling and Machine Learning in: 14th International Conference, ICTERI 2018, Kyiv, Ukraine, May 14–16, 2018 (Vadim Ermolayev, Mari Carmen Suárez-Figueroa, Vitaliy Yakovyna, Heinrich C. Mayr, Mykola Nikitchenko, Aleksander Spivakovsky (Eds.)), Revised Selected Papers, Series: Communications in Computer and Information Science, Springer, Vol. 1007. 2019. https://doi.org/10.1007/978- 3-030-13929-2_6. 6. Дорошенко А.Ю., Іваненко П.А., Новак О.С., Старушик А.М. Автотьюнінг парале- льних програм з використанням системи аналізу даних IBM Watson Analytics. Про- блеми програмування. 2018. № 1. С. 46–54. 7. Neil Savage. Going serverless. Communica- tions of the ACM. 2018. Vol. 61(2). P. 15–16. doi:10.1145/3171583 8. https://calculator.aws/#/createCalculator 9. Андон Ф.И., Дорошенко А.Е., Жереб К.А., Шевченко Р.С., Яценко Е.А. Методы алге- браического программирования. Формаль- ные методы разработки параллельных программ. Киев: Наукова думка. 2017. 440 с. 10. Gleixner Ambros, Hendel Gregor, Gamrath Gerald, Achterberg Tobias, Bastubbe Mi- chael, Berthold Timo, Christophel Philipp M., Jarck Kati, Koch Thorsten, Linderoth Jeff, L’ubbecke Marco, Mittelmann Hans D., Ozyurt Derya, Ralphs Ted K., Salvagnin Domenico and Shinano Yuji. MIPLIB 2017: Data-Driven Compilation of the 6th Mixed- Integer Programming Library. 2020 Mathematical Programming Computation. http://www.optimization-onli- ne.org/DB_FILE/2019/07/7285.pdf 11. Rimmi Anand, Divya Aggarwal & Vijay Kumar (2017). A comparative analysisof optimization solvers. Journal of Statistics and Management Systems. 20:4. P. 623–635. DOI:10.1080/09720510.2017.1395182 12. A Comparative Analysis of Optimization Solvers. Available from: https://www.researchgate.net/publication/ 314750497_A_Comparative_Analysis_of_Op timization_Solvers [accessed Nov 14 2020]. References 1. Duan Yucong, Fu Guohua, Zhou Nianjun, Sun Xiaobing, Narendra Nanjangud, Hu Bo (2015). "Everything as a Service (XaaS) on the Cloud: Origins, Current and Future Trends". 2015 IEEE 8th International Conference on Cloud Computing. IEEE. P. 621–628. doi:10.1109/CLOUD.2015.88 2. Singh Jatinder, Powles Julia, Pasquier, Thomas, Bacon Jean (July 2015). "Data Flow Management and Compliance in Cloud Computing". IEEE Cloud Compu¬ting. 2(4). P. 24–32. doi:10.1109/MCC.2015.69 3. Zelenyuk V. (2013). "A scale elasticity measure for directional distance function and its dual: Theory and DEA estimation". European Journal of Operational Research. 228(3). P. 592–600. doi:10.1016/j.ejor.2013.01.012 4. Azizi S., Shojafar M., Abawajy J. and Buyya R. "GRVMP: A Greedy Randomized Algorithm for Virtual Machine Placement in Cloud Data Centers," in IEEE Systems Journal, doi: 10.1109/JSYST.2020.3002721. 5. Anatoliy Doroshenko, Pavlo Ivanenko, Oleksandr Novak, and Olena Yatsenko, A Mixed Method of Parallel Software Auto- Tuning Using Statistical Modeling and Machine Learning in: 14th International Conference, ICTERI 2018, Kyiv, Ukraine, https://en.wikipedia.org/wiki/IEEE https://en.wikipedia.org/wiki/Doi_(identifier) https://www.repository.cam.ac.uk/handle/1810/255049 https://www.repository.cam.ac.uk/handle/1810/255049 https://www.repository.cam.ac.uk/handle/1810/255049 https://en.wikipedia.org/wiki/Doi_(identifier) https://doi.org/10.1109%2FMCC.2015.69 https://en.wikipedia.org/wiki/Doi_(identifier) https://doi.org/10.1016%2Fj.ejor.2013.01.012 https://doi.org/10.1007/978-3-030-13929-2_6 https://doi.org/10.1007/978-3-030-13929-2_6 https://ru.wikipedia.org/wiki/Communications_of_the_ACM https://ru.wikipedia.org/wiki/Communications_of_the_ACM https://ru.wikipedia.org/wiki/Doi https://dx.doi.org/10.1145%2F3171583 http://www.optimization-online.org/DB_FILE/2019/07/7285.pdf http://www.optimization-online.org/DB_FILE/2019/07/7285.pdf Інструментальні засоби і середовища програмування 21 May 14–16, 2018 (Vadim Er¬molayev, Mari Carmen Suárez-Figueroa, Vitaliy Yakovyna, Heinrich C. Mayr, Mykola Nikitchenko, Aleksander Spivakovsky (Eds.)), Revised Selected Papers, Series: Communications in Computer and Information Science, Springer, Vol. 1007, 2019. https://doi.org/10.1007/978- 3-030-13929-2_6 6. Doroshenko A., Ivanenko P., Novak O., Starushyk O. Autotuning of parallel programs using the data analysis system IBM Watson Analytics. Problems of Programming. 2018. N 1. P. 46–54. 7. Neil Savage. Going serverless. Commu- nications of the ACM. 2018. Vol. 61(2). P. 15–16. doi:10.1145/3171583 8. https://calculator.aws/#/createCalculator 9. Andon P.I. et al. (2017). Methods of algebraic programming. Formal methods of parallel program development. Kyiv: Naukova dumka. (in Russian) 10. Gleixner Ambros, Hendel Gregor, Gamrath Gerald, Achterberg Tobias, Bastubbe Mi- chael, Berthold Timo, Christophel Philipp M., Jarck Kati, Koch Thorsten, Linderoth Jeff, L’ubbecke Marco, Mittelmann Hans D., Ozyurt Derya, Ralphs Ted K., Salvagnin Domenico and Shinano Yuji. MIPLIB 2017: Data-Driven Compilation of the 6th Mixed- Integer Programming Library. 2020 Mathematical Programming Computation. http://www.optimization-onli- ne.org/DB_FILE/2019/07/7285.pdf 11. Rimmi Anand, Divya Aggarwal & Vijay Kumar (2017). A comparative analysisof optimization solvers. Journal of Statistics and Management Systems. 20:4. P. 623–635. DOI:10.1080/09720510.2017.1395182 12. A Comparative Analysis of Optimization Solvers. Available from: ht- tps://www.researchgate.net/publication/ 314750497_A_Comparative_Analysis_of_Op timization_Solvers [accessed Nov 14 2020]. Одержано 15.11.2020 Про авторів: Дорошенко Анатолій Юхимович, доктор фізико-математичних наук, професор, завідувач відділу теорії комп'ютерних обчислень Інституту програмних систем НАН України, професор кафедри автоматики і управління в технічних системах НТУУ "КПІ імені Ігоря Сікорського". Кількість наукових публікацій в українських виданнях – понад 180. Кількість наукових публікацій в зарубіжних виданнях – понад 100. Індекс Гірша – 6. http://orcid.org/0000-0002-8435-1451, Новак Олександр Сергійович, молодший науковий співробітник. Кількість наукових публікацій в українських виданнях – 11. Кількість наукових публікацій в зарубіжних виданнях – 1. https://orcid.org/0000-0002-1665-7360. Місце роботи авторів: Інститут програмних систем НАН України, 03187, м. Київ-187, проспект Академіка Глушкова, 40. E-mail: doroshenkoanatoliy2@gmail.com http://www.optimization-online.org/DB_FILE/2019/07/7285.pdf http://www.optimization-online.org/DB_FILE/2019/07/7285.pdf

To the issue of optimizing cloud computing based on their cost

Репозитарії

Схожі ресурси