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

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

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

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

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

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

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

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, що візуалізує типовий життєвий цикл запиту.

  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)

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)

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. Безпека та управління

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. Поступовий план міграції для існуючих команд

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

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

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

10. Висновок

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

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

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

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

• OPA Policy‑as‑Code для мікросервісів