무중단 배포 도입 이유

달록의 기존 배포 스크립트는 이렇습니다.

if [ -z "$CURRENT_PID" ]; then
	echo "🌈 구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
	echo "🌈 구동중인 애플리케이션을 종료했습니다. (pid : $CURRENT_PID)"
	kill -9 $CURRENT_PID
fi

echo "\\n🌈 SpringBoot 애플리케이션을 실행합니다.\\n"

JAR_NAME=$(ls | grep .jar | head -n 1)

nohup java -jar -Dserver.port=$1 -Dspring.profiles.active=${SPRING_PROFILE} -Duser.timezone=Asia/Seoul /home/ubuntu/$JAR_NAME > /dev/null 2>&1 &
  1. 구동중인 애플리케이션을 확인하고
  2. 구동중인 애플리케이션이 있다면 종료한다.
  3. 이후 jar 파일을 실행한다.

여기서 2 → 3의 과정, 구동중인 애플리케이션을 종료하고 새로 실행하는 과정에서 서비스가 중단됩니다. 저희 서비스의 중단 시간을 측정해보니 약 8초 정도 중단되는 것을 확인할 수 있었습니다.

물론 지금이야 달록의 사용자가 많지 않아 그 동안 큰 문제는 없었습니다. 하지만 사용자가 많은 실제 서비스에서 매 배포때마다 8초씩 서비스가 멈춘다면 사용자들의 신뢰가 떨어지고 매출에도 영향을 미치겠조랭이떡? 🤔  저희 달록도 사용자의 편의성과 서비스의 안정성을 보장하기 위해 무중단 배포를 도입하기로 했습니다.

달록의 배포 전략 선택

이번 글은 실제 무중단 배포 도입기이기 때문에 이론적인 내용은 자세히 다루지 않겠습니다.

무중단 배포 전략의 자세한 내용이 궁금하다면? 후디의 무중단 배포 아키텍처와 배포 전략을 참고해주세요.

1. 롤링(Rolling) 배포

트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식.

애초에 달록은 EC2 한 대만 사용하고 있으며 호환성 문제가 발생할 가능성이 있어 제외했습니다.

2. 카나리(Canary) 배포

소수 인원에 대해서만 트래픽을 새로운 버전에 옮겨둔 상태에서 서비스를 운영한다. 새로운 버전에 이상이 없다고 판단하였을 경우에 모든 트래픽을 신규 버전으로 옮기는 방식. A/B 테스트를 하기에 적합하다.

롤링 배포와 마찬가지로 호환성 문제가 발생합니다. 또한 달록에서는 트래픽까지 점진적으로 옮겨가며 배포할 정도로 오류 감지에 대한 필요성을 느끼지 못해 제외했습니다.

3. 블루그린(Blue/Green) 배포

현재 운영 중인 서비스를 종료하지 않고 새로운 운영 환경을 만든 뒤 트래픽을 한 번에 신버전으로 옮기는 방식.

3-1. N개의 서버를 이용하는 방식