Nginx, Docker, Github Actions를 이용한 무중단 배포 진행

무중단 배포 도입 이유

• 진행중인 프로젝트에서 Github Actions를 통해 CI/CD를 구축한 상태이다. main 브랜치에 merge될 때마다 자동 배포가 진행되는데, 이때 필연적으로 서버가 종료되고 다시 시작되는 시간(Downtime)이 발생했다. 최소 30초에서 길면 60초 정도가 걸렸는데, 지금은 개발기간이라 큰 문제는 없지만 이후 운영 상황에서의 이 Downtime은 사용자 경험 측면에서도 안좋고 서비스가 성장할 수록 손실이 커질 것이라 판단하여 무중단배포 도입을 결정하였다.
• Nginx를 선택한 이유
  • 무중단 배포를 구현하는 여러 가지 방식이 있다. Kubernetes, AWS ELB, Nginx 등
  • K8s는 학습 비용이 높고, AWS ELB는 인스턴스를 생성, 관리(과금 위험)해야 했다. Nginx는 추가적인 서버 개설 없이 단일 서버로 구현할 수 있기에 가난한 취준생인 나에게 가장 적합하였다.

 

전략 선택

크게 세 가지의 전략이 존재한다.

1. Rolling 

   • 

   • 서버를 순차적으로 업데이트 하는 전략이다.
   • 점진적 배포로 인해 Downtime이 존재하지 않으며 서버 자원이 제한된 환경에서 구성이 가능하다.
   • 하지만 롤백이 복잡할 수 있고, 어느 사용자는 구 버전, 어느 사용자는 신 버전을 사용할 수 있어서 호환성이 안맞을 수 있다는 단점이 존재한다.
2.  Blue/Green
   • 현재 운영중인 환경을 Blue, 신버전을 Green이라고 한다.

   • 

   • 롤링 방식과 마찬가지로 롤백이 쉽다는 장점이 있고, 롤링 방식의 단점인 구버전과 신버전 호환성 문제가 사라진다.
   • 하지만 신버전의 배포가 완료될 때까지는 항상 구버전이 실행되어야 하기 때문에 서버의 자원이 두 배가 필요하다는 단점이 존재한다.
3. Canary

   • 

   • Canary라는 새 이름을 따서 만들어진 것으로, 위험을 사전에 방지하는 전략이다.
   • 서비스 일부만 신버전으로 배포하고 트래픽 일부를 신버전으로 향하도록 가중치를 둔다. 모니터링 후 문제가 없다면 롤링 방식을 사용해 나머지 서버를 업데이트하는 방식이다.
   • 신버전의 문제를 조기에 파악할 수 있고 상황에 따라 트래픽을 늘리거나 롤백할 수 있다.
   • 하지만 전체 배포 속도가 느릴 수 있고, 롤링 방식과 같이 신버전과 구버전의 호환성 문제가 존재할 수 있다.

 

겪은 문제

• Blue/Green 전략 시, EC2 프리티어에서 RAM 1GB 초과로 인한 CPU 사용량 100% 달성.! -> 서버 다운 현상 
• 여기서 자세히 볼 수 있습니다. 무중단 배포 시 AWS EC2 프리티어 CPU 사용량 100% 초과

RAM 용량 최적화를 위해 기존 버전 삭제

• blue , green 버전이 모두 서버에 올라와있다면 향후 동일한 문제가 발생할 여지가 있어 다른 버전이 정상적으로 배포되면 기존 버전 이미지를 삭제하도록 진행하였습니다.

과정

1. Nginx 설치
2. Nginx.green.conf, Nginx.blue.conf 생성
3. deploy.sh 생성
4. Git Actions에서 CD 진행 시 deploy.sh 실행

자세한 과정은 https://mr-popo.tistory.com/230 를 참고하였습니다.

Github Action, Nginx, Docker 무중단 배포하기(블루/그린)

 

 

 

<최종 구조>