CC BY
5
УДК 004.42 DOI: 10.30837/0135-1710.2021.177.029
П. Е. СИТН1КОВА, О. П. ГОВДЕРЧАК
AWS STEP FUNCTIONS ЯК НЕВЩ'еМНА СКЛАДОВА АРХ1ТЕКТУРИ СИСТЕМИ З ПОСЛ1ДОВНИМ ВИКОНАННЯМ БЕЗСЕРВЕРНИХ ФУНКЦ1Й
У стати дослвджено використання сервюу Step Functions хмарного провайдера Amazon Web Services (AWS) у системах, що мають последовые виконання функщй/дш в алгоритм свого виконання. Дослвджено також серв1с AWS, що може бути використаний в будь-якш оргатзацй для будь-яко! системи задля отримання стану виконання усього ланцюга функцш.
1. Вступ
Створюючи безсерверш додатки, розробники, як правило, хочуть масштабувати програ-му вщповщно до зростаючого навантаження, збер^аючи при цьому низью витрати i дозво-ляючи декшьком командам одночасно працювати над р1зними частинами програми. У безсервернш модел1 одшею з найкращих практик для досягнення цих цшей е роздшення б1знес-лог1ки програми на наб1р нерозв'язаних служб. Велика безсерверна програма може складатися з десятюв або сотень безсерверних служб [1].
Проблема виникае, коли така велика кшьюсть служб потребуе доступу до р1зних частин спшьного стану. Для ефективно! роботи цих служб команди також повинш мати можливють оргашзувати потш даних через ус служби додатюв в одному мющ, i це саме те, що обробляе кроков1 функци AWS. Step Functions стали найважлившим елементом безсервер-но! екосистеми завдяки всьому стану та керуванню даними, необхщними для ефективно! роботи безсерверних систем у масштаба
Бшьше того, AWS Step Functions дозволяе оргашзувати ваш1 завдання AWS за допомо-гою в1зуального редактора робочих процешв. Ви використовуете цей редактор для створен-ня д1аграм стану машини або покрокових функцш, як пот1м стають основою побудови, спшьного використання та модифшаци поведшки додатюв [2].
2. Постановка задачi
На сьогодшшнш день дуже багато додатюв використовують хмарш обчислення для спрощення або покращення !хньо! роботи, тому питання, чи використовувати безсерверш обчислення у данш робот не розглядаеться, це взято за основу системи. Як провайдер серв1с1в хмарних обчислень розглядаеться Amazon Web Services (AWS).
У данш статп розглядатиметься проблема послщовного виклику безсерверних функцш (Serverless, FaaS - Function as a Service), як! у даного представника хмарних послуг назива-ються AWS Lambda, та можливостi виршення цих проблем з допомогою сервюу AWS Step Functions.
Дослщжуючи необхщнють мiкросервiсних додаткiв запускати деякi частини лопки системи послiдовно, розбиваючи !х на окремi сервiси, можна дiйти до висновку, що найпошире-нiшим рiшенням е використання синхронного виклику хмарних функцш як сервгав, у випадку AWS - Lambdas. Накопичений досвiд експлуатацп веб-служб Amazon (AWS) дозволяе зробити висновок про те, що багато органiзацiй-користувачiв AWS спочатку використову-вали AWS Lambda (продукт Amazon's Function-as-a-Service) для автоматизаци робочих процесiв навколо запущеного та масштабованого коду. Хоча таке ршення дозволило розробникам простих програм заощаджувати час, з пiдвищенням складностi програм у компанiй, якi використовували AWS Lambda, виникали проблеми [3].
Ц проблеми об'еднувалися у двi основш групи: збiльшення тривалостi роботи та управл-iння станом. Зокрема, тд час виконання front-end сервiсiв AWS Lambda дозволяе виконува-ти функци не довше 15 хвилин. Пюля цього сервiс закiнчуеться, залишаючи завдання незавершеними [4].
Очевидно, цей недолш е критичним для оргашзацш, якi використовують складнi програми, що вимагають тривалих обчислень. Крiм того, наслiдком е неможливiсть повторного
виконання незавершених задач, оскiльки функцiя, що виконувалася, заново викликатися не може. Кожен новий запуск ще! функцп сприймаеться як окремий новий запуск Í3 сво!м особистим станом.
Для виходу з подiбно! ситуацп можливо скористатися контейнерами за допомогою Amazon Elastic Container Service (ECS). Але у випадку, коли контейнери зайнят шшими завданнями, треба додати стан.
Ще один недолш полягае в тому, що AWS Lambda не створена для ефективного управлшня станами. Розробники повинш писати код у сво!х програмах для збершання цього самого стану, що ускладнюе управлшня та збшьшуе час обробки. Отже, користувачi змушеш вибирати мiж запуском вимогливих програм та забезпеченням достатнього стану для максимального використання [5].
З огляду на описану вище проблему, метою дано! статтi е дослщження, чи е AWS Step Functions самостшним вирiшенням питання контексту та довготривалост виконання та чи варто використовувати цей шдхщ с точки зору цшоутворення.
3. Використання Step Functions архггектури системи з послщовним
виконанням функц1й
Розглянемо, що е AWS Step Functions. AWS Step Functions - це послуга, що надаеться Amazon Web Services, яка спрощуе оргашзащю декiлькох служб AWS для виконання завдань. Step Functions дозволяють створювати кроки в процес^ де результат одного кроку стае входом для шшого кроку, i це все робитьсяза допомогою вiзуального редактора робочого процесу.
Step Functions забезпечують досить зручну функцiональнiсть: автоматичну обробку повторних спроб, активащю та вщстеження для кожного кроку робочого процесу та забез-печення виконання кроюв у правильному порядку. Хоча спочатку цей список може здатися не вражаючим, виявляеться, зовшм не тривiально забезпечувати, щоб усi цi речi вщбували-ся правильно в робочих процесах, що мiстять десятки кроюв i сотнi паралельних виконань. Step Functions виконуе багато функцш, яю потребуе робити програма. 1ншими словами Step Functions е автоматом стану, його основш абстракцп називаються станами. Конф^уращя функцiй кроку е картою вшх можливих крокiв та переходiв мiж ними. Стани та !х переходи визначаються з використанням мови шта^в Амазонки. Ця мова базуеться на JSON i е власнютю Amazon [6].
Кроковi функцп AWS е невщ'емною частиною безсерверно! екосистеми завдяки наступ-ному. Створюючи безсерверш додатки, розробники, як правило, хочуть масштабувати програму вiдповiдно до зростаючого навантаження, зберiгаючи при цьому низью витрати i дозволяючи декшьком командам одночасно працювати над рiзними частинами програми. У безсервернiй моделi однiею з найкращих практик для досягнення цих цшей е роздшення бiзнес-логiки програми на набiр нерозв'язаних служб. Велика безсерверна програма може складатися з десяткiв або сотень безсерверних сервюв [7]. Проблема виникае, коли така велика кшьюсть служб потребуе доступу до рiзних частин спшьного стану. Для ефективно! роботи цих служб команди також повинш мати можливють органiзувати потш даних через усi сервiси додатюв в одному мiсцi, i саме цим займаються AWS Step Functions. Вони стали найважлившим елементом безсерверно! екосистеми впродовж усього стану системи i управлшня даними, необхщними для ефективно! роботи безсерверних систем у масштаба
4. Переваги AWS Step Functions
По-перше, Step Functions «полегшують життя» безсерверного розробника, дозволяючи швидко створювати складш послiдовностi задач в AWS, одночасно беручи на себе функщю обробки помилок i повторно! спроби виконання лопки та дозволяючи вщокремити бiзнес-логiку додатка вщ логiки оркестрац^'. Нижче буде розглянуто особливостi використання цiе! технолог^', що може допомогти шд час дизайну та розробки системи.
По-друге, завдяки цьому сервюу надаеться можливють швидкого створювання склад-них послiдовностей задач. Оргашзащя послiдовностi з десяти окремих безсерверних до-даткiв, управлiння !х повторними спробами та усунення будь-яких помилок може бути надзвичайно складним завданням. Коли ви додаете ще бшьше функцiй, складнiсть управл-шня ними зростае в геометричнiй прогреси.
По-трете, завдяки графiчному iнтерфейсу та вбудованому мехашзму оперативного контролю Step Functions управляе послiдовнiстю задач i зшмае великий оперативний тягар з команди розробниюв.
Крiм того е можливють керування станом мiж виконанням рiзних безсерверних та безстанових функцiй. Для багатьох безсерверних робочих процешв налаштування черг та баз даних для зв'язку мiж усiма безсерверними службами може зайняти багато часу та спричинити помилки, не кажучи вже про те, що не вс випадки використання вимагають реально! бази даних або реально! системи черг.
Step Functions дозволяють також легко налаштувати управлшня станом на раншх етапах, i це продовжуе працювати добре з приростом масштабу завдань, коли використовуються багато сервiсiв разом.
1з використанням ц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й, отримати високу продук-тивнiсть вiд системи може бути складно. Деяю оркестрованi фрагменти можуть обробляти лише одну задачу за раз, що може сповшьнити роботу вае! програми. Step Functions дозволяють одночасно виконувати багато паралельних робочих процешв, переконуючись, що продуктивнють масштабуеться залежно вiд завантаження програми [8].
Пропонуеться розглянути двi однаковi системи, де у базi даних будуть 100 000 запишв, запускатимуться декшька послщовних функцiй, кожна з яких виконуватиме операцiю фiльтрацi! за сво!м параметром. Рiзниця у тому, що в першш системi кожна функщя викликатиме наступну за протоколами Amazon, без використання Step Functions (щшьно зв'язаш функцi!), а друга система буде запускати Step Functions, де функци будуть незалежними. Виконаемо 10 запита та порiвняемо результати (рис.1).
Рис 1. Пор1вняння шдход1в з/без використання Step Functions
З рисунку можна зробити висновок, що продуктившсть системи з використанням Step Functions виявилась кращою за продуктившсть системи без використання цього сервюу.
Функци кроку AWS можуть шдвищити продуктивнiсть роботи в кiлькох напрямах.
Перший напрям - обробка даних. Iншi види обробки даних також добре шдходять для функцiй кроку AWS, особливо якщо джерело та адреса знаходяться всередиш AWS. Функци кроку спрощують взаемозв'язок декiлькох кроюв обробки даних, включаючи тi, що зроблеш за допомогою функцiй AWS Lambda, просто! служби черги та просто! служби сповщень.
Другий напрям - оргашзащя робочого процесу без серверiв. Основна цiннiсть крокових функцш AWS полягае в простiй оргашзаци програм, якi вимагають взаемозв'язку множини безсерверних функцiй. Для сукупностi бiзнес-процесiв, для отримання кiнцевого результату яких потрiбна комбiнацiя декiлькох роз'еднаних безсерверних програм, функщя Step може бути правильним вибором для зручносп оргашзаци.
5. Недолжи AWS Step Functions
Ус зазначенi вище переваги можуть забезпечити високу цшнють для багатьох команд та випадюв використання, але перед тим, як взяти участь у запуску функцш Step у виробницга, слщ також врахувати потенцшш недолiки використання цiе! програми у додат-ку. Хоча AWS Step Functions виршують багато проблем для безсерверно! спiльноти, перехiд усiх шарiв оркестраци на Step Functions не обов'язково е правильним ршенням. Наступне зауваження треба враховувати при використанш покрокових функцiй у вироб-нищта.
Конфiгурацiя з мовою станiв Amazon е досить складною; його синтаксис заснований на JSON i тому ошташзований для машинно! читабельностi замють читабельностi людьми. Вивчення мови може бути складним завданням, i, оскшьки воно е власнiстю Amazon, набуп навички не застосовуватимуться нiде, ^м контексту AWS Step Functions [9]. Ця мова е власнiстю Amazon i може використовуватися лише на Amazon Web Services. Тому при змш постачальника хмарних послуг потрiбно повторно впроваджувати рiвень оркестровки або замшити його альтернативою iншого постачальника.
6. Мехашзм цiноутворення AWS Step Functions
Мехашзм цiноутворення е додатковою причиною переконатися у необхщносп використання Step Functions в архiтектурi системи, що мае ланцюг послщовно виконуваних функцiй.
Розглянемо основнi характеристики цього мехашзму. Безкоштовний рiвень AWS обме-жений 4000 переходiв стану функцш кроку AWS на мюяць. Цей показник щомюячно поновлюеться, тому можливо скористатися безкоштовним рiвнем, навт якщо облiковий запис AWS не е абсолютно новим.
За межею безкоштовного рiвня використання Step Functions коштуе 0,025 доларiв США за 1000 переходiв стану. Розглянемо роботу мехашзму цшоутворення в цьому випадку на такому прикладi. Нехай е робочий процес, який перетворюе зображення для веб-сайту у чотири рiзних розмiри, причому робочий процес складаеться iз десяти переходiв стану в середньому для кожного зображення i близько 10% виконання робочого циклу передбачае одну повторну спробу. Припустимо, що завантажуеться 100 000 зображень на мюяць. Кшькють переходiв робочого процесу буде складати 1 000 000 (10 переходiв x 100 000 оброблюваних зображень). Додатково повторш спроби обробки дадуть 100 000 переходiв (((100 000 оброблюваних зображень/100) х 10) х10 переходiв). Усього за мюяць робочий процес потребуе 1 100 000 переходiв, 4 000 з яких будуть безкоштовними. У цьому випадку вартють використання функцш кроку AWS буде дорiвнювати 27,4 $ ((1 100 000 - 4 000) х 0,025 / 1 000).
Плата за AWS Step Functions доповнюе будь-яю збори за передачу даних та вартють будь-яких послуг AWS, якими ви користуетесь у робочих процесах. Наприклад, якщо щ 100 000 виконання робочого процесу призводять до плати за AWS Lambda 600 $ на мюяць та до плати за передачу даних 100 $ на мюяць, загальна вартють за мюяць складе 600 $ + 100 $ + 27,4 $ (плата за використання крокових функцш) = 727,4 $ на мюяць для вше! системи.
7. Аналiз конкурентноспроможност AWS Step Functions
Розглянемо конкурентоспроможнiсть AWS Step Functions вщносно альтернатив вiд iнших хмарних постачальниюв. Насамперед, слiд зазначити, що Step Functions не мають прямого конкурента серед лiдерiв хмарних провайдерiв таких, як Google (Google Cloud Platform, GCP) або Microsoft (Azure). Найближчим за походженням можна взяти Google Cloud Dataflows (GCP - Google Cloud Platform)
Розглянемо основш вщмшносп AWS Step Functions та Google Cloud Dataflow.
AWS Step Functions - це програмне забезпечення для створення розподшених додаткiв за допомогою вiзуальних робочих процесiв. Ця технологiя спрощуе координацiю компонентiв розподшених програм та мiкропослуг за допомогою вiзуальних робочих процесiв. Створення програм з окремих компонентiв, кожна з яких виконуе дискретнi функци, дозволяе швидко масштабувати та змшювати програми.
Google Cloud Dataflow е повнютю керованою хмарною послугою та моделлю програму-вання для пакетно! та потоково! обробки великих даних. Google Cloud Dataflow також може використовуватися як керований сервю для розробки та виконання широкого спектру шаблошв обробки даних, включаючи пакетш обчислення та безперервш обчислення. Cloud Dataflow забезпечуе автоматичне управлшня ресурсами та оптимiзацiю продуктивностi.
AWS Step Functions належить до категори «Хмарне управлiння задачами» у технолопч-ному стещ, тодi як Google Cloud Data Flow можна класифшувати як продукт, що належить до категорп «Обробка даних у реальному часЬ>.
SWOT-таблицю аналiзу цих продуктiв наведено у табл. 1.
Таблиця 1 -
SWOT AWS Step Functions порiвняно з конкурентами (GCP Dataflows)
Ключовi фактори Краще за конкурента Прше за конкурентiв
Графiчне вiдображення виконування алгоритму програми v
Конф^рування послщовних або паралельних кроюв алгоритму програми v
Контроль переходу стану мiж рiзними сервiсами v
Легюсть конфiгурування v
Швидка обробка великих об'емiв даних v
Рiвень популярностi серед розробниюв v
Рiвень цiноутворення v
Рiвень популярностi бренду v
Щдгримка штеграци з рiзними сервюами того ж самого хмарного провайдеру v
Переваги використання саме AWS Step Functions стають очевидними, тому що наразi немае конкурентного сервюу вщ шших постачальникiв, що може графiчно вiдображувати штеграци з рiзними сервюами, контролювати стан переходу мiж ними та !х вхiднi парамет-ри.
Стосовно найближчого конурента, GSP Dataflows, слщ зазначити: це сервiс, створений бшьше для монiторингу обробки великого набору даних, автоматичного збшьшення пам'ятi для !х обробки, але не для конфиураци послiдовного чи паралельного виконання рiзних сервiсiв Google.
За шшими критерiями - популярнiсть у всьому свггу та легкiсть конф^урування - AWS Step Functions виявилася гiршою, нiж система Google. Щодо популярностi, звiсно, Амазон не може сперечатися з Google, але не у свт розробникiв, де AWS юнуе вже давно та дос е безперечним лiдером з постачання сервiсiв для хмарних обчислень. Щодо легкост конфь гурування, AWS Step Functions конф^уруеться спецiальною мовою, заснованою на JSON шаблош, тому розробникам потрiбно буде спочатку навчитися !! використовувати.
Слiд також пам'ятати про цшоутворення, а саме, про те, що AWS надае 4000 безкоштов-них виконань цього сервiсу на мюяць. Це означае, що якщо система буде використовувати-ся нечасто, то кошти не потрiбно буде сплачувати взагалг Також слiд зазначити, що неважливо, скiльки сервiсiв було викликано шд час одного виконання автомату стану Амазону, це все буде вважатися одним виконанням Step Functions, i кошти тдуть окремо за сервюи та окремо за одне виконання Step Functions.
8. Висновки
У данш робот було розглянуто проблему використання безсерверних функцш, а саме, вщсутнють стану використання системи, вщсутнють механiзму повторних запитв до лан-цюга виконуваних послщовно функцiй у випадку некоректно! пращ будь-якого елементу, та сильну зв'язанють мiж усiма послiдовними функцiями у виглядi прямого запиту кожно! з них до наступно!.
Також було дослщжено особливост AWS Step Functions як окремого сервюу та шляхи вирiшення усх проблем архiтектури системи з послщовним виконанням безсерверних функцiй. Для цього пропонуеться знову звернути увагу на визначення Step Function та на проблему, що розглядалася.
Step Functions слщ належним чином описувати як «стан як послуга». Без нього неможли-во було б тдтримувати стан кожного виконання, що мае множину лямбда-функцiй/дiй.
Технолопя мiкросервiсiв передбачае, що кожен сервю - це незалежна частина системи, яка може бути навггь написана шшою мовою програмування. Тому коли потрiбне послщов-не виконання декшькох функцiй як сервiсiв, у випадку AWS - Lambdas, то впровадження Step Functions - необхщний крок для завдання порядку виконання, який залшае сервюи незалежними. Без ще! технологй доведеться на кожному кроку, у кожнш функцй задавати iм'я наступно!, тобто сервiси будуть знати кожен про кожного, що означае - тюне зв'язуван-ня i порушення концепту мiкросервiсно! архiтектури.
Як один з недолЫв Step Functions було визначено, що !х доволi складно конфiгурувати, тому що потрiбно знати нову мову AWS - Amazon State Language. Складно також уявити конф^уращю функцш, що послщовно викликаються та знають одна про одну, як вже було сказано, для того, щоб виключити або просто змшити один з кроюв, щоб пюля 3-го кроку, наприклад, викликався 6-й, а потм 4-й. Функщя, викликаючи наступну у своему ж код^ тюно зв'язана iз цiею наступною функцiею. Тому змша порядку викликiв або виключення одного з етатв виконання призведе до змши коду майже кожно! функцп окремо у той час, коли, опанувавши ASL та сконфiгурувавши Step Functions, можна з легкютю маншулювати порядком або робити щось шше, не торкаючись окремих функцiй.
AWS Step Functions виршують питання контексту мiж усiма послiдовними функцiями, що, безперечно, е !хшм плюсом, адже концепт Lambda як раз говорить, що це функщя безконтекстна та швидка. Тому вигадування лопки передачi його без Step Functions суперечить самому принципу безсерверних функцш та робить лопку виконання та тдтрим-ки складшшою та повiльнiшою. Як говорить один з принцитв розробки SOLID, лтера S -Single Responsibility, що означае «единий обов'язок». Тобто, якщо лямбди не вмдать працю-вати з контекстом i за сво!м принципом не повинш, - не треба !х змушувати, нехай про це подбае той сервю, що був створений для цього, - AWS Step Functions.
I нарешт цшоутворення. Як вже було сказано вище, Step Functions - не дуже дорогий сервю. Якщо компашя дозволяе собi систему, яка побудована на мшросервюнш архiтектурi i використовуе AWS, то у випадку послщовного виконання функцш необхщно замислитись над використанням технологи автомату стану Амазона. Адже, навт якщо сто або бшьше функцш виконуеться послщовно, коли вони сконф^уроваш у Step Functions - це все одно лише одне виконання автомату, а тисяча таких виконань коштуе лише 0,025 $.
Тому можна дти до висновку, що саме цей сервю е невщ'емною складовою мшросервгсно! архгтектури системи i3 пocлiдoвним виконанням функцiй. Step Functions - це вщносно новий продукт AWS, який, бeзcумнiвнo, змiнитъ показники продуктивноси, дозволивши розбити програ-ми на основн компоненти служби з можливютю манiпулювати кожним i3 цих компонента окремо.
Список лггератури: 1. Ньюмен С. Создание микросервисов. СПб.: Штер, 2018. 304 с. 2. AWS Step Functions: Developer Guide. Режим доступу: https://www.amazon.com/AWS-Step-Functions-Developer-Guide-ebook/dp/B078XBSLY5 3. FowlerM. Microservices. Режим дocтупу:https://martшfowler.com/ articles/ microservices.html 4. Witting A., Witting M. Amazon Web Services in Action. Shelter Island, 2015. 200p. 5. Офщшний сайт С++ Micro Services. - Режим доступу: http://cppmicroservices.org/ 6. Boricha V, Rajani M., AmannaA. Learn AWS Serverless Computing. Packt Publishing, 2019. 174 p. 7. Richardson, C. Pattern: Microservice Architecture // Kong. - Access mode: http://microservices.io/ patterns/microservices.html 8. AWS Step Functions. Режим доступу: https://aws.amazoncom/ru/step-functions/?step-functions.sort-by=item.addtionalFields.postDateTime&step-functions.sort-order=desc 9. Офщшний сайт Google: Compare AWS and Azure services to Google Cloud. Режим доступу: https://cloud.google.com/free/docs/aws-azure-gcp-service-comparison
Надтшла до редколегИ' 06.05.2021
Ситшкова Полша Едуардiвна, кандидат техшчних наук, доцент, доцент кафедри системо-техтки ХНУРЕ. Наукoвi штереси: Data Mining and Knowledge Discovery, лопчне моделю-вання даних, прийняття piшeнъ в умовах невизначеностг Адреса: Украна, 61166, м. Харюв, пр. Науки, 14, тел. (057) 702 10 06; e-mail: polina.sytnikova@nure.ua.
Говдерчак Олексш Павлович, студент групи СПРм-19-2 ХНУРЕ, мапстрант. Наукoвi iнтepecи: розробка програмного забезпечення, розробка аpхiтeктуpи систем. Адреса: Ук-ратна, м. Хаpкiв, 61166, пр. Науки, 14, тел. (057) 702 14 46; e-mail: oleksii.hovderchak@nure.ua.
УДК 004.048:004.89 DOI: 10.30837/0135-1710.2021.177.035
А.П. САФОНИК, 1.М. ГРИЦЮК, М.М. М1ЩАНЧУК, 1.В. 1ЛЬК1В
1НФОРМАЦ1ЙНА ТЕХНОЛОГ1Я ВИЗНАЧЕННЯ ЗАЛ1ЗА В КОАГУЛЯНТ НА ОСНОВ1 НЕЙРОННО1 МЕРЕЖ
Розглядаються питания побудови штелектуально! системи для визначення концент-рацii зал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дного шарiв, описано активацiйнi функцii. Проаналiзовано точшсть навчання нейронно! мережi шляхом порiвняння даних, отриманих з використан-ням рiзних оптимiзаторiв, iз використанням бiблiотеки TensorFlow. Розроблений веб-дода-ток може бути використаний в якостi складово! iнформацiйно-аналiтичноi' системи автома-тизованого керування техиологiчним процесом електрокоагуляцiйноi очистки.
1. Вступ
Очищення спчних вод - це одна з проблем сучасного людства. Останшм часом для очищення води набувають популярносп невелик! очисш споруди. Оснащення водоочисних споруд такими системами особливо важливе для сшьського господарства, легко! промисло-восп тощо. Але використання реагенпв зумовлюе створення служб забезпечення !х доставки та збер1гання, що е накладним в пор1внянш з електрохiмiчними методами, яю, в свою чергу, дають змогу добувати реагенти на мющ з наявно! сировини. Одним !з найбшьш перспектив-них метод1в, як надають таку можливють, е метод електрокоагуляци. На даний час все бшьше уваги придшяеться дослщженням цього процесу за допомогою математичних моделей, що допомагае полшшити конструктивш особливосп пристрою та зменшити витрати в експлуатацп, а також прогнозувати ефектившсть процесу в широкому д1апазош операцш з
