Веб-додатки для розгортання в хмарному середовищі.

1. Аналіз існуючих рішень

Використання хмарної інфраструктури вирішує низку проблем з якими зіткаються організації та компанії при розробці програмних продуктів. Однією із найбільших переваг хмарної архітектури є відсутність потреби здійснювати витрати на придбання, налаштування та підтримку фізичного обладнання. Проте, використання хмарної інфраструктури потребує від розробників чіткого бачення системи на етапі проектування. На початку життєвого циклу розробки будь-якого застосування проектується архітектура, яка згодом може виявитись непридатною до використання із певним архітектурним рішенням. Таким чином, при розробці архітектури особливу увагу потрібно приділити які переваги та недоліки вона має з інфраструктурного боку. Наприклад, 1-рівневе застосування не дає змогу повністю використати можливості хмарної архітектури та є більш придатним для розгортки на виділеному фізичному сервері. З іншого боку, багаторівневі застосування здатні ефективно використовувати ресурси хмарних обчислень та масштабувати певний рівень за потреби.

Отже, веб-додаток – це комп’ютерна програма, яка працює в браузері, як Microsoft Word працює в OС Windows. Тому, для доступу до програми потрібні браузер та Інтернет. Зберігання та обробка інформації при такій організації обчислень відбувається на віддаленому сервері, а веб-переглядач служить програмою-клієнтом і призначеним для користувача інтерфейсом

Схема роботи веб-додатку

У прикладному відношенні – веб-додатки мають ту істотну перевагу: вже розроблено багато програм і сервісів, за допомогою яких будь-яка людина, не будучи програмістом і навіть просунутим користувачем, може створювати різні корисні програми для своєї зручності та розваги. Причому абсолютно безкоштовно.

В основу роботи комп'ютерів покладено програмний принцип керування, який полягає в тому, що комп'ютер виконує дії за заздалегідь заданою програмою. Цей принцип забезпечує універсальність використання комп'ютера: у певний момент часу розв'язується задача відповідно до вибраної програми. Після її завершення у пам'ять завантажується інша програма і т.д. Програма – це запис алгоритму розв'язання задачі у вигляді послідовності команд або операторів мовою, яку розуміє комп'ютер. Кінцевою метою будь-якої комп'ютерної програми є керування апаратними засобами

Програмне та апаратне забезпечення у комп'ютері працюють у нерозривному зв'язку та взаємодії. Склад програмного забезпечення обчислювальної системи називається програмною конфігурацією. Між програмами існує взаємозв'язок, тобто багато програм працюють, базуючись на програмах нижчого рівня. Міжпрограмний інтерфейс – це розподіл програмного забезпечення на декілька пов'язаних між собою рівнів. Рівні програмного забезпечення являють собою піраміду, де кожен вищій рівень  базується на програмному забезпеченні попередніх рівнів

2. Вибір архітектури веб-застосування

Архітектура застосування визначає схему взаємодії між різними компонентами системи. Зручним є розділення архітектури на логічні рівні. Фактично, відбувається фізичне розділення на системи на певні компоненти. Наприклад, такими компонентами можуть бути сервер бази даних, бекенд сервер, користувацький інтерфейс, сервер кешування, messaging сервер, тощо. В залежності від кількості рівнів, застосунки поділяються на 1-рівневі, 2-рівневі, 3-рівнені та багаторівнені. Кожен із цих підходів має свої переваги та недоліки пов’язані із складністю розробки, розгортки та використання.

Порівняльна характеристика архітектурних підходів

1-рівневе застосування - це застосування у якому сервер бізнес-логіки, база даних та користувацький розташовані на одній машині.

Візуалізація 1-рівневого застосування

1-рівневі застосування володіють низкою переваг, проте це архітектурне рішення є непридатним до використання у веб-застосуваннях, адже усі компоненти програмної системи мусять бути на одній фізичній машині. Ключовими перевагами є: відсутність мережевих запитів до ресурсів системи, швидкий доступ до даних, відносно гарний рівень безпеки. Прикладами 1-рівневих застосувань є настільки додатки (desktop applications). Одним із найбільших недоліків даних застосувань є складність внесення змін після того як застосунок було доставлено. Наприклад, якщо користувач встановив певне програмне забезпечення, яке містить помилку, він мусить власноруч завантажити та встановити оновлення. Цей недолік змушує розробників дуже ретельно тестувати, адже будь-який помилковий код який було доставлено буде складно виправити.

2-рівнева архітектура включає в себе клієнт-серверну взаємодію. Зазвичай, клієнтський рівень містить користувацький інтерфейс, а сервер фактично виступає у ролі сервера бази даних.

Візуалізація 2-рівневого застосування

