Node.js Redis 종료: exit 이벤트에서 비동기 정리를 하지 않기

process.on의 exit 콜백에서 Promise를 기다려 Redis를 닫으려는 설계는 종료 시점과 맞지 않습니다. 연결을 닫는 함수 이름을 바꾸는 것보다, 새 작업을 언제 멈추고 진행 중 작업을 언제 끝낼지 정하는 것이 먼저입니다.

Node.js exit 문서는 이 이벤트의 listener에서 동기 작업만 수행해야 하는 조건을 설명합니다. 여기서 예약한 비동기 작업이 끝날 것이라고 기대할 수 없습니다. beforeExit도 모든 종료 원인에서 호출되는 대체 종료 관리자라고 가정하면 안 됩니다.

정리 순서를 하나의 상태 전이로 만들기

RUNNING -> STOP_ACCEPTING -> DRAINING -> CLOSE_REDIS -> DONE
                              | deadline/error
                              v
                         RECORD_FAILURE -> FORCED_CLOSE

설계 예의 RUNNING에서 SIGTERM을 받으면 종료 중 표시를 먼저 설정해 반복 신호가 중복 정리를 시작하지 않게 합니다. HTTP·queue consumer 등 새 작업 유입을 막고, 이미 시작한 작업의 완료를 제한 시간 안에서 기다린 뒤 Redis를 닫습니다. 제한 시간을 넘겼다면 미완료 작업과 종료 실패를 기록해야 하며 정상 배출로 보고하지 않습니다.

node-redis 버전을 먼저 확인

v4→v5 이행 문서에서는 quit 대신 close, disconnect 대신 destroy를 안내합니다. 따라서 오래된 예제의 함수 이름을 현재 프로젝트에 그대로 복사하지 않습니다. 정상적인 배출과 즉시 연결 파기를 같은 종료 결과로 취급하지 말고, 설치한 패키지 버전의 동작을 확인하세요.

스테이징 검증은 유휴 종료, 진행 중 요청이 있는 종료, Redis 연결이 이미 끊긴 상태, 반복 SIGTERM, 제한 시간 초과를 나눕니다. 각 경우 새 요청 거부 시점·작업 완료 수·종료 코드를 기록합니다. 소켓이 닫혔다고 메시지가 정확히 한 번 처리됐거나 커널 zombie가 사라졌다는 뜻은 아닙니다. 이 글의 상태도는 설계 분석이며 실제 실행 결과가 아닙니다.