Deployment Strategy이란?
예전에는 서비스 릴리스가 자주 발생하지 않았습니다. 하지만 최근에는 서비스를 더 작게 만들고(마이크로 서비스) 더 자주 배포(Deployment) 하는 방식으로 변화하고 있습니다. 그만큼 변경 사항이 생겼을 때 더 빠르게 반영하기 위한 방식으로 변하고 있으며, 이때 서비스 중단 여부에 따라 무중단/중단 배포 전략으로 나뉩니다.
그중 무중단 배포 전략은 아래 4가지 방식이 있습니다.
- 인플레이스 배포(In-Place Deployement)
- 롤링 배포(Rolling Update Deployement)
- 블루/그린 배포(Blue/Green Deployement)
- 카나리 배포(Canary Deployement)
인플레이스 배포(In-Place Deployement)
인플레이스 배포는 사용중이던 리소스에 previous 버전 → new-release 버전을 적용한 배포전략 입니다.
1. 4개의 previous 버전의 인스턴스가 서비스 진행중이다.
2. 그중 좌측 첫번째 인스턴스를 LB로부터 분리해 트래픽 유입을 방지한다.
3. 연결이 끊어진 인스턴스에 new-release 버전으로 배포한다.
4. 해당 인스턴스를 다시 LB에 연결한다.
위의 방식으로 4개 인스턴스에 순차적으로 적용됩니다.
장점으로는
- 블루/그린 배포보다 비용적으로 절감이 가능하다.
단점으로는
- new-release 버전이 배포될 때 인스턴스 수가 감소하기 때문에 사용중인 인스턴스에 트래픽이 몰릴 수 있다.
- 배포가 진행될때 previous 버전과 new-release 버전이 공존하기에 호환성 문제가 발생할 수 있다.
롤링 배포(Rolling Update Deployement)
사용중인 인스턴스 내에서 새 버전을 점진적으료 교체하는 방식입니다. 서비스 진행중이던 인스턴스 1개를 LB에서 라우팅하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅되도록 합니다. 정리하자면,
1. 4개의 previous 버전의 인스턴스가 서비스 진행중이다.
2. 그중에 좌측 첫번째 인스턴스를 LB로부터 분리해 트래픽이 유입되지 않도록 한다.
3. 연결이 끊어진 인스턴스말고 새롭게 생성된 인스턴스에 new-release 버전으로 배포한다.
4. 새롭게 생성된 인스턴스(new-release 버전 적용완료)를 다시 LB에 연결한다.
위의 방식으로 4개 인스턴스에 순차적으로 적용됩니다.
인플레이스 배포는 리소스(Ex. EC2) 한개로 previous 버전 → new-release 버전으로 변경 후 배포하는 것이며, 롤링 배포의 경우 새롭게 생성된 리소스에 new-release 버전을 적용한 뒤 배포가 이뤄진다는 것입니다. 즉, 기존에 사용되던 리소스의 재사용 여부에 따른 차이점이 존재합니다.
장점으로는
- 인스턴스마다 차례로 배포를 진행하기에 상황에 따라 손쉽게 롤백이 가능하다.
- 추가적인 인스턴스를 늘리지 않아도 된다.
단점으로는
- new-release 버전이 배포될 때 인스턴스 수가 감소하기 때문에 사용중인 인스턴스에 트래픽이 몰릴 수 있다.
- 배포가 진행될때 previous 버전과 new-release 버전이 공존하기에 호환성 문제가 발생할 수 있다.
Blue / Green 배포
애플리케이션 사용자 트래픽이 previous 버전에서 new-release 버전으로 점진적 이전하는 모델입니다. 이때 두 버전(previous, new-release) 모두 운영 환경에서 실행 상태를 유지합니다.
블루/그린 배포는 하나의 버전만 운영 환경에서 적용되기 때문에 하나의 운영 환경에서 동시에 2개 버전(previous, new-release)이 운영되는 문제를 방지 할 수 있습니다. 또한 운영환경에 영향을 주지 않고 new-release 버전을 따로 테스트 할 수 있습니다.
장점으로는
- previous 버전의 인스턴스가 그대로 남아있어서 손쉬운 롤백이 가능합니다.
- previous 버전의 환경을 다음 배포에 재사용 할 수 있습니다.
- 버전 충돌 문제를 방지 할 수 있습니다.
- new-release 버전을 따로 테스트 해볼 수 있습니다.
단점으로는
- 시스템 자원이 두배로 필요합니다. (⇒ But, AWS와 같은 클라우드 서비스에서 종량 과금이라는 메리트가 있어 큰 부담 요소로 작용되지 않습니다.)
카나리 배포(Canary Deployement)
신버전을 소수의 유저들에게만 배포를 해보고 문제가 없는것을 확인해가며 점차 많은 유저들에게 배포하는 기법입니다. 블루그린 배포와 유사하지만 트래픽을 한번에 바꾸는 것이 아니라 단계적으로 전환하기에 부정적 영향을 최소화하고 상황에 따라 트래픽 양을 조절하며 롤백 할 수 있습니다.
장점으로는
- 문제 상황을 빠르게 감지 할 수 있습니다.
단점으로는
- 네트워크 트래픽 제어가 부담됩니다.
- 추가 인스턴스 및 자원이 필요합니다.
참고
- DeveopersIO : https://dev.classmethod.jp/articles/ci-cd-deployment-strategies-kr/
- AWS Deployment Strategies : https://www.pluralsight.com/guides/aws-deployment-strategies