
# Композиційна архітектура мікросервісів ШІ для масштабованої автоматизації анкети безпеки

Компанії тону**ть** у постійно зростаючій хвилі анкет безпеки, оцінок постачальників та аудитів відповідності. Традиційні монолітні інструменти не встигають, особливо коли потрібно інтегруватися з різними екосистемами продуктів, підтримувати багатомовні запити та забезпечувати реальне аудиторське слідування.  

**Композиційна мікросервісна архітектура**, побудована навколо великих мовних моделей (LLM) та генерації з підкріпленням пошуком (RAG), пропонує спосіб масштабувати автоматизацію, зберігаючи гнучкість і управління, які вимагають регульовані галузі. У цьому посібнику ми:

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

> **TL;DR:** Розділіть платформу автоматизації анкет на маленькі, чітко визначені сервіси, розмістіть LLM за безстанним інференс‑шаром і використовуйте подієво‑орієнтовані конвеєри, щоб підтримувати єдине джерело правди для доказів і контролю версій.

---

## 1. Чому варто композувати, а не будувати величезний моноліт?

| Підхід моноліт | Композиційна мікросервісна архітектура |
|----------------|------------------------------------------|
| Один кодовий базис, важко масштабувати конкретні навантаження (наприклад, інференс LLM). | Незалежне масштабування – інференс ШІ може працювати на GPU‑нодах, а сховище залишатися на економічному об’єктному сховищі. |
| Тісне зв’язування ускладнює оновлення; помилка в UI може вивести з ладу всю систему. | Асинхронні події або HTTP‑API забезпечують слабке зв’язування, ізоляція збоїв. |
| Обмежена інтеграція між мовами – часто прив’язка до однієї технології. | Підтримка багатьох мов – кожен сервіс може писатися на найкращій для завдання мові (Go для автентифікації, Python для оркестрації LLM, Rust для високопродуктивних конвеєрів). |
| Аудит і відповідність стають кошмаром, бо журнали змішані. | Центральне сховище подій + незмінний журнал аудиту забезпечують чіткий, запитуваний слід для регуляторів. |

