대부분의 서버/엔진을 구현할 때, 무중단 배포시 혹은 임의 종료시에 정상적으로 종료되도록 하는 것이 좋다.

Graceful shutdown 은 프로그램이 종료될 때 최대한 Side effect 가 없도록 로직들을 잘 갈무리하고 종료하도록 하는 것을 뜻한다.

로직이 진행되고 있는 와중에 프로세스가 종료되어버리면 처리중인 데이터가 증발할 수도 있고, 어디까지 처리중에 멈추었는지 추적하기 힘들어지는 경우도 있다.

보통 SIGTERM 을 이용해서 구현한다. 아래는 graceful shutdown 을 위해 Go 에서 주로 사용하는 방법이다.

func main() {
  stop := make(chan os.Signal, 1)
  signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)
  <-stop
  // ... 
}

위와 같이 구현하면, SIGINT 와 SIGTERM 신호가 왔을때 바로 종료되는 것이 아니라 Catch 해서 이후 로직을 이어가겠다는 뜻이다.

최근 회사에서 EKS 환경에서 다음과 같은 상황이 있었다.

A 서버는 multi pod 로 동작하며, 일반적으로 3개의 pod가 항시 동작함.

이 때, 하나의 pod 에서만 특정 작업을 수행해야 하고, 해당 pod 가 종료되지 않는 한 다른 pod 는 그 작업을 시도하면 안됨.

이를 보장하기 위해 redis 의 SETNX 를 이용해 락을 집는 방식.

작업을 수행하는 서버는 SIGTERM 신호를 받으면 해당 락을 삭제하고 os.Exit(1) 종료.

문제는 여기서 시작됐는데, pod 가 교체되면서 해당 작업을 수행하지 못하고 바로 종료되었다.

애초에 로그조차도 찍히지 않았기때문에, SIGKILL 을 받은것으로 보였다.

k8s 는 SIGTERM 을 보낸지 30초가 지나도 해당 컨테이너가 종료되지 않으면 SIGKILL을 보낸다.

서버가 SIGTERM 을 받지 못했다고 가정하고 디버깅을 시작했다.

우선 아래 명령어를 이용해서 실행중인 pod 에서 상태를 체크해보기로 했다.

kubectl exec -it "..." -- /bin/sh 

$ > ps -ef

확인해보니 이상한 점이 보였다.

1번 프로세스가 /bin/sh ./run

1번 프로세스를 부모로 가지는 자식 프로세스 /bin/bash ./server

1번 프로세스의 손주(위의 자식 프로세스) ./server

./server 는 컴파일 후 나온 outfile (binary)

k8s 는 SIGTERM 을 1번 프로세스에 보낸다.

내 서버는 손주 프로세스가 되어있기 때문에 받지 못한 것이고, Dockerfile 을 확인해보니 회사의 모든 서버는 아래와 같이 실행되고 있었다.

...

CMD ./run

run 이라는 스크립트를 CMD 를 이용해서 실행하기 때문에, 1번 프로세스가 /bin/sh 가 되는 것.

사실 해당 스크립트는 레거시에 가깝고 프로세스 실행 외에 역할이 아예 없었기 때문에 아래와 같이 바꾸고 실행해보았다.

...

ENTRYPOINT ./server

위와 같이 ENTRYPOINT 로 실행하게 되면 1번 프로세스가 나의 서버가 되기 때문에, SIGTERM 을 받을 수 있게 된다.

사실 해결 방법으로 Helm chart 에서 preStop 등을 이용해 SIGTERM 을 전파할까도 싶었지만, 굳이 그럴 필요가 있나 싶어서 필자는 위와 같이 해결했다.

테스트 하고 싶다면 직접 배포를 다시 해봐도 되고 kubectl delete pod “…” 커맨드를 실행해서 로그를 살펴봐도 되고, deployment 를 수정하면서 테스트 하던가… 뭐 방법이야 많을 것 같다.

편한 방식대로 하자.

