Чому архітектура AI відрізняється від класичних застосунків
Системи AI мають специфічні вимоги, які відрізняють їх від типових веб-застосунків. Моделі мови вимагають значних обчислювальних ресурсів, але не завжди і не всюди. Різні компоненти системи мають діаметрально різні профілі навантаження: модуль висновків GPU є вузьким місцем ресурсів, шар API повинен обробляти тисячі паралельних запитів, а процеси навчання працюють пакетно і можуть тривати години. Архітектура повинна враховувати це.
Аргументи на користь моноліту на старті
Більшість проектів AI повинна розпочинатися як моноліт. Причини є простими: монолітна архітектура простіша у налагодженні, легша для розуміння новою командою і швидша в ітераціях. Коли система знаходиться в експериментальній фазі і межі між компонентами ще формуються, передчасний поділ на мікросервіси приносить більше шкоди, ніж користі.
Класичною помилкою є проектування десятків мікросервіси до того, як система обслужить першого реального користувача. Невідомі закономірності використання перекладаються на помилкові межі сервісів, які потім генерують величезні витрати на рефакторинг.
Коли мікросервіси є правильним вибором
Міграція до мікросервіси має сенс, коли з'являються конкретні, вимірювані проблеми з монолітом:
- Різні вимоги масштабування: модуль OCR вимагає в 10 раз більше ресурсів під час кампанії, а решта системи залишається стабільною.
- Незалежні цикли впровадження: команда моделей ML впроваджує нові версії кілька разів на день, а зміни в модулі звітності раз на місяць.
- Ізоляція аварій: помилка в одному компоненті не повинна переривати роботу інших.
- Різні технологічні стеки: модуль обробки зображень вимагає бібліотек Python, недоступних у основному стеку.
Стратегії міграції з моноліту
Безпечна міграція базується на шаблоні Strangler Fig: поступовому вирізанні функціональності з моноліту та заміні її незалежними сервісами, при збереженні робочої системи протягом усього часу. Ключем є ідентифікація природних доменних кордонів: не штучний розріз по технічних лініях, а поділ, узгоджений з логікою бізнесу.
Першим кандидатом на виділення повинно бути компонент, який: добре визначений функціонально, має чітке та стабільне API, генерує найбільше проблем через різницю в вимогах масштабування. Зазвичай це саме модуль висновку моделей AI.
Оркестрація багатокомпонентна та архітектура сервісів
Системи багатокомпонентні ESKOM AI діють на рівні вище традиційних мікросервісів: окремі агенти AI можуть використовувати як монолітне бізнес-додаток, так і екосистему мікросервісів. Ключовим є проектування інтерфейсів так, щоб внутрішня архітектура цільової системи не обмежувала можливостей інтеграції з логікою агентів.