**Композиційна** модель втілює філософію *«будуйте лише те, що потрібно, і замінюйте те, що не потрібно»*. Вона відповідає динамічній природі анкет безпеки, де нові контрольні рамки (наприклад, [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) з’являються регулярно, а командам треба швидко адаптуватись.

---

## 2. Основні архітектурні стовпи

1. **Безстанний API‑шлюз** – вхідна точка для UI, SaaS‑конекторів та зовнішніх інструментів. Обробляє автентифікацію, валідацію запитів та дроселювання.  
2. **Мікросервіси, орієнтовані на домен** – кожен інкапсулює обмежений контекст:  
   * **Сервіс анкет** – зберігає метадані анкет, версіонування та розподіл завдань.  
   * **Сервіс доказів** – керує артефактами (політики, скріншоти, журнали аудитів) в незмінному об’єктному сховищі.  
   * **Сервіс оркестрації ШІ** – формує підказки, запускає RAG‑конвеєри та повертає чернетки відповідей.  
   * **Сервіс виявлення змін** – спостерігає за оновленнями доказів, ініціює переоцінку уражених відповідей.  
   * **Сервіс сповіщень** – надсилає події у Slack, Teams або електронну пошту.  
3. **Шина подій (Kafka / Pulsar)** – гарантує доставку «принаймні один раз» доменних подій (наприклад, `EvidenceUploaded`, `AnswerDrafted`).  
4. **Стек спостережуваності** – трасування OpenTelemetry між сервісами, метрики Prometheus, журнали Loki.  
5. **Двигун «Policy‑as‑Code»** – перевіряє правила відповідності (написані у Rego або OPA) перед позначенням відповіді як «кінцевої».  

Всі сервіси спілкуються через **gRPC** (для низької затримки) або **REST** (для зовнішніх інтеграцій). Дизайн підкреслює *«дурні труби, розумні кінцеві точки»* – логіка бізнесу розташована там, де їй місце, а шина просто переносить повідомлення.

---

## 3. Потік даних – від питання до аудиторської відповіді

Нижче наведено діаграму Mermaid, що візуалізує типовий життєвий цикл запиту.

```mermaid
flowchart TD
    subgraph UI["User Interface"]
        UI1["\"Web UI\""] -->|Submit questionnaire| AG["\"API Gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Questionnaire Service\""]
    QMS -->|Fetch template| AIOS["\"AI Orchestration Service\""]
    AIOS -->|Retrieve relevant evidence| ES["\"Evidence Service\""]
    ES -->|Evidence objects| AIOS
    AIOS -->|Generate draft answer| RAG["\"RAG Pipeline\""]
    RAG -->|LLM output| AIOS
    AIOS -->|Store draft| QMS
    QMS -->|Emit AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Trigger| CDS["\"Change‑Detection Service\""]
    CDS -->|Re‑run if evidence changed| AIOS
    CDS -->|Emit AnswerUpdated| EB
    EB -->|Notify| NS["\"Notification Service\""]
    NS -->|Push to Slack/Email| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px
```

**Ключові моменти потоку**:

1. Користувач надсилає нову анкету або вибирає існуючу.  
2. **API‑шлюз** перевіряє JWT, контролює дроселювання, переспрямовує запит до сервісу анкет.  
3. **Сервіс анкет** отримує шаблон анкети й генерує подію для сервісу оркестрації ШІ.  
4. **Оркестрація ШІ** виконує *крок пошуку* – запитує сервіс доказів про всі артефакти, що стосуються поточного контрольного питання (за допомогою векторного пошуку або ключових слів).  
5. Отриманий контекст і шаблон підказки надходять у **конвеєр RAG** (наприклад, `openAI/gpt‑4o‑preview`).  
6. Чернетка відповіді зберігається назад у сервісі анкет, позначається як *«очікує перегляду»*.  
7. **Сервіс виявлення змін** стежить за новими завантаженнями доказів. Якщо політика оновлюється, він повторно запускає RAG‑конвеєр для уражених відповідей.  
8. Після затвердження рецензентами, **двигун Policy‑as‑Code** перевіряє, чи відповідає відповідь усім правилам, перед записом у незмінний журнал аудиту.  

---

## 4. Технічні деталі реалізації

### 4.1. API‑шлюз (Envoy + OIDC)

* **Маршрутизація** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **Безпека** – примусові області (`questionnaire:write`).  
* **Дроселювання** – 100 запитів/хв на тенанта, щоб захистити витрати на LLM.

### 4.2. Сервіс анкет (Go)

```go
type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}
```

* PostgreSQL для реляційних даних, **EventStoreDB** для доменних подій.  
* gRPC‑методи `GetTemplate`, `SaveDraft`, `FinalizeAnswer`.

### 4.3. Сервіс доказів (Python + FastAPI)

* Файли зберігаються в **MinIO** або **AWS S3** з шифруванням на рівні бакету.  
* Індексує вміст у **Qdrant** (векторна БД) для пошуку схожості.  
* REST‑endpoint `POST /search` приймає запит і повертає top‑k ідентифікаторів артефактів.

### 4.4. Сервіс оркестрації ШІ (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
    Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – комбінує векторний пошук і системну підказку, що інструктує модель цитувати ідентифікатори доказів.  
* **Кешування** – зберігає згенеровані відповіді 24 год для уникнення дублювання LLM‑запитів.

### 4.5. Сервіс виявлення змін (Rust)

* Підписується на події `EvidenceUploaded`.  
* Обчислює **хеш** нового артефакту та порівнює його з існуючими, що прив’язані до кожного контрольного питання.  
* Якщо різниця перевищує поріг, публікує `AnswerRequiresRegen`.

### 4.6. Сервіс сповіщень (Node.js)

* Слухає `AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`.  
* Форматує повідомлення для Slack, Teams або електронної пошти.  
* Підтримує **детупікацію** – сповіщає лише один раз per зміна per анкета.

---

## 5. Безпека та управління

| Питання | Заходи |
|----------|--------|
| **Протікання даних** – підказки LLM можуть містити конфіденційну інформацію. | Використовувати **локальну інференс‑систему** (наприклад, Llama 3.2) у VPC. Маскувати PII перед передачею в зовнішні API. |
| **Неавторизований доступ до доказів** | Надавати деталізовані ACL за допомогою OPA‑політик у сервісі доказів. |
| **Зміщення моделі** – якість відповідей падає. | Планувати **регулярну оцінку** з використанням контрольного корпусу та оновлювати підказки. |
| **Аудитність** | Кожен стан зберігається в незмінному журналу подій на **WORM S3**. |
| **Відповідність GDPR/CCPA** | Реалізувати **право на забування**: стирати користувацькі дані з векторної БД та об’єктного сховища ([GDPR](https://gdpr.eu/)). |
| **ISO 27001** | Перевірити, що політики зберігання, шифрування та контролю доступу відповідають стандарту ISO 27001. |
| **HIPAA / SOC 2** | Розширити OPA‑правила для задоволення вимог HIPAA або SOC 2 у відповідних секторах. |

---

## 6. Стратегії масштабування

1. **Горизонтальне автоскейлінг (HPA)** – масштабувати підсервіси оркестрації ШІ за використанням GPU (`nvidia.com/gpu`).  
2. **Черги з бустером** – використати розділення тем у Kafka для ізоляції навантаження високих тенантів.  
3. **Зниження холодного старту** – підтримувати «теплий пул» контейнерів інференс‑сервера (наприклад, через **KEDA** із кастомним скейлером).  
4. **Контроль витрат** – впровадити **бюджет токенів** на тенанта; автоматично дроселювати або стягувати оплату за перевищення.

---

## 7. Спостережуваність та безперервне удосконалення

* **Трасування** – OpenTelemetry‑спани від UI‑запиту → API‑шлюз → оркестрація ШІ → RAG → сервіс доказів.  
* **Метрики** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **Журнали** – Структуровані JSON‑журнали з `request_id`, що поширюються між сервісами.  
* **Зворотний зв’язок** – Після фіналізації відповіді збирати коментарі рев’юера (`review_score`). Використовувати їх у **RL‑моделі**, що коригує температуру підказки чи підбирає альтернативні джерела доказів.

---

## 8. Поступовий план міграції для існуючих команд

| Фаза | Ціль | Дії |
|------|------|-----|
| **0 – Дослідження** | Карта поточного процесу заповнення анкет. | Ідентифікувати джерела даних, сформувати таксономію контролів. |
| **1 – Побудова фундаменту** | Розгорнути API‑шлюз, автентифікацію та базові сервіси. | Контейнеризувати `questionnaire-service` і `evidence-service`. |
| **2 – Впровадження ШІ** | Запустити RAG на пілотній анкеті. | Використати пісочницю LLM, вручну перевіряти чернетки. |
| **3 – Автоматизація подій** | Підключити конвеєр виявлення змін. | Увімкнути автоматичний перезапуск на оновлення доказів. |
| **4 – Жорстка відповідність** | Додати OPA‑політики, незмінний журнал аудиту. | Перейти на продукційний локальний LLM. |
| **5 – Масштаб та оптимізація** | Автоскейл GPU‑поди, впровадити контроль витрат. | Розгорнути стек спостережуваності, задати SLO. |

Інкрементальна адаптація композиційної архітектури дозволяє уникнути ризику «одного великого кидка» і демонструє ранню поверненість інвестицій (зазвичай **30‑50 % скорочення** часу відповіді на анкети).

---

## 9. Підготовка до майбутнього

* **Федероване навчання** – тренувати легковагові адаптери на даних кожного тенанта, не переміщуючи сирі докази, підвищуючи релевантність відповідей і дотримуючись суверенітету даних.  
* **Zero‑Trust Service Mesh** – використати **Istio** або **Linkerd** з mTLS для захисту внутрішнього трафіку.  
* **Семантичне управління** – розширити двигун Policy‑as‑Code, щоб перевіряти не лише вміст відповіді, а й **семантичну схожість** між доказами та формулюванням контролю.  
* **Генеративна трасованість** – зберігати точну температуру, top‑p та системну підказку разом з кожною відповіддю для форензіки.

---

## 10. Висновок

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

* Відповідати на запити постачальників за хвилини, а не за дні.  
* Підтримувати актуальність доказів за допомогою автоматичного виявлення змін.  
* Надавати регуляторам чіткий, незмінний журнал аудиту.  

Починайте з малого, швидко ітераціонуйте, і нехай принципи мікросервісної архітектури ведуть вас до майбутнього, де відповідність — це **функція**, а не «вузька місце».  

---

## Дивіться також

- [OPA Policy‑as‑Code для мікросервісів](https://www.openpolicyagent.org/docs/latest/policy-language/)