Особливості реалізації сервіс-орієнтованих додатків у хмарі

Найбільший європейський проект зі створення Європейської відкритої науково-дослідницької хмари (European Open Science Cloud for Research, EOSC), що розпочався в 2017 р. і базується на сервіс-орієнтованому підході, мотивує дослідження технологій розміщення сервіс-орієнтованих структур (SOA) прикладни...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2017
Автор:	Петренко, О.О.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Навчально-науковий комплекс "Інститут прикладного системного аналізу" НТУУ "КПІ" МОН та НАН України 2017
Назва видання:	Системні дослідження та інформаційні технології
Теми:	Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи
Онлайн доступ:	https://nasplib.isofts.kiev.ua/handle/123456789/151175
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Особливості реалізації сервіс-орієнтованих додатків у хмарі / О.О. Петренко // Системні дослідження та інформаційні технології. — 2017. — № 3. — С. 29-42. — Бібліогр.: 26 назв. — укр.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	nasplib_isofts_kiev_ua-123456789-151175
record_format	dspace
spelling	nasplib_isofts_kiev_ua-123456789-1511752025-02-09T12:50:09Z Особливості реалізації сервіс-орієнтованих додатків у хмарі Особенности реализации сервис-ориентированных приложений в облаке Features of service-oriented applications in the cloud Петренко, О.О. Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи Найбільший європейський проект зі створення Європейської відкритої науково-дослідницької хмари (European Open Science Cloud for Research, EOSC), що розпочався в 2017 р. і базується на сервіс-орієнтованому підході, мотивує дослідження технологій розміщення сервіс-орієнтованих структур (SOA) прикладних додатків у хмарі. Досліджено базові відмінності традиційних SOA першого покоління (на основі веб-сервісів з уніфікованими протоколами зв’язку) і хмарних SOA нового покоління (на основі мікросервісів з контейнерами), які необхідно враховувати під час переміщення SOA застосувань у хмару. Крупнейший проект по созданию Европейской открытого научно-исследовательского облака (European Open Science Cloud for Research, EOSC), который начался в 2017 г. и базируется на сервис-ориентированном подходе, мотивирует исследования технологий размещения SOA прикладных приложений в облаке. Приведены базовые различия традиционных SOA первого поколения (на основе веб-сервисов с унифицированными протоколами связи) и облачных SOA нового поколения (на основе микросервисов с контейнерами), которые необходимо учитывать при перемещении SOA приложений в облако. The largest European project of building the European Open Science Cloud for Research (EOSC), which started in 2017 and is based on a service-oriented approach, motivates research on moving SOA practical applications to the cloud. Therefore, in this work, the basic differences between the traditional first generation SOA (based on Web services with standardized communications protocols) and the new generation of cloud SOA (based on microservices and containers) that must be taken into account during moving SOA applications to the cloud. 2017 Article Особливості реалізації сервіс-орієнтованих додатків у хмарі / О.О. Петренко // Системні дослідження та інформаційні технології. — 2017. — № 3. — С. 29-42. — Бібліогр.: 26 назв. — укр. 1681–6048 DOI: https://doi.org/10.20535/SRIT.2308-8893.2017.3.04 https://nasplib.isofts.kiev.ua/handle/123456789/151175 004.046: 004.896: 004.942: 004.021:042 uk Системні дослідження та інформаційні технології application/pdf Навчально-науковий комплекс "Інститут прикладного системного аналізу" НТУУ "КПІ" МОН та НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи
spellingShingle	Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи Петренко, О.О. Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології
description	Найбільший європейський проект зі створення Європейської відкритої науково-дослідницької хмари (European Open Science Cloud for Research, EOSC), що розпочався в 2017 р. і базується на сервіс-орієнтованому підході, мотивує дослідження технологій розміщення сервіс-орієнтованих структур (SOA) прикладних додатків у хмарі. Досліджено базові відмінності традиційних SOA першого покоління (на основі веб-сервісів з уніфікованими протоколами зв’язку) і хмарних SOA нового покоління (на основі мікросервісів з контейнерами), які необхідно враховувати під час переміщення SOA застосувань у хмару.
format	Article
author	Петренко, О.О.
author_facet	Петренко, О.О.
author_sort	Петренко, О.О.
title	Особливості реалізації сервіс-орієнтованих додатків у хмарі
title_short	Особливості реалізації сервіс-орієнтованих додатків у хмарі
title_full	Особливості реалізації сервіс-орієнтованих додатків у хмарі
title_fullStr	Особливості реалізації сервіс-орієнтованих додатків у хмарі
title_full_unstemmed	Особливості реалізації сервіс-орієнтованих додатків у хмарі
title_sort	особливості реалізації сервіс-орієнтованих додатків у хмарі
publisher	Навчально-науковий комплекс "Інститут прикладного системного аналізу" НТУУ "КПІ" МОН та НАН України
publishDate	2017
topic_facet	Прогресивні інформаційні технології, високопродуктивні комп’ютерні системи
url	https://nasplib.isofts.kiev.ua/handle/123456789/151175
citation_txt	Особливості реалізації сервіс-орієнтованих додатків у хмарі / О.О. Петренко // Системні дослідження та інформаційні технології. — 2017. — № 3. — С. 29-42. — Бібліогр.: 26 назв. — укр.
series	Системні дослідження та інформаційні технології
work_keys_str_mv	AT petrenkooo osoblivostírealízacííservísoríêntovanihdodatkívuhmarí AT petrenkooo osobennostirealizaciiservisorientirovannyhpriloženijvoblake AT petrenkooo featuresofserviceorientedapplicationsinthecloud
first_indexed	2025-11-26T00:21:16Z
last_indexed	2025-11-26T00:21:16Z
_version_	1849810200532353024
fulltext	 О.О. Петренко, 2017 Системні дослідження та інформаційні технології, 2017, № 3 29 УДК 004.046: 004.896: 004.942: 004.021:042 DOI: 10.20535/SRIT.2308-8893.2017.3.04 ОСОБЛИВОСТІ РЕАЛІЗАЦІЇ СЕРВІС-ОРІЄНТОВАНИХ ДОДАТКІВ У ХМАРІ О.О. ПЕТРЕНКО Анотація: Найбільший європейський проект зі створення Європейської від- критої науково-дослідницької хмари (European Open Science Cloud for Research, EOSC), що розпочався в 2017 р. і базується на сервіс-орієнтованому підході, мотивує дослідження технологій розміщення сервіс-орієнтованих структур (SOA) прикладних додатків у хмарі. Досліджено базові відмінності традиційних SOA першого покоління (на основі веб-сервісів з уніфікованими протоколами зв’язку) і хмарних SOA нового покоління (на основі мікросерві- сів з контейнерами), які необхідно враховувати під час переміщення SOA за- стосувань у хмару. Ключові слова: SOA, мікросервіс, контейнер, хмара, API, ESB, Workflows, EOSC. ВСТУП Підвищення складності сучасних інформаційних систем, включаючи грід (хмарні) інфраструктури, зумовило поширення модульного підходу до роз- роблення їх програмного забезпечення з використанням стандартизованих по можливості інтерфейсів між частинами, як це передбачено концепцією SOA. Ця архітектура має вигляд набору сервісів і процесів, які можна ком- бінувати, а також змінювати з часом відповідно до змін вимог за допомогою планувальників потоку завдань (workflows). У широкому сенсі SOA — це підхід до розроблення додатків, відповідно до якого додаток розщеплюється на окремі частини. Ці частини, як правило, розподілені по всій системі і спілкуються одна з одною через мережу. Функціональність SOA найпрос- тіше реалізується за веб-сервісами (службовими) з використанням стандар- тів WSDL (Web Services Description Language) і SOAP (Simple Object Access Protocol) для опису інтерфейсів та формату повідомлень, що приймаються або посилаються [1–3]. Для забезпечення комунікації та інтеграції велико- масштабних гетерогенних прикладних процесів найбільш зручним є вико- ристання сервісної шини підприємства ESB (Enterprise Service Bus), яка діє як проміжний шар (або посередник) і використовується для інтеграції, орке- стровки, маршрутизації, моніторингу оброблення подій і кореляції ділової активності [5]. Веб-сервіси — це технологічні специфікації, тоді як SOA є принципом проектування архітектури програмних систем, а ESB — архітек- турним шаблоном. Додатки, які мають бути розміщеними в хмарі у зв’язку зі створенням Європейської відкритої науково-дослідницької хмари EOS [6], значно змі- нюють традиційні правила, за якими побудовано SOA першого покоління. Щоб максимізувати переваги хмарних технологій завдяки використанню віртуалізації апаратних і загальносистемних ресурсів, необхідно змінити О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 30 моделі сервісних додатків і оптимізувати хмару відповідно до цих змін. По- чинаючи з 2017 р., мікросервіси в поєднанні з контейнерами дозволили пришвидшити розроблення сервісних хмарних додатків і підвищити ефек- тивність їх розгортання; забезпечити переміщення сервісів і їх перезапуск в умовах відмови, а також масштабування сервісів зі зміною навантаження [7]. Мікросервіси є додатками з однією функцією, як правило, невеликими за розміром, набагато меншими, ніж традиційні компоненти SOA програм- них додатків, і доступними за допомогою простих RESTful HTTP або JSON інтерфейсів. Це ідеальний варіант, особливо для мобільних пристроїв та ін- тернету речей (ІоТ), двох з основних джерел і драйверів для мікросервісів. API Swagger, імовірно, стає стандартом за замовчуванням для визначення, реалізації, виявлення і тестування REST сервісів. Контейнер (докер) є програмним забезпеченням для автоматизації роз- гортання і керування додатками в середовищі віртуалізації на рівні опера- ційної системи (ОС). Він дозволяє «упакувати» додаток з усім його оточен- ням і залежностями в контейнер, який може бути перенесений на будь-яку Linux-систему, а також надає середовище для керування контейнера- ми. Контейнеризація, по суті, реалізується на рівні віртуалізації ОС (на від- міну від віртуальних машин), кожна з яких оснащена повною вбудованою ОС). Кілька контейнерів можуть бути розміщені в одній віртуальній машині. Контейнери та мікросервіси не одне й те саме. Мікросервіс може працювати в контейнері, але він також може працювати і на виділеній віртуальній ма- шині. Проте контейнери є надійним способом розроблення і розгортання мікросервісів, згрупованих в певні композиції, а інструменти і платформи для запуску контейнерів є надійним способом для керування мікросервісни- ми додатками. У роботі наведено результати досліджень базових технологій і напра- цювань хмарних SOA, розглянуто мікросервіси і API, контейнери і SOA, а також описано дійсний стан підтримання сервісного забезпечення європей- ської відкритої наукової хмари і сформовано висновки та передбачення. МІКРОСЕРВІСИ ТА API Нині розпочалася епоха мікросервісів. Сервіси реалізують обмежений набір функцій, вони розробляються, розгортаються і масштабуються незалежно, мають власний життєвий цикл, не ставлять жодних умов до засобів їх опису або моделювання (наприклад, форми веб-сервісів). Як результат менше часу витрачається на досягнення результатів і підвищення гнучкості. Крім переваг мікросервісів, вони створюють також деякі складності, а саме: потребують інтеграції, засобів автоматизації розгортання і конфігура- ції, реєстрації та моніторингу, додають значно збільшеного обсягу комуні- каційних процедур. Мікросервісний архітектурний стиль являє собою підхід до розроблен- ня єдиного додатка як набору невеликих мікросервісів, кожний з яких пра- цює у власному процесі і спілкується з іншими через сервісний шлюз API Gateway за допомогою HTTP ресурсів API. Кожен мікросервіс зазвичай роз- ташований в окремій віртуальній машині або Docker-контейнері для забез- печення необхідної ізоляції і самостійно розгортається за допомогою повні- Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології, 2017, № 3 31 стю автоматизованого механізму розгортання. Мікросервіси можуть бути написані різними мовами програмування і використовувати різні типи тех- нологій зберігання даних. Щоб збільшити доступність до них, можна вико- ристати кілька екземплярів мікросервісу разом з балансувальником наван- таження. У цій ситуації кожен мікросервіс матиме власну базу даних або можна зробити всі екземпляри мікросервісу одного типу, зв’язаного із зага- льною базою даних. Мікросервіси зберігають свій внутрішній стан у влас- них базах даних. Для зміни мікросервісу може знадобитися оновлення схе- ми бази даних: таблиці мають бути оновлені для нової схеми. Є два можливі способи організації взаємодії клієнта з цим мікросерві- сом: прямий зв’язок клієнт–мікросервіс і зв’язок через API Gateway (рис. 1). У першому випадку (рис. 1, а) клієнт зв’язується з кожним мікросервісом окремо, тобто клієнт має бути запрограмований на реалізацію індивідуаль- ного механізму зв’язку з кожним мікросервісом. Це може зробити програму клієнта більш громіздкою і складною в обслуговуванні. Такі поцедури, як аутентифікація, моніторинг та інші також потрібно обробляти кожним мік- росервісом окремо, підвищуючи їх складність. Оновлення API мікросервісу потребує поновлення клієнтської програми та підтримання синхронізації між API. Оскільки кожен мікросервіс має бути оприлюднений, то ускладню- ється підтримання безпеки. У другому випадку (рис. 1, б) API шлюз є єдиною точкою входу в сис- тему, побудовану на базі мікросервісів. Замість того, щоб клієнт відправляв запити кожному мікросервісу, він спілкується з API Gateway. API шлюз, у свою чергу, переформовує і пересилає кожен запит на відповідний мікро- a б Рис. 1. Взаємодія клієнта з мікросервісом: пряма (а) і через API Gateway (б) О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 32 сервіс та повертає його відповідь клієнту. Використання цього підходу до- зволяє зробити публічно відкритим тільки API шлюз. API керування стає важливим у багатьох галузях, незалежно від того, чи то комунікації бізнес для бізнесу (B2B), чи бізнес для клієнта (B2C). Ши- роко відомі такі засоби API керування: TIBCO API Exchange, IBM, Apigee, 3scale, WSO2, MuleSoft, Mashery, Layer 7, Vordel [10]. Для API потріб- ні складні портали, на яких розробники додатків могли би знаходити й екс- периментувати з цими програмними інтерфейсами. Оскільки програмні ін- терфейси виставляються публічно, то шлюзи, через які надається доступ, повинні забезпечувати найвищий рівень безпеки. Сервісний шлюз (service gateway) використовується для забезпечення безпеки, дотримання політик, подання мікросервісів через API зовнішнім споживачам і статичного оброблення відповідей. З ним зв’язані засоби, по- будовані для аутентифікації, моніторингу, балансування навантаження, ке- шування, формування і керування запитами, а також інтеграції, оркестров- ки, маршрутизації, моніторингу, оброблення і кореляції подій, ділової активності. Можна назвати ці засоби псевдо-ESB, або платформою інтегра- ції чи мікросервісною платформою. Наявність шлюзу API дозволяє кожному мікросервісу використовувати механізм зв’язку, який підходить до нього, без внесення будь-яких змін до клієнта. Різні механізми зв’язку можуть бути змішані і підібрані для мікросервісів відповідно до вимог його функціональ- ності, наприклад, для синхронного зв’язку «один-до-одного» чи асинхрон- ного зв’язку «один-до-багатьох». Сервісний шлюз керує сервісами інтеграції (побудованими за допомо- гою псевдо-ESB), прикладними сервісами (побудованими за допомогою псе- вдо-ESB або будь-якої іншої технології), а також зовнішніми хмарними сер- вісами (не важливо, як вони побудовані, важливо, що є домовленість про постачання сервісів). Щоб корелювати події, які відбуваються в різних мікросервісах, необ- хідно зберігати ці події в пам’яті, зробити їх видимими в режимі моніторин- гу в реальному часі, доступними для аналітики та активних прогнозованих дій. Підтримувати синхронізацію даних між мікросервісами стає набагато складніше у випадку мікросервісних SOA додатків, оскільки кожен мікросер- віс має власну базу даних, яка може бути доступна або модифікована тільки через його API, тобто кінцеву точку. Для вирішення цієї проблеми можна використати подієво-керовану архітектуру [4], у якій мікросервіс публікує подію, коли відбувається подія, наприклад, коли він оновлює запис у базі даних. Інші мікросервіси підписуються на ці події. Коли мікросервіс отри- мує інформацію про подію, він може оновлювати відповідні записи у влас- ній базі даних, що може викликати появу більшої кількості подій, які публі- куються і споживаються іншими сервісами. Подіями можна керувати через використання:  черг повідомлень (messaging queues), таких як RabbitMQ або ZeroMQ;  бази даних як проміжного шару між сервісами, коли один сервіс створює і записує подію в базу даних. Інші сервіси постійно запитують цю базу даних і починають діяти, коли виявляють запис про подію. Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології, 2017, № 3 33 Варто відзначити, що подієво-орієнтована архітектура при переході до мікросервісів стає базовим типом архітектури додатків на відміну від тради- ційних SOA [4], що означає більш високу складність таких додатків. Це призводить до значного зростання комунікаційного навантаження порівняно з транзакціями в пам’яті традиційних додатків. Мікросервісам потрібна така мова опису інтерфейсу, щоб за її допомогою можна було легко реалізовува- ти клієнтів, з одного боку, а з другого, була типізованою звичною мовою (Swagger, proto, WSDL). Навіть якщо мікросервіси розробляються за різни- ми технологіями (наприклад, мов Java, Scala, Python, або графічного інстру- ментарію), всі вони керуватимуться і контролюватимуться за допомогою єдиного призначеного для користувача інтерфейсу. Перехід на контейнерне керування сервісами за технологією API є по суті альтернативною реалізацією сервісної шини підприємства, що не тільки спрощує виклик сервісів додатками (або їх частинами), але й допомагає їм передавати дані і поширювати повідомлення про події з позицій оброблення складних подій. КОНТЕЙНЕРИ І SOA Контейнери, імовірно, є найбільш швидко зростаючою і найбільш захопли- вою галуззю розвитку віртуалізації і хмарних обчислень. Зв’язок між кон- тейнерами та мікросервісами не є простим. Контейнери не потрібні для роз- гортання мікросервісів, але водночас мікросервіси потрібні для обґрунтування доцільності використання контейнера. Мікросервіси є одним зі способів підвищення маневреності додатків і повторного використання коду. Контейнери — форма віртуалізації, яка дозволяє уникнути дублюван- ня ОС в машинному образі, забезпечуючи загальну платформу, яка поділя- ється між всіма компонентами додатка (рис. 2) [8]. Усунення дублювання цих великих програмних елементів дозволяє на- багато більшій кількості мікросервісів працювати на одному сервері: від п’яти до десяти разів більше, ніж у звичайних провадженнях. Деякі корис- тувачі повідомляють, що вони можуть запускати мікросервіси з контейне- рами в 30 разів більшу кількість порівняно з кількістю віртуальних машин. Рис. 2. Порівняння структур контейнерів і віртуальних машин [8] О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 34 Мікросервіси також розгортаються швидше в контейнерах, ніж на вір- туальних машинах. Це може бути дуже корисним під час горизонтального масштабування сервісів зі зміною навантаження або перерозподілу мікросе- рвісів у зв’язку з відмовою мережевого сервера. Якщо кожен мікросервіс розмістити в окремій віртуальній машині з незалежною ОС, то витрачати- меться багато пам’яті й інших ресурсів. Продукція фірми Docker домінує на ринку, задовольняючи на 40% іс- нуючий попит. Google давно використовує контейнери. Компанія є одним з основних вкладників у різні контейнеро-орієнтовані проекти з відкритим вихідним кодом, включаючи Kubernetes оркестратор і Google Container Engine, що функціонують у Google Cloud Platform [11]. Microsoft підтримує контейнеризацію за допомогою Windows Server Containers, що дозволяє спі- льне використання ядра ОС між хостом і контейнерами. Hyper-V контейнери розширюють цю послугу, запускаючи кожен контейнер в оптимізованій вір- туальній машині. Для хмари є також Azure Container Сервіс (ACS), розроб- лений спільно з Docker, який може керувати підтриманням ін- ших інструментів оркестровки, таких як Kubernetes. Клієнти AWS можуть розгортати контейнери на своїй EC2 платформі, забезпечуючи керування кластерами і планування двигуном Docker за допомогою EC2 Container Service (ECS). Ця можливість підтримується EC2 Container Registry (ECR) шляхом зберігання. Компанія VMware випустила vSphere Integrated Containers для перетворення віртуальних машин у Docker-подібні контейне- ри для створення платформи відкритого керування системою сервісів для реалізації бізнес-процесів у середовищі PhotonOS. Інші приклади включа- ють IBM контейнери для Bluemix, Rackspace Carina (на основі OpenStack Magnum убудоване підтримання для контейнерів та оркестровка). Ще є одна ініціатива з відкритим вихідним кодом Deis, платформа-як-сервіс (PaaS) на основі CoreOS. Слід визнати, що ринок контейнеризації стрімко зміню- ється [12]. Hyper-V контейнери пропонують новий спосіб реалізації SOA, який є більш ефективним у багатьох випадках. За допомогою контейнера можна запустити кожен сервіс (частину програми) всередині контейнера і далі ви- користовувати контейнерний оркестрант (orchestrator) для керування зв’язком між контейнерами та гарантувати, що кожний сервіс усередині програми працює правильно. Контейнери є кращими будівельними блоками для SOA, ніж традиційні веб-сервіси через такі їх якості [8]:  Контейнери легко переміщуються між хостами (хмарами, вузлами). У використанні традиційних SOA сервіси залежать від конкретних умов хостів. Наприклад, якщо мережевий файл файлової системи встанов- люється на сервері CentOS Linux для надання сервісу зберігання даних для SOA, зміна хоста NFS на сервер Ubuntu потребує значних зусиль. На відміну від цього переміщення контейнера від одного хоста до іншого значно прос- тіше, оскільки контейнерне середовище хоста завжди однакове.  Контейнери мають високу масштабованість. Оскільки контейнери додатків можуть легко переміщуватися між вузлами, контейнерна інфра- структура також легко масштабується. Якщо необхідні додаткові екземпля- ри певного сервісу, то більше контейнерів можуть бути розгорнуті. Масш- табування в традиційних розподілених системах не реалізується так просто.  Контейнери легко оновлюються. Щоб оновити додаток, який працює в контейнері, треба відновити зображення контейнера, на якому заснований Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології, 2017, № 3 35 додаток, а потім перезапустити контейнер. Цей процес є більш простим і безвідмовним порівняно з традиційним оновленням сервісу в розподіленій системі, тому нескладно відмінити зміни, якщо це необхідно.  Контейнери можуть бути використані повторно. Однією з основ- них цілей SOA є повторне використання сервісів, їх розділення і зменшення кількості надлишкових сервісів. Контейнери легко використовувати повтор- но, оскільки зображення контейнерів можна скопіювати і контейнери мо- жуть швидко переміщатися між вузлами.  Контейнери спричиняють менше навантаження. Контейнери забез- печують гнучкість роботи віртуальних сервісів усередині програмного сере- довища без необхідності запуску повної віртуальної машини для розміщен- ня сервісів. Замість цього контейнери поділяють обчислювальні ресурси з хостом контейнера. Це означає, що є переваги традиційних програмно- орієнтованих сервісів без істотних накладних витрат ресурсів. Для розроб- лення і впровадження нових додатків вибираються контейнери для їх роз- міщення. Необхідно переконатися, що додатки написані для роботи всере- дині контейнерів, потім установити Docker, розгорнути додатки і використовувати контейнерний оркестрант для керування ними. Сервер забезпечує повну ізоляцію контейнерів, що запускаються на ву- злі, на рівні файлової системи (у кожного контейнера власна коренева фай- лова система), на рівні процесів (процеси мають доступ тільки до власної файлової системи контейнера, а ресурси розділені засобами), на рівні мере- жі (кожен контейнер має доступ тільки до цього мережевого простору імен і до відповідних віртуальних мережевих інтерфейсів). Набір клієнтських засобів дозволяє запускати процеси в нових контей- нерах, зупиняти і запускати контейнери, припиняти та відновлювати процеси в контейнерах. Серія команд дає змогу здійснювати моніторинг запущених процесів. Нові зображення контейнера можна створювати зі спе- ціального сценарного файла, записувати всі зміни, зроблені в контейнері, в нове зображення. Крім того, в інтерфейсі командного рядка вбудова- ні можливості взаємодії з публічним репозиторієм Docker Hub, у якому роз- міщені попередньо зібрані зображення контейнерів [12]. Кілька контейнерів розгортаються у кластерах, багато з яких попередньо вбудовуються як ком- поненти, які можуть бути розміщені поруч для створення зображення додатків. Є чотири положення, які необхідно враховувати: 1. Операційні системи контейнерів. Навіть якщо контейнери не мають вбудованих ОС, одна спільна ОС, як і раніше, потрібна. Будь-яка стандартна ОС буде працювати, у тому числі Linux або Windows. Проте фактичні потріб- ні ресурси ОС, як правило, обмежені, тому ОС може бути багато. Це спону- кало до розроблення спеціальних контейнерних ОС, таких як Rancher OS, CoreOS, VMware Photon, Ubuntu Snappy, Red Hat Project Atomic і Microsoft Nano сервер [13]. 2. Двигун (рушій) контейнера. Тут домінує Docker, але є конкуренти, такі як CoreOS Rocket (Rkt). Двигуни поставляються з допоміжними засоба- ми, наприклад, Docker Toolbox, який спрощує налаштування Docker для ро- зробників, і Docker Trusted Registry для зображення керування. 3. Оркестровка контейнерів. Контейнери повинні бути розумно згрупо- вані для забезпечення функціонування додатків, і це потребує оркестровки. О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 36 Двигуни виконують основне підтримання для визначення простих мульти- контейнерних застосувань, наприклад, Docker Compose. Проте повна оркес- тровка включає в себе планування того, як і коли контейнери повинні працювати, керування кластером і надання додаткових ресурсів, часто ін- ших хостів. Інструменти оркестровки включають Docker Swarm, Google Kubernetes і Apache Mesos [14 ]. Можна використовувати інструменти кон- фігурації загального призначення, такі як Chef and Puppet (обидва з відкри- тим вихідним кодом) або комерційні пропозиції, такі як HashiCorp Atlas або Electric Cloud ElectricFlow. 4. Переміщення додатка з однієї хмарної платформи на іншу. У цьому випадку постачальники програмного забезпечення повинні послідовно оно- вити свої додатки для розгортання їх у користувачів. Потрібні контейнери будуть копіюватися і додатки будуватимуться з цих контейнерів, оскільки повне робоче середовище відтворене, у тому числі і самі контейнери, балан- си навантаження, мережі і т. ін. У 2015 р. компанія Docker випустила Docker Networking для включення віртуальних з’єднань між контейнерами. Англій- ська фірма Weaveworks також створила WeaveNet, а Micro-Software-Calico збільшує безпеку контейнерної мережі через динамічну побудову firewalls (брандмауерів). Docker теж розробляє нові інструменти для підтримання життєвого циклу контейнерних додатків. Docker Universal Control Plane (UCP) забезпечує можливості створення, розгортання та керування додат- ками на вимогу [15]. СУЧАСНИЙ СТАН СЕРВІСНОГО ЗАБЕЗПЕЧЕННЯ EOSС Із 2017 р. розпочався справжній бум зі створення SOA додатків другого по- коління. Найкращими підходами було б розбиття існуючих додатків (legacy) на мікросервіси відповідно до потреб науки чи створення абсолютно нових сервісів (рис. 3). Рис. 3. Розкладання монолітних прикладних додатків на компоненти Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології, 2017, № 3 37 Згідно з планами Європейського Союзу в 2020 р. має бути створена Єв- ропейська відкрита наукова хмара (EOSC) як екосистема сервісів, які нада- ються різними постачальниками сервісів, для обслуговування 1,7 млн уче- них і 80 млн професіоналів з різних галузей науки і технологій (рис. 4). Жорсткі терміни введення її в дію змушують відомі європейські органі- зації та інфраструктури (EUDAT, СERN, OpenAIRE, GÉANT, EGI, ESFRI, e-IRG, ESA, INDIGO та ін.) базуватися на своїх існуючих монолітних про- грамних рішеннях, перетворюючи їх на декілька десятків макросервісів (за- мість мікросервісів). Тому, розміщуючи такі макросервіси в контейнери, тимчасово відмовляються від віртуалізації ОС і вимушено в кожний контей- нер включають повний екземпляр ОС і власну базу даних. Приклади серві- сів, які запропонували EGI, INDIGO, EUDAT, наведено в табл.1–3 [17–19]. Т а б л и ц я 1 . EGI (European Grid Infrastructure) сервіси [17] Сервіс забезпечення або підтримання № з/п Назва сервісу Обчислювальні сервіси 1 2 3 1 Cloud Compute Виконання обчислень і оброблення даних. Підтримання тривалих сервісів (наприклад, веб-сервісів або баз даних). Створення середовища розроблення і виконання тестування. Вибір конфігурації віртуальної машини відповідно до вимог користувача. Керування ресурсами хмари на гнучкій основі з комплексним моніторингом і можливостями обліку 2 Cloud Container Compute Підготовка додатка на вимогу. Середовище для максимального продуктивності. Стандартний інтерфейс для розгортання сервісів від кількох постачальників. Виконання Dоcker контейнеів у віртуальному середовищі. Сумісність (interoperable) і прозорість. Усунення конфліктів між середовищами розроблення та експлуатації Рис. 4. Європейська відкрита наукова хмара [16] ‘External’ Date ‘Internal’ Date Network Storage Servers Технологічне підтримання е-инфраструктура О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 38 Продовження табл. 1 1 2 3 3 High-Throughput Compute Доступ до високоякісних обчислювальних ресурсів. Інтегровані засоби моніторингу та обліку для надання інформації про доступність і споживання ресурсів. Інструменти для робочого навантаження і керування даними для всіх обчислювальних задач. Велика кількість перероблених завдань протягом тривалого періоду часу Сервіси зберігання 4 Online Storage Призначення глобальних ідентифікаторів файлам. Доступ до високомасштабованих сховищ у будь-якій точці світу. Контроль за даними, що використовуються зумисно. Організація даних з використанням гнучкої ієрархічної структури 5 Data Transfer Сумісність із надвеликими файлами. Здатність оброблення великих обсягів файлів. Підтримання процесу передавання з автоматичною повторною спробою 6 Archive Storage Збереження даних на тривалий термін. Збереження великої кількості даних. Звільнення власного інтернет-сховища Сервіси навчання і тренувань 7 FitSMTraining Збільшення досвіду в галузі керування ІТ-сервісами. Підвищення професійного профілю визнаної сертифікації 8 Training Infrastructure Цільові конкретні курси та додана вартість для наукових співтовариств. Легке розгортання курсів і їх повторне використання Т а б л и ц я 2 . INDIGO (INtegrating Distributed data Infrastructures for Global ExplOitation) сервіси [18] № з/п Назва сервісу Сервіс забезпечення або підтримання 1 2 3 1 IAM (Identity and Access Management) Реєстрація сервісу. Менеджмент спільних рішень VO (віртуальних організацій). Постачання сертифікованих OIDC / сервер авторизації OAuth. Надання APIs, базованих на стандарті SCIM. Забезпечення ідентифікації користувачів і надання інфор- мації про політики сервісам для прийняття послідовних рішень щодо авторизації в умовах розподілених сервісів 2 Dynpart (Partition Director Service for Batch and Cloud re- sources) Керування гібридним центром оброблення даних, який може надавати сервіси як для пакетного оброблення даних, так і для хмарно розподілених сервісів 3 Cloud Provider Ranker Автономний WEB REST сервіс, який виконує ранжування постачальників хмар за пріоритетами користувачів з вибору ресурсів. Використання двигуна системи керування бізнес- правилами (BRMS, Business Rules Management System) Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології, 2017, № 3 39 Продовження табл. 2 1 2 3 5 Orchestrator (PaaS Orchestrator) Основний компонент прошарку PaaS. Збирання запитів на розгортання з прошарку (рівня) програмного забезпечення. Координація ресурсів або сервісів розгортання динамічних Mesos кластерів або безпосередньо на базі IaaS платформ 6 udocker (Userspace Container Support ) Інструмент для виконання простих контейнерів Docker у просторі користувача. Можливість завантаження і виконання повністю кінцевим користувачем. Bdocker і udocker: два взаємодоповнювальні підходи для виконання контейнерів в пакетних системах оброблення даних 7 Ophidia (Data Mining and Ana- lytics for eScience Server) Фреймворк (структура, яка підтримує аналіз даних, інтенсивно використовуючи паралельні методи обчислень і смарт-методи розподілу даних. Використання ієрархічної організації зберігання для поділу і розподілу багатовимірних масивів наукових даних на декілька вузлів 8 IM (Infrastructure Manager) Розгортання складних і індивідуальних віртуальних ресурсів на різних платформах IaaS хмара (таких як AWS, OpenStack). Надання оркестранту обчислювальних ресурсів можливості використання стандартних мов OASIS (наприклад, протоколу TOSCA) 9 Kubernetes Monitoring Accounting Забезпечення основних функціональних можливостей та інструментів, що підтримують роботу всіх севісів PaaS, доступних в інфраструктурі 10 fgAPIServer, fgPortal- Setup, fgTools (Future Gateways (Pro- grammable Scientific Portal) Програмований інтерфейс з RESTful API сервера: містить набір програмних компонентів, здатних створити або допомогти існуючим веб-порталам стати первісними шлюзами; забезпечує доступ до розподілених обчислювальних ресурсів, таким як грід, хмари і високопродуктивні обчислення 11 indigoclient, indigoKepler (INDIGO Plug-ins for scientific workflow systems) Система керування робочими потоками (Workflow ). Забезпечення інфраструктури установленням, запуском і моніторингом певної послідовності завдань, що створює робочий потік з використанням ресурсів та сервісів, наданих постачальниками й іншими спільнотами 12 NOW (Network Orchestration Wrappercomponent for OpenNebula-based clouds). Приймання запитів для маніпуляції віртуальної мережі. Глобальна попередня авторизація і виконання запитів через API OpenNebula 13 Orchent (the orchestrator client) Командний рядок додатка для керування його розгортанням і вибору ресурсів (оркестратор) у швидкий і простий спосіб 14 Mobile Toolkit Надання набору засобів розроблення програмного забезпечення (SDK, Software Development Kit), необхідного для створення мобільних додатків, здатних експлуатувати севіси INDIGO PaaS. Надання можливості менеджерам і розробникам взає- модіяти з усіма сервісами і ресурсами з використанням мобільних пристроїв. Інструментарій, призначений для Android О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 40 Т а б л и ц я 3 . EUDAT (European Data Infrastructure) сервіси [19] № з/п Назва сервісу Сервіс забезпечення або підтримання 1 B2DROP (Sync and Exchange Re- search Data) Рішення для персональної хмари, засноване в довіреному EUDAT CDI домені для зберігання та спільного використання наборів даних на початку дослідження життєвого циклу даних 2 B2SHARE (Store and Share Research Data) Зручний, надійний сервіс, що заслуговує довіри дослідницьких спільнот, для зберігання та обміну дрібномасштабними обсягами даних, що надходять з різних контекстів 3 B2FIND (Find Research Data) Простий, зручний портал для пошуку колекцій наукових даних, що зберігаються в EUDAT центрах оброблення даних та інших сховищах даних 4 B2SAFE (Replicate Research Data Safely) Надійний, безпечний і доступний для керування даними і їх реплікаціями сервісів, що дозволяє спільнотам і відомчим рекозитаріям дублювати та зберігати наукові дані у вузлах EUDAT 5 B2STAGE Get Data to Computation) Надійний, ефективний, простий у використанні сервіс для переміщення великих обсягів наукових даних між вузлами EUDAT і робочим простором обчислювальних систем високої продуктивності 6 B2ACCESS (Indentity and Authoresation) Підтримання декількох методів аутентифікації ідентичності користувачів (OpenID, SAML, x.509). Використання як первинного постачальника посвідчень; у разі потреби може бути інтегрований з EduGain і, отже, підтримувати ідентичність користувачів по всьому світу. Забезпечення унікальних ідентифікаторів EUDAT 7 B2HANDLE (Register your research data) Забезпечення доступу до даних, довговічних посилань на дані і полегшення публікації даних Відмінності наведених сервісів у різних реєстрах є істотними згідно з різними стандартами і фрейворками, які доступні для керування сервісами, а також через різні процеси керування портфелем сервісів у різних міс- цях e-інфраструктури на різних рівнях реалізації практики керування серві- сами, відсутність стандартизованого способу визначення і опису сервіс- ної e-інфраструктури сервісів, різні пропозиції сервісів від різних постачальників, що потенційно частково перекриваються. Тому існує насушне завдання сьогодення, яке полягає в необхідності об’єднання існуючих сервісів хоч би у загальний каталог сервісів (не кажу- чи вже про загальний репозитарій). Роботи зі складання загального каталогу сервісів розпочато в межах проекту eInfraCentral зусиллями дев’яти органі- зацій (січень 2017 – червень 2019) [20]. Життя (особливо потреби сервісного сектору економіки) потребує за- собів створення хмарних мікросервісних систем і адаптації для цілей існую- чого інструментарію провідних фірм (ASP.NET, SAP Enterprise SOA, Oracle SOA Suite 12c, HP SOA Center та ін.) і для створення мікросервісних реєстрів та забезпечення тим самим реалізації у хмарних SOA віртуалізації як серве- Особливості реалізації сервіс-орієнтованих додатків у хмарі Системні дослідження та інформаційні технології, 2017, № 3 41 рів, так і операційних систем [21–24]. Видається доцільним поєднати для цього веб-сервіси з контейнерними технологіями, що дає змогу збільшити розміри хмарних репозитаріїв сервісів (до кількох тисяч компонентів за- мість десятка тепер) і організації в них автоматичних семантичних ме- тодів пошуку (відкриття) необхідних сервісів (замість ручних, що практи- куються в EOSC) [25] . ВИСНОВКИ Ключ до успіху SOA лежить у повторному використанні існуючих ІТ- ресурсів, наприклад, успадкованих додатків. Однак хмарні SOA мають від- мінності від SOA, побудованих на ізольованих е-інфраструктурах, переду- сім у використанні переваг віртуалізації як апаратних (серверів), так і про- грамних (ОС) ресурсів. Натепер наявні два напрями: орієнтація на потреби наукових спільнот, мотивована початком створення з 2016 р. Європейської відкритої наукової хмари, і орієнтація на потреби бізнесу, зумовлена стрімким становленням сервісного сектору економіки. У першому випадку сервіси, необхідні для створення додатків, переважно вимушено формуються на базі успадкованих наукових застосувань. Таких макросервісів у реєстрах EGI, INDIGO, EUDAT, GIANT поки небагато, і користувач зможе в разі потреби їх знахо- дити досить просто. Утім тепер стоїть завдання складання з них хоч би ка- талогу. У другому випадку сервіси, необхідні для створення додатків, роз- робляються переважно самими користувачами за допомогою ефективного і різноманітного інструментарію провідних фірм, таких як Microsoft, Oracle, HP, SAP тощо. Сервіси, як правило, створюються у вигляді веб-сервісів із семантичним описом (повним або тільки анотованим), що дозволяє впрова- дити методи автоматичного відкриття необхідних сервісів у надвеликих за обсягом репозитаріях сервісів. Принаймні, веб-сервіси можна створювати і без розглянутого інструментарію провідних фірм, користуючись лише від- критими технологіями і мовами семантичного веб. Для умов хмарного середовища найбільш притаманне з точки зору до- сягнення максимальної віртуалізації ресурсів використання мікросервісів і контейнерів для організації їх взаємодій. Тому видається доцільним реко- мендувати надалі (як для наукових, так бізнесових додатків) застосову- вати веб-технології для формування та опису мікросервісів і їх компози- цій, а також контейнерне керування ними. ЛІТЕРАТУРА 1. Maglio P. Handbook of Service Science (Service Science: Research and Innovations in the Service Economy) / P. Maglio, C.A. Kieliszewski, J. Spohrer // Springer, NewYork, 2010. — 82 p. 2. Service Oriented Architecture: SOA Features and Benefits. — Available at: https://www.opengroup.org/soa/ source-book/soa/soa_features.htm 3. Петренко А.А. Объекты и методы науки о сервісах / А.А. Петренко // Системні дослідження і інформаційні технології. —№ 2. — 2015. — С. 75–83. 4. Петренко О.О. Порівняння типів архітектури систем сервісів / О.О. Петренко // Системні дослідження і інформаційні технології. — № 4. — 2015. — С. 48–62. О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2017, № 3 42 5. Enterprise service bus. — Available at: http://www.service-architecture.com/ articles/web-services/enterprise_service_bus_esb.html 6. Tiziana Ferrari. EGI towards the European Open Science Cloud. — Available at: https://indico.egi.eu/indico/event/3249/session/24/contribution/10 7. Ньюмен С. Создание микросервисов / С. Ньюмен. — СПб.: Питер, 2016. — 304 с. 8. Picking The Right Cloud Container Platform. — Available at: http://www. communicationstoday.co.in/images/reports/20170501-container-deployment-g6 gc442244-report.pdf 9. Microservices and containers present a new deployment model in 2017. — Avail- able at: http://searchmicroservices.techtarget.com/opinion/Microservices-and- containers- present-a-new-deployment-model-in-2017 10. Wilson Mar. API Management Evaluation. — Available at: https://wilsonmar. github.io/api-management-evaluation/ 11. Containers as a Service: Comparing Providers and Evaluating the State of the Market. — Available at: http://sandhill.com/article/containers-as-a-service- comparing-providers-and-evaluating-the-state-of-the-market/ 12. Repositories on Docker Hub. — Available at: https://docs.docker.com/docker- hub/repos/ 13. Operating System Containers vs. Application Containers. — Available at: https://blog.risingstack.com/operating-system-containers-vs-application- containers/ 14. Kubernetes is an open-source system for automating deployment, scaling, and man- agement of containerized applications. — Available at: https://kubernetes.io/ 15. Universal Control Plane overview. — Available at: https://docs.docker.com/ datacenter/ucp/2.1/guides/ 16. Realising the European Open Science Cloud. — Available at: https://ec.europa.eu/ research/openscience/pdf/realising_the_european_open_science_cloud_ 2016.pdf 17. Online EGI Service Catalogue. — Available at: https://www.egi.eu/services/ 18. INDIGO сервіси. — Available at: https://www.indigo-datacloud.eu/service- component 19. EUDAT site. — Available at: www.eudat.eu 20. eInfraCentra. — Available at: http://einfracentral.eu/ 21. .NET Framework. — Available at: https://en.wikipedia.org/wiki/.NET_Framework 22. Enterprise soa development handbook. — Available at: https://archive.sap.com/ kmuuid2/40db4735-02f9-2a10-b198-a888a056bb67/Enterprise%20SOA%20 Development%20Handbook.pdf 23. Oracle SOA. — Available at: https://www.oracle.com/middleware/application- integration/products.html/ 24. HP SOA Center: Concepts, Technology and Architecture. — Available at: http://www.hp.com/hpinfo/analystrelations/wp_cloudcomputing_soa_capgemini_ hp.pdf 25. Петренко І.А. Автоматизовані методи пошуку і відкриття необхідних сервісів / І.А. Петренко, О.О. Петренко // Вісник Університету «Україна», Серія «Інформатика, обчислювальна техніка та кібернетика». — №1(17). — 2015. — С. 55–64. 26. Kunal Joshi. Introduction to Microservices. Available at: https://techblog.xavient. com/introduction-to-microservices/ Надійшла 21.06.2017

Особливості реалізації сервіс-орієнтованих додатків у хмарі

Репозитарії

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