리포트 생성 타임아웃 초과 위험 제거
목차
리포트 생성 작업이 간헐적으로 타임아웃 에러를 내던 문제를 대응했다.
배경: 여유 부족한 타임아웃의 위험성
리포트 생성은 대량의 데이터를 처리해 문서로 조합하는 무거운 작업이다. 이런 작업은 반드시 타임아웃을 설정해야 한다. 무한정 기다릴 수는 없으니까. 기존 타임아웃은 480초(8분)로 설정되어 있었는데, 실제 리포트 생성 소요 시간을 측정해보니 최대 약 4분 50초였다.
숫자만 보면 충분해 보인다. 하지만 여기에 함정이 있다:
- 여유가 극히 좁음: 4m50s 실측값에서 480s까지는 불과 10초 미만의 여유만 남는다.
- 운영 환경의 변동성: 피크 시간대 트래픽, 시스템 부하, DB 쿼리 성능에 따라 소요 시간이 수십 초 이상 변할 수 있다. 어느 날은 4m55s, 어느 날은 5m일 수도 있다.
- 외부 의존성의 불확실성: 리포트 데이터가 다양한 소스에서 오면, 네트워크 지연이나 I/O 경합으로 예상 밖 지연이 생긴다.
결과적으로 실제 운영에서 간헐적으로 사용자가 "타임아웃" 에러를 맞닥뜨렸던 것이다.
조치: 안전 마진을 확보한 타임아웃 상향
실측값 4m50s를 기준으로 src/lib/reading.ts의 타임아웃을 상향 조정했다. 이제 실제 측정값에 버스트와 변동성을 고려한 충분한 여유를 확보했다.
변경 내용:
| 항목 | 기존 | 이후 |
|-----|-----|-----|
| 타임아웃 설정값 | 480초 | 실측값 + 안전 마진 |
| 실측값 대비 여유 | ~10초 | 수십 초 이상 |
| 운영 변동성 수용 | 취약 | 견고 |
이 조정으로:
- 정상 작업은 충분한 시간 내에 완료된다
- 정말로 필요한 타임아웃(무한 루프, 데드락)은 여전히 감지된다
- 사용자가 겪는 간헐적 실패가 줄어든다
회고: 타임아웃 설정의 원칙들
이번 작업을 통해 "타임아웃 설정"이라는 작아 보이지만 실제로는 큰 결정임을 다시 느꼈다.
원칙 1: p99 값에 안전 마진을 더할 것
평균값이나 중앙값으로 타임아웃을 정하면 절대 안 된다. 최악의 경우(p99, p99.9)를 잡아야 하고, 거기에 다시 10~20% 정도의 추가 마진을 얹어야 한다. 운영 환경의 예측 불가능성은 항상 생각보다 크다.
원칙 2: 타임아웃은 지나치게 길게 설정하지 말 것
반대로 타임아웃을 너무 길게 두면 좀비 프로세스가 쌓이거나 누적된 요청으로 서버 리소스가 고갈된다. 예를 들어 리포트가 30분까지 대기할 수 있게 하면, 서버가 동시에 수백 개의 30분짜리 작업을 들고 있을 수 있다는 뜻이다. 따라서 필요한 만큼만, 그리고 "합리적인 범위 내"에서 정해야 한다.
원칙 3: 모니터링이 필수
타임아웃 값을 정하고 끝이 아니다. 운영 중에:
- 리포트 생성이 실제로 얼마나 걸리는지 (p50, p95, p99)
- 타임아웃으로 실패하는 비율은 얼마나 되는지
를 지속해서 추적해야 한다. 이상이 보이면 즉시 알림을 받아야 하고, 데이터를 토대로 다시 조정한다.
원칙 4: 팀과 함께 의사결정하기
타임아웃 값을 혼자 정해서 집어넣으면 안 된다. 왜냐하면:
- 타임아웃이 길어지면 평균 응답 시간과 서버 부하가 함께 커진다
- 팀의 리소스 계획이나 SLA와 연결되어 있다
- 비슷한 작업(다른 리포트, 배치 작업, 내보내기 등)에도 같은 원칙을 적용해야 하므로, 일관성 있는 정책이 필요하다
이번에는 실측 데이터를 정리한 후 팀과 논의해서 타임아웃을 조정했다. 이 과정 자체가 팀의 이해도를 높이고 비슷한 상황에서 스스로 판단할 수 있는 토대가 된다.
마무리
타임아웃처럼 "구현하면 잊혀지는" 설정들은 자주 무시된다. 일단 안정적으로 작동하는 동안은 누가 세세히 들여다보지 않기 때문이다. 하지만 한 번 문제가 터지면 사용자 경험과 팀의 신뢰가 함께 떨어진다. 앞으로는 리포트 생성 같은 무거운 작업들의 타임아웃과 성능을 정기적으로 검토하면서 여유를 확보하고, 팀 내에서 "타임아웃 설정 원칙"을 공유해 비슷한 실수를 줄여 나갈 것이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.