AI 리포트 시스템 아키텍처: SQS 기반 비동기 처리 구조 완전 정리

Published by

Steve Kim

on

2025년 11월 20일

AI 기반 리포트 생성 서비스에서 가장 중요한 요소는 안정적이고 확장 가능한 비동기 처리 구조를 어떻게 설계하느냐이다. 이 글에서는 AWS SQS를 중심으로 요청/응답 큐 구조, DLQ 활용법, 확장 전략, RabbitMQ 대비 비용 비교, 표준 메시지 스키마까지 한 번에 정리한다. 실제 서비스 아키텍처에 바로 적용할 수 있는 구성이다.

1. 전체 아키텍처

이 시스템은 클라이언트 요청 → 중계 서버 → SQS 요청 큐 → AI 워커 → SQS 응답 큐 → 중계 서버 → 클라이언트, 이렇게 흐른다.

Client
  ↓ REST API
Gateway / 중계 서버
  ↓ SQS (Request Queue)
AI Report Workers (A/B/C) — EC2 또는 ECS
  ↓ SQS (Response Queue)
Gateway / 중계 서버 (결과 수집)
  ↓
Client (비동기 조회 또는 웹훅)

핵심 포인트:

중계 서버는 요청 수집과 결과 집계에만 집중
AI Report 워커는 SQS polling 기반
클라이언트는 비동기 조회 API 또는 웹훅 방식으로 결과 수신

2. 큐 개수 설계 — 초기 구성과 확장 구성

초기 구성(가장 현실적)

Request Queue 1개
Response Queue 1개
각 큐당 DLQ 1개 → 총 4개

AWS SQS는 큐 개수 자체로 비용이 늘지 않는다. 비용은 요청 수(Request Count) 기반이라 초기에는 이 구성이 가장 효율적이다.

확장 구성(트래픽 증가 시)

Report A/B/C 별도 Request Queue → Request(3) + Response(1) + DLQ(4) = 총 8개

이렇게 분리하면 “특정 리포트 타입이 폭주할 때 전체 시스템에 영향을 주지 않도록” 격리하는 효과가 있다.

3. 표준 메시지 스키마 설계

요청 메시지(Request)

{
  "requestId": "uuid-1234",
  "reportType": "A",
  "payload": {},
  "clientId": "user-999",
  "createdAt": "2025-11-19T10:00:00Z"
}

응답 메시지(Response)

{
  "requestId": "uuid-1234",
  "reportType": "A",
  "status": "DONE",
  "result": {
    "s3Url": "...",
    "durationMs": 3200
  }
}

설계의 핵심:

requestId: 요청/응답 매칭을 위한 primary key
reportType: 워커 라우팅을 위한 타입 구분
payload: 처리 대상 데이터
clientId: 사용자를 식별하여 모니터링·로깅 가능

4. SQS Standard Queue vs FIFO Queue — 선택 기준

AWS 공식 문서 기준:

Standard Queue는 최대 처리량·중복 허용·순서 미보장,

FIFO Queue는 순서 보장·중복 제거·처리량 제한.

추천: Standard Queue

대부분의 AI Report 생성에는 순서 보장이 필요 없음
중복 메시지도 requestId 기반 idempotency로 처리 가능
처리량 제한이 없어 확장성 우수

FIFO Queue는 언제?

동일 사용자의 요청이 반드시 순서대로 처리되어야 하는 경우에만 고려

5. DLQ(Dead-Letter Queue)의 필요성

DLQ는 “문제가 있는 메시지”를 격리하는 용도로 필수적이다.

AWS 공식 권고 패턴이기도 하다.

DLQ로 보내는 대표 사례:

maxReceiveCount 초과 (지속 실패)
JSON 포맷 손상
requestId 누락 또는 유효하지 않음
reportType 오류
AI 워커 내부 예외 발생 반복

DLQ의 목적:

장애 메시지가 전체 큐를 막지 않도록 격리
실패한 메시지만 따로 분석·수동 재처리 가능

6. 비용 분석 — RabbitMQ vs AWS SQS

SQS 비용

100만 요청 무료
이후 $0.40 / 1,000,000 요청
대부분 서비스는 월 $1~$10 수준에서 끝남 → 사실상 거의 무료

참고:

AWS SQS 공식 요금: https://aws.amazon.com/sqs/pricing/

RabbitMQ 비용

Amazon MQ Managed RabbitMQ: 월 $600~$1,000 수준
직접 EC2에 설치해도 인스턴스 비용 + 운영 인력 비용 발생

결론

SQS가 월 단위 비용 효율성에서 압승이다.

7. 왜 RabbitMQ 대신 SQS를 선택해도 문제 없는가?

네 서비스는 동적 큐 생성/삭제가 필수 조건이 아님
요청/응답 구조는 Request Queue + Response Queue + requestId면 충분
타입 구분은 reportType attribute 또는 큐 분리로 해결됨
운영·비용·안정성 측면에서 SQS가 훨씬 단순하고 유지보수가 적음

8. 최종 아키텍처 구성안

1. 큐 구성

ReportsRequestQueue
ReportsResponseQueue
ReportsRequestQueueDLQ
ReportsResponseQueueDLQ

2. AI Report Worker 구성

ECS/EC2 기반으로 Report A/B/C 각각 실행
단일 Request Queue poll
reportType 기반 라우팅
트래픽 증가 시 큐를 타입별로 분리

3. Gateway / 중계 서버

REST 입력 → RequestQueue push
ResponseQueue poll → requestId 기준으로 결과 집계
DB 저장 후 클라이언트에 비동기 조회 API 제공 또는 웹훅 전달

최종

초기에는 “요청/응답 큐 + DLQ” 구조로 단순하게 시작하고, 트래픽 증가 시 reportType별로 큐 분리하면 된다. SQS는 비용이 거의 없고, 이 아키텍처에 가장 적합한 선택이다.