Таке розділення рівнів дозволяє розмістити різні рівні на різні машини (віртуальні або фізичні). Безумовно, розміщення бізнес-логіки на клієнтській стороні створює потенційні загрози безпеці. Користувач матиме змогу здійснити reverse engineering та отримати доступ до критичних аспектів системи. Проте, даний підхід має й низку позитивних аспектів. Розміщення користувацького інтерфейсу та бізнес-логіки на одному рівні дозволяє зменшити кількість мережевих запитів до бази даних. В свою чергу, це дозволяє зменшити витрати на підтримку серверної інфраструктури.

3-рівнева архітектура є однією з найбільш використовуваних у вебзастосуваннях. Вона строго розподіляє застосунок на 3 рівні: користувацький інтерфейс, бізнес-логіка застосунку та база даних.

- Візуалізація 3-рівневого застосування

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

Багаторівнева архітектура (або N-tier architecture) є розширення 3- рівневої архітектури. Даний підхід наслідує принцип Single Responsibility, тобто кожен рівень повинен мати свою задачу і виконувати її добре. Прикладами додаткових рівнів які можуть використовувати багаторівневі застосування є: компоненти кешування, messaging сервіси, балансувальники навантаження, пошукові сервіси, тощо.

2.1. Розміщення на власних ресурсах

Розміщення застосування на власних ресурсах є одним із найстаріших підходів у доставці веб-застосувань. Проте, цей підхід є широковживаним навіть зараз, здебільше у великих корпораціях, які володіють великими (часто legacy) програмними продуктами. Раніше, кожна з таких корпорацій будувала та константно оновлювала власну інфраструктуру. У свою чергу, будь-які нові програмні продукти які розроблялися орієнтувалися на вже вибудовану інфраструктуру. Використання власних ресурсів має низку переваг: можливість повністю контролювати інфраструктуру, підвищений рівень захищеності даних. Організація, яка володіє певними обчислювальними ресурсами має також можливість оновити інфраструктуру (обладнання), щоб максимально задовольнити свої потреби. Величезною перевагою є зберігання даних на власних серверах, адже таким чином, компанія повністю контролює усе що відбувається із цими даними. Також, варто зазначити, що існують певні сфери у яких компанії зобов’язані зберігати дані користувачів на власних серверах. Проте, також існують певні недоліки у такого підходу. 

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

По-друге, відсутня можливість швидкого масштабування за потреби. У випадку швидкого зростання навантаження на систему та недостатньої кількості апаратних ресурсів може виявитись, що система не здатна обробити усі запити достатньо швидко.

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

2.2. Розміщення на орендованих ресурсах

Розміщення на орендованих ресурсах є непоганою альтернативою використанню власних ресурсів. Насамперед, завдяки відсутності великих витрат на початковому етапі розробки застосування. Часто, такий підхід використовується, якщо є потреба у розміщенні застосування на певний невеликий період часу. У порівнянні із використанням власних ресурсів даний підхід має декілька недоліки: менша гнучкість у виборі апаратних ресурсів, менший рівень захищеності даних. 

Проте, варто зазначити декілька ключових переваг використання орендованих ресурсів: 

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

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

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

2.3. Розміщення на хмарній платформі

Зазвичай, хмарні послуги надаються за трьома моделями: IaaS (Infrastructure as a service), PaaS (Platform as a service), SaaS (Software as a service). Інколи також виділяють додаткову модель DaaS (Data storage as a service), яка фактично є особливим випадком IaaS. Модель IaaS надає доступ до обчислювальних ресурсів, наприклад: сервери, сховища даних, мережні ресурси. Ці ресурси можуть бути масштабованими за потреби, та часто підтримують віртуалізацію. Прикладами IaaS є AWS EC2, Google Compute Engine, DigitalOcean, тощо. Модель PaaS надає користувачам доступ до хмарної платформи, в якому вони можуть розроблювати, адмініструвати та доставляти застосування. Така модель спрощує розміщення веб-застосувань, адже зникає необхідність адмініструвати власну або хмарну інфраструктуру. Прикладами PaaS є AWS Elastic Beanstalk, Google App Engine, Heroku, тощо. Модель SaaS надає користувачам доступ до хмарних програмних продуктів. Зазвичай, ці програмні продукти існують у вигляді вебзастосувань. Користувачі не встановлюють ніяке програмне забезпечення для взаємодії із застосуваннями. Прикладами SaaS є Google Apps, Dropbox, Slack.

3. Структурна розробка веб-застосування

У якості прикладу, розглядається багаторівневе веб-застосування для обміну миттєвими текстовими повідомленнями та файлами. Ключові вимоги до застосування: розбиття на рівні, підтримка обміну файлами, системи ідентифікації користувачів, можливість комунікації між двома користувачами, використання сервісів AWS.

