무중단 배포 부터 알아보겠다.
서비스의 버전이 바뀌고 새로운 버전으로 업데이트 할 때 구버전의 프로세스를 종료하고 신버전의 프로세스를 진행시킨다. 그러면 신버전이 올라갈 때 까지 요청을 처리할 수 없게 된다.
이 시간을 다운타임이라고 한다. 이 다운타임을 없애기 위한 방법들은 여러가지가 있으며(롤링, 블루그린, 카나리) 오늘은 블루 그린 배포에 대해서 더 자세히 알아볼 것이다.
블루는 구버전, 그린은 신버전을 의미한다.
운영중인 구버전과 신버전의 인스턴스를 구성한 후 로드 밸런서를 통해서 모든 트래픽을 한번에 신버전 쪽으로 전환하는 방식이다.
- 구버전의 인스턴스가 그대로 남아 있어 롤백이 용이하다.
- 구버전의 환경을 다음 배포에 재사용할 수 있다.
- 운영환경에 영향을 주지 않고 새 버전이 테스트가 가능하다.
- 시스템 자원이 두배로 필요하다.
- 새로운 환경에 대한 테스트가 전제되어야한다.
다음과 같은 상황을 예시로 들어보겠습니다.
- 오토스케일링 그룹을 사용하고 있다.
- 하루에 수없이 많은 인스턴스가 자동으로 생성, 종료된다.
- 배포시 블루/그린 배포를 해야한다.
여기서 인스턴스는 자동으로 추가되기 때문에 인스턴스가 생길 때마다 사람들이 인스턴스에 접속해서 소스코드를 최신화 시킬 수는 없습니다.
그래서 최신 코드를 가지는 EC2 AMI를 사용해 인스턴스를 만듭니다.
AMI를 생성할 때만 쓰이는 Main 소스 코드를 담당하는 EC2를 가지고 있어야 합니다. (평상시에는 정지되어 있고 소스 코드가 업데이트 되어 AMI를 변경하고자 할 때 인스턴스를 실행시켜 AMI를 만듭니다.)
v1.02 버전으로 업데이트를 하기 위해서는 새로운 버전의 AMI를 만들어야 합니다. 즉 위에서 보았던 것 처럼 Green 그룹의 Blue 그룹에 존재하는 인스턴스 수를 똑같이 맞추어줍시다.
위와 같이 새로운 시작 템플릿에 새로운 버전의 AMI를 넣고 만들어야 합니다.
그리고 로드 밸런서에 그린, 블루 그룹을 등록해서 잠시동안 그린, 블루 그룹의 인스턴스들의 모든 요청을 나눠 처리합니다.
블루, 그린 그룹에서 모두 요청을 처리하는 데 문제가 없는 것을 확인하면 블루 그룹을 로드 밸런서에서 제외합니다.