Архітектура

Клієнт-серверна архітектура — це підхід до побудови розподілених систем, що включає дві основні частини: клієнти та сервери. Ця архітектура дозволяє ефективно розділити обробку даних між ними. Основна ідея полягає в тому, що клієнтські програми надсилають запити до серверів, які обробляють ці запити та повертають відповіді.

Організація програмних систем, її компонентів, властивостей цих компонентів та взаємодії між ними. Рішення, які визначають структуру та поведінку систем, а також способи, за допомогою яких системи будуть розвиватися та масштабуватися.

База

Основні компоненти

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

Характеристика

Централізоване управління ресурсами: Сервери управляють ресурсами та даними, що забезпечує централізоване місце для їх зберігання, доступу та управління.
Масштабованість: Систему можна масштабувати, додавши більше серверів або покращивши їх характеристики, щоб впоратися зі зростаючим навантаженням.
Гнучкість: Клієнти та сервери можуть бути розроблені та оновлені незалежно, дозволяючи легше впроваджувати нові технології та оновлення.
Спеціалізація: Сервери можуть бути оптимізовані для виконання специфічних задач, що підвищує ефективність обробки запитів.

Типи архітектур

Клієнт-сервер з дублікацією даних (наявний)

На схемі зображена схема клієнт-серверної архітектури, яка включає використання проксі-серверів та дублювання даних з основною бази.

Алгоритм

Клієнти: Каса, мобільний застосунок, браузер відправляють запити до сервера. Запити можуть йти через інтернет або локальну мережу.
Проксі-сервери: Є два проксі-сервери, вони відповідають за фільтрацію запитів та забезпечення певної безпеки серверів. Клієнти можуть підключатися до тієї проксі, до якої привʼязане те чи інше доменне імʼя.
Веб-сервер: Веб-сервер обробляє запити, отримані від проксі-серверів, і взаємодіє з базою даних. Веб-сервер налаштований на виконання бізнес-логіки додатку, видачу веб-сторінок, обслуговування API-запитів тощо.
База даних: Основна база даних зберігає дані, які використовуються веб-сервером. Вона може обробляти запити на читання та запис, управління транзакціями, запити на оновлення тощо.
Дублікація бази даних: Дані з головної бази даних дублюються на інший сервер, який відповідає виключно за збереження актуальних даних без будь-якого доступу до них. Це реалізовано з метою забезпечення безпеки цих даних на випадок відмови головної бази (аварії у датацентрі, пошкодження дискових масиві, технічні несправності сервера...), у такому разі буде повна копія актуальних даних на момент аварії, які будуть використанні технічними спеціалістами для відновлення роботи головного серевера з даними.

Схема показує, що всі компоненти взаємопов'язані, і кожен з них виконує певну роль у загальній архітектурі системи. Але тут існує вагомий недолік: у разі критичних проблем технічного характеру на одному з серверів, необхідно визначена ситуацією кількість часу на відновлення роботоздатності системи.
Наприклад, вийшли з ладу диски - у такому випадку необхідно дочекатись поки фахівці в датацентрі підʼєднають нові диски до сервера (скільки на це піде часу, залежить суто від датацентра, тобто час є динамічно визначеним), потім налаштувати ці диски під роботу на самому сервері, підготувати віртуальні машини в кластері (близько години), та перенесення на них даних з інших серверів, які підтримували та зберігали їх актуальність (тут час залежить суто від обʼємів та масштабів клієнта).
При досить складних обставинах, такі роботи можуть займати дні. Іноді, рішенням може виступити взагалі оренда нового сервера, а на підготовку піде не менше тижня (мова про випадок, у якому із ладу вийдуть планки памʼяті, до прикладу).

Клієнт-сервер з реплікацією серверів (розглядається)

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

Алгоритм

Клієнти: Каса, мобільний застосунок, браузер відправляють запити до сервера. Запити можуть йти через інтернет або локальну мережу.
Проксі-сервери: Є два проксі-сервери, вони відповідають за фільтрацію запитів та забезпечення певної безпеки серверів. Клієнти можуть підключатися до тієї проксі, до якої привʼязане те чи інше доменне імʼя. У випадко збоїв роботи на головному веб сервері, проксі перемикають на реплікаційни веб сервер.
Веб-сервер: Веб-сервер обробляє запити, отримані від проксі-серверів, і взаємодіє з базою даних. Веб-сервер налаштований на виконання бізнес-логіки додатку, видачу веб-сторінок, обслуговування API-запитів тощо.
База даних: Основна база даних зберігає дані, які використовуються веб-сервером. Вона може обробляти запити на читання та запис, управління транзакціями, запити на оновлення тощо.
Реплікація веб сервера: Повна копія веб сервера зі всіма необхідними налаштуваннями. Головне завдання - синхронізуватись з головним веб сервером та підтримувати актуальні стани сервісів на випадок критичних проблем у звʼязці: веб-сервер -> база даних.
Реплікація бази даних: Повна копія бази даних зі всіма необхідними налаштуваннями. Головне завдання - синхронізація даних з головною базою даних та підтримувати їх актуальність на випадок критичних проблем у звʼязці: веб-сервер -> база даних.

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

Порівняння

Архітектура з реплікацією даних пропонує ряд значущих переваг, які покращують надійність та стабільність роботи системи, по-пунктах:

Висока доступність - реплікація забезпечує наявність кількох копій даних, що розташовані на різних локаціях, обслуговуються різними датацентрами та підʼєднані до різних провайдерів, тим самим знижуючи ризик втрати доступу до даних у разі відмови одного сервера.
Відмовостійкіст - у разі збою або відмови основної бази даних, система може швидко перемкнутися на репліковану копію без істотної перерви у роботі. На відміну від першого, класичного варіанта, де необхідна певна кількість часу для вирішення технічної проблеми (вище детально описано), цей час сильно залежить від обʼємів бази даних та датацентра.
Легкість ведення робіт - реплікація дозволяє проводити обслуговування та оновлення системи з мінімальними перервами у наданні послуг, оскільки процесінг можна перемкнути на реплікі під час робіт на основних серверах.
Розподіл навантаження - якщо клієнт має достатньо великі обʼєми даних, для оптимізації їх роботи, сам процесінг можна налаштувати таким чином, щоб певні операції були розподілені між реплікацією та головною базою, до прикладу: операції видалення/запису відпрацьовуватимуть на головній базі даних, а операції читання, обрахунків - на реплікації.
Автономність - при активних атаках на інфраструктуру датацентра збоку мережовиків це може вплинути на роботу серверів, які у ньому розміщені. Наявні реплікації, що розсташовані у іншому ізольованому середовищі дозволять безболісно перемкнутись на них і не відчути наслідків від подій, на які ми не маємо впливу.