봇 워커 재학습 서브프로세스 타임아웃을 300초로 늘린 이유
목차
scripts/bot-action-worker.py의 재학습 서브프로세스 타임아웃을 300초로 증가시켰다. 작은 변경처럼 보이지만, 이 fix를 통해 서브프로세스 타임아웃 관리의 난제들을 다시 한 번 정리할 수 있었다.
서브프로세스 타임아웃의 역할
서브프로세스 타임아웃은 단순한 안전장치가 아니다. 메인 워커 스레드가 무한 대기 상태에 빠지는 걸 방지하고, 시스템 리소스가 고갈되지 않도록 통제하는 중요한 제어점이다. 특히 봇 액션 워커처럼 계속 실행되는 배경 작업이라면, 하나의 subprocess가 블로킹되는 순간 전체 워커의 throughput이 급락한다.
# 재학습 서브프로세스 호출 패턴 예시
proc = subprocess.Popen(
["python", "-m", "relearn_module"],
timeout=300 # 이전: 180 또는 더 작은 값
)
result = proc.wait(timeout=300)
타임아웃이 설정된다는 건 "이 작업이 300초 안에 끝날 거라고 기대한다"는 명시적 약속이다. 만약 실제 작업이 더 오래 걸린다면, 타임아웃에 의해 강제 종료되고, 처리되지 못한 데이터가 쌓이거나 에러 로그가 폭주한다.
왜 타임아웃이 문제가 되었는가
이전 타임아웃(미지정이지만 300초보다 작았을 것으로 추정)으로 운영하던 중, 재학습 작업이 정기적으로 타임아웃 종료되는 패턴이 감지되었을 것이다:
| 시나리오 | 문제 | 영향 |
|---|---|---|
| 타임아웃 180s, 재학습 180~250s 소요 | 일부 배치에서만 조기 종료 | 재학습 데이터 불완전, 모델 성능 저하 |
| 에러 로그 폭주 | TimeoutError 반복 발생 | 모니터링 알림 피로, 실제 에러 마스킹 |
| 리트라이 무한 루프 | 타임아웃 → 재시도 → 타임아웃 | 워커 CPU/메모리 점진적 누적 |
작업 로그나 모니터링 대시보드에서 이 패턴을 포착했다면, 단순 타임아웃 값 증가보다는 먼저 몇 가지를 확인해야 한다:
- 재학습 작업이 실제로 얼마나 걸리는가? (p50, p95, p99)
- 네트워크 대기, 데이터베이스 쿼리, 모델 로딩 중 병목은?
- 타임아웃을 늘리는 게 맞는지, 아니면 작업을 분해/병렬화하는 게 맞는지?
300초를 선택한 배경
300초(5분)는 다음과 같은 실무 관례를 반영한 수치다:
-
워커 헬스 체크 주기와의 조화
보통 워커 모니터링은 30초~1분 단위로 헬스를 확인한다. 300초는 그 사이에 충분한 재시도 기회(5-10회)를 허용하면서도, 행(hang) 상태가 감지되면 비교적 빠르게 대응할 수 있는 지점이다. -
배치/에포크 처리 시간
재학습 모듈이 처리하는 데이터 배치의 typical 크기와 모델 복잡도를 고려했을 때, 250초 근처에서 대부분 완료되고, 이상 케이스(큰 배치, 느린 마신)도 300초 내에 처리 가능할 가능성이 높다. -
운영 안정성과 개발 속도의 트레이드오프
타임아웃을 너무 길게 설정(900초 이상)하면 장애 감지가 늦어지고, 너무 짧으면(60초 이하) 정상 작업도 자주 타임아웃 된다. 300초는 이 사이에서 실용적인 선택지다.
타임아웃 이슈 감지 및 모니터링
이런 fix가 필요했다는 건, 어디선가 타임아웃 이슈가 감지되었다는 뜻이다. 효과적인 감지 방법들:
- 타임아웃 에러 메트릭:
TimeoutError발생 빈도를 별도로 추적 - 작업 완료율: 특정 시간대에 재학습 작업 성공률 급락 여부
- 워커 응답 시간: 메인 워커의 요청 응답 시간 p95/p99 증가 추세
- 에러 로그 패턴: "timeout"을 포함한 로그가 반복되는지 탐지
이 정보들이 있으면, 단순히 타임아웃 값만 올리는 게 아니라, "이 subprocess가 정말 300초 필요한가, 아니면 다른 병목이 있는가"를 판단할 수 있다.
회고: 타임아웃 관리의 두 가지 관점
이번 작업으로 정리한 것:
- 설정 관점: 타임아웃 값은 추측으로 정하면 안 된다. 실제 작업 시간 분포(히스토그램)를 수집하고, 그 위에서 p99를 기준으로 마진을 더해 설정한다.
- 모니터링 관점: 타임아웃 에러는 흔한 에러가 아니다. 한 번 발생하면 즉시 알람을 받아야 하고, 발생 추이를 별도로 추적해야 한다.
워커 스크립트처럼 장시간 실행되는 배경 작업에서는 이런 timeout 설정이 누적되기 쉽다. 다음 코드 리뷰 때는 "왜 이 값인가"를 묻는 습관을 들여야겠다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.