Graceful Shutdown을 "안전하게 종료하는 것" 정도로 외운 사람과, 시나리오를 단계별(트래픽 차단 → 진행 중 작업 마무리 → 자원 정리 → 강제 종료)로 분해해서 각 지점의 결정과 대안을 짚을 줄 아는 사람을 가른다. 후속 질문은 보통 preStop·타임아웃·장기 작업·재시도 안전성으로 이어진다.
Graceful Shutdown은 프로세스가 종료 신호를 받았을 때 곧바로 죽지 않고, 신규 요청을 받지 않도록 입구를 닫은 뒤 이미 처리 중인 요청·트랜잭션·메시지 컨슘을 마무리하고 자원을 정리한 다음에 종료하는 절차다. 일반적으로 SIGTERM을 받고 정리 모드로 들어가며, 정해진 타임아웃 안에 끝나지 않으면 마지막에 SIGKILL로 강제 종료된다. 쿠버네티스 환경이라면 preStop 훅과 readiness probe로 로드밸런서 트래픽을 먼저 끊고 그 다음 SIGTERM이 들어오는 순서까지가 한 묶음이다. 즉 "종료 신호를 어떻게 받느냐"가 아니라 "신호를 받은 뒤 어떤 순서로 입구·진행 중 작업·자원을 닫느냐"가 본질이다.
배포할 때마다 5xx가 튀는 걸 readiness probe·preStop·SIGTERM 순서를 다시 잡아서 잡은 경험이 있다면 그 순서 자체로 답을 끌고 갈 수 있다
결제·주문 같은 트랜잭션이 종료 시점에 어떻게 새지 않게 설계했는지 떠올릴 수 있다면 단계별 의사결정을 구체적인 작업 단위로 풀 수 있다
Kafka·SQS 컨슈머에서 메시지 commit 타이밍과 종료 신호를 어떻게 맞췄는지 경험이 있다면 "진행 중 작업 마무리" 단계를 깊게 설명할 수 있다
terminationGracePeriod를 짧게 잡았다가 SIGKILL로 잘려 본 경험이 있다면 타임아웃과 SLA 사이의 트레이드오프를 자기 사례로 말할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.