CC BY
21
pp. 8. He K, Zhang X, Ren S, Sun J. Deep residual learning for image recognition. // In: IEEE Conference on Computer Vision and Pattern Recognition, 2016. 770-778 pp.
Над1йшла до редколегИ' 14.05.2021
Ситшков Дмитро Едуардович, кандидат техтчних наук, доцент, професор кафедри систе-мотехшки ХНУРЕ. №yKOBi штереси: Data Mining and Knowledge Discovery. Адреса: Укра!-на, 61166, м. Харюв, пр. Науки 14, тел. (057) 702 10 06.
Андрусенко Юлiя Олександрiвна, астрангка кафедри електронних обчислювальних машин ХНУРЕ. ^yraBi iнтереси: методи прогнозування часових р.вдв. Адреса: Укра!на, 61166, м. Харюв, пр. Науки 14, тел. +38 (063) 407 06 09.
УДК 004.4 DOI: 10.30837/0135-1710.2021.177.047
Н.С. КРАВЕЦЬ
ВИЗНАЧЕННЯ ОБМЕЖЕНЬ РЕАЛ1ЗАЦП ОБРОБКИ ПОД1Й В ХМАРНОМУ ДОДАТКУ ЗА ДОПОМОГОЮ БЕЗСЕРВЕРНИХ ОБЧИСЛЕНЬ
У статп розглядаються безсерверш обчислення як нова i перспективна парадигма для розгортання хмарних додаткiв, зокрема таких що мають подieво-орieнтованy архiтектyрy. Платформи FaaS провiдних постачальникiв хмарних послуг е найсyчаснiшою реалiзацieю безсерверно! моделi. На основi порiвняння характеристик та перел^ джерел оброблюва-них подiй платформ FaaS ввд Amazon i Azure визначено переваги та обмеження використан-ня цiеi моделi для реалiзацii високопродуктивних систем, що обробляють поди в режимi реального часу.
1. Вступ
У тепершнш час розробникам все часпше доводиться виршувати проблеми, пов'язаш 1з обробкою в реальному час потоку р1зномаштних подш, що надходять з р1зних джерел i вимагають р1зно! обробки. Под1бш проблеми покликана виршувати под1ево-ор1ентована арх1тектура. Для виршення проблем використовуються: асинхронна обробка подш, черги р1зних тишв, мехашзм шдписки на поди тощо. Хмарш провайдери пропонують значну кшьюсть ршень на баз1 сво!х платформ, яю також припускають використання безсерверних обчислень.
Безсерверш обчислення - це новий шдхщ, який концептуально ще бшьше дистанщюе програмне забезпечення в1д шфраструктури, на якш воно виконуеться. Цей р1вень абст-ракцп ютотно полегшуе життя розробникам, дозволяючи зосередитися тшьки на реатзаци конкретних функцш. Хоча для реал1заци безсерверних обчислень ктента використовуються ф1зичш сервери, розробникам не потр1бно думати про !х конф1гуращю, характеристики та обслуговування. Компашя, що користуеться послугами безсерверного постачальника, по факту сплачуе за використовуваш ресурси i не повинна резервувати i оплачувати фшсовану пропускну здатшсть або кшьюсть сервер1в, оскшьки послуга автоматично масштабуеться.
У багатьох хмарних провайдер1в, що пропонують безсерверш обчислення як послугу, е платформи Function-as-a-Service (FaaS), яю дозволяють створювати проси функцп, яю незалежно запускаються при настанш яко!сь поди i виконують одну задачу. За допомогою FaaS розробники можуть створювати модульну арх1тектуру, роблячи код бшьш масштабо-ваним, не витрачаючи ресурси на тдтримку бекенда. Основними перевагами безсерверних обчислень е низью експлуатацшш витрати i ефективне управлшня та використання ресурс1в. На тепершнш час безсерверш обчислення пропонуються декшькома постачальниками загальнодоступних хмарних сервюв. Безсерверш обчислення активно розвиваються, а !х реал1заци в1д р1зних хмарних провайдер1в мають ютотш в1дмшност1, анатз яких е метою дано! статп. AWS Microsoft i Azure на даний момент е лщерами ринку хмарних послуг, пор1вняемо можливост! !х платформ FaaS з точки зору обробки подш.
2. Пор1вняння Azure Fuctions та AWS Lambda
Як правило, безсерверна технолопя мае наступш характеристики:
- вщсутнють керування серверами: не потрiбно надавати або обслуговувати будь-якi сервери, немае доступу до програмного забезпечення або середовища виконання для установки, обслуговування або адмiнiстрування серверiв;
- автоматичне масштабування: не потрiбно турбуватися про масштабування додатка в разi рiзкого стрибка навантаження;
- бiльш «тонкий» бшнг: до появи безсерверних хмарних сервiсiв в результатi автоматичного масштабування автоматично надавалися вiртуальнi машини, тобто резервувалися ресурси, яю клiент оплачував, навiть якщо вони простоювали; тд час використання безсерверних обчислень оплата стягуеться на основi споживання ресурав i часу, необидного для виконання;
- виконання в результат настання якоюь поди: зазвичай функцiя виконуеться пiсля настан-ня поди, наприклад, завантаження нового файлу в сховище або спрацьовування таймера;
- висока доступшсть: висока доступнiсть i вщмовостшюсть надаються безсерверним додаткам за замовчуванням.
Найчастiше функцiя як сервiс взаемодiе iз масивом хмарних служб для реалiзацil наступних сценарпв: створення веб-API, обробка переданих файлiв, створення безсерверного робочого процесу, реагування на змши бази даних, виконання запланованих завдань, створення надiйних систем черги повщомлень, аналiз потокiв даних 1нтернету речей, обробка даних в реальному чаш. Однак безсерверш платформи мають власну специфiку, яка залежить вiд виробника.
Наприклад, i AWS Lambda i Azure Fuctions [1,2] дозволяють використовувати крiм базового набору будь-яку додаткову мову програмування за допомогою API Runtime, Custom handler або gRPC language worker. При цьому AWS Lambda включае в себе шдтримку довiльних бiблiотек, проте iснують певш обмеження на модель програмування, наприклад, максимальний час виконання, вщсутшсть збереження стану.
У Azure Fuctions вщ вибору варiанту розмiщення залежить реалiзацiя автоматичного масштабування, максимально можлива кшьюсть примiрникiв; перелiк ресурсiв, доступних для кожного пришрника програми-функцп; пiдтримка розширених функцiй, таких як пщклю-чення до вiртуальноl мережi Azure. При розгортанш функцп AWS Lambda в залежносп вiд профiлю робочого навантаження потрiбно визначити тiльки максимальний розмiр видшено! пам'ятi, потужнiсть процесора i вартiсть виконання функцп пропорцiйнi видшенш пам'ятi. Щоб запустити безсерверну функщю в AWS, ll потрiбно розгорнути в сервiсi AWS Lambda. Microsoft дотримуеться шшого пiдходу: поняття моделi програмування Azure Fuctions вiдокремлено вщ безсерверно! операцшно! моделi.
AWS Lambda мае просту модель програмування: функщя отримуе об'ект JSON в якосп вхiдних даних i може повертати шший JSON в якостi вихщних [2]. Тип поди визначае схему тих об'екпв, якi задокументованi i визначенi в мовi SDK. Функцп Azure мають бiльш складну модель, засновану на тригерах та прив'язках. Тригер задае подiю, яка прослухо-вуеться функцiею. Функцiя може мати будь-яку кшьюсть вхiдних i вихщних прив'язок для вилучення та/або повернення даних пiд час обробки [1].
Безсерверш функцп - це невелик блоки коду, що виконують тшьки одне завдання. Тому створення великих додатюв i систем з цих невеликих шматочкiв, е нетривiальною проблемою, але деякi рiшення юнують. Безсервернi обчислення заснованi на концепцп контейнери-зацп. Кожного разу, коли функщя запускаеться, система створюе контейнер, в якому ll можна запустити. У той час, як запуск функцп може зайняти всього мшросекунди, запуск контейнера займае 1-2 секунди. Для багатьох додатюв це досить швидко, в порiвняннi зi створенням вiртуальноl машини, проте в деяких випадках подiбний час затримки може виявитися критичним. I AWS, i Azure мають спецiальнi сервiси для оркестровки робочих процесiв. Часто функцп використовуються в якосп крокiв в цих робочих процесах, що дозволяе !м залишатися незалежними, але при цьому виршувати важливi завдання.
Бшьш докладне порiвняння характеристик платформ Faas в1д Amazon i Azure наведено в табл. 1.
Одшею з важливих характеристик послуг FaaS е набiр пiдтримуваних типiв подш. У табл. 2 наведено джерела подш для AWS Lambda та Azure Fuctions.
Проблемою при обробщ подш може стати некоректно сформована подiя або збш одного з екземплярiв функцп. Для забезпечення надшносп обробки повщомлень використовують-
Таблиця 1 -
Пор1вняння характеристик AWS Lambda та Azure Fuctions
Характеристика AWS Lambda Azure Fuctions
Пщгримуват мови програмування C#, Java, Python, Node,js, Ruby, Go, API Runtime C#, JavaScript (Express.js, Node.js), F#, Java, Python, Type Script, Custom handler/ gRPC language worker
Автоматичне масштабування Функцп Lambda не збер^ають стан, кшьюсть оброблюваних запипв не обмежена Визначаеться планом розмщення Consumption plan, Premium plan, and Dedicated (App Service) plan
Оркестратор AWS Step Functions ASE, Kubernetes , Kubernetes с Azure Arc
Тригери функцiй Пщписка на поди, тригери, Lambda API Тригери i прив'язки
Iнтеграцiя черг повщомлень + +
1нструмент монiторингу Amazon Cloud Watch Azure Application Insights
Пiдтримка CLI + +
Пщгримка PowerShell + +
Пiдтримка шаблона ARM + +
Управлшня Консоль AWS Lambda, AWS SDK REST API, Visual Studio
Контекст виконання У хмарi Локально /у хмарi
ся черги. У Azure Functions при обробщ повщомлення з черги функщя може заблокувати некоректну подiю, а також гарантуе, що обробить подт хоча б один раз. У потоках подш (наприклад, в концентраторах подш Azure) блокування не використовуються. Цi служби налаштованi так, щоб забезпечити високу пропускну здатнiсть, шдтримувати кiлька груп споживачiв i можливють вiдтворення.
У AWS Lambda при безпосередньому виклику функцп потрiбно визначити стратегда обробки помилок: повторити спробу, вiдправити подiю в чергу для налагодження або промо-рувати помилку. Якщо функцiя викликаеться побiчно, можливi наступнi сценарп: асинхронний виклик, зютавлення джерел подiй. При асинхронному виклику AWS Lambda повторюе помил-ковий запит двiчi. Якщо у функцп недостатньо можливостей для обробки вшх вхщних запитiв, поди можуть чекати в черзi протягом декiлькох годин або дшв, щоб бути вщправленими в функцiю. Якщо використовуеться зютавлення джерел подш, яю зчитуються з потоюв, повто-рюеться весь пакет елеменпв. Повторнi помилки блокують обробку порушеного блоку доти, поки помилка не буде усунена або термш ди елементiв не закiнчиться.
З точки зору реалiзацil паралельно! обробки подш, як AWS, так i служби Azure здатш здiйснювати кшька виконань одша i ие1 ж функцп одночасно.
Таким чином реалiзацiя обробки подш у хмарi за допомогою безсерверних технологiй мае наступи переваги: вiдсутнiсть необхiдностi керувати шфраструктурою; суттеве скоро-чення часу випуску додатка; «тонкий» бшшг; висока продуктивнють, доступнiсть, вщмо-востiйкiсть та масштабованють. До ризикiв слiд вiднести обмеження на модель програму-вання; проблеми з оркестращею, якщо додаток складаеться iз велико1 кiлькостi незалежних функцш; збiльшення часу вiдгуку внаслiдок так званого «холодного» запуску, якщо щшьшсть потоку оброблюваних подiй недостатньо велика; потреба у додаткових налаштуваннях задля надiйностi обробки подiй, якщо щшьшсть потоку оброблюваних подш досить велика.
3. Висновки
Для високопродуктивних систем, що обробляють поди в режимi реального часу, головш характеристики - це час вщгуку на запит i доступнiсть, час вiдгуку (response time) - те, що бачить ктент: ^м фактичного часу обробки запиту (час обслуговування, service time), вш включае затримки при передачi шформацп по мережi i затримки повщомлень в черзi.
Таблиця 2 -
Джерела подш, що обробляються AWS Lambda та Azure Fuctions
Джерело оброблюваних подш Azure Fuctions AWS Lambda
Сховища даних CxoBH^e BLOB-06'eKTiB, Azure Cosmos DB Amazon DynamoDB, Amazon Cognito, Amazon Simple Storage Service Batch, Amazon Simple Storage Service
Черги Queue storage, Service Bus Amazon Simple Queue Service
Середовище для створення мжросервюних додатюв Dapr
Брокер подш Event Grid, Event Hubs Amazon CloudWatch Events
HTTP-запити та веб-перехоплювачi HTTP Tpurepu, API, Be6-nepexonnK>Bani, Azure SignalR Amazon API Gateway
1нтернет речей IoT Hub AWS IoT, AWS IoT Events
Брокер повiдомлень RabbitMQ, Kafka Amazon MQ (Apache ActiveMQ), Amazon Kinesis, Amazon Managed Streaming for Apache Kafka, self-managed Apache Kafka, Amazon Connect, Amazon Simple Notification Service, Amazon Simple Email Service
Таймер Tpurep TanMepa MoxnnBHH 3anycK ^yHKqin 3a po3raagoM, BHKopncTOByroHH Amazon CloudWatch
Сервюи монiторингу та управлiння ^epe3 Event Grid Ta Event Hubs Elastic Load Balancing, Amazon CloudWatch, AWS CodeCommit, AWS CodePipeline
Сервiси i3 голосовим управлiнням Amazon Lex, Alexa
Сервiси доставки даних ^epe3 Event Grid Ta Event Hubs Amazon Kinesis Data Firehose, CloudFront
Сервюи роботи з шфраструктурою як з кодом AWS Cloud Formation, AWS Config
Обмеженням безсерверних обчислень е так званий холодний запуск: запуск «холодних» функцш, тобто тих, яю не запускалися протягом тривалого часу, займае додатковий час. Можна виршувати цю проблему, перюдично запускаючи функци, це гарантуе, що вони залишаться «теплими», але разом з тим це призводить до додаткових витрат i зводить нашвець одну ¡з основних переваг безсерверно! системи - «тонкий» бшшг. Час запуску функци можна оптим1зувати, але цього не достатньо [3]. Таким чином, проблеми, пов'язаш ¡з холодним запуском, означають, що висока продуктивнють, яку пропонують безсерверш обчислення, досяжна тшьки за певних умов. I AWS Lambda, i Azure дозволяють уникнути холодного запуску в прем1альних i видшених планах.
Безсерверш обчислення стають новою i привабливою парадигмою для розгортання хмарних додатюв, багато в чому завдяки недавньому переходу вщ арх1тектури корпоратив-них додатюв до контейнер1в i м1кросервю1в. Але найчастше запускати весь додаток у безсерверному середовищ1 недоцшьно або економ1чно невипдно, тому ця модель передба-чае можливють запускати в нш певш частини програми, яким постшно потр1бна висока продуктивнють i значш обчислювальш ресурси. FaaS - це бшьше розширення, яке працюе разом ¡з контейнерами або в1ртуальними машинами. Таким чином, потр1бно розглядати 50
безсерверш ршення скорiше як cnoci6 доповнити pi3Hi типи архтектур додаткiв i пoдieвo-opieHTOBaHy архтектуру зокрема.
Список лггератури: 1. Sreeram P. K. Azure Serverless Computing Cookbook: Build and monitor Azure applications hosted on serverless architecture using Azure functions. - Packt Publishing Ltd, 2020. 2. Sbarski P., Kroonenburg S. Serverless architectures on Aws: with examples using Aws Lambda. - Shelter Island : Manning Publications Company, 2017. - С. 376. 3. McGrath G., Brenner P. R. Serverless computing: Design, implementation, and performance //2017 IEEE 37th International Conference on Distributed Computing Systems Workshops (ICDCSW). - IEEE, 2017. - С. 405-410.
Над1йшла до редколегИ' 02.06.2021
Кравець Наталя Сергивна, кандидат техтчних наук, доцент, доцент кафедри програмно! шженери ХНУРЕ. H^y^si штереси: хмарш технологи, паралельш обчислення. Адреса: Укратна, 61166, м. Харюв, пр. Науки, 14, тел. (057) 702 14 46.
УДК 004.62 DOI: 10.30837/0135-1710.2021.177.051
М.С. Т1ТОВСЬКОЙ, О.В. ХРЯПК1Н
ДОСЛ1ДЖЕННЯ МЕТОД1В М1ГРАЦП ДАНИХ В СИСТЕМАХ ЕЛЕКТРОННО1 КОМЕРЦП НА ПРИКЛАД1 CMS MAGENTO
Проведено aнaлiз особливостей та ризишв м^ацп даних на пpиклaдi системи електронно! кoмеpцii Magento. Визначено основш стpaтегii мiгpaцii даних. Для ви6ору найкра-щих метoдy та стратеги мпраци даних проведено oпитyвaння експеpтiв. За pезyльтaтaми oпитyвaння oбrpyнтoвaнo вибip найкращих метoдy та стратеги мпраци даних для систем електронно! комерци piзних мaсштaбiв.
1. Вступ
Система електронно! комерци - це шформацшна система (1С), яка iнтегpye вщповщне апаратне i програмне забезпечення для досягнення певних фyнкцioнaльних можливостей [1]. Серед таких можливостей можна видшити основш: прийом i оформлення замовлень по каталогах i прайс-листах через 1нтернет на товари piзних кaтегopiй, збеpiгaння замовлень в единш бaзi даних, pеeстpaцiя кopистyвaчiв, тдтримка вiддaленoгo aдмiнiстpyвaння; оброб-ка замовлень за стандартною схемою (обробка, поставка, звiтнo-фiнaнсoвi дoкyменти).
Тема електронно! комерци е популярною в Cвpoпi, що пiдтвеpджyють стaтистичнi дaнi eurostat [2]. Як показано на рис. 1, з 2010 року частка oнлaйн-пpoдaжiв щopiчнo зростае серед покупщв вшх вiкoвих груп, що свiдчить про юнування величезного
Рис.1. Змiнювaння частки oнлaйн-пpoдaжiв серед кopистyвaчiв 1нтернету piзнoгo вiкy
