개발 slecs

봇 워커 재학습 서브프로세스 타임아웃을 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분)는 다음과 같은 실무 관례를 반영한 수치다:

  1. 워커 헬스 체크 주기와의 조화
    보통 워커 모니터링은 30초~1분 단위로 헬스를 확인한다. 300초는 그 사이에 충분한 재시도 기회(5-10회)를 허용하면서도, 행(hang) 상태가 감지되면 비교적 빠르게 대응할 수 있는 지점이다.

  2. 배치/에포크 처리 시간
    재학습 모듈이 처리하는 데이터 배치의 typical 크기와 모델 복잡도를 고려했을 때, 250초 근처에서 대부분 완료되고, 이상 케이스(큰 배치, 느린 마신)도 300초 내에 처리 가능할 가능성이 높다.

  3. 운영 안정성과 개발 속도의 트레이드오프
    타임아웃을 너무 길게 설정(900초 이상)하면 장애 감지가 늦어지고, 너무 짧으면(60초 이하) 정상 작업도 자주 타임아웃 된다. 300초는 이 사이에서 실용적인 선택지다.

타임아웃 이슈 감지 및 모니터링

이런 fix가 필요했다는 건, 어디선가 타임아웃 이슈가 감지되었다는 뜻이다. 효과적인 감지 방법들:

  • 타임아웃 에러 메트릭: TimeoutError 발생 빈도를 별도로 추적
  • 작업 완료율: 특정 시간대에 재학습 작업 성공률 급락 여부
  • 워커 응답 시간: 메인 워커의 요청 응답 시간 p95/p99 증가 추세
  • 에러 로그 패턴: "timeout"을 포함한 로그가 반복되는지 탐지

이 정보들이 있으면, 단순히 타임아웃 값만 올리는 게 아니라, "이 subprocess가 정말 300초 필요한가, 아니면 다른 병목이 있는가"를 판단할 수 있다.

회고: 타임아웃 관리의 두 가지 관점

이번 작업으로 정리한 것:

  1. 설정 관점: 타임아웃 값은 추측으로 정하면 안 된다. 실제 작업 시간 분포(히스토그램)를 수집하고, 그 위에서 p99를 기준으로 마진을 더해 설정한다.
  2. 모니터링 관점: 타임아웃 에러는 흔한 에러가 아니다. 한 번 발생하면 즉시 알람을 받아야 하고, 발생 추이를 별도로 추적해야 한다.

워커 스크립트처럼 장시간 실행되는 배경 작업에서는 이런 timeout 설정이 누적되기 쉽다. 다음 코드 리뷰 때는 "왜 이 값인가"를 묻는 습관을 들여야겠다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.