많은 서비스 기업들이 짧은 주기로 배포를 진행하고 있다. 짧은 주기 배포를 통해 유저의 피드백을 빠르게 받고 문제를 빠르게 수정한다. 또 한, 사용자에게 제품의 가치를 빠르게 전달한다. 이런 상황에서 서비스 중단을 요구하는 중단 배포를 사용하면 다운 타임이 발생하고 고객 경험을 해치는 요소가 될 수 있다. 예컨대 Big Bang Deployment는 애플리케이션의 상당 부분을 한 번에 배포한다. 그 때문에 광범위한 개발과 상당한 테스트를 요구한다. 한 번에 모든 변경을 배포하기 때문에 배포 중에는 서비스를 사용할 수 없으며 문제 발생으로 인한 롤백 시 많은 비용이 부과된다. 광범위한 개발은 릴리즈 주기를 길게 만들고 롤백 비용이 크다는 것은 배포에 부담을 안긴다. 즉, 짧은 주기 배포로 고객의 요구를 빠르게 만족시켜야 하는 현재 상황과는 맞지 않는 배포 방식이다.
그에 반해 무중단 배포는 서비스를 중단하지 않기 때문에 배포에 대한 부담이 적다.
무중단 배포를 하기 위해선 여러 대의 서버가 존재해야 하며 클라이언트와 서버 사이에 로드밸런서가 로드밸런싱을 해주고 있어야 한다.
무중단 배포 방식
무중단 배포 방식은 크게 롤링 배포, 블루-그린 배포, 카나리 배포로 나뉜다.
Rolling Deployment
롤링 배포는 점진적으로 구버전 애플리케이션을 새로운 버전으로 교체하는 방식이다. 로드밸런서에서 새 버전으로 업데이트하는 서버의 라우팅을 끊고, 새 버전으로 업데이트가 끝나면 다시 라우팅 하는 방식으로 진행된다. 교체 도중에는 각 서버가 다른 서버 기능에 영향을 주지 않는다. 롤링 배포는 새 버전에 문제가 발생했을 때 롤백하기 쉽다는 장점이 있다.
롤링 배포를 도식화하면 다음과 같다.
장점
- 차례대로 배포를 하기 때문에 새버전에 문제 발생 시 쉽게 롤링할 수 있다.
- 추가적인 인스턴스가 필요 없다.
단점
- 새버전 배포 시 인스턴스 수 감소로 인해 트래픽이 몰릴 수 있다.
- 배포 도중에 사용자들이 균등한 서비스를 제공받지 못한다.
Blue-Green Deployment
두 개의 동일한 환경을 가진 서버 그룹이 존재한다. Blue 라 불리는 한 그룹은 기존 버전이며 모든 유저 트래픽을 감당한다. 다른 한 그룹은 green이라 불리며 새로운 버전 배포를 위해 사용된다.
그린에 새 버전이 배포되면 기능과 퍼포먼스에 대한 테스트를 진행한다. 테스트가 성곡적으로 완료되면 블루로 라우팅 되던 트래픽을 그린으로 옮긴다. 만약 배포된 후 문제가 발생했다면 언제든지 다시 블루로 옮길 수 있다.
Blue-Green 배포 방식에서는 블루, 그린 모두가 같은 영속 레이어를 사용한다. 따라서 데이터 동기화가 중요하다. 데이터 동기화를 위해 블루에서는 쓰기를 담당하는 마스터 DB를, 그린에서는 읽기 연산을 담당하는 슬레이브 디비를 사용할 수 있다. 만약 그린에서도 쓰기 연산이 필요하다면 bi-bidirectional replication을 사용하면 된다.
Carnary Deployment
카나리 배포는 블루-그린 배포와 비슷하나 한 번에 블루에서 그린으로 바꾸지 않는다는 점이 다르다. 카나리 배포는 소수의 유저만 새로운 버전의 애플리케이션을 사용하게 해서 실제 배포 환경에 문제가 있는지 테스트한다. 만약 문제가 없다면 나머지 애플리케이션 역시 새로운 버전으로 업데이트한다.
카나리 배포에서는 어떤 방식을 통해 소수의 유저만 새로운 버전을 사용하게 할지를 정해야 한다. 이를 위해 다음과 같은 방식을 사용할 수 있다.
1. IP 범위를 기반으로 유저를 나누어 라우팅 한다.
2. 특정 리전 서버에만 배포한다.
3. 애플리케이션 로직을 통해 특정 유저 그룹에만 새 버전을 공개한다. 배포가 완료되면 해당 로직을 삭제한다.