1. Загальний опис архітектури

ЦБД являє собою Core API систему, яка не має інтерфейсу для взаємодії з інтернет-користувачем. З системою взаємодіють сайти (площадки/майданчики) способом надсилання REST API запитів через VPN зʼєднання.

Інфраструктура ЦБД базується на платформі оркестрації Kubernetes.

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

Такий підхід дозволяє розгорнути систему в мінімальні терміни на будь-якому хмарному провайдері (AWS, Google, Azure, Digital Ocean). Основною вимогою є лише підтримка роботи з Kubernetes.

1.1. Структура

2. Логічна архітектура

Інфраструктура як код (Infrastructure as Code, IaC)

Усі операції, пов’язані з розгортанням інфраструктури, оновленням програмного забезпечення та адміністративними задачами, реалізуються відповідно до підходу Infrastructure as Code (IaC) — «інфраструктура як код». Це сучасний метод управління інфраструктурою, який дозволяє автоматизувати створення, зміну та підтримку обчислювальних ресурсів за допомогою коду, що зберігається в системі контролю версій.

Переваги підходу IaC:

• Автоматизація процесів розгортання та оновлення, що значно знижує ризик людської помилки;

• Відтворюваність середовищ: однакові конфігурації можна розгортати в різних середовищах (Dev, Stage, Prod) без змін;

• Масштабованість: інфраструктура легко масштабується через зміну параметрів у коді;

• Контроль змін: усі зміни фіксуються в git-репозиторіях, що дозволяє відслідковувати історію, робити рев’ю та швидко відкотитись до стабільної версії при потребі.

Технології, які використовуються:

• Terraform (v1.11.1)
  Використовується для створення та управління ресурсами хмарної інфраструктури, включаючи розгортання Kubernetes-кластера. Завдяки декларативному синтаксису дозволяє легко описати архітектуру середовища та керувати залежностями між компонентами.

• Helm (v3.17.1)
  Використовується для розгортання та оновлення застосунків всередині Kubernetes-кластера. Helm Charts дозволяють шаблонізувати конфігурації та централізовано керувати версіями застосунків, що спрощує CI/CD-процеси.

• GitLab CI/CD
  Усі дії з розгортання та оновлення виконуються автоматично через пайплайни в GitLab. Після коміту змін у репозиторій запускається відповідний пайплайн, який проходить усі етапи — від валідації коду до розгортання в обране середовище. Це забезпечує повну автоматизацію без необхідності втручання людини.

Як це працює на практиці:

1. Розробник або адміністратор вносить зміни в код Terraform або Helm.

2. Зміни комітяться у GitLab-репозиторій.

3. GitLab CI/CD автоматично запускає пайплайн, що:

   • перевіряє синтаксис конфігурацій,

   • виконує dry-run (імітаційний запуск),

   • застосовує зміни в обраній інфраструктурі.

4. Успішне виконання пайплайну призводить до оновлення реального середовища (наприклад, Dev або Prod).

3. Фізична архітектура

Інфраструктура системи реалізована на основі двох незалежних кластерів Kubernetes, розгорнутих у хмарному середовищі AWS (Europe, Ірландія) в різних дата-центрах для забезпечення відмовостійкості, георезервування та безперервності бізнес-процесів.

Структура кластерів:

1. Кластер №1 — ЦБД (Центральна база даних)

   • Розташування: дата-центр eu-west-1b

   • Призначення: основний кластер, в якому безпосередньо розгортається Центральна база даних (ЦБД), її компоненти та вся прикладна логіка.

   • Характеристики: забезпечує стабільну роботу ключових сервісів, включаючи бази даних, API, бекенд-логіку тощо.

2. Кластер №2 — Система автоматизації та CI/CD

   • Розташування: дата-центр eu-west-1c

   • Призначення: обслуговує адміністративні процеси, включаючи деплоймент, оновлення інфраструктури, CI/CD-процеси, моніторинг та логування.

   • Основний сервіс: GitLab, який відповідає за реалізацію автоматичних пайплайнів, перевірку коду, розгортання застосунків через Helm/Terraform.

Комунікація між кластерами

Для забезпечення безпечного та ефективного обміну командами та даними між двома кластерами (наприклад, під час оновлення компонентів або запуску автоматизованих сценаріїв), використовується:

• AWS VPC Peering — це захищене з'єднання між віртуальними приватними мережами (VPC), що дозволяє кластерам обмінюватися даними напряму без використання публічного інтернету.

Такий підхід:

• мінімізує затримки при обміні даними;

• гарантує високий рівень безпеки (ізоляція трафіку в межах AWS);

• забезпечує масштабованість і простоту інтеграції нових сервісів.

Система розгорнута у хмарному середовищі та використовує наступні технології:

• Контейнери (Docker, Kubernetes) – для розгортання та управління сервісами.

• Балансувальник навантаження (NGINX, AWS ALB) – рівномірний розподіл запитів.

• Системи логування та моніторингу (Elasticsearch, Kibana, Prometheus, Grafana) – для відстеження роботи системи.

• Автоматичне масштабування (Kubernetes HPA) – підвищення продуктивності під час пікових навантажень.

Приклад потоку запиту:

1. Користувач публікує обʼєкт Procedure

2. Запит надходить до API Gateway, який перенаправляє його до відповідного сервісу.

3. Якщо це участь в аукціоні, запит проходить через сервіс обробки ставок.

4. Дані кешуються у Redis для швидкого доступу.

4. Взаємодія компонентів

• Всі сервіси обмінюються даними через захищений API (REST).

• Використовується шифрування трафіку через TLS 1.3.

Приклад взаємодії:

1. Користувач подає заявку на участь в аукціоні.

2. Дані перевіряються

3. Якщо все гаразд – користувач отримує доступ до аукціону.

4. Всі події логуються в централізовану систему моніторингу.

5. Вимоги до продуктивності та масштабованості

• Час обробки запиту – не більше 500 мс.

• Кількість одночасних користувачів – до 100 000.

• Горизонтальне масштабування дозволяє автоматично додавати нові сервери.