Blue/Green 무중단 배포 시 구버전의 애플리케이션은 언제 종료해야 할까? (graceful shutdown)

1. 개요

진행 중인 Jikgong 서비스에서 Nginx를 사용하여 Blue/Green  무중단 배포 전략을 사용하여 배포 시 다운 타임을 최소화 시켰다. 

 

그 과정에서 작성한 deploy.sh 파일엔 다음과 같은 코드가 작성되어있다. 

# 기존에 실행 중이었던 docker-compose는 종료시켜줍니다.
echo "jikgong-${TERMINATE_CONTAINER} down"
sudo docker-compose -f docker-compose.${TERMINATE_CONTAINER}.yml down --rmi all

 

이 부분이 문제였다.

 

현재 사용 중인 Blue/Green 방식의 무중단 배포 프로세스를 간략하게 설명하면

 

1. 새로운 버전의 애플리케이션 구동

2. 지속적인 헬스체크로 구동 완료 확인

3. 구동 완료 시 리버스 프록시로 사용 중인 Nginx의 프록시 설정을 변경하여 새로운 버전의 애플리케이션을 가르키도록 변경

4. 기존의 애플리케이션 컨테이너 종료

 

 

위 코드가 4번 작업을 수행하는 코드인데, 여기서 문제점은 구버전의 처리 중인 작업을 무시하고 강제 종료 시킨다는 점이다. 

 

 

그럼 어떻게 안전하게 종료시킬 수 있을까?

 

결론 부터 말하면 나는 2.2 / 2.3 을 사용하여 문제를 해결하였다. 

 

 

 

 

 

 

 

2.1 프로세스를 직접 종료할 때 

나는 보통 프로세스를 죽이곤 할 때 kill -9 PID 를 사용했다. 하지만 -9로 프로세스를 종료하면 시스템에 악영향을 줄 수 있다. 

 

예를 들어 사용자의 요청을 받고 처리하는 데 5초가 걸리는 API가 있고 이를 실행 중일 때 kill -9로 종료하게 되면 즉시 종료되어 버리고 데이터가유실되거나 리소스가 제대로 닫히지 않는 문제가 발생할 수 있다. 

 

kill을 할 땐 signal을 줄 수 있는데 목록은 다음과 같다.

$ kill -l

1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR

 

 

하지만 15 - SIGTERM을 사용하면 프로세스를 정상 종료 시킬 수 있다. 또한, 프로세스가 현재 사용중인 리소스를 해제하고, 데이터를 저장하는 등 안전하게 모든 작업을 완료할 때 까지 기다려준다. 

 

 

나의 경우 프로세스를 직접 죽이지 않기 때문에 PASS~

 

 

 

 

 

 

 

2.2 Spring Boot 종료 시 Graceful Shutdown

Graceful Shutdown은 Spring Boot 2.3.0 Release 부터 제공하는 기능이다. 

 

이를 활성화 하면 스프링 부트는 종료 요청이 들어온 이후론 더 이상 새로운 요청을 받지 않으면서, 처리 중인 요청은 모두 처리한 뒤 프로세스를 종료하게 된다. 

server:
  shutdown: graceful

 

 

기본적으로 30s 동안 기다리고 이는 아래와 같이 변경할 수 있다. 

spring:
  lifecycle:
    timeout-per-shutdown-phase: 100s

 

 

 

 

 

 

 

 

2.3 Docker 컨테이너를 종료할 때

나같은 경우엔 docker-compose를 사용해서 스프링 애플리케이션을 띄우고 종료하고있다. 

 

2.2 방법 처럼 애플리케이션 단에서 graceful shutdown 설정을 해뒀지만 컨테이너 종료 시엔 설정이 먹히질 않았다. 위에서 언급은 하지 않았지만 graceful shudown이 설정되어 있더라도 kill -9로 종료 시 즉시 종료 된다. 

 

 

 

테스트에 사용하기 위해 1분 간 Thread.sleep을 하는 테스트 api를 작성해뒀다. 

@RestController
@Slf4j
public class TestController {

    @GetMapping("/test")
    public String test() throws InterruptedException {
        log.info("시작");
        Thread.sleep(60000);
        log.info("종료");
        return "배포 완료";
    }
}

 

 

 

 

