문제 배경
우아한테크코스에서 프로젝트를 진행할 때는 우아한테크코스에 AWS 계정을 제공해줘서 EC2를 비용 걱정없이 갯수 상관없이 사용할 수 있었다. 하지만 우아한테크코스를 수료하고 나서는 AWS 계정 제공이 되지 않아서 팀원들이 자체 AWS 계정을 만들어서 인프라를 구축해야 했다.
이때 AWS에서는 프리티어로 RDS 인스턴스 한 개와 EC2 인스턴스 한 개를 제공해주는 점을 활용해서 최대한 비용을 줄일 수 있다.
하지만 기존 프로젝트는 CD와 무중단 배포를 위해 젠킨스를 EC2로 띄워서 구현했다. 그리고 Nginx를 따로 EC2로 띄워서 리버스 프록시 및 로드밸런싱 기능을 할 수 있도록 구축했다. 그래서 하나의 EC2로는 기존의 인프라 구조를 구현하기 어렵다.
AWS 무중단 배포를 구현하는 여러 방법들
기존에는 젠킨스의 스크립트로 Nginx를 조절하는 방식으로 우리가 직접 Blue-Green 무중단 배포를 구현하는 방식이었다.
하지만 EC2 사용 갯수가 제한된 상황이기 때문에 AWS에서 제공하는 Blue-Green 무중단 배포 방법들을 참고해서 문제를 해결해보자.
Route 53으로 DNS 라우팅 업데이트
AWS의 DNS 서비스인 Route 53을 활용해서 무중단 배포를 구현할 수 있다.
다음과 같은 가중분포의 경우는 점진적으로 Green 환경으로 트래픽을 분산시킬 수 있다. 트래픽의 일부를 새로운 환경에서 처리해보도록 하는 카나리아 배포를 구현할 수 있다. ELB를 사용하면 Green 환경이 점차적으로 전체 프로덕션 부하를 감당하도록 점진적으로 스케일 아웃 할 수 있다. 다만 ELB에서 스케일 아웃은 즉시 이뤄지지 않으니 스케일 아웃이 잘 작동하는 지 모니터링하고 문제를 감지할 수 있도록 구현하는 게 중요하다.
Green 환경에서 문제가 발견되면 Route 53의 DNS 레코드를 롤백하는 방식으로 Blue 환경으로 롤백시킨다. 하지만 DNS 라우팅은 DNS TTL(클라이언트가 DNS 쿼리를 어느 시간만큼 캐시)를 고려해야 하고, 심지어는 클라이언트에 따라서는 특정 세션이 이전 환경에 연결되어 있는 경우가 존재할 수 있다.
Elastic Load Balancer 뒤에서 Auto Scaling 그룹 교체
DNS 라우팅 업데이트를 활용한 방법이 복잡하다면 ELB와 Auto Scaling 그룹을 활용해서 Blue-Green 배포를 구현할 수 있다.
다음과 같이 Blue 환경을 대기 상태로 만들어 놓고 유사 시에 빠르게 이전 버전으로 롤백할 수 있게 구현할 수도 있다. 만약 그럴 필요가 없는 경우는 이전 Auto Scaling 그룹을 폐기하면 된다.
이 방식은 DNS 방식만큼 세분하게 구현할 수는 없지만 DNS가 복잡하다면 도입해볼만 하다.
Elastic Beanstalk 애플리케이션 환경 교체
EB를 활용하면 인프라에 대한 지식이 많지 않아도 쉽게 애플리케이션을 배포할 수 있다. 배포하려는 어플리케이션 번들과 어플리케이션 버전, 멏 가지 정보를 제공하면 EB가 해당 정보를 기반으로 어플리케이션을 배포하고 어플리케이션에 액세스할 수 있는 URL을 제공한다.
EB는 Auto Scaling 그룹을 추가하는 방식이나 일부 인스턴스를 업데이트하는 방식으로 하나의 환경 안에서 롤링 방식으로 무중단 배포를 구현할 수 있다.
EB를 활용해서 Blue-Green 배포를 할 수도 있다. 배포되고 있던 환경과 동일한 환경을 만들고 해당 환경을 새 버전 어플리케이션으로 교체한 다음 새로운 환경의 URL을 DNS에서 업데이트 하는 방식으로 설계할 수 있다.
참고
https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html