Дослідження методів і алгоритмів передачі великих об’ємів даних в режимі реального часу на базі рішень AWS

ЧЕКАЛЕНКО, Олексій
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9423
Title:	Дослідження методів і алгоритмів передачі великих об’ємів даних в режимі реального часу на базі рішень AWS
Authors:	ХРУЛЬОВ, Микола ЧЕКАЛЕНКО, Олексій
Issue Date:	2022
Abstract:	Темою даної кваліфікаційної роботи магістра є дослідження методів і алгоритмів передачі великих обʼємів даних в режимі реального часу на базі рішень AWS. При розробці великих програмних рішень, де присутня велика кількість сервісів (серверних програмних додатків, які повинні взаємодіяти між собою), існує проблема в передачі великої кількості даних між цими сервісами в режимі реального часу . Тому дана тема дуже важлива для розробки сучасних програмних рішень. Метою даної кваліфікаційної роботи магістра є дослідження існуючих методів і алгоритмів та розробка рішення, яке дозволяє швидко та оптимально передавати дані з мінімальною кількість зв'язків між сервісами та створити сервіс, який дає можливість компаніям отримувати зворотний зв'язок від своїх клієнтів. Об’єкт дослідження — методи та алгоритми передачі великих обʼємів даних в режимі реального часу. Предмет дослідження — програмне забезпечення та алгоритм передачі великих обʼємів даних в серверних додатках. Наукова новизна одержаних результатів полягає у розробці рішення, яке дозволяє передати велику кількість даних між сервісами системи без зменшення продуктивності цих самих сервісів. При цьому сервіси системи не будуть на пряму пов'язані між собою. Що дозволить також підвищити масштабування системи. Практична цінність результатів роботи полягає у зменшенні часу отримання даних сервісами, матиме можливість працювати з великою кількістю даних, невелика вартість використання для розробленої системи та можливість автоматичного масштабування за допомогою AWS. У першому розділі розглянуто існуючі методи та алгоритми, які дають можливість виконувати передачу даних між сервісами (http(s) requests, kafka, mqtt, kinesis), та обрано напрям дослідження. Проведено аналіз та визначено основні задачі для даної роботи. У другому розділі проведено огляд існуючих технологій розробки подібних систем передачі великих об’ємів даних в режимі реального часу. Обґрунтовано вибір архітектури для системи, яка буде реалізована в магістерській роботі. У третьому розділі описується структура системи, описуються функції, які вона виконує, розробляється захист інформації. Визначаються вимоги для роботи із системою. Наприкінці наводиться оцінка ефективності застосування системи. Висновки включають в себе основні результати роботи. У додатках наведено специфікацію, текст програми та інструкцію користувача. Загальний обсяг роботи становить 72 сторінки. У кваліфікаційній роботі магістра 18 рисунків, 2 таблиці, 3 додатки. Для виконання роботи використано 20 літературних джерел.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9423
Appears in Collections:	123 Комп’ютерна інженерія (Комп'ютерні системи та мережі)
Files in This Item:
File	Description	Size	Format
1_Титулка_Чекаленко-merged.pdf Restricted Access		2.39 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ
ІНЖЕНЕРІЇ
Пояснювальна записка
до кваліфікаційної роботи магістра
на тему: «Дослідження методів і алгоритмів передачі
великих об’ємів даних в режимі реального часу на
базі рішень AWS»
ЧДТУ.222287.004 ПЗ
Виконав: студент 2 курсу, групи МКМ-2105
спеціальності 123 – Комп’ютерна інженерія
за освітньою програмою – Комп’ютерні системи
та мережі
Олексій ЧЕКАЛЕНКО
Керівник
к.т.н., доцент
Микола ХРУЛЬОВ
Н. контроль
Світлана ГРЕСЬКО
Рецензент
науковий консультант ТОВ «Юнібіт»,
к.т.н., доцент
Юрій ЄРОФЕЄВ
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор ______ Володимир РУДНИЦЬКИЙ
Черкаси 2022 року
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра інформаційної безпеки та комп‘ютерної інженерії
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 123 – Комп’ютерна інженерія
Освітня програма Комп’ютерні системи та мережі
«ЗАТВЕРДЖУЮ»
Завідувач кафедри _____ Володимир РУДНИЦЬКИЙ
«20» жовтня 2022 року
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Чекаленку Олексію Леонідовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи Дослідження методів і алгоритмів передачі великих об’ємів
даних в режимі реального часу на базі рішень AWS
Керівник роботи к.т.н., доцент Хрульов М.В.
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «14» жовтня 2022 р. № 275/04
2. Строк подання студентом роботи
3. Вихідні дані до роботи:
передача даних, звʼязність між системами, протокол HTTP, Apache Kafka, протокол обміну
MQTT, протокол транспортного рівня UDP, Amazon Kinesis, Big Data.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1 Аналіз предметної області та постановка задачі дослідження
Розділ 2 Вибір технології та інструментальних засобів розробки системи
Розділ 3 Оптимізація методів і алгоритмів передачі великих об’ємів даних в режимі
реального часу на базі рішень AWS
Висновки
Перелік скорочень та умовних позначень
Додатки
Список використаних джерел
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
Додаток А Специфікація
Додаток Б Текст програм
Додаток В Інструкція користувача
6. Консультанти розділів роботи
Підпис, дата
Розділ Прізвище, ініціали та
посада завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 20 жовтня 2022 року
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи магістра Строк виконання
етапів роботи Примітка
1 Збір матеріалу 21.10 – 28.10 виконано
2 Обробка матеріалу 29.10 – 06.11 виконано
3 Обґрунтування актуальності виконання 12.11 – 15.11 виконано
досліджень
4 Оцінка стану проблеми, виокремлення виконано
дослідницьких задач, постановка задачі 16.11 – 18.11
дослідження
5 Викладення сутності і результатів дослідження 20.11– 25.11 виконано
6 Практичне застосування результатів 26.11 – 27.11 виконано
дослідження
7 Оформлення результатів в пояснювальну записку 27.11 – 30.11 виконано
8 Подання роботи на відгук та рецензування 01.12.22 виконано
Студент-магістрант ____________________________ Олексій ЧЕКАЛЕНКО
(підпис)
Керівник роботи _____________________________ Микола ХРУЛЬОВ
(підпис)
АНОТАЦІЯ
Темою даної кваліфікаційної роботи магістра є дослідження методів і
алгоритмів передачі великих обʼємів даних в режимі реального часу на базі
рішень AWS. При розробці великих програмних рішень, де присутня велика
кількість сервісів (серверних програмних додатків, які повинні взаємодіяти
між собою), існує проблема в передачі великої кількості даних між цими
сервісами в режимі реального часу . Тому дана тема дуже важлива для
розробки сучасних програмних рішень.
Метою даної кваліфікаційної роботи магістра є дослідження існуючих
методів і алгоритмів та розробка рішення, яке дозволяє швидко та
оптимально передавати дані з мінімальною кількість зв'язків між сервісами
та створити сервіс, який дає можливість компаніям отримувати зворотний
зв'язок від своїх клієнтів.
Об’єкт дослідження — методи та алгоритми передачі великих обʼємів
даних в режимі реального часу.
Предмет дослідження — програмне забезпечення та алгоритм
передачі великих обʼємів даних в серверних додатках.
Наукова новизна одержаних результатів полягає у розробці рішення,
яке дозволяє передати велику кількість даних між сервісами системи без
зменшення продуктивності цих самих сервісів. При цьому сервіси системи не
будуть на пряму пов'язані між собою. Що дозволить також підвищити
масштабування системи.
Практична цінність результатів роботи полягає у зменшенні часу
отримання даних сервісами, матиме можливість працювати з великою
кількістю даних, невелика вартість використання для розробленої системи та
можливість автоматичного масштабування за допомогою AWS.
У першому розділі розглянуто існуючі методи та алгоритми, які дають
можливість виконувати передачу даних між сервісами (http(s) requests, kafka,
mqtt, kinesis), та обрано напрям дослідження. Проведено аналіз та визначено
основні задачі для даної роботи.
У другому розділі проведено огляд існуючих технологій розробки
подібних систем передачі великих об’ємів даних в режимі реального часу.
Обґрунтовано вибір архітектури для системи, яка буде реалізована в
магістерській роботі.
У третьому розділі описується структура системи, описуються функції,
які вона виконує, розробляється захист інформації. Визначаються вимоги для
роботи із системою. Наприкінці наводиться оцінка ефективності
застосування системи.
Висновки включають в себе основні результати роботи. У додатках
наведено специфікацію, текст програми та інструкцію користувача.
Загальний обсяг роботи становить 72 сторінки. У кваліфікаційній роботі
магістра 18 рисунків, 2 таблиці, 3 додатки. Для виконання роботи
використано 20 літературних джерел.
ANNOTATION
The topic of this master's qualification work is the study of methods and
algorithms for transferring large volumes of data in real time based on AWS
solutions. When developing large software solutions, where there is a large number
of services (server software applications that must interact with each other), there
is a problem in transferring a large amount of data between these services in real
time. Therefore, this topic is very important for the development of modern
software solutions.
The purpose of this master's qualification work is to research existing
methods and algorithms and develop a solution that allows you to quickly and
optimally transfer data with a minimum number of connections between services
and create a service that enables companies to receive feedback from their
customers.
The object of the study is methods and algorithms for the transmission of
large volumes of data in real time.
The subject of research is the software and algorithm for transferring large
volumes of data in server applications.
The scientific novelty of the obtained results lies in the development of a
solution that allows transferring a large amount of data between system services
without reducing the performance of these same services. At the same time, the
services of the system will not be directly connected with each other, which will
also increase the scaling of the system.
The practical value of the results of the work consists in reducing the time
of receiving data by services, will be able to work with a large amount of data, low
cost of use for the developed system and the possibility of automatic scaling with
the help of AWS.
In the first section, existing methods and algorithms that make it possible to
transfer data between services (http(s) requests, kafka, mqtt, kinesis) are
considered, and the direction of research is chosen. The analysis was carried out
and the main tasks for this work were determined.
In the second chapter, an overview of existing technologies for the
development of such systems for the transmission of large volumes of data in real
time is provided. The choice of architecture for the system, which will be
implemented in the master's thesis, is justified.
The third chapter describes the structure of the system, describes the
functions it performs, and develops information protection. The requirements for
working with the system are defined. At the end, an assessment of the effectiveness
of the system is given.
The conclusions include the main results of the work. Appendices include
specification, program text, and user manual. The total volume of work is
72 pages. There are 18 figures, 2 tables, and 3 appendices in the Master's thesis.
20 literary sources were used to perform the work.
2
ЗМІСТ
ВСТУП………………………………………………………………………… 4
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА
ЗАДАЧІ ДОСЛІДЖЕННЯ…………………………………………………..... 7
1.1 Аналіз предметної області……………………………………........ 7
1.2 Вибір напряму дослідження…………………………………......... 14
1.3 Постановка задачі………………………………………………...... 17
1.4 Висновки до розділу 1…………………………………………...... 22
РОЗДІЛ 2 ВИБІР ТЕХНОЛОГІЇ ТА ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ
РОЗРОБКИ СИСТЕМИ………………………………………………………. 23
2.1 Огляд існуючих технологій……………………………………….. 23
2.2 Вибір технологій ………………………………………………….. 37
2.3 Висновки до розділу 2…………………………………………….. 44
3 ОПТИМІЗАЦІЯ МЕТОДІВ І АЛГОРИТМІВ ПЕРЕДАЧІ ВЕЛИКИХ
ОБ’ЄМІВ ДАНИХ В РЕЖИМІ РЕАЛЬНОГО ЧАСУ НА БАЗІ
РІШЕНЬ AWS………………………………………………………………… 45
3.1 Структура системи……………………………………………….... 45
3.2 Опис функцій системи…………………………………………….. 55
3.3 Забезпечення захисту інформації при роботі з створеною
системою ………………………………………………………………. 59
3.4 Технічні вимоги для роботи з системою………………………..... 62
3.5 Оцінка ефективності застосування методів і алгоритмів
передачі великих об'ємів даних………………………………………. 64
3.6 Висновки до розділу 3…………………………………………….. 66
ВИСНОВКИ…………………………………………………………………... 67
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ………………….... 69
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………….. 70
3
ДОДАТКИ:
А – 482.ЧДТУ.22287-01 Дослідження методів і алгоритмів передачі
великих об’ємів даних в режимі реального часу на базі
рішень AWS
4
ВСТУП
Актуальність теми дослідження. В сучасному світі дуже багато
компаній та корпорацій мають справу з великою кількістю серверів, що
повинні взаємодіяти між собою. Але через це виникають проблеми в передачі
великої кількості даних між цими сервісами в режимі реального часу. Для
компаній це може бути дуже збитково та негативно вплинути на їх роботу та
репутацію.
Тому, щоб уникнути надалі таких проблем та покращити роботу
потрібно розробити таке рішення, яке передаватиме дані з мінімальними
зв'язками між сервісами.
Метою випускної роботи є розробка методу та алгоритму передачі
великих обʼємів даних, що базуватиметься на AWS Kinesis. Що дасть змогу
передавати дані з мінімальними зв'язками між сервісами. Сам AWS Kinesis
це сервіс для стрімінгу великих об’ємів даних. Це буде відображено у сервісі,
який дає можливість компаніям отримувати зворотний зв'язок від своїх
клієнтів.
Для досягнення сформульованої мети необхідно розв'язувати такі
задачі:
- провести аналіз предметної області, розглянути способи передачі даних
між системами та оптимізації їх;
- обґрунтувати доцільність розробки нового методу;
- сформувати та обрати технології, що будуть використовуватися при
розробці;
- розробити спосіб поєднання усіх компонентів для співпраці між собою;
- оптимізувати систему та налаштувати;
- оцінити складність реалізації методу.
5
На цей час існує не багато джерел інформації, в яких автори описують
різноманітні способи розробки та вдосконалення цього методу. Наприклад в
книзі «Scalable Data Streaming with Amazon Kinesis: Design and secure highly
available, cost-effective data streaming applications with Amazon Kinesis» автори
Tarik Makota, Brian Maguire, Danny Gagne та Rajeev Chakrabarti розповідають
про огляд основних концепцій потоків даних, а також основ AWS Kinesis.
Потім ознайомлюють з вимогами сценарію використання, щоб допомогти
розпочати роботу та охопити ключові проблемні моменти, які виникають у
життєвому циклі потоку даних. Також описують архітектуру компонентів
Kinesis, як вони налаштовані для побудови конвеєрів даних, які
підключаються до них для споживання та обробки. Та як інші служби AWS
можна інтегрувати в Kinesis.
Об'єкт дослідження – методи та алгоритми передачі великих обʼємів
даних в режимі реального часу.
Предмет дослідження – програмне забезпечення та алгоритм передачі
великих об’ємів даних в серверних додатках.
Наукова новизна одержаних результатів полягає у розробці рішення,
яке дозволяє передати велику кількість даних між сервісами системи без
зменшення продуктивності цих самих сервісів. При цьому сервіси системи не
будуть на пряму пов'язані між собою. Що дозволить також підвищити
масштабування системи.
Практичне значення полягає у зменшенні часу отримання даних
сервісами. Також можливість працювати з великою кількістю даних та
автоматичного масштабування за допомогою AWS. Невелика вартість
використання для розробленої системи стає більш доступною.
У першому розділі розглянуто існуючі методи та алгоритми, які дають
можливість виконувати передачу даних між сервісами (http(s) requests, kafka,
mqtt, kinesi), та обрано напрям дослідження. Проведено аналіз та визначено
основні задачі для даної роботи.
6
У другому розділі проведено огляд існуючих технологій розробки
подібних систем. Обґрунтовано вибір архітектури для системи.
У третьому розділі описується структура системи, описуються функції,
які вона виконує, розробляється захист інформації. Визначаються вимоги для
роботи із системою. Наприкінці наводиться оцінка ефективності
застосування системи.
7
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА
ЗАДАЧІ ДОСЛІДЖЕННЯ
1.1 Аналіз предметної області
Аналіз предметної області полягає в огляді програмного забезпечення
та алгоритмах передачі великих об’ємів даних в серверних додатків, які вже
застосовуються.
Більш детально розберемо, що таке передача даних та способи
передачі даних між ними.
Передача даних — фізичне перенесення даних цифрового (бітового)
потоку у вигляді сигналів від точки до точки, або від точки до множини
точок засобами електрозв'язку каналом зв'язку; як правило, для подальшої
обробки комп'ютерами. Передавання даних може бути аналоговим чи
цифровим (потік двійкових сигналів), а також модульованим за допомогою
аналогової модуляції, або за допомогою цифрового кодування. Залежно від
виду сигналу використовують різні середовища передавання — проводові чи
безпроводові.
Способи передачі даних між системами.
HTTP — протокол передачі даних, що використовується в
комп'ютерних мережах. Назва скорочена від HyperText Transfer Protocol,
протокол передачі гіпертекстових документів
HTTP належить до протоколів моделі OSI 7-го прикладного рівня.
Основним призначенням протоколу HTTP є передача веб-сторінок
(текстових файлів з розміткою HTML), хоча за допомогою нього успішно
передаються як інші файли, пов’язані з веб-сторінками (зображення та
застосунки), так і не пов’язані з ними (в цьому HTTP-конкурсі зі складнішим
FTP).
8
HTTP припускає, що клієнтська програма — веб-браузер — здатна
відображати гіпертекстові веб-сторінки та файли інших типів у зручний для
користувача формі [1]. Для правильного відображення HTTP клієнти можуть
отримати та кодувати символи веб-сторінок і/або запитувати версії сторінки
мовою в потрібних мовах/кодуванні, використовуючи позначку зі стандарту
MIME, зображено на рисунку 1.1.
Рисунок 1.1 - Робота протоколу HTTP
Apache Kafka це платформа потокової передачі подій, яка
використовується для збору, обробки, зберігання та інтеграції даних у
масштабі. Він має численні варіанти використання, включаючи розподілене
потокове передавання, обробку потоків, інтеграцію даних і обмін
повідомленнями pub/sub принцип роботи Apache Kafka зображено на
рисунку 1.2.
9
Рисунок 1.2 - Платформа Apache Kafka
MQTT це легкий відкритий протокол обміну повідомленнями, який
надає клієнтам мережі з обмеженими ресурсами простий спосіб розподілу
телеметричної інформації в середовищах із низькою пропускною здатністю.
Протокол MQTT визначає два типи мережевих об’єктів - це брокер
повідомлень і кілька клієнтів. Посередник MQTT — це сервер, який отримує
всі повідомлення від клієнтів, а потім направляє повідомлення відповідним
клієнтам призначення [2]. Клієнт MQTT — це будь-який пристрій (від
мікроконтролера до повноцінного сервера), який запускає бібліотеку MQTT і
підключається до брокера MQTT через мережу, принцип роботи зображено
на рисунку 1.3.
10
Рисунок 1.3 - Робота протоколу MQTT
UDP — один із протоколів в стеку TCP/IP. Від протоколу TCP він
відрізняється тим, що працює без встановлення з'єднання. UDP — це один з
найпростіших протоколів транспортного рівня моделі OSI, котрий виконує
обмін повідомленнями без підтвердження та гарантії доставки, принцип
роботи зображено на рисунку 1.4.
Рисунок 1.4 - Робота протоколу UDP
11
Amazon Kinesis — хмарний сервіс для обробки великої кількості
розподілених потоків даних в режимі реального часу. Сервіс входить в
інфраструктуру Amazon Web Services. Дозволяє розробникам витягувати
будь-яку кількість даних з будь-якої кількості джерел, збільшуючи або
зменшуючи кількість джерел при необхідності, принцип роботи зображено
на рисунку 1.5.
Рисунок 1.5 - Хмарний сервіс Amazon Kinesis
Big Data в інформаційних технологіях — це набори інформації (як
структурованої, так і неструктурованої) настільки великих розмірів, що
традиційні способи та підходи (здебільшого засновані на рішеннях класу
бізнесової аналітики та системах управління базами даних) не можуть бути
застосовані до них. Приклад використання Big Data може бути в різних цілях,
найбільш відомі зображені на рисунку 1.6. З
12
Рисунок 1.6 - Напрямки використання Big Data
Оптимізація передачі даних між системами. Gzip це утиліта стиснення
і відновлення файлів, що використовує алгоритм Deflate. Використовується в
основному в UNIX-системах, у ряді яких є стандартом для стиснення даних.
Крім того, до традиційного UNIX-програмування, gzip виконує лише
одну функцію — це стиснення та розпакування одного файлу, не вміє
упаковувати кілька файлів в один архів. При стиску до оригінального
розширення файлу додається суфікс .gz. Для пакування кількох файлів
зазвичай їх спочатку архівують в один файл утилітою tar, а потім цей файл
стискають gzip [3]. Таким чином, стиснуті архіви вже мають подвійне
розширення .tar.gz.
13
З іншого боку, указана особливість дає gzip можливість працювати з
безперервним потоком даних, стискаючи або розпаковуючи їх. Це широко
застосовується в UNIX-системах, за допомогою перенаправлення потоків
можна працювати із запакованими файлами так само легко, як і з
розпакованими (розпаковуючи їх у пам’яті при читанні та упаковуючи при
записі); багато UNIX-утилітів мають вбудовану підтримку цього механізму.
Останнім часом gzip активно працює для завантаження Інтернет-трафіку.
Зараз gzip підтримує більшість сучасних браузерів [4]. Завдяки повсюдному
впровадженню скриптової мови програмування php, кількість сайтів з
підтримкою gzip постійно підтримується. Принцип стиснення файлів
зображено на рисунку 1.7.
Рисунок 1.7 - Стиснення файлів за допомогою GZIP
Стиснення GZIP дозволяє серверу NGINX стискати дані перед
надсиланням їх у браузер клієнта. Це зменшує пропускну здатність даних,
покращує швидкість веб-сайту та заощаджує витрати на сервер.
14
1.2 Вибір напряму дослідження
При розробці монолітного програмного забезпечення, що працює в
одному процесі, компоненти викликають один одного за допомогою методів
рівня мови або викликів функцій. Вони можуть бути сильно звʼязаними, якщо
обʼєкти створюються за допомогою коду, або можуть бути викликаними у
відокремлений спосіб, якщо використовується Dependency Injection,
посилаючись на абстракції, а не на конкретні екземпляри об’єктів.
Впровадження залежності (англ. Dependency injection, DI) - шаблон
проектування програмного забезпечення, що передбачає надання зовнішньої
залежності програмному компоненту, використовуючи «інверсію
управління» (англ. Inversion of control, IoC) для розв'язання (отримання)
залежностей.
У будь-якому випадку об’єкти працюють в одному процесі. Найбільша
проблема при переході від монолітної програми до програми на основі
мікросервісів полягає в зміні механізму зв’язку. Пряме перетворення
викликів методів у процесі на виклики до служб призведе до неефективного
спілкування, яке не працюватиме належним чином у розподілених
середовищах. Проблеми правильного проектування розподіленої системи
достатньо відомі, тому навіть існують перераховані припущення, які
розробники часто роблять, переходячи від монолітних до розподілених
проектів.
Програма на основі мікросервісів — це розподілена система, що
працює на кількох процесах або службах, зазвичай навіть на кількох серверах
або хостах. Кожен екземпляр служби зазвичай є процесом. Тому служби
повинні взаємодіяти між собою за допомогою протоколу між процесного
зв’язку, такого як HTTP, MQTT, або інших.
15
Клієнт і служби можуть спілкуватися за допомогою багатьох різних
типів спілкування, кожен з яких націлений на різні сценарії та цілі. Дані типи
спілкування можна розділити на дві групи.
Перша група визначає, чи є протокол синхронним, чи асинхронним.
Синхронний протокол. HTTP — це синхронний протокол. Клієнт
відправляє запит і чекає відповіді від сервісу. Це не залежить від виконання
коду клієнта, яке може бути синхронним (потік заблоковано) або
асинхронним (потік не заблоковано, і відповідь зрештою досягне зворотного
виклику). Важливим моментом тут є те, що протокол (HTTP/HTTPS) є
синхронним і код клієнта може продовжувати виконання завдання лише тоді,
коли він отримує відповідь сервера HTTP.
Асинхронний протокол. Інші протоколи, такі як AMQP (протокол, який
підтримується багатьма операційними системами та хмарними
середовищами), використовують асинхронні повідомлення. Код клієнта або
відправник повідомлення зазвичай не чекає на відповідь.Просто надсилає
повідомлення, як і під час надсилання повідомлення до черги RabbitMQ або
будь-якого іншого брокера повідомлень.
Друга група визначає, чи зв’язок має одного одержувача, чи кількох
одержувачів.
Одинарний приймач. Кожен запит має бути оброблений рівно одним
отримувачем або службою. Прикладом такого спілкування є шаблон
команди.
Кілька приймачів. Кожен запит може бути оброблений від нуля до
кількох одержувачів. Цей тип зв'язку повинен бути асинхронним. Прикладом
є механізм публікації/підписки, який використовується в таких шаблонах, як
Event-driven architecture.
Програма на основі мікросервісу часто використовує комбінацію цих
стилів спілкування. Найпоширенішим типом є зв’язок з одним приймачем із
синхронним протоколом, таким як HTTP/HTTPS, під час виклику звичайної
16
служби HTTP Web API. Мікросервіси також зазвичай використовують
протоколи обміну повідомленнями для асинхронного зв’язку між
мікросервісами.
Через те, що і в монолітному програмному забезпеченні, в
мікросервісній архітектурі також існує поняття звʼязності між сервісами.
Звʼязність — це міра в якому модулі програми залежить від кожного
іншого модуля (використовує якусь інформацію про нього). Зв'язність
традиційно протиставляється пов'язаності. Слабка зв'язність часто є ознакою
доброї структури комп'ютерної системи, та гарної архітектури, і в поєднанні
з високою пов'язаністю дозволяє досягти гарної підтримки коду в
майбутньому.
Зв'язність може бути «слабкою» (чи «низькою») або «сильною»
(«високою»).
Зв'язність за вмістом (сильна). З'являється, коли один модуль
модифікує або залежить від внутрішнього вмісту іншого модуля (наприклад,
використовує його змінні). Тому при зміні способу, яким другий модуль
обробляє дані, також вимагатиме зміни коду залежного модуля;
Зв'язність за спільністю даних. Два модулі мають спільні глобальні дані
(глобальні зміни). Зміна спільного ресурсу передбачає зміну всіх модулів, які
його використовують.
Зв'язність контролю. З'являється коли один модуль контролює вихід
іншої роботи, передаючи йому інформацію про те, що робить.
Залежність-штамп. (Залежність від структурованих даних) коли модулі
мають спільну складну структуру даних (наприклад, коли певний модуль
передає повну інформацію про обʼєкт, хоча інший модуль потребує лише
його частину).
Зв'язність через повідомлення. Найслабший тип зв'язності. Досягається
за допомогою децентралізації стану (в об'єктах). Взаємодія компонентів
системи через обмін повідомленнями.
17
Для системи з великою кількістю сервісів потрібно обирати
максимально “слабкий” тип звʼязності, щоб у майбутньому уникнути
збільшення витрат на розробку систем подібного рівня.
Тому в рамках даної роботи потрібно визначити максимально
ефективний метод передачі даних між сервісами мікросервісної системи,
який матиме змогу забезпечити мінімальну звʼязність між модулями системи.
Також потрібно дослідити ефективність використання даного методу при
роботі з великою кількістю даних.
1.3 Постановка задачі
При роботі з великою кількістю даних виникає проблема актуальності
даних при передачі їх між великою кількістю програмних сервісів.
Програмний сервіс — це програмне забезпечення, яке виконує якусь одну
роль у великій програмній системі. Це дає можливість, по перше, розділити
навантаження в системі та розділити обовʼязки програмного продукту (одне з
правил SOLID).
SOLID - це абревіатура складена з перших літер п'яти базових
принципів програмування та дизайну запропонована Робертом Мартіном.
Принципи SOLID використовують для дизайну та розробки таких
програмних систем, які, з великою ймовірністю, зможуть тривалий час
розвиватися, розширюватися і підтримуватися. Як зазначає сам автор,
запропоновані ним принципи не є «істиною в останній інстанції», правилами,
або ж суворими законами. У нього немає доказів, що вони завжди працюють,
або ж що їх слід неухильно дотримуватись. Проте, вони були сформульовані
на основі спостережень й зазвичай допомагають уникнути проблем. SOLID
складається з:
- single responsibility principle (принцип єдиного обов'язку). Кожен об'єкт
має виконувати лише один обов'язок;
18
- open/closed principle (принцип відкритості/закритості). Програмні
сутності повинні бути відкритими для розширення, але закритими для
змін. Тобто, має бути спосіб змінювати поведінку програмних модулів
без потреби змінювати їхній вихідний код (наприклад, через механізм
динамічного або статичного поліморфізму);
- Liskov substitution principle (принцип підстановки Лісков). Об'єкти в
програмі можуть бути зміненими їх нащадками без зміни коду
програми;
- interface segregation principle (принцип розділення інтерфейсу). Багато
спеціалізованих інтерфейсів краще за один універсальний. Інтерфейс
може бути поділений на спеціалізовані ще на стадії проектування,
заради майбутньої гнучкості програмних компонентів;
- dependency inversion principle (принцип інверсії залежностей).
Залежності всередині системи будуються на основі абстракцій, що не
повинні залежати від деталей; навпаки, деталі мають залежати від
абстракцій. Модулі вищих рівнів не мають залежати від модулів
нижчих рівнів.
Принцип єдиного обовʼязку і є головним принципом при побудові
великих програмних комплексів, якщо мова йде про високонавантажені
комплекси. Також цей принцип покладений в сучасну програмну архітектуру
з назвою “мікросервісна архітектура”.
Мікросервіси — архітектурний стиль, за яким єдиний додаток
будується як сукупність невеликих сервісів, кожен з яких працює у своєму
власному процесі та спілкується з рештою, використовуючи прості та швидкі
протоколи передачі даних, зазвичай HTTP. Ці сервіси будуються навколо
бізнес-потреб та незалежно один від одного з використанням зазвичай
повністю автоматизованого середовища. Існує абсолютний мінімум
централізованого керування цими сервісами. Самі по собі вони можуть бути
19
написані з використанням різних мов програмування і технологій зберігання
даних.
Мікросервісна архітектура зручна для реалізації процесу безперервного
постачання програмного продукту, на відміну від сервісу — орієнтованої
архітектури, мікросервісна спрямована на створення одного застосунку в той
час, як сервісно — орієнтована система являє собою множину застосунків,
які взаємодіють між собою.
Тому при розробці систем на базі мікросервісної архітектури, особливо
якщо дана система буде оперувати з великими даними, потрібно обрати
оптимальний метод доставки даними між цими сервісами. Стандартний
спосіб передачі даних через HTTP зʼєднання підходить при роботі з
синхронним методом отримання інформації. Але бувають випадки, коли
велика кількість сервісів повинні отримувати актуальну інформацію від
джерела даних в момент, коли ці дані зʼявляються в системі.
Актуальність (від лат. actualis — справжній, теперішній, сучасний,
важливий у цей момент) - означає властивість інформації, відомостей, норм,
яка може бути втрачена із часом, з появою свіжішої, сучасної інформації.
Актуальність може втрачатися поступово, частинами, або в певних випадках
— разово і повністю. Актуальність даних — властивість даних перебувати в
стані, який відповідає сучасній дійсності.
Для того, щоб сервіси отримували актуальні дані від джерела даних,
сервіси можуть використовувати наступні підходи для отримання даних:
- HTTP Long Polling підхід;
- підписка для stream, який створений джерелом даних;
- відправка даних напряму з сервісу, який володіє даними.
Long Polling - це метод, який дає можливість клієнту (програмному
сервісу) отримати актуальні дані від сервера (джерела даних) в режимі
реального часу (рисунок 1.8)
20

Рисунок 1.8 - Схема роботи методу Long Polling
Недоліком даного підходу є велика кількість запитів, які буде
отримувати джерело даних. Також є проблема актуальності даних. При
використанні такого підходу клієнт отримує останні дані, але з невеликою
затримкою.
В програмуванні термін потік використовується в кількох значеннях,
але у всіх випадках посилаються на послідовність елементів даних, що
стають доступними через якийсь час.
В Unix і споріднених системах, заснованих на мові програмування C,
потік — це джерело або призначення даних, зазвичай індивідуальних байтів
або знаків. Потоки — це абстракція, що використовується, наприклад при
читанні або записі файлів, або при зв'язку з вузлами мережі.
Файлова система може підтримувати багато іменованих незалежних
потоків для одного файлу. Є один головний потік, який передає нормальні
дані з файлу. Додаткові потоки можуть використовуватися, щоб запам'ятати
іконки, короткий звіт і індексацію інформації, зональну інформацію (для
файлів, що завантажуються) тощо.
Реалізації потоків даних описана в шаблоні проектування системи -
Observable. Спостерігач, Observer — поведінковий шаблон проектування.
Визначає залежність типу «один до багатьох» між об'єктами таким чином, що
21
при зміні стану одного об'єкта всіх залежних від нього сповіщають про цю
подію, його зображено на рисунку 1.9.
Рисунок 1.9 - Схема роботи Streams на базі шаблона Observable
Даний підхід дає можливість джерелу даних публікувати оновлену
інформацію в потік даних, і при цьому клієнти (сервіси) підписуються на
даний потік даних, а не на пряму до джерела даних.
Посилання даних напряму з джерела даних до кожного клієнта значно
ускладнює розробку головного сервісу та зменшує можливість
масштабування даного сервісу.
Масштабування програмного забезпечення — це здатність програми чи
продукту (апаратне чи програмне забезпечення) продовжувати нормально
функціонувати, коли змінюється їх розмір або обсяг, щоб і надалі
задовольняти потреби. Зазвичай це повторне масштабування на більший
розмір або обсяг. Масштабування може здійснюватися як для самого
продукту (наприклад, набору комп’ютерних систем різного розміру з точки
зору пам’яті, оперативної пам’яті тощо), так і для заміни масштабованого
об’єкта на вищу версію (наприклад, оновлення програмного забезпечення).
Виходячи з вищесказаного можна зробити висновок, що кращим
методом при передачі даних між сервісами є метод використання потоків
даних. Тому, для даного дослідження можна обрати можливість
використання потоків даних при роботі з великою кількістю сервісів і даних,
які будуть передаватися між цими сервісами.
22
1.4 Висновки до розділу 1
В розділі було розглянуто та проаналізовано предметну область
передачі даних між системами, а саме протокол http, платформу Apache
Kafka, протокол обміну MQTT, протокол транспортного рівня UDP та
хмарний сервіс Amazon Kinesis. Також зроблено огляд Big Data та
оптимізацію передачі даних між системами (gzip).
В напрямку дослідження представили звʼязність між системами,
масштабування та принцип передачі великої кількості інформації.
На підставі отриманої інформації було поставлено задачі до
розробленої системи, які потрібно реалізувати в рамках роботи.
23
РОЗДІЛ 2 ВИБІР ТЕХНОЛОГІЇ ТА ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ
РОЗРОБКИ СИСТЕМИ
2.1 Огляд існуючих технологій
Для розробки системи та кращого розуміння технологій, які вже
використовуються у світі було розглянуто протоколи передачі даних (Kinesis,
Apache Kafka, MQTT та HTTPS).
Протокол передачі даних HTTP(S). Це розширення протоколу (спосіб
передавання даних) HTTP , необхідне для підтримки шифрування з метою
підвищення рівня безпеки даних. HTTPS розробила компанія Netscape
Communications для браузера Netscape Navigator у 1994 році.
Це особливо важливо, коли користувачі передають конфіденційні дані,
наприклад під час входу в банківський рахунок, службу електронної пошти
або постачальника медичного страхування.
HTTPS використовує протокол шифрування для шифрування зв’язку.
Протокол називається Transport Layer Security (TLS), хоча раніше він був
відомий як Secure Sockets Layer (SSL). Цей протокол забезпечує захист
зв’язку за допомогою так званої інфраструктури асиметричного відкритого
ключа. Цей тип системи безпеки використовує два різні ключі для
шифрування зв’язку між двома сторонами.
Приватний ключ – цей ключ контролюється власником веб-сайту, і він,
зберігається в закритому вигляді. Цей ключ знаходиться на веб-сервері та
використовується для розшифровки інформації, зашифрованої відкритим
ключем.
Відкритий ключ – цей ключ доступний кожному, хто хоче взаємодіяти
з сервером у безпечний спосіб. Інформацію, зашифровану відкритим ключем,
можна розшифрувати лише закритим ключем [9].
24
HTTPS запобігає трансляції інформації веб-сайтів у спосіб, який легко
переглядають усі, хто стежить за мережею. Коли інформація надсилається
через звичайний HTTP, інформація розбивається на пакети даних, які можна
легко «прослідкувати» за допомогою безплатного програмного забезпечення.
Це робить зв’язок через незахищене середовище, наприклад
загальнодоступну Wi-Fi, дуже вразливим до перехоплення. Насправді всі
комунікації, які відбуваються через HTTP, відбуваються у вигляді простого
тексту, що робить їх дуже доступними для всіх, хто має відповідні
інструменти, і вразливими для атак на шляху. Приклад різниці HTTP та
HTTPS зображено на рисунку 2.1
Рисунок 2.1 - Схема роботи HTTP та HTTPS протоколу
За допомогою HTTPS трафік шифрується таким чином, що навіть якщо
пакети прослуховуються або іншим чином перехоплюються, вони
виглядатимуть як безглузді символи.
25
Технічно кажучи, HTTPS не є окремим протоколом від HTTP. Це
просто використання шифрування TLS/SSL через протокол HTTP. HTTPS
виникає на основі передачі сертифікатів TLS/SSL, які підтверджують, що
певний постачальник є тим, за кого себе видає [10].
Коли користувач підключається до веб-сторінки, веб-сторінка надсилає
свій SSL-сертифікат, який містить відкритий ключ, необхідний для запуску
безпечного сеансу. Потім два комп’ютери, клієнт і сервер, проходять процес,
який називається рукостисканням SSL/TLS, який являє собою серію
зворотних зв’язків, які використовуються для встановлення безпечного
з’єднання. Щоб глибше зануритися в шифрування та рукостискання
SSL/TLS, прочитайте про те, що відбувається під час рукостискання TLS.
HTTPS пропонує численні переваги перед HTTP-з’єднаннями.
Захист даних і користувачів. HTTPS запобігає прослуховування між
веб-браузерами та веб-серверами та встановлює безпечний зв’язок. Таким
чином він захищає конфіденційність користувача та конфіденційну
інформацію від хакерів [11]. Це важливо для транзакцій, пов’язаних з
особистими чи фінансовими даними.
Коли клієнти знають, що веб-сайт автентичний і захищає їхні дані, це
дає надійність. Крім того, HTTPS збільшує швидкість передачі даних,
зменшуючи розмір даних.
Пошукова оптимізація (SEO). Веб-сайти HTTPS зазвичай займають
вищі позиції на сторінках результатів пошукової системи, що є значною
перевагою для організацій, які прагнуть збільшити свою цифрову
присутність за допомогою SEO.
З’єднання HTTPS можуть бути вразливими до таких шкідливих дій:
- криптоаналіз або слабкість протоколу. Зловмисники можуть
використовувати криптоаналіз або потенційні недоліки, щоб зламати
з’єднання HTTPS;
26
- атаки на клієнтський комп'ютер. Зловмисники можуть встановити
зловмисний кореневий сертифікат на клієнтський комп’ютер або
довірене сховище браузера, таким чином скомпрометувавши з’єднання
HTTPS;
- маніпулювання центром сертифікації. Зловмисники можуть
маніпулювати або скомпрометувати центр сертифікації, щоб отримати
фальшивий сертифікат, якому помилково довіряють основні браузери.
Протокол MQTT. Це протокол обміну повідомленнями, розроблений
для створення надійного стандарту між машинного зв’язку (m2m). Енді
Стенфорд Кларк з IBM і Арлен Ніппер з Eurotech створили протокол у 1999
році.
MQTT — це протокол публікації та підписки, що означає, що замість
зв’язку із сервером клієнтські пристрої та програми публікують теми, які
обробляє брокер, і підписуються на них. Зазвичай використовує IP (Інтернет-
протокол) як транспорт, але також може використовувати інші двонаправлені
транспорти.
MQTT є стандартом OASIS. Специфікацією керує технічний комітет
OASIS MQTT [11].
В Інтернету речей є одне завдання — це передавати дані на пристрої в
мережі та з них. Проблема полягає в тому, що ці мережі можуть бути будь-де
у світі, і кожна з них стикається з багатьма умовами, які можуть і призведуть
до їх збою. MQTT, а також MQTT-SN, має багато вбудованих функцій, які
допомагають пом’якшити деякі з цих проблем. Деякі з основних функцій
перераховані нижче.
Протокол MQTT визначає два типи мережевих об’єктів — це брокер
повідомлень і кілька клієнтів. Посередник MQTT — це сервер, який отримує
всі повідомлення від клієнтів, а потім направляє їх до відповідних клієнтів
призначення. Клієнт MQTT — це будь-який пристрій (від мікроконтролера
27
до повноцінного сервера), який запускає бібліотеку MQTT і підключається до
брокера MQTT через мережу.
Інформація організована за ієрархією тем. Коли видавець має новий
елемент даних для розповсюдження, він надсилає керуюче повідомлення з
даними підключеному брокеру. Потім брокер розповсюджує інформацію
всім клієнтам, які підписалися на цю тему. Видавцю не потрібно мати
жодних даних про кількість або місцеперебування передплатників, а
передплатникам, і собі, не потрібно налаштовувати будь-які дані про
видавців.
Якщо брокер отримує повідомлення на тему, на яку немає поточних
передплатників, брокер відхилив повідомлення, якщо видавець повідомлення
не призначив це повідомлення як збережене. Збережене повідомлення — це
звичайне повідомлення MQTT із прапорцем збереження, встановленим у
значення true. Посередник зберігає останнє збережене повідомлення та
відповідний QoS для вибраної теми [12]. Кожен клієнт, який підписується на
шаблон теми, який відповідає темі збереженого повідомлення, отримує
збережене повідомлення одразу після підписки. Посередник зберігає лише
одне збережене повідомлення на тему. Це дозволяє новим підписникам на
тему отримувати найновішу цінність, а не чекати наступного оновлення від
видавця.
Коли клієнт публікації вперше підключається до посередника, він може
налаштувати повідомлення за замовчуванням, яке надсилатиметься
передплатникам, якщо посередник виявить, що клієнт публікації несподівано
від’єднався від посередника.
Клієнти взаємодіють лише з брокером, але система може містити
кілька серверів-брокерів, які обмінюються даними на основі тем їхніх
поточних абонентів.
Мінімальне повідомлення керування MQTT може містити лише два
байти даних. У разі потреби контрольне повідомлення може містити близько
28
256 мегабайтів даних. Існує чотирнадцять визначених типів повідомлень, які
використовуються для підключення та відключення клієнта від брокера, для
публікації даних, для підтвердження отримання даних і для контролю
з’єднання між клієнтом і сервером.
MQTT покладається на протокол TCP для передачі даних. Варіант,
MQTT-SN, використовується над іншими транспортними засобами, такими
як UDP або Bluetooth.
MQTT надсилає облікові дані підключення у форматі звичайного
тексту та не включає жодних заходів безпеки чи автентифікації. Це можна
забезпечити за допомогою TLS для шифрування та захисту переданої
інформації від перехоплення, модифікації чи підробки.
Стандартним не зашифрованим портом MQTT є 1883. Зашифрованим
портом є 8883 [13].
Брокер MQTT — це частина програмного забезпечення, що працює на
комп’ютері (запущено локально або в хмарі), і може бути створено
самостійно або розміщено третьою стороною. Він доступний у відкритому
коді.
Брокер виконує функції поштового відділення. Клієнти MQTT не
використовують адресу прямого з’єднання передбачуваного одержувача, а
використовують рядок теми під назвою «Тема». Кожен, хто підписався,
отримує копії всіх повідомлень на цю тему. Кілька клієнтів можуть
підписатися на тему в одного брокера (можливість «один до багатьох»), а
один клієнт може зареєструвати підписку на теми в кількох брокерів (багато
до одного).
Кожен клієнт може як створювати, так і отримувати дані шляхом
публікації та підписки, тобто пристрої можуть публікувати дані датчиків і
все ще мати можливість отримувати інформацію про конфігурацію або
команди керування (MQTT — це протокол двонаправленого зв’язку). Це
допомагає як в обміні даними, так і в управлінні та контролі пристроїв.
29
Клієнт не може транслювати одні й ті самі дані для ряду тем і повинен
опублікувати кілька повідомлень для брокера, кожне з окремою темою.
Завдяки архітектурі брокера MQTT клієнтські пристрої та серверна
програма стають роз’єднаними. Таким чином, клієнти не знають інформації
один одного. MQTT, якщо його налаштовано, може використовувати
шифрування TLS із з’єднаннями, захищеними сертифікатом, іменем
користувача та паролем. За бажанням для підключення може знадобитися
сертифікація у формі файлу сертифіката, який надає клієнт і який має
збігатися з копією сервера.
У разі збою програмне забезпечення брокера та клієнти можуть
автоматично перейти до резервного/автоматичного резервного брокера.
Посередників резервного копіювання також можна налаштувати для
розподілу навантаження клієнтів між декількома локальними серверами, у
хмарі чи комбінацією цих серверів.
Посередник може підтримувати як стандартний MQTT, так і MQTT для
сумісних специфікацій, таких як Sparkplug. Це можна зробити з тим самим
сервером, в той самий час і з однаковими рівнями безпеки.
Посередник відстежує всю інформацію про сеанс під час увімкнення та
вимкнення пристрою за допомогою функції під назвою «постійні
сеанси» [14]. У цьому стані брокер зберігатиме інформацію про підключення
для кожного клієнта, теми, на які підписався кожен клієнт, і будь-які
повідомлення для теми з QoS 1 або 2. На рисунку 2.2 зображено приклад
підключення MQTT (QoS 0) із підключенням, публікацією/підпискою та
відключенням. Перше повідомлення від клієнта B зберігається завдяки
прапору збереження.
30
Рисунок 2.2 - Приклад підключення протоколу MQTT
Основними перевагами брокера MQTT є:
- усуває вразливі та незахищені підключення клієнтів, якщо
налаштовано;
- можна легко масштабувати від одного пристрою до тисячі;
- керує та відстежує всі стани підключення клієнта, включаючи облікові
дані безпеки та сертифікати, якщо налаштовано;
- зменшення навантаження на мережу без шкоди для безпеки, якщо
налаштовано на (стільникову або супутникову мережу).
31
Типи повідомлень:
- підключення (приклад підключення MQTT (QoS 0) із підключенням,
публікацією/підпискою та відключенням. Перше повідомлення від
клієнта B зберігається завдяки прапору збереження);
- очікування (очікує встановлення з’єднання з сервером і створює
зв’язок між вузлами);
- відключення (чекає, поки клієнт MQTT завершить будь-яку роботу, яку
він повинен виконати, і сеанс TCP/IP від’єднається);
- публікування (негайно повертається до потоку програми після передачі
запиту клієнту MQTT).
Apache Kafka — це розподілена платформа потокового передавання
даних, яка може публікувати, підписуватися, зберігати та обробляти потоки
записів у реальному часі. Він призначений для обробки потоків даних із
кількох джерел і доставки їх багатьом споживачам.
Apache Kafka є альтернативою традиційній корпоративній системі
обміну повідомленнями. Починався як внутрішня система, розроблена
Linkedin для обробки 1,4 трильйона повідомлень на день, але тепер це
рішення для потокової передачі даних із відкритим вихідним кодом із
застосуванням для різноманітних корпоративних потреб.
Мікросервіси змінили ландшафт розвитку. Що роблять розробників
більш гнучкими, зменшуючи залежність, наприклад рівні спільних баз даних.
Але розподілені програми, які створюють ваші розробники, все ще
потребують певного типу інтеграції для обміну даними. Один із популярних
варіантів інтеграції, відомий як синхронний метод, використовує інтерфейси
прикладного програмування (API) для обміну даними між різними
користувачами.
Другий варіант інтеграції, асинхронний метод, передбачає реплікацію
даних у проміжному сховищі. Саме тут на допомогу приходить Apache
Kafka, який передає дані від інших команд розробників для заповнення
32
сховища даних, тож даними можна ділитися між кількома командами та
їхніми програмами.
Команди мікросервісів мають інші вимоги до інтеграції, ніж традиційні
команди каскадного розвитку. Ці команди вимагають 3 основних здібностей:
- розподілені інтеграції — легкі інтеграції на основі шаблонів, які можна
безперервно розгортати, де це необхідно, і не обмежуються
централізованим розгортанням типу ESB;
- API - послуги для підтримки екосистем партнерів, клієнтів і
розробників, які можуть запропонувати надійне та прибуткове
використання послуг;
- контейнери — платформа для розробки, керування та масштабування
хмарних і підключених програм. Контейнери не дозволяють
розробляти ощадливі артефакти, які можна розгортати окремо, є
частиною процесів DevOps і підтримують готову кластеризацію,
забезпечуючи високу доступність.
Apache Kafka вбудовано в конвеєри потокових даних, які обмінюються
даними між системами та/або програмами, а також вбудовано в системи та
програми, які споживають ці дані. Apache Kafka підтримує низку випадків
використання, де життєво важливі висока пропускна здатність і
масштабованість. Оскільки Apache Kafka зводить до мінімуму потребу в
інтеграції точка-точка для обміну даними в певних програмах, він може
зменшити затримку до мілісекунд. Це означає, що дані стають доступними
для користувачів швидше, що може бути корисним у випадках використання,
які вимагають доступності даних у режимі реального часу, таких як ІТ-
операції та електронна комерція [14].
Apache Kafka може обробляти мільйони точок даних за секунду, що
робить його ідеальним для розв'язання проблем із великими даними. У
багатьох випадках обробки даних, таких як Інтернет речей (IoT) і соціальні
медіа, дані зростають експоненціально та можуть швидко перевантажити
33
програму, яка створюється на основі сьогоднішнього обсягу даних. З точки
зору обробки даних, потрібно враховувати можливість масштабування, а це
означає планування збільшення кількості ваших даних.
У Kafka потоковий процесор — це все, що отримує безперервні потоки
даних із вхідних тем, виконує певну обробку цих вихідних даних і створює
безперервні потоки даних для вихідних тем. Наприклад, роздрібна програма
може приймати вхідні потоки продажів та поставок і виводити потік
повторних замовлень і коригування цін, обчислених на основі цих даних [15].
Можна виконати просту обробку безпосередньо за допомогою API
виробника та споживача. Однак для складних перетворень Kafka надає
повністю інтегрований Streams API. Можна створювати програми за
допомогою Streams API, які виконують нетривіальні завдання обробки, які
обчислюють агрегації на основі потоків або об’єднують потоки разом.
Потоки допомагають розв'язати такі проблеми, як обробка не
порядкових даних, повторна обробка вхідних даних під час зміни коду,
виконання обчислень зі збереженням стану тощо.
API потоків побудовано на основних примітивах Kafka, зокрема, він
використовує API виробника та споживача для введення, Kafka для
збереження стану та той самий груповий механізм для відмовостійкості серед
примірників потокового процесора.
Для конвеєрів потокових даних комбінація підписки на події в
реальному часі дає змогу використовувати Kafka для конвеєрів із дуже
низькою затримкою. Здатність Kafka надійно зберігати дані означає, що його
можна використовувати для критично важливих даних, де має бути
гарантована доставка даних; або для інтеграції з офлайн-системами, які
завантажують дані лише періодично або можуть не працювати протягом
тривалого періоду часу для обслуговування. Засоби потокової обробки
дозволяють перетворювати дані в міру їх надходження.
34
Amazon Kinesis спрощує збір, обробку та аналіз потокових даних у
режимі реального часу, щоб можна було своєчасно отримувати статистичні
дані та швидко реагувати на нову інформацію.
Kinesis - це набір сервісів для обробки потоків різноманітних даних.
Дані обробляються в шардах — кожен шард може приймати 1000
записів на секунду.
Шард (Shard) - це екземпляр MongoDB, що містить підмножину даних
колекції. Кожен shard являє собою повторюючу копію.
Існує обмеження за замовчуванням у 500 шардів, але можна подати
запит на збільшення до необмеженої кількості шардів.
Запис складається з ключа розділу, порядкового номера та блоку даних
(до 1 МБ).
Тимчасове зберігання даних – збереження за умовчанням 24 години,
але можна налаштувати до 7 днів.
Існує чотири типи послуги Kinesis.
Kinesis Video Streams дозволяє легко та безпечно передавати відео з
підключених пристроїв на AWS для аналітики, машинного навчання (ML) та
іншої обробки [16].
Надійно зберігає, шифрує та індексує потоки відеоданих і забезпечує
доступ до даних через простий у використанні API.
Хмарні сервіси надають потоки даних. За умовчанням зберігає дані
протягом 24 годин, до 7 днів. Зберігає дані – 5 транзакцій на секунду для
читання, максимальна швидкість читання до 2 МБ за секунду та 1000 записів
за секунду для запису до максимальної швидкості 1 МБ за секунду.
Підтримується шифрування в стані спокою за допомогою шифрування
на стороні сервера (KMS) із головним ключем клієнта.
Потоки даних Kinesis. Kinesis Data Streams дозволяє створювати власні
програми, які обробляють, аналізують потокові дані для спеціальних потреб.
35
Kinesis Data Streams дозволяє обробляти великі потоки даних в
реальному часі. Корисний для швидкого переміщення даних від виробників
даних і подальшої безперервної обробки даних. Data Streams зберігає дані
для подальшої обробки програмами (ключова відмінність від Firehose, який
доставляє дані безпосередньо до служб AWS).
Загальні випадки використання включають:
- прискорене приймання журналів і даних;
- показники та звітність у реальному часі;
- аналітика даних у реальному часі.;
- комплексна потокова обробка.
На рисунку 2.3 показано високорівневу архітектуру потоків даних
Kinesis.
Рисунок 2.3 - Високорівнева архітектура потоків даних Kinesis
Споживачі обробляють дані в режимі реального часу. Також можуть
зберігати свої результати за допомогою служби AWS, як-от Amazon
DynamoDB, Amazon Redshift або Amazon S3. Програми Kinesis Streams є
споживачами, які працюють на примірниках EC2. Шарди — це унікальні
групи або записи даних у потоці. Записи — це одиниці даних, що
зберігаються в Kinesis Stream [17].
Amazon Kinesis Data Firehose — це повністю керована служба для
доставки потокових даних у режимі реального часу в такі місця призначення,
36
як Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon
OpenSearch Service, Splunk. Сторонні постачальники послуг, зокрема
Datadog, Dynatrace, LogicMonitor, MongoDB, New Relic і Sumo Logic. Kinesis
Data Firehose є частиною платформи потокових даних Kinesis разом із Kinesis
Data Streams, Kinesis Video Streams і Amazon Kinesis Data Analytics. З Kinesis
Data Firehose не потрібно писати програми чи керувати ресурсами [18].
Налаштування виробників даних для надсилання даних до Kinesis Data
Firehose, і він автоматично доставляє дані до вказаного пункту призначення.
Також можливо налаштувати Kinesis Data Firehose для перетворення даних
перед їх доставкою.
Amazon Kinesis Data Analytics — це найпростіший спосіб обробки й
аналізу потокових даних у реальному часі. Може використовувати стандартні
запити SQL для обробки потоків даних Kinesis. Також забезпечує аналіз у
реальному часі. Для генерації аналітики часових рядів, в інформаційних
панелях в режимі реального часу, можуть створювати сповіщення та
сповіщення в реальному часі, швидко створюється та запускаються потужні
коди SQL для потокових джерел. Також отримувати дані з Kinesis Streams і
Kinesis Firehose. Виведення в потоки даних S3, RedShift, Elasticsearch і
Kinesis. Сидить над Kinesis Data Streams і Kinesis Data Firehose.
Програма Kinesis Data Analytics складається з трьох компонентів.
Вхід – джерело потокового передавання для програми.
Код програми – серія інструкцій SQL, які обробляють вхідні дані та
створюють вихідні дані.
Вихід – один або кілька потоків у програмі для зберігання проміжних
результатів [19].
37
2.2 Вибір технологій
Для досягнення цілей даної роботи потрібно розробити систему, яка
буде мати можливість приймати велику кількість даних через
користувацький інтерфейс, а потім відправляти між елементами
мікросервісної системи. Для досягнення цих цілей потрібно перш за все
визначитися з мовою програмування, яку буде використано для реалізації
даної системи.
Мова програмування — це штучна мова, створена для передачі команд
машинам, зокрема комп'ютерам. Мови програмування використовуються для
створення програм, які контролюють поведінку машин, та для запису
алгоритмів. Мова програмування — це нотація для запису програм, які є
специфікаціями якогось обчислення або алгоритму.
Для розробки подібної системи потрібно розробити користувацький
інтерфейс, який дасть можливість вводити дані для тестування роботи
системи, а також розробити декілька мікросервісів серверною мовою
програмування.
Інтерфейс користувача — засіб зручної взаємодії користувача з
інформаційною системою. Сукупність засобів для обробки та відбиття
інформації, якнайбільше пристосованих для зручності користувача. У
графічних системах інтерфейс користувача, втілюється багатовіконним
режимом, змінами кольору, розміру, видимості (прозорість, напівпрозорість,
невидимість) вікон, їх розташуванням, сортуванням елементів вікон,
гнучкими налагодженнями як самих вікон, так і окремих їх елементів (файли,
теки, ярлики, шрифти тощо), доступністю багатокористувацьких
налаштувань.
Розглянемо наявні мови програмування, які використовуються для
реалізації інтерфейсу користувача.
38
HTML - стандартизована мова розмітки документів для перегляду веб-
сторінок у браузері. Веб-браузери отримують HTML документ від сервера за
протоколами HTTP/HTTPS або відкривають з локального диска, далі
інтерпретують код в інтерфейс, який відображатиметься на екрані монітора.
Елементи HTML є будівельними блоками сторінок HTML. За
допомогою конструкцій HTML, зображення та інші об'єкти, такі як
інтерактивні форми, можуть бути вбудовані у візуалізовану сторінку. HTML
надає засоби для створення структурованих документів, позначаючи
структурну семантику тексту, наприклад заголовки, абзаци, списки,
посилання, цитати та інші елементи. Елементи HTML окреслені тегами,
написаними з використанням кутових дужок. Теги на кшталт <img /> чи
<input /> безпосередньо виводять вміст на сторінку. Інші теги, такі як <p>,
оточують текст і надають інформацію про нього, а також можуть включати
інші теги як піделементи. Браузери не показують теги HTML, але
використовують їх для інтерпретації вмісту сторінки.
CSS — це спеціальна мова стилю сторінок, що використовується для
опису їхнього зовнішнього вигляду. Самі ж сторінки написані мовами
розмітки даних. CSS є основною технологією всесвітньої павутини, поряд із
HTML та JavaScript.
Найчастіше CSS використовують для візуальної презентації сторінок,
написаних HTML та XHTML, але формат CSS може застосовуватися до
інших видів XML-документів. CSS має різні рівні та профілі. Наступний
рівень CSS створюється на основі попередніх, додаючи нову
функціональність або розширюючи вже наявні функції. Рівні позначаються
як CSS1, CSS2 та CSS3. Профілі — сукупність правил CSS одного або більше
рівнів, створені для окремих типів пристроїв або інтерфейсів. Наприклад,
існують профілі CSS для принтерів, мобільних пристроїв тощо.
JavaScript (JS) — динамічна, об'єктно-орієнтована прототипна мова
програмування. Реалізація стандарту ECMAScript. Найчастіше
39
використовується для створення сценаріїв вебсторінок, що надає можливість
на боці клієнта (пристрої кінцевого користувача) взаємодіяти з користувачем,
керувати браузером, асинхронно обмінюватися даними з сервером,
змінювати структуру та зовнішній вигляд вебсторінки.
JavaScript також частково підтримує інші парадигми програмування
(імперативну та частково функціональну) і деякі відповідні архітектурні
властивості, зокрема динамічна та слабка типізація, автоматичне керування
пам'яттю, прототипне наслідування, функції як об'єкти першого класу.
Зазвичай для розробки користувацького інтерфейсу використовують ці
3 мови програмування. Також для роботи з Javascript потрібно обрати
фреймворк, який допоможе швидко втілити ідею в реальність.
Фреймворк (англ. Framework, каркас, платформа, структура,
інфраструктура) — інфраструктура програмних рішень, що полегшує
розробку складних систем. Спрощено дану інфраструктуру можна вважати
своєрідною комплексною бібліотекою, але при цьому вона має ряд обмежень,
що задають правила створення структури проекту та написання коду.
Програмний фреймворк (англ. software framework) — це готовий до
використання комплекс програмних рішень, включаючи дизайн, логіку та
базову функціональність системи або підсистеми. Відповідно — програмний
фреймворк може містити в собі також допоміжні програми, деякі бібліотеки
коду, скрипти та загалом все, що полегшує створення та поєднання різних
компонентів великого програмного забезпечення чи швидке створення
готового і не обов'язково об'ємного програмного продукту. Побудова
кінцевого продукту відбувається, зазвичай, на базі єдиного API.
Також фреймворки використовують не тільки на стороні
користувацького інтерфейсу, але й на стороні сервера.
Основними мовами програмування при розробці серверних додатків є
PHP, Node.js, Java. Розглянемо кожну з цих мов програмування окремо.
40
PHP — скриптова мова програмування, була створена для генерації
HTML-сторінок на стороні вебсервера. PHP є однією з найпоширеніших мов,
що використовуються у сфері веброзробок. PHP підтримується переважною
більшістю хостинг-провайдерів. PHP — проект відкритого програмного
забезпечення.
PHP — мова, у код якої можна вбудовувати безпосередньо html-код
сторінок, які, у свою чергу, коректно оброблюватимуться PHP-
інтерпретатором. Обробник PHP просто починає виконувати код після
відкриваючого тегу і продовжує виконання до того моменту, поки не
зустріне закриваючий тег.
Велика різноманітність функцій PHP дає можливість уникати
написання багаторядкових функцій, призначених для користувача, як це
відбувається в C або Pascal.
Node.js — платформа з відкритим кодом для виконання
високопродуктивних мережевих застосунків. Якщо раніше JavaScript
застосовувався для обробки даних в браузері користувача, то node.js надав
можливість виконувати JavaScript-скрипти на сервері та відправляти
користувачеві результат їхнього виконання. Платформа Node.js перетворила
JavaScript на мову загального використання з великою спільнотою
розробників.
Платформа Node.js призначена для виконання високопродуктивних
мережевих застосунків, написаних мовою програмування JavaScript.
Платформа окрім роботи із серверними скриптами для веб-запитів, також
використовується для створення клієнтських та серверних програм.
Java — об'єктно-орієнтована мова програмування, випущена 1995 року
компанією «Sun Microsystems» як основний компонент платформи Java. З
2009 року мовою займається компанія «Oracle», яка того року придбала «Sun
Microsystems». В офіційній реалізації Java-програми компілюються у байт-
41
код, який при виконанні інтерпретується віртуальною машиною для
конкретної платформи.
«Oracle» надає компілятор Java та віртуальну машину Java, які
задовольняють специфікації Java Community Process, під ліцензією GNU
General Public License.
Мова значно запозичила синтаксис із C і C++. Зокрема, взято за основу
об'єктну модель С++, проте її модифіковано. Усунуто можливість появи
деяких конфліктних ситуацій, що могли виникнути через помилки
програміста та полегшено сам процес розроблення об'єктно-орієнтованих
програм. Ряд дій, які в С/C++ повинні здійснювати програмісти, доручено
віртуальній машині. Передусім Java розроблялась як платформо-незалежна
мова, тому вона має менше низькорівневих можливостей для роботи з
апаратним забезпеченням, що в порівнянні, наприклад, з C++ зменшує
швидкість роботи програм. За необхідності таких дій Java дозволяє
викликати підпрограми, написані іншими мовами програмування.
При виборі мови програмування потрібно також враховувати команду,
яка в майбутньому буде виконувати підтримку даного проекту.
Розглянемо системи, які дають можливість передавати дані в потоці.
Apache Kafka - це програмне забезпечення для обробки потокових
даних з відкритим вихідним кодом, розроблене LinkedIn (а потім подароване
Apache) для ефективного управління їх зростаючими даними та переходу до
обробки в реальному часі з пакетної обробки. Він написаний на Scala та Java і
заснований на моделі обміну повідомленнями "публікація-підписка".
Kinesis – це керована платформа, розроблена Amazon для збору та
обробки великих потоків даних у режимі реального часу. На відміну від
Apache Kafka, відомо, що Kinesis неймовірно швидкий, надійний та простий
в експлуатації.
Розглянемо основні відмінності між даними рішеннями.
42
Kafka – це рішення для розподіленого обміну повідомленнями з
відкритим вихідним кодом, тоді як Kinesis – це керована платформа, яку
пропонує Amazon. У Kafka користувач несе відповідальність за встановлення
та керування кластерами, а також за забезпечення високої доступності,
довговічності та відновлення після збоїв. Якщо використовується Kinesis, то
не потрібно турбуватися про розміщення програмного забезпечення та
ресурсів. Користувач може легко вивчити Kafka, встановивши його в
локальній системі.
Ціна на протоки даних в Kinesis залежить від кількості частин, які
використовуються. Також доведеться заплатити додатково, якщо планується
зберегти повідомлення протягом тривалого часу. У випадку з Kafka ціна в
основному залежить від кількості брокерів, які використовуються. Для Kafka
додатково потрібна команда програмістів для обслуговування, але це іноді
дорого коштує. З Kafka можна зберігати повідомлення протягом тривалого
часу без додаткової оплати, якщо немає вільного місця;
У сфері безпеки Kafka пропонує багато функцій на стороні клієнта,
таких як шифрування даних, автентифікація клієнта та авторизація клієнта,
тоді як Kinesis забезпечує шифрування на стороні сервера за допомогою
головних ключів AWS KMS для шифрування даних, що зберігаються в
потоці даних.
І Kafka, і Kinesis надають хорошу платформу для обробки даних у
режимі реального часу. Якщо організації не вистачає експертів Apache Kafka
людських ресурсів, її слід розглянути Kinesis. Але якщо потрібно зберігати
повідомлення у своїх кластерах і протягом тривалого часу, це піде з Kafka.
У випадку дослідження більше підходить продукт Kinesis, тому що
дане рішення повністю підтримується компанією Amazon, і не потребує
додаткової підтримки спеціалістами.
Продукт Amazon Kinesis підтримує усі популярні мови програмування,
включаючи PHP, Node.js та Java.
43
Тож при виборі мови програмування використовувалися наступні критерії:
- простота розробки рішень;
- вартість розміщення даного рішення на сервері;
- простота інтеграції з Amazon Kinesis SDK.
SDK — набір із засобів розробки, утиліт і документації, який дає
програмістам змогу створювати прикладні програми за визначеною
технологією або для певної платформи. Програміст, як правило, отримує
SDK безпосередньо від розробника цільової технології або системи. Часто
SDK розповсюджується через Інтернет. Багато SDK розповсюджуються
безплатно для того, щоб заохотити розробників використовувати дану
технологію або платформу.
Для розробки системи обміну великими даними було обрано мову
програмування PHP, бо ціна впровадження даного рішення на базі продукту
Amazon Kinesis буде значно нижчою, ніж при виборі Java та Node.js. Мова
програмування PHP дає можливість розгортання даного рішення на
віртуальних хостингах.
Віртуальний хостинг — вид хостингу, при якому багато вебсайтів
розташовано на одному вебсервері. Це найекономічніший вид хостингу, який
підходить для невеликих проектів. Зазвичай кожен вебсайт розташований на
своєму власному розділі вебсервера, але вони всі разом користуються одним
і тим же програмним забезпеченням.
44
2.3 Висновки до розділу 2
В другому розділі було розглянуто технології та засоби, які будуть
використані для розробки.
Проаналізовано різні протоколи передачі даних такі як Kinesis, Apache
Kafka, MQTT та HTTPS.
Мови для користувацького інтерфейсу було обрано HTML, CSS та
Javascript та для нього фреймворк. Платформа для збору та обробки великих
потоків даних у режимі реального часу обрано Kinesis, що розроблена
Amazon.
Для розробки системи обміну великими даними було обрано мову
програмування PHP. Тому що дає можливість розгортання даного рішення на
віртуальних хостингах.
45
РОЗДІЛ 3 ОПТИМІЗАЦІЯ МЕТОДІВ І АЛГОРИТМІВ ПЕРЕДАЧІ
ВЕЛИКИХ ОБ’ЄМІВ ДАНИХ В РЕЖИМІ РЕАЛЬНОГО ЧАСУ НА БАЗІ
РІШЕНЬ AWS
3.1 Структура системи
Для досягнення мети та цілей даної роботи було розроблено систему,
яка дає можливість компаніям отримувати зворотний звʼязок від своїх
клієнтів.
Зворотний зв'язок — у найширшому розумінні реакція на відповідь
людини або групи людей на отриману інформацію або чинну дію. Зворотний
зв'язок як інструмент для зміни поведінки (її поліпшення) інших людей, що
широко використовується в соціальній взаємодії (наприклад, при оцінці
персоналу) і в навчанні.2
Вважається, що негативний зворотний зв'язок рідко призводить до
зміни поведінки людини. Існує кілька способів надання зворотного зв'язку,
при якому найбільш ймовірно, що вона досягне мети щодо зміни поведінки
людини. Вирізняють конструктивний зворотний зв'язок, коли дотримується
принцип поваги співрозмовника. Для цього важливо виділяти недоліки у
вигляді констатації фактів та пропонувати рішення, яке усуває ці недоліки.
На даний час існує велика кількість компаній, переважно невеликих,
які продають свої послуги через соціальні мережі або використовують
невеликі сайти для залучення нових клієнтів. Такі компанії зазвичай не
надають можливість користувачу відправити відгук про роботу і власники
даних бізнесів можуть навіть не знати про недоліки своїх компаній.
Для розв'язання даної проблеми було розроблено систему, яка надасть
можливість компанії використовувати спеціальне посилання або віджет для
клієнта, який буде мати можливість отримати відгук про роботу, а також
дасть можливість компанії відповісти та опрацювати даний відгук.
46
Вебвіджет — контент-модуль, що вбудовується у вебсторінку або у
браузер. Цей тип заснований на вебтехнологіях, що працюють через браузер.
Такі модулі існували досить давно, а віджетами їх стали називати відносно
недавно.
Дана система є максимально простою для користувача (як для клієнта
компанії, так і для співробітника), при цьому система розрахована на
отримання великої кількості даних з різних джерел (сторінок компаній).
Для реалізації даної системи було використано мікросервісний підхід
при плануванні технічного дизайну, а також було використано методику
передачі даних між сервісами за допомогою потоків даних (streams).
Мікросервіс — це найпростіша одиниця, сервіс, який приймає вхідні
запити для здійснення дії. Це може бути бекенд сервіс, який доступний
цілодобово та без вихідних, або функція, яка викликається, коли відбувається
подія. Це функція або набір функцій, доступних через певний API через
мережу. Отже, це бекенд служба, розгорнута на сервері. Це монолітний
додаток. Отриманий додаток побудований як набір відносно невеликих
незалежних служб, що називаються «мікросервісами», які комунікують через
комп’ютерну мережу. Можна сказати, мікросервіси – це ті самі логічні
модулі монолітного додатка, які розподілені через комп’ютерну мережу,
замість того, щоб працювати в рамках одного процесу (пристрою).
Розроблена система складається з 3 підсистем, що зображено на
рисунку 3.1:
- клієнтська частина, якою буде користуватись користувач системи;
- серверна частина, яка буде виконувати всі дії користувачів;
- частина адміністратора, в якій компанія зможе переглянути відгуки та
клієнтів.
47
Рисунок 3.1 - Основні частини розробленої системи
Розглянемо кожну частину системи окремо. Буде використовуватися
клієнт-серверна архітектура. Архітектура клієнт-сервер є одним з
архітектурних шаблонів програмного забезпечення та є домінантною
концепцією у створенні розподілених мережних застосунків і передбачає
взаємодію та обмін даними між ними. Вона передбачає такі основні
компоненти:
- набір серверів, які надають інформацію або інші послуги програмам,
які звертаються до них;
- набір клієнтів, які використовують сервіси, що надаються серверами;
- мережа, яка забезпечує взаємодію між клієнтами та серверами.
48
Сервери є незалежними один від одного. Клієнти також функціонують
паралельно і незалежно один від одного. Немає жорсткої прив'язки клієнтів
до серверів. Більш ніж типовою є ситуація, коли один сервер одночасно
обробляє запити від різних клієнтів; з іншого боку, клієнт може звертатися то
до одного сервера, то до іншого. Клієнти мають знати про доступні сервери,
але можуть не мати жодного уявлення про існування інших клієнтів.
Клієнтом може бути клієнтський комп'ютер, з якого відбувається
звернення до інших комп'ютерів. Може бути клієнтське та серверне
програмне забезпечення. Або це людей, які бажають за допомогою
відповідного програмного та апаратного забезпечення отримати доступ до
тієї чи іншої інформації. Загальноприйнятим є положення, що клієнти та
сервери — це перш за все програмні модулі. Найчастіше вони знаходяться на
різних комп'ютерах, але бувають ситуації, коли обидві програми — і
клієнтська, і серверна, фізично розміщуються на одній машині; в такій
ситуації сервер часто називається локальним.
Модель клієнт-серверної взаємодії визначається перш за все
розподілом обов'язків між клієнтом та сервером. Можна відокремити три
рівні операцій:
- рівень представлення даних, який по суті являє собою інтерфейс
користувача та відповідає за представлення даних користувачеві і
введення від нього керуючих команд;
- прикладний рівень, який реалізує основну логіку застосунку і на якому
здійснюється необхідна обробка інформації;
- рівень управління даними, який забезпечує зберігання даних та доступ
до них.
Ціль розробленої серверної системи забезпечити збереження
коментарів від користувачів до бази та виконати дії в фоновому режимі, які
допоможуть власникам компаній вчасно дізнатися про новий відгук та
49
опрацювати його. Також розроблена система автоматично створює базу
клієнтів для компаній, на базі відгуків, які були їми надані.
Клієнтська база — це перелік інформації, який містить контакти
клієнтів, їх імена та прізвища, номери телефонів, email-адреси тощо. Вона
також може включати:
- демографічні характеристики (вік, стать, цивільний стан, склад сім‘ї);
- характеристики пов‘язані з професією (посада, робочі електронні
адреси);
- дані про купівельну поведінку (вподобання, інформація про попередні
покупки, середня сума чека, останні скасування).
Основною точкою входу в роботу системи є API, яке надає можливість
клієнтській частині передати дані, отримані від клієнтів чи персоналу
системи.
Інтерфейс прикладного програмування — це спосіб взаємодії двох чи
більше частин програми одна з одною. Це різновид програмного інтерфейсу,
який пропонує послуги іншим частинам програмного забезпечення.
Документ або стандарт, який описує, як створити або використовувати таке
з’єднання чи інтерфейс, називається специфікацією API. Кажуть, що
комп’ютерна система, яка відповідає цьому стандарту, реалізує або надає
API. Термін API може стосуватися або специфікації, або реалізації.
На відміну від інтерфейсу користувача, який з’єднує комп’ютер з
людиною, інтерфейс прикладного програмування з’єднує частини системи
або частини програмного забезпечення один з одним. Він не призначений для
безпосереднього використання особою (кінцевим користувачем), крім
програміста, який включає його в програмне забезпечення. API часто
складається з різних частин, які діють як інструменти або служби, доступні
програмісту. Кажуть, що програма або програміст, який використовує одну з
цих частин, викликає цю частину API. Виклики, які складають API, також
50
відомі як підпрограми, методи, запити або кінцеві точки. Специфікація API
визначає виклики, тобто пояснює, як їх використовувати або реалізувати.
Для того, щоб розроблена система відповідала сучасним стандартам
було використано REST API для більш зручної роботи з системою.
REST API — це інтерфейс прикладного програмування (API або веб-
API), який відповідає обмеженням архітектурного стилю REST і дозволяє
взаємодіяти з веб-службами RESTful. REST розшифровується як
репрезентативна передача стану і був створений комп’ютерним науковцем
Роєм Філдінгом.
REST — це набір архітектурних обмежень, а не протокол чи стандарт.
Розробники API можуть реалізувати REST різними способами.
Коли клієнтський запит робиться через RESTful API, він передає
представлення стану ресурсу запитувачу або кінцевій точці. Ця інформація
або представлення надається в одному з кількох форматів через HTTP - це
JSON, HTML, XLT, Python, PHP або звичайний текст. JSON є
найпопулярнішим форматом файлів для використання, оскільки, попри на
свою назву, він не залежить від мови, а також читається як людьми, так і
машинами.
Щоб API вважався RESTful, він має відповідати цим критеріям:
 архітектура клієнт-сервер, що складається з клієнтів, серверів і ресурсів
із запитами, керованими через HTTP;
 зв’язок клієнт-сервер без збереження стану, тобто інформація про
клієнта не зберігається між запитами на отримання, і кожен запит є
окремим і не пов’язаним;
 кешовані дані, які спрощують взаємодію клієнт-сервер;
 уніфікований інтерфейс між компонентами, щоб інформація
передавалась у стандартній формі.
Отримавши запит від клієнтської частини вхідні дані перевіряються на
валідність та будуть збережені в базу даних. Валідність - це ознака
51
надійності, чинності вихідної інформації, яка використовується в відгуках.
Реальність інформації, відсутність у ній помилок, можливих через неточність
обраної методики збирання та обробки даних.
Дані, після проходження валідації зберігаються в базу даних. Це
синхронний процес, тому як тільки сервіс отримав інформацію,
використовуючи механізм транзакцій, дані зберігаються в базу даних
MySQL.
Транзакція — група послідовних операцій з базою даних, яка є
логічною одиницею роботи з даними. Транзакція може бути виконана або
цілком і успішно, дотримуючись цілісності даних і незалежно від інших
транзакцій, що йдуть паралельно, або не виконана зовсім, і тоді вона не може
справити ніякого ефекту. Транзакції обробляються транзакційними
системами, в процесі роботи яких створюється історія транзакцій. Транзакції
з базою даних використовуються для забезпечення надійних робочих
елементів, які дозволяють правильно відновити роботу у випадку збоїв та
зберігати цілісність бази даних у випадку системних відмов, коли виконання
операцій зупиняється (повністю або частково) і більшість операцій над базою
даних залишаються незавершеними з нез'ясованим статусом.
Після збереження даних про відгук сервіс, який прийняв ці дані
передає їх до системи Amazon Kinesis, яка своєю чергою надасть доступ до
цих даних іншим частинам сервісної частини системи. Дані будуть передані
до Kinesis, який дозволить отримати ці дані іншими сервісами в режимі
реального часу.
Система реального часу — система, яка має реагувати на події у
зовнішній, стосовно системи, середовищі чи впливати на середовище у
межах необхідних тимчасових обмежень. Обробка інформації системою
повинна проводитись за певний кінцевий період часу, щоб підтримувати
постійну та своєчасну взаємодію із середовищем. Масштаб часу
контролюючої системи та контрольованого нею середовища має збігатися.
52
Розглянемо принцип отримання даних від Kinesis іншими сервісами.
Рисунок 3.2 - Схема отримання даних з потоку даних Kinesis.
Як видно на малюнку 3.2 всі додаткові сервіси системи, які виконують
допоміжні функції не завʼязані на роботі з базою даних, а отримують
інформацію у режимі реального часу через потік даних Kinesis. Такий
принцип роботи забезпечує рівномірне навантаження на системи, при цьому
кожен сервіс самостійно вирішує, коли та в якій кількості отримати дані від
Kinesis. Також, як видно на рисунку 3.2 даний підхід дозволяє досить просто
масштабуватися системі, і зменшує звʼязність нових сервісів, які будуть
розроблені в майбутньому.
Зв'язність (англ. coupling) чи залежність (англ. dependency) це міра в
якій модуль (компонент) програми залежить від кожного іншого модуля
(використовує якусь інформацію про нього). Зв'язність зазвичай
протиставляється пов'язаності. Метрики програмного забезпечення зв'язність
та пов'язаність, винайдені Ларрі Костянтином, першим розробником
Structured Design, який також був першим їхнім прихильником (див. також
SSADM). Слабка зв'язність часто є ознакою добре структурованої
комп'ютерної системи, та гарної архітектури, і в поєднанні з високою
пов'язаністю дозволяє досягти гарної стійкості та підтримуваного коду.
53
Сервіс формування бази клієнтів забезпечує автоматичне опрацювання
отриманого відгуку і на базі чого формується інформація про клієнта. Ці дії
відбуваються в фоновому режимі.
Сервіс посилання повідомлень формує спеціальні інформаційні
повідомлення для користувачів системи про надходження нового відгуку до
системи. Даний сервіс має можливість відправити email чи sms повідомлення
за допомогою спеціальних провайдерів.
Провайдер — це компанія, яка надає додаткові послуги, які можуть
бути використаними при розробці програмного забезпечення. У випадку
розробленої системи було використано Twilio для SMS повідомлень та
Mailgun для Email повідомлень.
Twilio - це платформа для програмістів, що дозволяє легко інтегрувати
різні методи комунікації та використовувати наявні навички веб-розробки,
код, сервери, бази даних та карму для швидкого та надійного розв'язання
проблем зі зв'язком. Система створена для здійснення дешевих телефонних
дзвінків, покупки номерів для різних країн, створення дзвінків між кількома
телефонами з одного облікового запису та запуску конференцій. Звідси
можна навіть створювати свої скрипти для кінцевого налаштування.
Mailgun — це ефективний SaaS-сервіс для автоматизації електронної
пошти, що володіє інтерфейсом користувача, розробленим спеціально для
розробників і компаній, які хочуть налаштувати власне поштове рішення. У
комплект постачання входять потужні API, засоби моніторингу електронної
пошти та журнали з можливістю пошуку. Mailgun забезпечує 99,9%
безвідмовної роботи відповідно до SLA, що гарантує надійність та
цілодобову підтримку користувачів.
Користувацька частина системи складається з:
- контент-модуль, який додається на сайт компанії;
- клієнтської сторінки, на якій користувач може надати зворотний
звʼязок;
54
- панель адміністратора.
Розроблений віджет являється простим iFrame, який додається на
сторінку компанії у вигляді HTML коду та дає можливість загрузити контент
клієнтської частини прямо на сторінку сайту.
iFrame — це скорочення від Inline Frame, яке позначає потужний
елемент веб-дизайну, також відомий як плавучий вбудований кадр. iFrame
дозволяє розмістити на сайті усі види мультимедіа.
Клієнтська сторінка являє собою HTML сторінку з формою, через яку
клієнт може надати відгук про роботу компанії. Дана сторінка побудована з
використанням фреймворку React для спрощення майбутньої підтримки
продукту.
React — відкрита JavaScript бібліотека для створення інтерфейсів
користувача, яка покликана розв'язувати проблеми часткового оновлення
вмісту вебсторінки, з якими стикаються в розробці односторінкових
застосунків. Розробляється Meta і спільнотою індивідуальних розробників.
React дозволяє розробникам створювати великі веб-застосунки, які
використовують дані, котрі змінюються з часом, без перезавантаження
сторінки. Його мета полягає в тому, щоб бути швидким, простим,
масштабованим. React обробляє тільки користувацький інтерфейс у
застосунках. Це відповідає видові у шаблоні модель-вид-контролер (MVC), і
може бути використане у поєднанні з іншими JavaScript бібліотеками або в
великих фреймворках MVC, таких як AngularJS. Він також може бути
використаний з React на основі надбудов, щоб піклуватися про частини без
користувацького інтерфейсу побудови веб-застосунків. Як бібліотеку
інтерфейсу користувача React найчастіше використовують разом з іншими
бібліотеками, такими як Redux.
Панель адміністратора являє собою ресурс, який також побудований на
базі фреймворку React та дає можливість користувачам системи
55
(адміністраторам) передивлятися та опрацьовувати відгуки, надані клієнтами,
а також передивлятися створену базу клієнтів.
3.2 Опис функцій системи
Для того, щоб отримати інформацію від клієнта у компанії є
можливість додати спеціальний віджет на сайт, який виведе розроблену
форму для збору інформації. У випадку, якщо компанія не має вебсайту
(наприклад, якщо продажі відбуваються через соціальні мережі), створена
система має можливість згенерувати спеціальне посилання, через яке клієнт
буде мати можливість зайти на сторінку системи та надати відгук про роботу
компанії.
Соціальна мережа, також суспільна, мережа — соціальна структура,
утворена індивідами або організаціями. Вона відбиває розмаїті зв'язки між
ними через різноманітні соціальні взаємовідносини, починаючи з випадкових
знайомств і закінчуючи тісними родинними зв'язками.
Соціальними мережами називають також інтернет-програми, які
допомагають друзям, бізнес-партнерам або іншим особам спілкуватись та
встановлювати зв'язки між собою, використовуючи набір інструментів. Ці
програми, відомі як «Онлайнові соціальні мережі», стають дедалі
популярнішими.
Розглянемо клієнтську сторінку, за допомогою якої клієнт має
можливість надати зворотний відгук по компанії.
56
Рисунок 3.3 - Форма введення зворотного звʼязку.
Розглянута на рисунку 3.3 форма також може бути виведена за
допомогою віджету для більшої зручності компанії.
Після того, як користувач заповнив дану форму, компанія отримує цей
зворотний звʼязок в панель адміністратора.
Панель адміністратора — це інтерфейс для керування отриманими від
клієнтів даними. Панель адміністратора зазвичай користуються кінцеві
користувачі продукту (представники компанії), для якої було приєднано
системи збору зворотного звʼязку.
57
Для доступу до даної системи користувач повинен бути
зареєстрованим в системі та повинен пройти авторизацію.
Авторизація — це керування рівнями та засобами доступу до певного
захищеного ресурсу, як у фізичному розумінні (доступ до кімнати готелю за
карткою), так і в галузі цифрових технологій (наприклад, автоматизована
система контролю доступу) та ресурсів системи залежно від ідентифікатора і
пароля користувача або надання певних повноважень (особі, програмі) на
виконання деяких дій у системі обробки даних. З позицій інформаційної
безпеки авторизація є частиною процедури надання доступу для роботи в
інформаційній системі, після ідентифікації та автентифікації.
Рисунок 3.4 - Авторизація в панелі адміністратора.
Для того, щоб компанія могла переглянути відгуки, які були надані
клієнтами, було розроблено спеціальний дашборд, на якому компанія має
можливість отримати список повідомлень з можливістю опрацювання
кожного повідомлення.
58
Термін «dashboard» з англійської на українську перекладається як
інформаційна панель. Дашборд — це програмне рішення, що дозволяє
створювати, одержувати, аналізувати дані в реальному часі. Видані
інформаційною панеллю «розумні звіти» допомагають власнику, керівнику,
менеджеру розуміти певні тенденції в конкретному сегменті діяльності та
контролювати події, що відбуваються.
Рисунок 3.5 - Перегляд списку відгуків.
У адміністратора є можливість зробити експорт всіх відгуків у Excel
формат, що дозволить компанії опрацювати ці дані локально з
використанням відповідного ПО.
Microsoft Excel — табличний процесор, програма для роботи з
електронними таблицями, створена корпорацією Microsoft для Microsoft
Windows, Windows NT і macOS. Програма входить до складу офісного пакета
Microsoft Office.
Також користувач (адміністратор) може переглянути список клієнтів,
які надіслали відгуки. Це також потрібно для того, щоб у майбутньому була
можливість відправляти маркетингове розсилання.
59
Маркетингові розсилки – це чудовий спосіб збільшення продажів.
Водночас його ефективність залежить від багатьох чинників, зокрема і від
інструментів. До їхньої низки належать email-розсилка, СМС-розсилка, а
також розсилка через месенджери. Зі свого боку кожен із них має свої
особливості.
Після отримання нового відгуку система автоматично відправляє
адміністраторам email лист, за допомогою якого користувач системи має
можливість отримати інформацію про новий зворотний звʼязок.
Рисунок 3.6 - Email сповіщення.
Також, крім email сповіщення, яке зображене на рисунку 3.6, система
відправляє аналогічне повідомлення за допомогою SMS каналу комунікації.
3.3 Забезпечення захисту інформації при роботі з створеною
системою
Ризики, пов'язані з порушенням конфіденційності, цілісності та
доступності даних, трохи занижені. Цьому є кілька причин, а перша з них —
60
психологічна, людям простіше оцінити прямий прибуток, ніж теоретичні
збитки. Друга пов'язана з тим, що побудова і підтримка ефективної системи
інформаційної безпеки — вельми складний процес, а придбання та
налаштування технічних засобів захисту є лише малою його частиною. Як
результат, маємо статистику, наведену аналітичним центром компанії
«InfoWatch», яка повідомляє про 1395 випадках витоку інформації у 2014-му
році. Середній збиток від кожної витоку оцінений у 25,51 мільйона доларів.
Менш масштабні випадки, що відбуваються щодня сотні разів, ніяк не
фіксуються, але можна порівняти вищевказані цифри з фактичною
ситуацією.
Крім технічних засобів захисту, існують і інші компоненти системи
забезпечення інформаційної безпеки. Згідно зі статистикою, більше 90-а%
інцидентів трапляються з вини людей це недостатній рівень ерудованості та
уважності співробітників призводить до витоку або повної втрати даних.
Тому не варто забувати про регулярне проведення тренінгів з інформаційної
безпеки, а також написанні зрозумілих і продуманих службових інструкцій.
Що стосується технічних засобів забезпечення захисту, їх кількість
величезна, але ось сам принцип використання дещо змінився. Поступова
міграція інформаційних систем в хмарні середовища розмиває ключові
поняття, такі як «периметр мережі». Раніше більшість мереж будувалися за
однією схемою (маршрутизатор, оснащений функціями безпеки, стояв на
кордоні мережі компанії та відділяє її від зовнішнього світу). Зараз багато
підприємств переносять свої сервери в хмару, що робить поняття «периметра
мережі» досить умовним. У такій конфігурації захист від спаму, вірусних
атак і підбирачів паролів беруть на себе постачальники сервісних послуг,
пропонуючи споживачеві сконцентруватися на захисті робочих станцій і
роботі з персоналом.
Грамотне застосування сучасних security-рішень допоможе знизити
потенційні ризики. Щоб визначитися з необхідними засобами забезпечення
61
інформаційної безпеки, необхідно повністю усвідомлювати, що саме
користувач захищає, а ось набір стандартних рішень можна представити та
без цього:
- по-перше, необхідний антивірусний захист;
- другим фактором протидії ворожому коду є своєчасне оновлення
програмного забезпечення, а також використання ліцензійних версій
операційних систем. Застосування піратського ПЗ може призвести до
повної зупинки роботи, що в грошовому еквіваленті багаторазово
перевищує заощаджену суму;
- важливо також контролювати, чим займаються співробітники на
робочому місці. Складати списки відвідуваних сайтів, відстежувати
установку сторонніх додатків, контролювати копіювання даних на
носії, а також їх відправлення за допомогою месенджерів, - все це не
повинно залишатися поза увагою;
- на випадок втрати пристроїв, дані на них повинні бути зашифровані
або хоча б заблоковані паролем. Google, наприклад, дозволяє власнику
домену змушувати власників смартфонів використовувати адекватні
методи захисту такі як PIN-коди, паролі та інші.
Через те, що розроблене рішення базується на хмарному продукті
Amazon Kinesis, тому питання безпеки — це спільна відповідальність
розробника системи та Amazon, як провайдера послуги.
Безпека хмари – AWS відповідає за захист інфраструктури, яка
запускає служби AWS у хмарі AWS. AWS також надає послуги, якими
можна безпечно користуватися. Ефективність безпеки регулярно тестується
та перевіряється сторонніми аудиторами в рамках програм відповідності
AWS.
Для того щоб контролювати доступ до потоку даних Kinesis в
розробленому рішенні використовувалося послуга AWS IAM.
62
AWS Identity and Access Management (IAM) дозволяє виконувати такі
дії:
- створювати нових користувачів та групи;
- призначати унікальні облікові дані безпеки кожному користувачеві під
обліковим записом AWS;
- контролювати дозволи кожного користувача на виконання завдань за
допомогою ресурсів AWS;
- дозволяти користувачам іншого облікового запису AWS ділитися
ресурсами AWS;
- створювати ролі для свого облікового запису AWS і визначте
користувачів або служби, які можуть їх приймати.
Використовуючи IAM із потоками даних Kinesis, має можливість
контролювати, чи можуть користувачі у створеній організації виконувати
завдання за допомогою певних дій Kinesis Data Streams API і чи можуть вони
використовувати певні ресурси AWS.
Також слід підтримувати актуальність версій програмного
забезпечення та мови програмування PHP при роботі з серверним
програмним забезпеченням. Більшість проблем, які трапляються з
серверними додатками — через застаріле ПО, яке встановлене на цих
серверах.
3.4 Технічні вимоги для роботи з системою
Технічні вимоги в контексті розробки програмного забезпечення та
системної інженерії — це чинники, необхідні для забезпечення бажаної
функції чи поведінки системи для задоволення стандартів і потреб
користувача. Технічні вимоги можуть стосуватися таких систем, як
63
програмне забезпечення, електронні апаратні пристрої або електронні
пристрої, керовані програмним забезпеченням.
Технічні вимоги є частиною аналізу вимог (також відомого як розробка
вимог), міждисциплінарної галузі в інженерії, яка включає проектування та
обслуговування складних систем.
Іншою стороною аналізу вимог є функціональні вимоги, які
визначають бажаний результат або поведінку системи. Хоча система може
досягти бажаного результату або поведінки без відповідності технічним
вимогам, вона, швидше за все, буде непридатною для використання.
Наприклад, програма може не відповідати розумним цілям ефективності. З
іншого боку, якщо система не відповідає функціональним вимогам, вона
може мати всю продуктивність у світі, але не може забезпечити очікуваний
результат. Прикладом такої ситуації може бути калькулятор, який виконує
неправильні обчислення, хоча й дуже швидко. Розглянемо технічні вимоги до
системи, таблиця 3.1.
Таблиця 3.1- Технічні та програмні вимоги до системи
Елемент системи Мінімальні вимоги Рекомендовані вимоги
PHP 5.x 8.x
MySQL 5.7 8.0
Amazon Kinesis Cloud version Cloud version
ОЗУ 128 МБ 512 МБ
Архітектура процесора x86-64 x86-64
Система може працювати на будь-якому віртуальному хостингу, що
робить її значно дешевшою в обслуговуванні та підтримці. Також можна
зазначити що розроблене рішення буде працювати й на старих версіях мови
програмування PHP та бази даних MySQL.
64
3.5 Оцінка ефективності застосування системи
Для оцінки ефективності системи потрібно визначити параметри, які
будуть розглянуті.
Ефективність — відношення корисного ефекту (результату) до витрат
на його одержання.
Результатом є система, яка побудована на базі рішення AWS та дає
можливість передавати велику кількість даних між сервісами системи в
режимі реального часу.
Amazon Web Services (AWS) – це найпоширеніша у світі хмарна
платформа з найширшими можливостями, що надає понад 200
повнофункціональних сервісів для центрів обробки даних по всій планеті.
Мільйони клієнтів, у тому числі стартапи, які стали лідерами за швидкістю
зростання, найбільші корпорації та передові урядові установи,
використовують AWS для зниження витрат, підвищення гнучкості та
прискореного впровадження інновацій.
Для оцінки ефективності застосування системи, у випадку
розробленого продукту потрібно порівняти технології, які були використані
під час розробки з аналогічними та оцінити, наскільки виправдано
використання обраних технології.
Технологія — це сукупність знань і прийомів, які впорядковано
застосовуються для досягнення певної мети або розв'язання проблеми.
У випадку розробленої системи було обрано метод передачі даних
через систему Amazon Kinesis. Тож буде логічно порівняти аналогічні
системи, наприклад Kafka і методологію Long Polling і визначити, наскільки
обґрунтованим був вибір технології.
При порівнянні (таблиця 3.2.) буде враховуватися швидкодія системи
при використанні інших технологій, а також ціну використання даного
рішення.
65
Швидкодія — це здатність виконувати певну кількість формалізованих
завдань (вирішувати певну кількість формалізованих завдань) за одиницю
часу.
Таблиця 3.2 - Порівняння використання технологій
Параметр Amazon Kinesis Apache Kafka HTTP Long Polling
Можливість Так Так Так
використання в
розробленій
системі
Час отримання 0.028 секунди 0.30 секунди 1 секунда
даних сервісами (залежно від
параметрів)
Тип рішення Хмарне рішення Окремий сервер Локальне рішення
Робота з Так Так Можливо, але
великою збільшується час
кількістю даних отримання даних
Вартість 5-10$ 5-10$ Безплатно
використання
(для
розробленої
системи)
Можливість Автоматичне, за Можливо, при Ні
масштабування допомогою AWS використанні
додаткового
сервера
Розглянувши можливі технології, які потенційно можна
використовувати для роботи в розробленій системі можна зробити висновок,
що обраний метод передачі великих даних при роботі з мікросервісною
архітектурою відповідає всім поставленим вимогам і є максимально
оптимальним при розробці подібних систем.
66
3.6 Висновки до розділу 3
В даному розділі було описано структуру та її складові. Вона
складатиметься з клієнтської частини, серверної та адміністратора.
Описано функції, які доступні на стороні клієнта.
Були надані рекомендації, які забезпечують захист інформації при
роботі зі системою. А також розроблені технічні та програмні вимоги.
Для даної системи було проведено оцінку ефективності, яка показує
позитивний результат та задовольняє поставлену мету.
67
ВИСНОВКИ
У даній кваліфікаційній роботі магістра було проведено аналіз
дослідження методів і алгоритмів передачі великих обʼємів даних, що
допоможуть більш чітко та глибоко зрозуміти тему та проблеми цього
напрямку.
Було проаналізовано способи передачі даних та їх принципи роботи. На
підставі цього було обрано напрям дослідження.
Щоб обрати найкращий протокол передачі даних, було досліджено Kinesis,
Apache Kafka, MQTT та HTTPS. Вибір було зупинено на Kinesis, платформа
розроблена Amazon для збору та обробки великих потоків даних у режимі
реального часу.
Мови для розробки користувацького інтерфейсу було обрано HTML,
CSS та Javascript та для нього фреймворк.
Для розробки системи обміну великими даними було обрано мову PHP.
На підставі набутих навичок було вирішено, що система
складатиметься з 3 підсистем, які доповнюють роботу одна одній:
1) клієнтська частина, якою буде користуватись користувач системи;
2) серверна частина, яка буде виконувати всі дії користувачів;
3) частина адміністратора, в якій компанія зможе переглянути відгуки та
клієнтів.
Кожну частину підсистеми було розглянуто та описано окремо. Для
більшого розуміння було описано з чого складається користувацька частина:
1) віджету, який додається на сайт компанії;
2) клієнтської сторінки, на якій користувач може надати зворотний
зв'язок;
3) панель адміністратора.
68
Описано функції, які буде виконувати система та наведено елементи
роботи у вигляді зображення.
Для забезпечення захисту інформації при роботі зі системою було
розроблено рекомендації, які поліпшують роботу та її захист, а також
визначено технічні та програмні вимоги до системи.
Результатом даної системи, яка побудована на базі рішення AWS та дає
можливість передавати велику кількість даних між сервісами системи в
режимі реального час, тому було проведено оцінку ефективності з іншими
такими як Apache Kafka та HTTP Long Polling.
З отриманих вище результатів можна зробити висновок, що система
повністю задовольняє умову даного дослідження та поставлене завдання
було виконане.
69
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
HTTP (HyperText Transfer Protocol) – протокол передачі даних, що
використовується в комп'ютерних мережах
HTTPS (Hypertext Transfer Protocol Secure) – це розширення протоколу
HTTP, необхідне для підтримки шифрування з метою підвищення рівня
безпеки даних
MQTT (Message Queuing Telemetry Transport) – це протокол обміну
повідомленнями для обмежених мереж із низькою пропускною здатністю та
пристроїв IoT із надзвичайно високою затримкою
UDP (User Datagram Protocol) – один із протоколів в стеку TCP/IP
API (Application Programming Interface) – інтерфейс програмування
додатків, програмний інтерфейс програми
AWS (Amazon Web Services) – є дочірньою компанією Amazon.com, що
надає платформу хмарних обчислень в оренду приватним особам, компаніям
та урядом на основі платної підписки
SQL (Structured Query Language) – декларативна мова програмування
для взаємодії користувача з базами даних, що застосовується для формування
запитів, оновлення і керування реляційними БД, створення схеми бази даних
та її модифікації, системи контролю за доступом до бази даних
70
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Sourav Kunal, Arijit Saha, Ruhul Amin, “An overview of cloud-fog
computing: Architectures, applications with security challenges”. 2019.
[Електроннии ̆ ресурс] – Режим доступу до ресурсу: URL:
https://www.researchgate.net/publication/333162093.
2. Cao, N., Wang, C., Li, M., Ren, K., Lou, W., “Privacy-preserving multi-
keyword ranked search over encrypted cloud data.”. 2014.[Електроннии ̆
ресурс]- Режим доступу до ресурсу: URL:
https://pdfs.semanticscholar.org/cbe3/e7cf2c1f64ce667cacad6666e8f62fa2ff
3f.pdf.
3. Viraj G. Mandlekar, Viresh Kumar Mahale, “Survey on Fog Computing Mitigating Data
Theft Attacks in Cloud”. 2014. [Електронний ресурс] - Режим доступу
URL:https://www.ijircst.org/DOC/3_IRP2144caa8e0e-a940-4c1d-81c1-5286717307d3.p
4. Amazon EMR Documentation [Електроннии ̆ ресурс] – Режим доступу до
ресурсу: https://docs.aws.amazon.com/em
5. Capacity augmentation bound of federated scheduling for parallel dag tasks.
[J. Li and oth.]. – Madrid: Computer Sciences Commons, 2014. – 314 p.
6. Leung, J.Y.T. A new algorithm for scheduling periodic real-time tasks. /
J.Y.T. Leung. – Irvine: Springer, 1989. – 267 p.
7. Narkhede N. Kafka: The Definitive Guide. / Narkhede N., Shapira G., Palino
T. – Sebastopol: O’Reilly, 2019. – 167 p.
8. Min Chen, Shiwen Mao, Yin Zhang, Victor C.M. Leung. Big Data. Related
Technologies, Challenges, and Future Prospects. — Spinger, 2014. — 100 p.
9. Bejeck W. P. Jr. Kafka Streams in Action Real-time apps and microservices
with the Kafka Streams API. / W. P. Jr. Bejeck. – New York: Manning,
2018. – 245 p.
71
10.Lou. W. A multipath routing approach for secure data delivery.
Communications for Network-Centric Operations: Creating the Information
Force./ W. Lou., Y. Fang. – Gainesville: Milcom, 2001. – 1467 p.
11.Abdallah T. A., Iglesia B. URL-based web page classification-a new method
for URL-based web page classification using n-gram language models //
SCITEPRESS Digital Library-KDIR 2014-Intern. conf. on Knowledge
Discovery and Information Retrieval. Rome, Italy, 2014.
12. Belmouhcine A., Benkhalifa M. Implicit Links based Web Page
Representation for Web Page Classification // Proc. of the 5th Intern. conf.
on Web Intelligence, Mining and Semantics. Larnaca, Cyprus, 2015.
13. Amin S. Security of interdependent and identical networked control
systems. Automatica./S. Amin, G. A. Schwartz, S. S. Sastry . – Santa
Barbara: Elsevier, 2013. – 125 p.
14. Brikman Y. Terraform: Up & Running: Writing Infrastructure as Code /
Yevgeniy Brikman. – Sebastopol, CA: O'Reilly Media, 2019. – 368 с.
15. W. N. Street, and Y. A. Kim, “Streaming Ensemble Algorithm (SEA) for
large-scale classification,” Proceedings of the 7th ACM SIGKDD
International Conference on Knowledge Discovery and Data Mining, 2001.
16. H. Wang, W. Fan, P.S. Yu, and J. Han, “Mining concept-drifting data
streams using ensemble classifiers,” Proceedings of the 9th ACM SIGKDD
international conference on Knowledge discovery and data mining, 2013. –
88 p.
17. F. Diebold, “Big Data: Dynamic Factor Models for Macroeconomic
Measurement and Forecasting,” Discussion read to the Eighth World
Congress of the Econometric Society, 2000. – 134 p.
18. D. Laney, “3-D Data Management: Controlling Data Volume, Velocity and
Variety”, February 6, 2018. – 64 p.
72
19. P.Domingos, and G. Hulten, “Mining high-speed data streams,”
Proceedings of the 6th ACM SIGKDD International Conference on
Knowledge Discovery and Data Mining. 2000. – 89 p.
20. W. N. Street, and Y. A. Kim, “Streaming Ensemble Algorithm (SEA) for
large-scale classification,” Proceedings of the 7th ACM SIGKDD
International Conference on Knowledge Discovery and Data Mining, 2001.–
109 p.
21. Чекаленко О.Л. Методи контролю та управління кліматичними
показниками приміщення в iot мережах / О.Л. Чекаленко // Проблеми
інформатизації: Тези доповідей десятої міжнародної науково-технічної
конференції 24-25 листопада 2022 року. Черкаси –– Баку – Бельсько-
Бяла— Харків: 2022.
ДОДАТОК А
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор Володимир РУДНИЦЬКИЙ
________________________
“___” _____________ 2022р.
Дослідження методів і алгоритмів передачі великих об’ємів даних в
режимі реального часу на базі рішень AWS
Специфікація
482.ЧДТУ.22287-01
Листів 2
Розробник _______________ Олексій ЧЕКАЛЕНКО
Керівник _______________ Микола ХРУЛЬОВ
Черкаси 2022
2
482.ЧДТУ.22287-01
Позначення Найменування Примітка
Документація
482.ЧДТУ.22287-01 12 01 Текст програми
482.ЧДТУ.22287-01 34 01 Інструкція користувача
ДОДАТОК Б
Дослідження методів і алгоритмів передачі великих об’ємів даних в
режимі реального часу на базі рішень AWS
Текс програми
482.ЧДТУ.22287-01 12 01
Листів 17
Розробник _______________ Олексій ЧЕКАЛЕНКО
Черкаси 2022
2
482.ЧДТУ.22287-01 12 01
<?php
namespace App\Service;
use App\Dto\Input;
use App\Entity\Customer;
use Doctrine\ORM\EntityManager;
use Doctrine\ORM\ORMException;
use Doctrine\ORM\OptimisticLockException;
use Symfony\Component\HttpKernel\Exception\ConflictHttpException;
class CustomerService
{
protected $entityManager;
public function __construct(EntityManager $entityManager)
{
$this->entityManager = $entityManager;
}
/**
* @param Input\CustomerDto $dto
*
* @return Customer
*/
public function createCustomer(Input\CustomerDto $dto): Customer
{
try {
$customer = $this->getCustomerEntity($dto);
$this->saveCustomerEntity($customer);
return $customer;
} catch (ORMException $exception) {
throw new ConflictHttpException($exception->getMessage());
}
}
/**
* @param Input\CustomerDto $dto
* @param Customer $customer
3
482.ЧДТУ.22287-01 12 01
*
* @return Customer
*/
public function updateCustomer(Input\CustomerDto $dto, Customer
$customer): Customer
{
try {
$customer = $this->getCustomerEntity($dto, $customer);
$this->saveCustomerEntity($customer);
return $customer;
} catch (ORMException $exception) {
throw new ConflictHttpException($exception->getMessage());
}
}
/**
* @param Customer $customer
*
* @return Customer
*/
public function deleteCustomer(Customer $customer): Customer
{
try {
$this->deleteCustomerEntity($customer);
return $customer;
} catch (ORMException $exception) {
throw new ConflictHttpException($exception->getMessage());
}
}
/**
* @param Input\CustomerDto $dto
* @param Customer|null $customer
*
* @return Customer
*/
private function getCustomerEntity(Input\CustomerDto $dto, Customer
$customer = null): Customer
{
if (!$customer) {
$customer = new Customer();
4
482.ЧДТУ.22287-01 12 01
$customer->setPassword($dto->getPassword());
}
return $this->mergeEntities($dto, $customer);
}
/**
* @param Input\CustomerDto $dto
* @param Customer|null $customer
*
* @return Customer
*/
private function mergeEntities(Input\CustomerDto $dto, Customer
$customer = null): Customer
{
$customer->setAddress($dto->getAddress());
$customer->setName($dto->getName());
$customer->setPhone($dto->getPhone());
$customer->setToken($dto->getToken());
return $customer;
}
/**
* @param Customer $customer
*
* @throws ORMException
* @throws OptimisticLockException
*/
private function saveCustomerEntity(Customer $customer)
{
$this->entityManager->persist($customer);
$this->entityManager->flush();
}
/**
* @param Customer $customer
*
* @throws ORMException
* @throws OptimisticLockException
*/
5
482.ЧДТУ.22287-01 12 01
private function deleteCustomerEntity(Customer $customer)
{
$this->entityManager->remove($customer);
$this->entityManager->flush();
}
}
<?php
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
use Doctrine\Common\Collections\Collection;
use Doctrine\Common\Collections\ArrayCollection;
/**
* @ORM\Entity(repositoryClass="App\Repository\CustomerRepository")
* @ORM\Table(indexes={@ORM\Index(name="customer_id", columns={"id",
"rfid"})})
*/
class Customer
{
/**
* @ORM\Id()
* @ORM\GeneratedValue()
* @ORM\Column(type="integer")
*/
private $id;
/**
* @ORM\Column(type="string", length=8, nullable=true)
*/
private $rfid;
/**
* @ORM\Column(type="string", length=100)
*/
private $name;
/**
6
482.ЧДТУ.22287-01 12 01
* @ORM\Column(type="string", length=255, nullable=true)
*/
private $password;
/**
* @ORM\Column(type="string", length=13, nullable=true)
*/
private $phone;
/**
* @ORM\Column(type="string", length=50, nullable=true)
*/
private $token;
/**
* @ORM\ManyToMany(targetEntity="App\Entity\Address",
mappedBy="customers")
*/
private $address;
public function __construct()
{
$this->address = new ArrayCollection();
}
public function getId()
{
return $this->id;
}
public function getRfid(): ?string
{
return $this->rfid;
}
public function setRfid(?string $rfid): self
{
$this->rfid = $rfid;
return $this;
}
7
482.ЧДТУ.22287-01 12 01
public function getName(): ?string
{
return $this->name;
}
public function setName(string $name): self
{
$this->name = $name;
return $this;
}
public function getPassword(): ?string
{
return $this->password;
}
public function setPassword(string $password): self
{
$options = [ 'cost' => 12 ];
$this->password = password_hash($password, PASSWORD_BCRYPT,
$options);
return $this;
}
public function getPhone(): ?string
{
return $this->phone;
}
public function setPhone(?string $phone): self
{
$this->phone = $phone;
return $this;
}
public function getToken(): ?string
8
482.ЧДТУ.22287-01 12 01
{
return $this->token;
}
public function setToken(?string $token): self
{
$this->token = $token;
return $this;
}
/**
* @return Collection|Address[]
*/
public function getAddress(): Collection
{
return $this->address;
}
public function addAddress(Address $address): self
{
if (!$this->address->contains($address)) {
$this->address[] = $address;
$address->addCustomer($this);
}
return $this;
}
public function removeAddress(Address $address): self
{
if ($this->address->contains($address)) {
$this->address->removeElement($address);
$address->removeCustomer($this);
}
return $this;
}
}
9
482.ЧДТУ.22287-01 12 01
<?php
namespace App\Service;
use SoapClient;
class MessageService
{
protected $settings;
public function __construct(array $settings)
{
$this->settings = $settings;
}
/**
* @param string $message
* @param array $phones
*/
public function sendMultipleSms(string $message, array $phones)
{
foreach ($phones as $phone) {
$this->sendOneSms($message, $phone);
}
}
/**
* @param string $message
* @param string $number
*/
public function sendOneSms(string $message, ?string $number)
{
if ($number) {
$client = new SoapClient($this->settings['path']);
$res = $client->auth($this->settings['customer'],
$this->settings['password']);
$client->sendSmsOne($res->message, $number,
$this->settings['title'], $message);
}
}
}
10
482.ЧДТУ.22287-01 12 01
<?php
namespace App\Service;
use App\Dto\Input;
use App\Entity\Address;
use Doctrine\ORM\EntityManager;
use Doctrine\ORM\ORMException;
use Doctrine\ORM\OptimisticLockException;
use Symfony\Component\HttpKernel\Exception\ConflictHttpException;
class AddressService
{
protected $entityManager;
public function __construct(EntityManager $entityManager)
{
$this->entityManager = $entityManager;
}
/**
* @param Input\AddressDto $dto
*
* @return Address
*/
public function createAddress(Input\AddressDto $dto): Address
{
try {
$address = $this->getAddressEntity($dto);
$this->saveAddressEntity($address);
return $address;
} catch (ORMException $exception) {
throw new ConflictHttpException($exception->getMessage());
}
}
/**
* @param Input\AddressDto $dto
* @param Address $address
11
482.ЧДТУ.22287-01 12 01
*
* @return Address
*/
public function updateAddress(Input\AddressDto $dto, Address $address):
Address
{
try {
$user = $this->getAddressEntity($dto, $address);
$this->saveAddressEntity($user);
return $user;
} catch (ORMException $exception) {
throw new ConflictHttpException($exception->getMessage());
}
}
/**
* @param Address $address
*
* @return Address
*/
public function deleteAddress(Address $address): Address
{
try {
$this->deleteAddressEntity($address);
return $address;
} catch (ORMException $exception) {
throw new ConflictHttpException($exception->getMessage());
}
}
/**
* @param Input\AddressDto $dto
* @param Address|null $address
*
* @return Address
*/
private function getAddressEntity(Input\AddressDto $dto, Address $address
= null): Address
{
if (!$address) {
12
482.ЧДТУ.22287-01 12 01
$address = new Address();
}
return $this->mergeEntities($dto, $address);
}
/**
* @param Input\AddressDto $dto
* @param Address|null $address
*
* @return Address
*/
private function mergeEntities(Input\AddressDto $dto, Address $address =
null): Address
{
$address->setAddress($dto->getAddress());
$address->setPolice($dto->getPolice());
$address->setProvider($dto->getProvider());
return $address;
}
/**
* @param Address $address
*
* @throws ORMException
* @throws OptimisticLockException
*/
private function saveAddressEntity(Address $address)
{
$this->entityManager->persist($address);
$this->entityManager->flush();
}
/**
* @param Address $address
*
* @throws ORMException
* @throws OptimisticLockException
*/
private function deleteAddressEntity(Address $address)
13
482.ЧДТУ.22287-01 12 01
{
$this->entityManager->remove($address);
$this->entityManager->flush();
}
}
<?php
namespace App\Service;
class EmailService
{
protected $settings;
public function __construct(array $settings)
{
$this->settings = $settings;
}
/**
* @param string $message
* @param array $tokens
* @param string $emailToken
* @param int $priority
*/
public function createEmail(string $message, array $tokens, string
$emailToken, int $priority = 0)
{
if (count($tokens) > 0) {
$request = $this->createHttpQuery($message, implode(',',
$tokens), $emailToken, $priority);
$context = $this->createContext($request);
$this->sendEmail($context);
}
}
/**
* @param $context
*/
private function sendEmail($context)
{
14
482.ЧДТУ.22287-01 12 01
file_get_contents(
$this->settings['path'],
$this->settings['include'],
$context
);
}
/**
* @param string $query
*
* @return array
*/
private function createContext(string $query)
{
$options = [
'header' => 'Content-Type: application/x-www-form-
urlencoded',
'method' => 'POST',
'content' => $query
];
return stream_context_create([
'http' => $options
]);
}
/**
* @param string $message
* @param string $token
* @param string $emailToken
* @param int $priority
*
* @return string
*/
private function createHttpQuery(string $message, string $token, string
$emailToken, int $priority)
{
$options = [
'token' => $emailToken,
'message' => $message,
'customer' => $this->settings['customer'],
15
482.ЧДТУ.22287-01 12 01
'priority' => $priority,
'sound' => $priority == 1 ? 'bike' : 'pushover',
'email' => $token
];
return http_build_query($options);
}
}
<?php
namespace App\EventSubscriber;
use App\Events;
use App\Entity\Action;
use App\Service\MessageService;
use App\Service\NotificationService;
use Symfony\Component\EventDispatcher\GenericEvent;
use Symfony\Component\Translation\TranslatorInterface;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
class ActionNotificationSubscriber implements EventSubscriberInterface
{
protected $translator;
protected $messageService;
protected $notificationService;
public function __construct(
MessageService $messageService,
TranslatorInterface $translator,
NotificationService $notificationService
) {
$this->translator = $translator;
$this->messageService = $messageService;
$this->notificationService = $notificationService;
}
public static function getSubscribedEvents(): array
{
16
482.ЧДТУ.22287-01 12 01
return [
Events::ACTION_CREATED => 'onActionCreated'
];
}
public function onActionCreated(GenericEvent $event): void
{
/** @var Action $action */
$action = $event->getSubject();
$translate = $this->createTranslate($action);
$parameters = $this->createParameters($action);
$message = $this->translator->trans( $translate, $parameters);
$this->createNotificationMessages($message, $action);
$this->createSmsMessages($message, $action);
}
private function createTranslate(Action $action): string
{
return 'notification.' . $action->getType();
}
private function createParameters(Action $action): array
{
$client = $action->getUser();
$customer = $action->getDevice();
$location = $customer->getLocation();
return [
'police' => $location->getPolice(),
'provider' => $location->getProvider(),
'clientName' => $client ? $client->getName() : null
];
}
/**
* Prepared SMS message for sending.
17
482.ЧДТУ.22287-01 12 01
* @param string $message
* @param Action $action
*/
private function createSmsMessages(string $message, Action $action)
{
$customer = $action->getDevice();
if ($action->getEmergency()) {
$this->messageService->sendMultipleSms(
$message,
$customer->getUsersPhones()
);
}
}
/**
* Prepared Email notification for sending.
* By default notification will sending only for subscribers.
* tokens what assigned for customer.
* @param string $message
* @param Action $action
*/
private function createNotificationMessages(string $message, Action
$action)
{
$customer = $action->getDevice();
$tokens = $customer->getSubscribersTokens();
if ($action->getEmergency()) {
$tokens = array_merge(
$tokens,
$customer->getUsersTokens()
);
}
$this->notificationService->createNotification(
$message,
$tokens,
$customer->getToken()
);
}
}
ДОДАТОК В
Дослідження методів і алгоритмів передачі великих об’ємів даних в
режимі реального часу на базі рішень AWS
Інструкція користувача
482.ЧДТУ.22287-01 34 01
Листів 3
Розробник _______________ Олексій ЧЕКАЛЕНКО
Черкаси 2022
2
482.ЧДТУ.22287-01 34 01
Для того, щоб розроблена система функціонувала правильно потрібно,
перш за все, налаштувати роботу сервера для роботи з програмним
забезпеченням. Через те, що розроблена система є мікросервісною системою,
потрібно налаштувати декілька програмних додатків та роботу з базою
даних.
Для того, щоб програмні додатки на сервері працювали правильно
потрібно налаштувати хости кожного сервісу в системі nginx.
Nginx - вільний вебсервер і проксі-сервер. Є версії для сімейства Unix-
подібних операційних систем (FreeBSD, GNU/Linux, Solaris, Mac OS X) та
Microsoft Windows. Розробляється Ігорем Сисоєвим з 2002-го року для
компанії Rambler і постійно вдосконалюється. Восени 2004 року вийшов
перший публічно доступний реліз.
Віртуальний сервер nginx має можливість підключати PHP як мову
програмування для кожного з хостів. Щоб встановити та налаштувати
fastCGI (FPM), PHP і Nginx на Ubuntu Linux, виконайте такі дії:
1) виконайте оновлення apt-get, щоб забезпечити доступ до останніх
пакетів;
2) встановіть Nginx на Ubuntu;
3) встановіть пакет php-fpm для Nginx;
4) відредагуйте файл конфігурації сервера за замовчуванням для
підтримки PHP у Nginx;
5) перезапустіть налаштований PHP сервер Nginx;
6) додайте файл PHP до каталогу html Nginx;
7) перевірте конфігурацію PHP, Nginx і PHP-FPM.
Після виконання всіх описаних дій встановлений віртуальний сервер
дозволяє працювати з обраною мовою програмування. Наступним кроком
буде налаштування бази даних. Для цього можна знову скористатися
3
482.ЧДТУ.22287-01 34 01
командою apt, щоб отримати та встановити це програмне забезпечення: sudo
apt install mysql-server.
Ця команда також покаже вам список пакетів, які будуть встановлені,
разом з обсягом дискового простору, який вони займатимуть. Введіть Y, щоб
продовжити.
Після завершення інсталяції запустіть простий сценарій безпеки,
попередньо встановлений разом із MySQL, який видалить деякі небезпечні
параметри за замовчуванням і заблокує доступ до вашої системи баз даних.
Запустіть інтерактивний сценарій, виконавши: sudo mysql_secure_installation.
Коли ви закінчите, перевірте, чи можете ви увійти в консоль MySQL,
ввівши: sudo mysql
Це дасть можливість під'єднатися до сервера MySQL як
адміністративний користувач бази даних root, який визначається
використанням sudo під час виконання цієї команди.
Після налаштування PHP та MySQL потрібно відредагувати файл
програми index.php та вказати всі потрібні логіни та паролі для роботи з ПО.
Після виконання всіх цих дій, при відкритті браузера порталу http://localhost/
у вас буде можливість отримати доступ до розробленої програми.
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