application.yml 설정은 아래와 같다.

server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 100s

 

 

 

 

docker compose 로 스프링 애플리케이션을 구동하고, curl로 요청을 보내보았다. 이후 바로 docker compose down으로 컨테이너를 내렸고 결과는 다음과 같다. 

$ docker compose up 

$ curl http://IP:8080/test  # 요청 시작

$ docker compose down

 

 

 

graceful shutdown 로그가 찍히며 기다리는가 싶더니 종료까지 기다리지 않고 바로 종료되었다. 

 

 

 

 

 

docker compose down 명령어가 실행되면 내부적으로 컨테이너 STOP 후 REMOVE 작업을 진행한다. 

이때 docker stop 은 graceful 한 종료를 지원해주는데 아래와 같이 -t 옵션을 사용해 몇 초간 대기할 지 지정할 수 있다. 단위는 s이다. 

docker stop -t 100 {contianer_id}

 

 

 

 

요청 처리 중 명령어를 날리면 아래와 같이 대기하다가 1분 후 모든 프로세스가 끝나면 정상 종료하는 걸 확인할 수 있다. 

 

 

 

 

 

그리고 shutdown 도중에 다른 엔드포인트로 요청을 보냈을 땐 연결 실패하였고, graceful 종료 대기 중엔 다른 요청을 받지 않는 다는 걸 확인할 수 있었다. 

    @GetMapping("/test2")
    public String test2() throws InterruptedException {
        log.info("test2 진입");
        return "처리 완료";
    }

 

 

 

 

 

 

 

위 처럼  docker stop 명령어에  -t 옵션을 넣을 수도 있지만 docker compose 파일에서 바로 설정할 수도 있다. 

version: "3.8"
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./log:/log
    ports:
      - "8080:8080"
    restart: always
    stop_grace_period: 100s  # 대기 시간 설정

 

docker-compose 에서 하는 graceful 시간을 설정하는 것이 아닌 -t로 종료하려면 deploy.sh 까지 수정해줘야 했다.

 

docker compose down는 내부적으로 stop -> remove 이긴 하지만 stop 시에 옵션을 붙여 줄 수 없기 때문이다. 하려면 docker compose stop, docker compose remove 로 나눠 사용해야 한다. 

 

 

귀찮기 때문에 난 compose에서 설정해뒀다.. ㅎㅎ 

 

 

 

 

 

 

 

3. 결과

Blue/Green 방식에서 기존 구버전의 애플리케이션을 종료시킬 때도 고려할 사항이 있었다. 이것 말고도 내가 놓치고 있는 또 다른 무언가가 있을 것 같다는 생각이 들지만 차근차근 알아갈 생각이다.

 

이밖에도 Nginx에서 리버스 프록시를 변경 후 재로딩 하는 데에도 정말 짧지만 시간이 소요되는 것으로 알고 있다. 

이 부분도 문제가 된다면 문제라고 할 수 있을 것 같다. 

 

위 방식은 사실 종료될 때 까지 설정한 시간 만큼 기다려 주는 것 뿐, 요청 처리에 그 이상의 시간이 소요된다면 이건 보장할 수 없다. 하지만 그 이상이 소요되는 것 부터 문제가 아마 있지 않을까..? 

 

배치 로직에 대해서도 고민한 적이 있다. 스케줄링을 통해 배치 로직을 실행 시키고 있었다면 100초? 보다 더 걸릴 수 있지 않을까? 했는데, 애초에 그런 배치 로직이 BLUE/GREEN 배포에 묶여 있으면 안 된다고 한다. 

 

 

 

아무튼, 작업 중인 프로세스 처리를 기다린 후 종료하기 위해 변경 시킨 부분을 정리하면 다음과 같다. 

 

1. application.yml에 graceful 설정

spring:
  # 종료 전 처리 중인 프로세스 100초간 대기
  lifecycle:
    timeout-per-shutdown-phase: 100s

# 작업 중인 프로세스 처리 후 종료
server:
  shutdown: graceful

 

 

2. docker-compose 파일에서 graceful 설정

version: "3.8"
services:
  app:
    stop_grace_period: 100s # garceful 종료