대부분의 서버/엔진을 구현할 때, 무중단 배포시 혹은 임의 종료시에 정상적으로 종료되도록 하는 것이 좋다.

Graceful shutdown 은 프로그램이 종료될 때 최대한 Side effect 가 없도록 로직들을 잘 갈무리하고 종료하도록 하는 것을 뜻한다.

로직이 진행되고 있는 와중에 프로세스가 종료되어버리면 처리중인 데이터가 증발할 수도 있고, 어디까지 처리중에 멈추었는지 추적하기 힘들어지는 경우도 있다.

보통 SIGTERM 을 이용해서 구현한다. 아래는 graceful shutdown 을 위해 Go 에서 주로 사용하는 방법이다.

func main() {
  stop := make(chan os.Signal, 1)
  signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)
  <-stop
  // ... 
}

위와 같이 구현하면, SIGINT 와 SIGTERM 신호가 왔을때 바로 종료되는 것이 아니라 Catch 해서 이후 로직을 이어가겠다는 뜻이다.

최근 회사에서 EKS 환경에서 다음과 같은 상황이 있었다.

A 서버는 multi pod 로 동작하며, 일반적으로 3개의 pod가 항시 동작함.

이 때, 하나의 pod 에서만 특정 작업을 수행해야 하고, 해당 pod 가 종료되지 않는 한 다른 pod 는 그 작업을 시도하면 안됨.

이를 보장하기 위해 redis 의 SETNX 를 이용해 락을 집는 방식.

작업을 수행하는 서버는 SIGTERM 신호를 받으면 해당 락을 삭제하고 os.Exit(1) 종료.

문제는 여기서 시작됐는데, pod 가 교체되면서 해당 작업을 수행하지 못하고 바로 종료되었다.

애초에 로그조차도 찍히지 않았기때문에, SIGKILL 을 받은것으로 보였다.

k8s 는 SIGTERM 을 보낸지 30초가 지나도 해당 컨테이너가 종료되지 않으면 SIGKILL을 보낸다.

서버가 SIGTERM 을 받지 못했다고 가정하고 디버깅을 시작했다.

우선 아래 명령어를 이용해서 실행중인 pod 에서 상태를 체크해보기로 했다.

kubectl exec -it "..." -- /bin/sh 

$ > ps -ef

확인해보니 이상한 점이 보였다.

1번 프로세스가 /bin/sh ./run

1번 프로세스를 부모로 가지는 자식 프로세스 /bin/bash ./server

1번 프로세스의 손주(위의 자식 프로세스) ./server

./server 는 컴파일 후 나온 outfile (binary)

k8s 는 SIGTERM 을 1번 프로세스에 보낸다.

내 서버는 손주 프로세스가 되어있기 때문에 받지 못한 것이고, Dockerfile 을 확인해보니 회사의 모든 서버는 아래와 같이 실행되고 있었다.

...

CMD ./run

run 이라는 스크립트를 CMD 를 이용해서 실행하기 때문에, 1번 프로세스가 /bin/sh 가 되는 것.

사실 해당 스크립트는 레거시에 가깝고 프로세스 실행 외에 역할이 아예 없었기 때문에 아래와 같이 바꾸고 실행해보았다.

...

ENTRYPOINT ./server

위와 같이 ENTRYPOINT 로 실행하게 되면 1번 프로세스가 나의 서버가 되기 때문에, SIGTERM 을 받을 수 있게 된다.

사실 해결 방법으로 Helm chart 에서 preStop 등을 이용해 SIGTERM 을 전파할까도 싶었지만, 굳이 그럴 필요가 있나 싶어서 필자는 위와 같이 해결했다.

테스트 하고 싶다면 직접 배포를 다시 해봐도 되고 kubectl delete pod “…” 커맨드를 실행해서 로그를 살펴봐도 되고, deployment 를 수정하면서 테스트 하던가… 뭐 방법이야 많을 것 같다.

편한 방식대로 하자.