약과 배포 과정에서 서비스 중단문제를 해결하기 위해 Blue-Green 무중단 배포 과정에서 배운 점을 기록합니다.
"API가 갑자기 안 돼요!"
저는 프로그라피 9기로 활동하며, 약 4개월간 AOS와 iOS 개발자분들과 함께 약과를 개발했습니다.
어느 날, 평소처럼 코드를 수정하고 배포하던 중, 한 iOS 개발자분으로부터 "방금까지 잘 되던 API가 갑자기 작동하지 않는다"는 연락을 받았습니다.
원인은 바로 제 배포 과정에서 발생한 문제였습니다.
기존 배포 방식의 문제
약과의 배포 과정은 다음과 같이 진행되었습니다:
- 깃허브에 코드 PUSH
- 깃허브 액션을 통해 코드를 빌드하고 도커 이미지를 생성
- EC2 서버에서 최신 도커 이미지 PULL
- 기존 애플리케이션 중지 (문제발생!!)
- 최신 도커 이미지로 애플리케이션 실행
iOS개발자께서 애플리케이션이 중지된 단계일때 API를 요청하여 정상동작을 하지 않은것이었습니다!
실제 서비스라 가정하면 앱이 정상적으로 동작하지 않을것이라 생각되어 무중단 배포가 필수적이라 생각하였습니다.
해결 방법: 무중단 배포
Blue-Green 배포란?
Blue-Green 배포는 선수 교체와 비슷합니다. 기존 애플리케이션 서버(Blue)가 실행 중인 상태에서 새로운 애플리케이션 서버(Green)를 배포합니다. Green 서버가 정상적으로 실행되면, 기존 Blue 서버를 중지합니다.
Nginx를 활용한 무중단 배포
Blue-Green 배포의 핵심은 Nginx를 이용해 트래픽을 분배하는 것입니다.
약과 프로젝트에서는 HTTPS를 적용했으며, 모든 API 요청은 Nginx를 거쳐 실행 중인 서버로 전달됩니다.
새로운 애플리케이션 서버(Green)가 정상적으로 실행되면, Nginx가 트래픽을 해당 서버의 포트로 변경합니다. 이 과정에서 사용자는 애플리케이션의 변경을 인지하지 못하여 무중단배포를 성공적으로 완성하게 됩니다!
파이프라인 과정
- 깃허브에 코드 PUSH
- 깃허브 액션을 통해 코드를 빌드하고 도커 이미지를 생성
- 만들어진 이미지를 DockerHub에 Push
- 깃허브 액션을 통해 EC2에 접근하여 만들어진 도커 이미지를 Pull해옵니다.
- EC2에서 작성한 deploy.sh 파일을 실행하여 이미지를 실행 및 헬스체크를 통해 Blue-Gree 배포를 완료합니다.
파이프라인을 거치게 되면, 서버에 두개의 스프링 서버가 올라가고 Nginx가 가르키고 있는 서버의 포트만 빠르게 변경하여 사용자가 서비스 중지없이 서비스를 배포하게됩니다!
Docker-Compose
약과에서 스프링뿐만 아니라 Redis, Certbot, Nginx까지 다양한 이미지를 사용하고 있는만큼 일일히 컨테이너를 직접 실행시키는 것은 비효율적이라 생각하여 docker-compose.yml 을 통해 도커컴포즈를 이용하여 한번에 모든 컨테이너를 작동하도록 하였습니다!
최종 아키텍처
최종적으로는 다음과 같은 아키텍처로 약과를 운영하고있습니다!
