서버를 배포하거나 업데이트할 때 프로세스가 갑자기 종료되면서 진행 중이던 요청이 끊기거나 데이터베이스 연결이 비정상적으로 종료되는 상황을 마주하는 경우가 종종 있더라고요. 특히 도커나 쿠버네티스 같은 컨테이너 환경에서는 컨테이너를 중지하거나 재시작할 때 프로세스에 종료 신호를 보내는데, 이때 애플리케이션이 이 신호를 제대로 처리하지 못하면 사용자에게 502 Bad Gateway 같은 오류가 노출될 수 있네요. 이러한 문제를 방지하기 위해 도입하는 개념이 바로 Graceful Shutdown이더라고요. 이 방식은 프로세스가 종료 신호를 받았을 때 즉시 종료하는 대신, 현재 처리 중인 요청을 모두 마무리할 수 있도록 일정 시간 동안 대기하는 원리예요.
리눅스 환경에서 프로세스가 종료될 때 사용하는 대표적인 신호로 SIGTERM과 SIGINT가 있네요. 도커 환경에서는 컨테이너를 중지할 때 기본적으로 SIGTERM 신호를 보내고, 설정된 대기 시간 동안 프로세스가 종료 준비를 마칠 때까지 기다려주더라고요. 이때 애플리케이션이 이 신호를 제대로 캐치하면, 새로운 요청은 더 이상 받지 않으면서 이미 들어온 요청은 끝까지 처리하는 단계를 거치게 돼요. 이 과정에서 데이터베이스 커넥션 풀이나 메시지 큐와의 연결도 안전하게 닫아주어야 다음 실행 시에 발생할 수 있는 연결 오류를 방지할 수 있더라고요.
process.on('SIGTERM', () => {
console.log('Graceful shutdown 시작');
// 새로운 연결을 받지 않도록 서버를 닫는 설정
server.close(() => {
console.log('모든 요청 처리 완료 및 서버 종료');
process.exit(0);
});
});
단순히 코드가 실행되는 것에만 집중하기보다 운영 환경에서의 안정성을 고려한다면 이러한 시그널 처리 로직을 반드시 포함하는 것이 좋더라고요. 특히 트래픽이 많은 서비스에서는 배포 시점에도 사용자 경험을 해치지 않고 매끄럽게 서비스를 전환하기 위해 필수적인 과정이라고 생각되네요. 데이터베이스 연결을 명시적으로 해제하고 외부 서비스와의 연결을 깔끔하게 정리하는 과정이 포함되어야만 재시작 시에도 안정적인 상태를 유지할 수 있더라고요. 이 과정이 제대로 작동하지 않으면 재시작 직후에 데이터베이스 연결이 꼬이거나 좀비 프로세스가 남는 등의 문제가 발생할 수 있으니 주의 깊게 살펴볼 필요가 있네요.
'develop > 공통' 카테고리의 다른 글
| HTTP Cache-Control 및 ETag 활용 전략 (0) | 2026.11.01 |
|---|---|
| HTTP 400 Bad Request와 422 Unprocessable Entity의 구분 및 활용 (0) | 2026.10.20 |
| HTTP 401과 403 상태 코드의 의미 차이와 활용 (0) | 2026.10.13 |
| Webhooks 재시도 전략 및 지수 백오프(Exponential Backoff) 적용 (0) | 2026.10.05 |
| Redis 캐시 Stampede 현상 방지 전략 (0) | 2026.09.27 |