성장하는 건강 및 영양 비즈니스에 단일 백엔드가 더 이상 감당할 수 없었습니다. AI 챗봇 트래픽, 방대한 웨어러블 데이터 수집, 일상적인 API 요청이 모두 동일한 리소스를 놓고 경쟁하면서 시스템 확장과 배포가 어려워지고 위험해졌습니다. 우리는 이 시스템을 AWS에서 실행되는 단일 API Gateway 뒤에 배치된 집중적이고 독립적으로 배포 가능한 서비스로 재설계했습니다.
당면 과제
- 모든 작업을 처리하는 단일 코드베이스. 하나의 워크플로는 사용자 관리, AI 챗봇 추론, 레시피, 건강 데이터 분석을 포함했습니다. 한 영역의 급증은 전체 플랫폼을 저하시켰고, 모든 변경은 전체를 재배포해야 함을 의미했습니다.
- 극도로 이질적인 리소스 프로필. LLM 기반 챗봇 요청은 CPU 및 메모리 사용량이 많고 버스트(bursty) 특성을 가지며, 웨어러블 데이터 수집은 쓰기 작업이 많고 지속적이며, 핵심 CRUD API는 가볍고 꾸준합니다. 세 가지 모두를 위한 하나의 서버를 크기 조정하는 것은 일부 워크로드에 과도하게 지불하고 다른 워크로드를 고갈시키는 것을 의미했습니다.
- 독립적인 확장 및 배포. 팀은 핵심 API에 영향을 주지 않고 AI 워크로드를 확장하고, 다른 영역에 위험을 초래하지 않으면서 하나의 도메인에 대한 변경 사항을 배포해야 했습니다.
단일하고 안전한 진입점. 여러 백엔드 서비스에도 불구하고 클라이언트(모바일, 웹, 관리)는 일관되고 인증된 단일 접점을 필요로 했습니다. 이는 내부 서비스 토폴로지가 외부에 노출되지 않도록 하는 것을 의미합니다.
우리의 솔루션
우리는 플랫폼을 세 가지 핵심 NestJS 서비스로 분할했으며, 이는 AWS Application Load Balancer 뒤에 위치하고 메인 서버는 API Gateway이자 오케스트레이터 역할을 합니다. 이 서버는 인증 및 핵심 도메인을 소유하고, 인증된 REST를 통해 챗봇 및 건강 마이크로서비스에 전문화된 작업을 위임합니다. 공유 데이터 및 메시징 계층은 서비스들을 느슨하게 결합하면서도 일관성을 유지하도록 합니다.
아키텍처
- 메인 서버 (NestJS) — API Gateway 및 오케스트레이터: 인증, 사용자, 목표, 레시피, 스케줄링 및 알림. 모든 클라이언트는 단일 공개 진입점을 가집니다.
- 챗봇 마이크로서비스 (NestJS) — LangChain/LangGraph를 통해 Azure OpenAI (GPT-4o)로 구동되는 AI 대화형 서비스로, 레시피 및 지식 검색을 위한 Elasticsearch 기반 RAG를 사용합니다.
- 헬스 마이크로서비스 (NestJS) — 웨어러블 및 수동 건강 데이터 (Apple Health, Health Connect)를 수집 및 집계하고 분석을 제공합니다.
- AWS ECS Fargate는 세 가지 컨테이너화된 서비스를 실행하며, 각 서비스는 자체 CPU/메모리 크기 조정 및 확장 정책을 가집니다.
- Application Load Balancer는 HTTPS를 종료하고 트래픽을 올바른 서비스로 경로 지정합니다.
- 공유 데이터 계층 — MongoDB Atlas (주 저장소), Redis (캐시/세션), Elasticsearch (검색), ActiveMQ (비동기 알림 전송).
CI/CD — Amazon ECR로 푸시된 Docker 멀티스테이지 빌드는 롤링 업데이트로 ECS에 배포됩니다.
주요 기능
1. 오케스트레이터 패턴. 메인 서버는 클라이언트에 노출되는 유일한 서비스입니다. 모든 요청을 인증한 후 내부 서비스 간 호출을 수행합니다. 따라서 백엔드 토폴로지는 비공개로 유지되고 클라이언트 통합은 단순합니다.
2. 인증된 서비스 간 호출. 서비스 간 통신은 공유 HTTP 클라이언트를 통한 REST이며, 서비스별 베어러 API 키로 보호됩니다:
// Main server delegating an AI request to the chatbot microservice const reply = await this.microserviceClient.post( this.chatbotApiKey, // per-service bearer key `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. 워크로드별 독립적인 확장. 각 서비스는 자체 크기 조정을 가진 별도의 Fargate 태스크 정의입니다. 메모리 사용량이 많은 챗봇 서비스는 경량 핵심 API와 독립적으로 확장되므로, AI 트래픽 급증이 일상적인 요청을 저하시키는 일이 없습니다.
4. 내장된 복원력을 갖춘 적절한 크기의 AI 서비스. 챗봇 서비스는 여러 Azure OpenAI 키를 순환하며, 속도 제한 또는 오류 발생 시 자동으로 페일오버하여 로드 상황에서도 AI 기능이 반응성을 유지하도록 합니다.
5. 비동기 메시징을 통한 알림. ActiveMQ 지연 큐가 시간 기반 알림 및 미리 알림을 요청 스트림과 분리하므로, 알림 전송이 핵심 API 트래픽을 방해하거나 늦추는 일이 없습니다.
6. 반복 가능하고 격리된 배포. ECR에서 ECS까지, 각 서비스는 자체 Docker 이미지로 배포됩니다. 헬스 서비스에 대한 수정은 단순히 헬스 서비스를 재배포하는 것으로, 헬스 체크가 포함된 롤링 업데이트를 통해 빠르고 위험 부담이 적은 릴리스가 가능합니다.
7. 일관된 단일 클라이언트 계약. 모바일 (React Native) 및 관리자 대시보드는 모두 단일 부하 분산된 HTTPS 진입점과 통신하며, 마이크로서비스로의 내부 분할은 클라이언트에게 보이지 않습니다.
결과
- 요즘에는 AI 챗봇, 건강 데이터 및 핵심 API 워크로드가 별도로 확장됩니다. 어떤 작업도 다른 작업의 성능을 저하시킬 수 없습니다.
- 각 서비스는 독립적으로 배포되어, 위험한 플랫폼 전체 릴리스를 빠르고 격리된 업데이트로 전환합니다.
- 각 서비스별로 컴퓨팅 자원이 적절하게 크기 조정되어, 모든 용도에 맞는 단일 서버의 과도한 프로비저닝이 제거되었습니다.
- 단일의 안전하고 부하 분산된 진입점은 클라이언트 통합을 단순하게 유지하는 동시에 백엔드는 비공개적이고 모듈식으로 유지됩니다.
기술 스택
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. AWS ECS로 비디오 처리 워크로드를 확장하는 방법
2. AWS ECR을 사용하여 컨테이너 이미지를 관리하고 배포하는 방법
3. 고성능 비디오 워크로드에 AWS EC2를 사용하는 방법
