이전 글에서 BullMQ가 어떤 구조로 동작하는지, 왜 사용하는지에 대해 정리해봤습니다. 이번 글에서는 NestJS에서 BullMQ를 사용하는 방법에 대해 살펴보겠습니다. 1. @nestjs/bullmqNestJS는 BullMQ를 공식적으로 지원하며, `@nestjs/bullmq` 패키지를 사용하면 간단하게 연동할 수 있습니다.설치먼저 BullMQ 관련 패키지를 설치합니다.$ pnpm install @nestjs/bullmq bullmq BullMQ는 Redis 기반으로 동작하기 때문에, 실행 환경에 Redis가 먼저 실행되어 있어야 합니다. 저는 Docker 통해 실행하였습니다.$ docker pull redis:latest$ docker run -d -p 6379:6379 --name redis re..

최근에 진행 중인 프로젝트에 LLM 기반의 챗봇 기능을 추가하게 되었습니다. 사용자 맞춤형 상담을 제공하기 위해, 미리 정의된 프롬프트와 함께 고급 추론이 가능한 모델을 호출하는 방식으로 구현하게 되었습니다. 그런데 실제로 서비스를 붙여보니, 모델의 응답 시간이 짧게는 1분, 길게는 3분 이상 걸리는 경우도 있었습니다. 단일 요청으로 처리하기에는 너무 긴 시간이었고, 이로 인해 시스템 응답성과 리소스 관리에 고민이 생기기 시작했습니다.처음에는 웹 소켓을 이용한 실시간 통신 방식도 고려했지만 모델 응답 시간이 길다 보니, 클라이언트를 계속 대기시키는 구조는 적절하지 않았고, 서버에서 작업이 완료되었을 때 클라이언트에 알림을 보내는 방식이 필요하다고 생각했기 때문입니다. 하지만 LLM 연동 자체도 처음이었고..

API를 개발하다 보면, 프론트엔드나 외부 서비스가 연동할 수 있도록 요청과 응답의 형식이 명확하게 정의된 API 문서를 제공해야 합니다. 이때 사용되는 대표적인 도구가 바로 Swagger입니다.NestJS 프레임워크는 이를 위해 공식적으로 Swagger 모듈(@nestjs/swagger)을 제공하고 있으며, 간단한 데코레이터만 추가하면 DTO와 라우터 정보를 바탕으로 자동으로 API 문서를 생성해줍니다. 덕분에 문서화에 따로 시간을 들이지 않고도, 실시간으로 최신 API 문서를 유지할 수 있어 매우 편리합니다.저도 그래서 Swagger 모듈을 사용하여 API 문서를 제공하고 있습니다. 그런데 최근에 서로 다른 모듈에서 동일한 이름의 DTO를 사용하는 상황에서 Swagger 문서에 한쪽 정보만 표시되는 ..

앞선 글에서는 API 요청 수를 지표로 수집했지만, 이 수치만으로는 서비스의 정상 여부를 판단하기 어렵다는 한계가 있습니다. 예를 들어 요청 수는 꾸준히 늘고 있지만, 그 중 절반이 500 에러라면 단순 요청 수만 봐서는 문제를 인지하지 못할 수 있습니다.이럴 때는 HTTP 응답 상태 코드별로 요청 수를 분류해 지표를 수집하면, 에러 비율이나 특정 상태 코드의 급증 여부를 통해 보다 정밀한 모니터링이 가능해집니다. 1. MetricInterceptor 수정하기앞선 글에서 만들었던 MetricInterceptor는 단순히 API 요청 수만 기록하도록 구현되어 있었습니다. 이제 여기에 HTTP 응답 상태 코드를 함께 수집할 수 있도록 로직을 확장해보겠습니다. [metric.interceptor.ts]impo..

모니터링은 서비스의 상태와 이상 징후를 파악하고, 문제 발생 시 빠르게 대응하기 위한 인프라 운영에 필수적인 부분입니다. 이러한 모니터링을 위해 가장 필요한 것은 지표(Metric)입니다. 예를 들어, API 요청 수, 응답 시간, 에러 비율, CPU 사용량, 메모리 사용량 등이 대표적인 지표에 해당합니다.앞선 글에서 설명한 것처럼 AWS에서는 CloudWatch를 통해 기본적인 지표들을 바로 확인할 수 있으며, EC2에 애플리케이션을 배포한 경우 CloudWatch Agent를 설치하여 추가적인 시스템 지표도 수집할 수 있습니다.하지만, API 요청 수나 응답 시간, 레이턴시와 같은 애플리케이션 레벨 지표는 CloudWatch Agent를 연동하더라도 수집할 수 없습니다. CloudWatch Agent..

모니터링은 안정적인 인프라 운영에 매우 중요한 부분입니다. 서비스에 문제가 발생하면 사용자는 서비스를 이용할 수 없게 되고, 그 영향이 연관된 다른 서비스로 번지며 더 큰 장애로 이어질 수 있습니다. 더 나아가, 발생한 문제를 수습하는 데는 많은 시간과 비용이 들기 때문에 사후 대응보다는 사전 탐지와 예방이 훨씬 중요합니다. 이를 위해 우리는 모니터링을 통해 시스템의 상태를 지속적으로 관찰하고, 문제가 발생하기 전의 이상 징후를 빠르게 파악하여 미리 대응할 수 있어야 합니다.이번 글에서는 AWS에서 EC2 인스턴스를 모니터링하기 위해 CloudWatch Agent를 설정하는 방법과, 수집된 데이터를 바탕으로 CloudWatch 대시보드를 구성하는 방법에 대해 단계별로 설명합니다. 1. CloudWatch..