Node.js 컨테이너, 왜 깔끔하게 안 죽을까? (feat. Graceful shutdown)
Summary
Node.js 컨테이너가 좀처럼 죽지 않는다면? PID 1과 이벤트 루프의 비밀
Kubernetes 환경에서 완벽한 Graceful Shutdown을 구현하기 위한 dumb-init 활용법과 타임아웃 전략
이 아티클은 Node.js 기반 배치 컨슈머가 컨테이너 환경에서 왜 정상적으로 종료되지 않는지 심층 분석합니다. Linux 커널의 PID 1 보호 메커니즘부터 Node.js 이벤트 루프의 특성까지 다루며, 실무적인 해결책으로 인프라와 애플리케이션 설정을 동기화하는 구체적인 방법을 제시합니다.
- 01Linux PID 1의 특별한 시그널 보호 원칙과 이를 해결하기 위한 dumb-init의 필요성
- 02NestJS 셧다운 훅 내 Promise.race를 활용한 애플리케이션 레벨 타임아웃 구현 패턴
- 03이벤트 루프가 완전히 비워지기 전까지 프로세스가 종료되지 않는 Node.js 동작 원리 설명
- 04애플리케이션 타임아웃과 K8s Grace Period 간의 유기적인 설정 정합성 강조
- 05데이터 정합성 유지를 위해 AbortController 기반 강제 종료 대신 인프라 정책을 선택한 의사결정 과정
RECOMMENDATION
Kubernetes에서 Node.js 마이크로서비스나 배치 앱을 운영하는 엔지니어에게 필독을 권하며, 특히 배포 시 작업 유실이 우려되는 상황에서 즉시 적용 가능한 가이드입니다.
The Problem
Kubernetes 환경에서 Node.js 컨테이너가 SIGTERM 시그널을 무시하거나, 종료 훅 실행 후에도 이벤트 루프에 남은 비동기 작업 때문에 프로세스가 즉시 종료되지 않아 배치 작업의 정합성이 깨지는 문제 발생.
The Solution
dumb-init을 도입하여 PID 1의 시그널 전파 및 좀비 프로세스 정리 문제를 해결하고, NestJS 셧다운 훅에 Promise.race 기반 타임아웃을 적용한 뒤 K8s의 terminationGracePeriodSeconds를 앱 타임아웃보다 길게 설정함.
The Result
종료 시그널이 모든 프로세스에 안정적으로 전달됨을 확인하였으며, 타임아웃 제어를 통해 프로세스 종료 시점을 예측 가능하게 관리하여 배치 작업 유실 리스크를 최소화함.
Trade-off
비동기 작업을 강제 중단하는 AbortController 방식은 코드 복잡도 증가와 외부 라이브러리의 트랜잭션 처리 불안정성 등 데이터 정합성 리스크가 있어 도입 대상에서 제외함.
Key Concepts
More from 쏘카
View all posts from 쏘카
S3 + CloudFront 기반 SPA 배포에서 캐시와 fallback 전략 설계하기
CloudFrontS3SPA2주 전쏘카 디자인 시스템 2.0 개발기 2편: 기술로 굴리기(웹)
Design SystemReactComponent Architecture4개월 전쏘카 디자인 시스템 2.0 개발기 1편: 시스템으로 굴리기(웹)
Design SystemFigmaFigma Plugin4개월 전쏘카프레임 - 블루투스 모듈
BluetoothBLEMobile Architecture6개월 전쏘카프레임 - 앱 프레임워크와 개발자 경험
Socar Frame개발자 경험Android6개월 전
