Єдиний бекенд переставав справлятися зі зростанням бізнесу в галузі охорони здоров'я та харчування. Трафік AI чат-ботів, інтенсивне надходження даних з носійних пристроїв та щоденні запити API — все це конкурувало за одні й ті самі ресурси, що ускладнювало масштабування системи та робило її впровадження ризикованим. Ми переробили її в сфокусовані, незалежно розгортані сервіси, організовані за єдиним API gateway, що працюють на AWS.
Виклик
- Одна кодова база, що виконує всі завдання. Один робочий процес включав управління користувачами, AI chatbot виведення даних, рецепти та аналітику даних про здоров'я. Сплеск у будь-якій з цих областей погіршував роботу всієї платформи, а кожна зміна означала повторне розгортання всього.
- Надзвичайно різні профілі ресурсів. Запити чат-ботів на базі LLM вимагають багато CPU та пам'яті і є нерівномірними; надходження даних з носійних пристроїв інтенсивно записує дані та є безперервним; базові CRUD APIs є легкими та постійними. Виділення одного сервера для всіх трьох означало переплату за одні робочі навантаження та недостатнє забезпечення інших.
- Незалежне масштабування та розгортання. Команда потребувала масштабувати робоче навантаження AI, не зачіпаючи основного API, і впроваджувати зміни в одній домені, не ризикуючи іншими.
Єдина, безпечна точка входу. Незважаючи на численні backend сервіси, клієнтам (мобільні, веб, адміністративні) потрібна була одна узгоджена, автентифікована поверхня для взаємодії — без витоку внутрішньої топології сервісів у зовнішній світ.
Наше рішення
Ми розділили платформу на три сфокусовані NestJS сервіси за AWS Application Load Balancer, при цьому головний сервер виступає як API gateway та оркестратор. Він відповідає за автентифікацію та основні домени, а спеціалізовану роботу делегує чат-боту та медичним microservices через автентифікований REST. Спільний шар даних та обміну повідомленнями підтримує слабку зв'язаність, але водночас узгодженість сервісів.
Архітектура
- Головний сервер (NestJS) — API gateway та оркестратор: автентифікація, користувачі, цілі, рецепти, планування та сповіщення. Усі клієнти мають єдину публічну точку входу.
- Chatbot Microservice (NestJS) — AI розмовний сервіс, що працює на Azure OpenAI (GPT-4o) через LangChain/LangGraph, з RAG на базі Elasticsearch для пошуку рецептів та знань.
- Health Microservice (NestJS) — приймає та агрегує дані про здоров'я з носійних та ручних пристроїв (Apple Health, Health Connect) та надає аналітику.
- AWS ECS Fargate запускає три контейнеризовані сервіси, кожен зі своєю власною конфігурацією CPU/memory та політикою масштабування.
- Application Load Balancer завершує HTTPS-з'єднання та маршрутизує трафік за шляхом до відповідного сервісу.
- Спільний шар даних — MongoDB Atlas (основне сховище), Redis (кеш/сесії), Elasticsearch (пошук), ActiveMQ (асинхронна доставка сповіщень).
CI/CD — Docker багатостадійні збірки, завантажені в Amazon ECR, розгортаються на ECS як rolling updates.
Ключові особливості
1. Шаблон оркестратора. Головний сервер є єдиним сервісом, доступним для клієнтів. Він автентифікує кожен запит, а потім здійснює внутрішні виклики між сервісами — таким чином топологія backend залишається приватною, а інтеграція клієнтів простою.
2. Автентифіковані виклики між сервісами. Зв'язок між сервісами здійснюється через REST поверх спільного HTTP client, захищений bearer API keys для кожного сервісу:
// Головний сервер делегує запит AI до microservice чат-бота const reply = await this.microserviceClient.post( this.chatbotApiKey, // bearer key для кожного сервісу `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. Незалежне масштабування для кожного робочого навантаження. Кожен сервіс є окремою Fargate task definition зі своєю власною конфігурацією — chatbot сервіс, що вимагає багато пам'яті, масштабується незалежно від легкого основного API, тому сплески трафіку AI ніколи не перевантажують повсякденні запити.
4. AI сервіс з оптимальним розміром та вбудованою стійкістю. Сервіс чат-бота обертається між кількома Azure OpenAI ключами, автоматично переключаючись у разі перевищення лімітів запитів або помилок — підтримуючи AI функції чутливими під навантаженням.
5. Сповіщення через асинхронний обмін повідомленнями. Оскільки ActiveMQ delay queues відокремлюють часові нагадування та повідомлення від потоку запитів, доставка сповіщень ніколи не перешкоджає і не уповільнює основний трафік API.
6. Повторювані, ізольовані розгортання. Від ECR до ECS, кожен сервіс поставляється як окремий Docker image. Зміна в health service просто розгортає health service повторно — швидкі, низькоризикові релізи з rolling updates, які проходять перевірку стану.
7. Єдиний узгоджений клієнтський контракт. Мобільні клієнти (React Native) та адміністративна панель взаємодіють з єдиною, балансувальною, HTTPS точкою входу — внутрішній поділ на microservices для них невидимий.
Результати
- Сьогодні робочі навантаження для AI чат-ботів, даних про здоров'я та основних API масштабуються окремо; жодне завдання не може погіршити інші.
- Кожен сервіс розгортається самостійно, перетворюючи ризиковані релізи по всій платформі на швидкі, ізольовані оновлення.
- Обчислювальні ресурси оптимізовано під кожен сервіс, що усуває надлишкове виділення ресурсів для універсального сервера.
- Єдина безпечна, балансувальна точка входу спрощує інтеграцію клієнтів, тоді як backend залишається приватним та модульним.
Стек технологій
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Інші блоги
1. How We Scale Video Processing Workloads with AWS ECS
2. How We Use AWS ECR to Manage and Deploy Container Images
3. How We Use AWS EC2 for Workloads in High-Performance Video
