Table of Contents

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

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

• Всі компоненти розгорнуті в хмарному середовищі (AWS).

• Взаємодія між компонентами здійснюється через REST API.

• Забезпечується авторизація та аутентифікація через OAuth 2.0.

• Всі аукціонні процеси логуються для контролю прозорості та аналітики.

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

Система складається з декількох рівнів:

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

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

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

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

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

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

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

1. Користувач заходить на сайт prozorro.sale.

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

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

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

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

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

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

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

• Для взаємодії з банками та держреєстрами використовується ESB-шина (Apache Kafka, RabbitMQ).

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

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

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

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

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

1.1. Структура

Image Added

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).

Власні сервіси, що розгортаються в Kubernetes, поділяються на два типи:

• Stateless-сервіси – не зберігають стан і не мають постійних даних.

• Stateful-сервіси – зберігають стан у Kubernetes Persistent Volumes (на EC2).

Сервіси можуть бути:

• власної розробки (кодова база: https://gitlab.prozorro.sale/prozorro-sale/)

• open-source рішеннями.

ЦБД реалізовано як мікросервісну архітектуру, де кожен сервіс виконує окрему функцію та, у разі потреби, має власну ізольовану базу даних (MongoDB). Взаємодія між сервісами відбувається всередині кластера через API-виклики між контейнерам

Kubernetes-архітектура ЦБД

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

• реалізує чітко визначену функцію або бізнес-процес;

• за потреби зберігання інформації — має власну окрему базу даних (MongoDB або PostgreSQL), розміщену як Stateful компонент у Kubernetes;

• не залежить від інших сервісів з точки зору зберігання даних.

Взаємодія між сервісами відбувається всередині кластера Kubernetes, через стандартні API-запити (HTTP/REST) між контейнерами. Такий підхід забезпечує:

• незалежність компонентів;

• гнучке масштабування;

• спрощену підтримку і супровід;

• підвищену безпеку, оскільки взаємодія обмежена внутрішньою мережею кластера.

Kubernetes GitLab

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаємодія з API ЦБД

Взаємодія з API ЦБД відбувається за допомогою REST API запитів через VPN зʼєднання. Cipher VPN Server сервер встановлено на окремій віртуальній машині (AWS EC2) та приймає запити на підключення із інтернету. REST API запити, які надсилаютьсявсередині VPN тунелю, надсилаються на балансувальник (AWS NLB), який розміщено перед кластером ЦБД

...

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

...

Дані перевіряються через інтеграцію з держреєстрами.

...

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

...

.

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

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

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

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