skip to content
Q
Table of Contents

배경

현재 우리 만들고 있는 서비스는 chrome extension에서 요청을 보내면 NestJS 백엔드 서버에서 LangGraph로 글을 생성 후 반환한다.

백엔드 NestJS 서버는 AWS App Runner에 배포되어 있는 상태이다.

클라이언트-서버의 연견 관계가 동기처리가 되고 있다.

문제 발생

글 생성 요청을 백엔드로 보내면 갑자기 503에러가 발생하고 에러 메시지는 upstream request timeout이 발생했다. 근데 이런 에러가 발생할 때도 있고 안할 때도 있다. timeout이니깐 결국 무슨 시간이 많이 걸릴 것 같아서. AI에게 ‘해줘’ 시전을 했다.

그랬더니 그냥 아래와 같이 코드를 추가해줬다.

// 서버 타임아웃 설정 (긴 생성 작업 지원)
const server: any = app.getHttpServer();
if (server && typeof server.setTimeout === 'function') {
// 요청 처리 타임아웃(비활동) 연장
server.setTimeout(15 * 60 * 1000); // 15분
}
// keep-alive/헤더 타임아웃 조정 (ALB/Nginx 504 예방)
if (server) {
// 헤더 수신 대기시간은 keepAliveTimeout보다 커야 함
server.keepAliveTimeout = 61 * 1000; // 61초
server.headersTimeout = 65 * 1000; // 65초
// Node18+: requestTimeout이 기본 5분인 경우가 있어 늘려줌
if (typeof server.requestTimeout === 'number') {
server.requestTimeout = 15 * 60 * 1000; // 15분
}
}

나는 ‘그냥 해주겠지~‘라는 마인드로 그냥 커밋하고 PR 날렸다. 물론 로컬에서 테스트했을 때는 해결이 되니 다시 PR을 올린거다.

나의 부족함

근데 배포 환경에서는 에러가 여전히 발생했다. 왜 계속해서 의문이 있어서 구글링을 했다.

App Runner에 배포했으니깐 해당 관련해서 좀 찾아보면 되지 않을 까 싶었다.

AWS App Runner 공식문서를 뒤적이니깐 120s limit이 있었다.

결국 나는 현재 배포 서버에 대한 이해없이 코드만 수정하다 실패를 보았다. LLM한테 그저 ‘고쳐줘’라는 말 밖에 못하니 발생한 거다.

그럼 어떻게 해결하나

결국 120초의 한계를 벗어날 수가 없다.

선택지는 몇개 있었는 것 같다.

  1. 웹소켓 통신
  2. 스트리밍 통신
  3. 비동기 처리후 클라이언트에서 pulling 요청

당장 내가 가진 지식내에서는 3번이라 생각했다. 글 생성 요청 후 먼저 완료 메시지를 반환한다. 그 이후에 글 생성은 비동기로 처리하고 클라이언트에서 일정 시간마다 요청을 보내서 완료됨을 확인하면된다.

비동기 처리는 어떻게 하냐

비동기 처리에도 여러가지 방법이 보였는 데, 간단하게 메시지 큐(SQS, BullMQ, Kafka), 로컬 비동기 처리(setImmediate)

당장 내 상황에서 trade-off가 있는 것 같다. 당연히 현직자 분들이나 개발 고수님들은 메시지 큐를 쓸 것이다. 하지만! 나는 개발 초보다…

당장 메시지 큐를 공부해야하고 이걸 다시 인프라 구축까지 하기에는 어려움이 있었다. redis cloud 쓰면..큼큼

그래서 배포하는 과정에 AWS App Runner가 비동기 처리를 하고 있다면, 그냥 날라가는 것이지만 setImmediate로 처리했다.

앞으로는?

지금 당장에는 유저가 10명도 안되니 임시 방편으로 땜빵했는 데, 빨리 공부해서 변경해야겠다. 추가적으로 setImmediate에 대한 것도 글을 쓰겠다.

오늘의 교훈

로컬은 배포랑 다르다. 배포 환경에 대한 이해를 합시다.