Graceful Shutdown과 SIGINT/SIGTERM/SIGKILL
1. Graceful Shutdown이란 무엇인가?
우아한 종료라고 직역하면 뭔가 어색하지만, 그 역의 경우를 생각해보면 제법 어울리는 표현이라는 생각이 든다.
우아한 종료는 프로그램이 종료될 때 최대한 side effect가 없도록 로직들을 잘 처리하고 종료하는 것을 말한다.
Gracueful Shutdown <-> Hard Shutdown
우아한 종료의 대척점에는 Hard Shutdown이 있다.
예를 들면 이런 것이다.
회사에서 코드를 한창 짜고 있는데, 팀장님이 "땡땡씨 퇴근하세요."라고 했을 때
- 코드를 커밋하고 푸시한 뒤 컴퓨터를 끄고 퇴근하는 것: graceful shutdown
- 그대로 컴퓨터를 바로 끄고 퇴근하는 것: hard shutdown
하고있던 작업을 적절히 마무리한 뒤 종료되는 것이 핵심이다.
http 요청을 처리하는 웹서버라면 서버가 종료되기 전,
기존 처리 중이던 요청들을 모두 처리한 뒤 종료되도록 구현하는 것이다.
웹서버를 예시로 들었지만 우아한 종료는 특정 형태의 프로그램에 국한된 개념은 아니다.
클라이언트 단에서도 우아한 종료가 가능하다.
메모장 기능을 하는 모바일 앱이라면, 유저가 따로 저장 버튼을 누르지 않고 앱을 종료시켜도
유저가 작성중이던 텍스트를 저장하도록 구현할 수 있을 것이다.
우아한 종료라는 개념은 왜 존재하는가? 왜 구현해야 하는가?
비즈니스 로직을 해치고 싶지 않기 때문이다.
의도한 종료든 의도하지 않은 종료든 간에 최대한 side effect를 줄이고 싶기 때문이다.
극단적인 예시로, 모바일 뱅킹 앱을 사용하던 중 뱅킹 서버에 문제가 있어서
유저들의 계좌 정보와 잔액 정보에 대한 로직이 제대로 처리되지 않은 상태로 서버가 종료된다면 끔찍할 것이다.
2. SIGINT/SIGTERM/SIGKILL
그러면 우아한 종료는 어떻게 구현하는가?
프로그램을 종료하라는 유닉스 신호를 catch하여 처리 로직을 하는 형태로 구현할 수 있다.
유닉스 신호는 유닉스 계열 등의 운영체제에서 사용하는 프로세스 간 통신의 일종이다.
프로그램 실행 중에 ctrl + c를 입력하면 SIGINT 시그널이 프로세스로 가게 되고, 대게 프로그램이 종료된다.
2-1. SIGTERM vs SIGINT
SIGTERM은 프로그램을 종료하는 일반적인 방법이다.
SIGINT는 유저가 직접 프로그램 종료를 지시했다는 것이 명확하다는 점에서 차이가 있다.
(앞서 유닉스 신호는 IPC라고 언급했다.)
일반적인 유저 입장에서는 사실 두 개가 딱히 다르게 느껴지지 않는다.
SIGINT의 INT는 interrupt에서 온 것인데, 결과적으로 프로그램이 종료된다는 점에서는 SIGTERM과 다를 바 없기 때문이다.
SIGINT와 SIGTERM은 둘 다 catch가 가능하다.
프로그램은 각 시그널을 전송받았을 때 자신만의 로직을 처리할 수 있다. (if process.Get("SIGTERM") ~ 같이)
특정 시그널을 받았을 때 실행하는 함수를 시그널 핸들러라고 한다.
과거에는 SIGINT가 어떻게 활용되었는지 모르겠지만,
현재 대부분의 프로그램들은 SIGINT를 받았을 때 프로그램을 종료하는 형태로 구현되어있다.
2-2. SIGTERM/SIGINT vs SIGKILL
SIGKILL은 말 그대로 프로세스를 kill 한다. catch가 불가능하다.
들어온 요청을 다 처리하고 종료한다든가, db에 유저가 작성중이던 텍스트 데이터를 저장한다든가 같은
로직을 처리하는 것이 불가능하다. SIGKILL에 대한 시그널 핸들러는 만들 수 없다.
기타
- 특정 시그널을 catch 할 수 있다는 것은, 시그널 핸들러를 제작할 수 있다는 뜻이기도 하지만 동시에 무시할 수 있다는 뜻이기도 하다.
- ctrl + z 의 경우 SIGSTOP 시그널을 보내는데, 원래라면 프로세스를 정지하는 것이지만 SIGSTOP을 받았을 때 종료되는 형태로 구현된 프로그램들도 종종 있다.