Було обрано наступні сервіси AWS для розробки веб-застосування: EC2, S3, RDS, CloudFront, Route53, Application Load Balancer. Сервіс EC2 виступає у ролі головного бекенд-сервера, який відповідає за бізнес-логіку застосування. Для простоти спілкування із іншими компонентами, даний сервер наслідує архітектуру REST API. Повідомлення передаються у форматі JSON. Сервіс S3 виконує декілька задач. По-перше, на ньому розміщуються статичні файли для роботи користувацького інтерфейсу. По-друге, зберігаються медіа-файли, якими обмінюються користувачі. Сервіс RDS виступає у ролі реляційної бази даних в якій зберігаються дані про користувачів, а також їх повідомлення. Cервіс CloudFront використовується для доставки об’єктів користувацького інтерфейсу, та фактично являється системою CDN. Сервіс Route53 дозволяє зареєструвати доменне ім’я, та пов’язати цей домен (або сабдомен) із певним ресурсом AWS. Сервіс Application Load Balancer розподіляє запити між екземплярами сервісу EC2 за певним алгоритмом, наприклад round robin.

Структурна схема веб-застосування

3.1. Опис компонентів веб-застосування. Користувацький інтерфейс

Для розміщення та доставки компонента користувацького інтерфейсу використовується зв’язка сервісів AWS S3 та AWS CloudFront. S3 дозволяє зберігати статичні файли (HTML, CSS, JS) веб-застосунку у хмарі, звертатися до них, налаштовувати права доступу до цих файлів, тощо. На додачу, S3 надає змогу хостингу статичного веб-сайту. Для того, щоб налаштувати подібний статичний веб-сайту потрібно виконати декілька кроків. По-перше, потрібно створити так званий bucket, який би містив статичні файли сайту.

3.2. Бізнес-логіка

Екземпляр сервісу EC2 відповідає за бізнес-логіку веб-застосування. Даний сервіс опрацьовує запити від користувачів, які здійснюються за допомогою користувацького інтерфейсу. Завдання коректної обробки цих запитів повністю лежить на розробнику, адже при створенні екземпляру EC2 надається порожній віртуальний сервер. Під час створення надається можливість обрати AMI (Amazon Machine Instance), кількість обчислювальних ресурсів, мережні налаштування, налаштування безпеки, тощо. До EC2 можна під’єднатися за допомогою SSH, або використовуючи веб-інтерфейс. Також надається можливість налаштувати автоматичне масштабування, балансувальник навантаження та змінити кількість обчислювальних ресурсів. Враховуючи, що за замовчуванням користувачам надається сервер без допоміжного програмного забезпечення, розробники повинні самостійно налаштувати веб-сервер. Найпопулярнішими з яких наразі є Apache та nginx.

Реалізації цих стандартів (наприклад gunicorn та uwsgi) фактично надає API для взаємодії Python-застосунку та веб-сервера, вирішує низькорівневі задачі, наприклад адміністрування сокетів та виділення так званих workers. Компонент бізнес-логіки є REST-подібним сервісом, який має змогу обробляти запити у форматі JSON. Даний компонент містить декілька сутностей пов’язаних із предметною областю: User (Користувач), Conversation (Бесіда), Message (Повідомлення). Сутність User містить дані про користувача; Conversation містить ідентифікатори користувачів які ведуть обмін повідомленнями; Message може містити текст повідомлення або посилання на медіа-файл. REST API описує такі ресурси: 

• GET “api/conversations/” - отримання усіх бесід 

• POST “api/conversations/” - створення нової бесіди 

• GET “api/conversation/pk/” - отримання однієї бесіди та повідомлень 

• POST “api/conversation/pk/” - створення нового повідомлення 

• DELETE “api/conversation/pk/” - видалення бесіди 

• POST “api/authenticate” - отримання JWT-токена 

• POST “api/refresh” - оновлення JWT-токена • POST “api/register” - реєстрація нового користувача

3.3. База даних

Сервіс Amazon RDS адмініструє розподілену реляційну базу даних. При створення екземпляру RDS надається можливість обрати двигун бази даних (MySQL, PostgreSQL, тощо), стратегію оптимізації бази даних, обчислювальні ресурси, базові налаштування доступу до бази даних (ім’я, пароль) та якій віртуальній мережі даний екземпляр належатиме. Варто зазначити, що з міркувань безпеки, за замовчуванням доступ до бази даних надається тільки сервісам які знаходяться у тій самій віртуальній мережі. Встановлення з’єднання між компонентом бізнес-логіки та бази даних здійснюється за допомогою URL-адреси.