МЕТОДИ ОЦІНЮВАННЯ ПРОЕКТІВ ХМАРНИХ СЕРВІСІВ ЗА РІВНЕМ QоS

Актуальные проблемы экономики и финансов: тезисы докладов XІІ Международной научно-практической конференции (Киев-Санкт-Петербург-Вена, 31 июля 2018)

Секція: Математичні методи, моделі  та інформаційні технології в економіці

Камінський Олег Євгенович

кандидат економічних наук,

доцент кафедри інформаційного менеджменту

 Київський національний економічний  університет імені Вадима Гетьмана

м. Київ, Україна

МЕТОДИ ОЦІНЮВАННЯ ПРОЕКТІВ ХМАРНИХ СЕРВІСІВ ЗА РІВНЕМ QоS

Для розробки та проектування хмарних сервісів необхідним є прийняття значної кількості технічних і управлінських рішень. Завдання ускладняється тим, що кількісний і якісний розвиток хмарної парадигми привів до потреби розглядати її як складну інформаційну систему, котра може охоплювати тисячі користувачів і містити сотні тисяч розподілених елементів, котра підтримує динамічне масштабування, котра використовує різні комунікаційні та обчислювальні сервіси та постійно взаємодіє з іншими інформаційними системами. Отже, очевидна актуальність вивчення економічного аспекту процесів порівняння, вибору і використання хмарних сервісів у діяльності підприємств і організацій. На рівні SaaS власники сервісів мають можливість контролювати якість обслуговування (QoS), для того щоб провадити оптимізацію відповідно до власних завдань [1]. Залежно від сфери використання та типу хмарних сервісів можуть використовуватися різні показники якості QoS, такі як час відгуку на запити користувача.

Задача вибору структурних елементів хмарного сервісу має наступний вигляд:

       (1)

Потрібно вибрати структурні елементи мінімальної вартості, які дозволять реалізувати вказаний проект хмарного сервісу. Першим обмеженням MCT є набір допустимих композицій структурних елементів. Друге обмеження гарантує, що характеристики хмарного сервісу, які ми можемо отримати, вибравши певну групу структурних елементів, не можуть бути нижче, ніж специфікації сервісу, визначені технічним завданням. Третє обмеження встановлює, що функції сервісу можуть бути реалізовані за допомогою вибраного набору структурних елементів сервісу.

Характеристики проекту сервіса включають в себе функціональні та нефункціональні вимоги. Функціональні вимоги – це опис глобальних необхідних функцій сервісу на високому рівні абстракції. Нефункціональні вимоги- це коефіцієнти, задані користувачем для кожного параметра QoS, виходячи з його пріоритету. Сума всіх призначених значень не має перевищувати 10.  Як цільову функцію ми використаємо модель сукупної вартість володіння хмарним сервісом ТСО (Total Cost of Ownership). Модель ТСО складається з розрахунку таких показників: вартість оренди хмарних ресурсів; вартість навчання персоналу; затрати праці на побудову сервісу; затрати праці на експлуатацію сервісу; затрати праці користувачів на роботу із сервісом.

Розглянемо приклад. Ми розробляємо кілька робочих проектів хмарного сервісу, що відповідають функціональним вимогам користувача. Ми розглядаємо обмеження структурних елементів перед створенням робочих проектів. На рис.1 наведено схему аналізу проектів сервісу, сформовану для попередньо описаного хмарного сервісу "движок блога".

Рис. 1. Схема аналізу проектів розробки хмарного сервісу «Блог»

Схема показує, що фреймворк WordPress для розробки блогу не може використовувати СУБД Oracle; оскільки опис сервіса WordPress визначає жорсткі обмеження щодо баз даних, та вимагає використання СУБД MySQL. Аналіз також показує, що фреймворк Drupal, як структурний елемент сервісу обов'язково потребує використання баз даних, але може використовувати різні СУБД, а не тільки конкретну, як у випадку з WordPress. Після ранжування робочих проектів хмарного сервісу, композиція структурних елементів з найвищим рейтингом розгортається на попередньо обраному IaaS. Для проектів хмарного сервісу ми обчислюємо рейтинг відповідності структурних елементів вимогами QoS. Ранг проектів сервісів розраховується на основі коефіцієнтів, пов'язаних із атрибутами QoS, і призначається користувачем на основі його пріоритетів. Доступні два сценарії ранжування коефіцієнтів.

Наприклад, – і-й проект хмарного сервісу, а  – j-й індикатор QoS, а RN – ранг проекту:

     (2)

Сценарій №1: чим вище значення атрибута (наприклад, доступність послуги), тим кращим є цей проект сервісу. У цьому випадку ранг, пов'язаний із цим атрибутом QoS для даного сервісу, розраховується таким чином:

   (3)

де:

Z - це значення атрибута QoS для даного проекта сервісу;

 - це максимальне значення атрибуту серед всіх проектів;

К - це коефіцієнт, раніше закріплений за атрибутом замовником.

Сценарій №2: чим менше значення атрибута (наприклад, час відгуку), тим кращим є цей проект сервісу. У цьому випадку ранг, пов'язаний із цим атрибутом для заданого проекта, розраховується таким чином:

   (4)

Припустимо, що показник RN() буде глобальним рейтингом щодо всіх показників QoS для і-го проекту хмарного сервісу. При виборі проекта сервісу перевага надається проектам з найвищим рейтингом.

    (5)

В табл.1 наведено параметри QoS, пов'язані з двома відповідними проектами хмарного сервісу, сформованими для попередньо описаного сценарію "движок блога".

Таблиця 1

Розраховані значення коефіцієнтів QoS для проектів хмарного сервісу

Використовуючи описаний вище спосіб розрахунку рангу коефіцієнтів, ми обчислюємо рейтинг, пов'язаний із проектами хмарного сервісу "движок блогу", відповідно на базі використання фреймворків WordPress і Drupal. Дані підрахунку свідчать, що проект сервісу, структурним елементом якого буде фреймворк Drupal має кращий рейтинг, ніж проект з використанням фреймворку WordPress.

Ми не розглядаємо ранг лише одного структурного елементу хмарного сервісу, а також складаємо ранг кожного елемента сервіса, що бере участь у робочому проекті. Визначається рейтинг структурних елементів сервісу, які знаходяться на рівнях PaaS та IaaS хмари, після чого визначається глобальний рейтингу всього проекту. В процесі розробки проекту та вибору технологій альтернативні варіанти порівнюються за QoS.  Розгортається в хмарі відповідно проект з найвищим рейтингом. Використання комплексу економічних, математичних та імітаційних моделей для вирішення окреслених проблем допоможе розробникам приймати економічно обґрунтовані рішення щодо розробки й упровадження хмарних сервісів.

Література

1. G. Singh, P. Jain and I. Gulati, “Process Model for Cloud Service Engineering”, International Journal of Computer Applications, vol. 36, no. 8, (2011), pp. 24-29.