배포 전략

대표적인 배포 전략: Rolling, Blue/Green, Canary에 대해 알아보자.

Rolling

서버를 한 대씩 구 버전에서 새 버전으로 교체해가는 전략
서비스 중인 서버 한 대를 제외시키고 그 자리에 새 버전의 서버를 추가해서 구 버전에서 새 버전으로 트래픽을 점진적으로 전환한다.
서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스 수가 감소되기 때문에 서버 처리 용량을 미리 고려해야 한다.

1. v1, v1
2. -, v1
3. v2, v1
4. v2, -
5. v2, v2

Blue/Green

구 버전에서 새 버전으로 일제히 전환하는 전략
구 버전의 서버와 새 버전의 서버들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환시킨다.
하나의 버전만 프로덕션 되므로 버전 관리 문제를 방지할 수 있고, 빠른 롤백이 가능하다. 또한 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새 버전 테스트가 가능하다. 단, 시스템 자원이 두 배로 필요하고 전체 플랫폼에 대한 테스트가 진행되어야 한다.

blue group v1.0.1 안에 두 대의 서버로 요청을 나눠 처리하고 있을 때 green group v1.0.2 코드로 배포하려고 할 경우.
먼저 blue group에 존재하는 인스턴스 수와 동일하게 green group에 인스턴스를 만들고, green group에 v1.0.2 버전을 배포한다.
blue/green group 모두 로드밸런서에 연결해 잠시 동안 두 개의 그룹 모두 트래픽을 처리하도록 한다.
그 후 blue group에 존재하는 모든 인스턴스를 종료한 후에 로드밸런서에서 blue group을 제외하고 green group이 모든 요청을 처리하도록 한다.

blue/green 배포 방식은 구/신 버전이 동시에 떠있는 시간을 매우 짧게 처리할 수 있고, 롤백을 빠르게 할 수 있다. 운영 서버에 배포했을 때 문제가 발생하면 재빨리 기존 버전으로 롤백할 수 있다. 또한, 배포 과정에서 인스턴스 수가 줄지 않아 요청량을 처리하는 데서 오는 장애의 부담이 없다.

1. blue(ec2-1, ec2-2): v0.0.1 / green()
2. blue(ec2-1, ec2-2): v0.0.1 / green(ec2-1, ec2-2): v0.0.2
3. blue(ec2-1, ec2-2): v0.0.1 / green(ec2-1, ec2-2): v0.0.2
4. blue() / green(ec2-1, ec2-2): v0.0.2

Canary

카나리아 새 처럼 위험을 빠르게 감지할 수 있는 배포 기법.
구 버전의 서버와 새 버전의 서버들을 구성하고 일부 트래픽을 새 버전으로 분산하여 오류 여부를 판단한다.
A/B 테스트가 가능하여 오류율 및 성능 모니터링에 유용하다.
트래픽을 분산시킬 라우팅은 랜덤으로 할 수도 있고, 사용자 프로필 등을 기반으로 분류할 수도 있다. 분산 후 결과에 따라 새 버전이 운영 환경을 대체할 수도 있고, 다시 구 버전으로 돌아갈 수도 있다.

1. v1(100%) / v2(0%)
2. v1(90%) / v2(10%)
3. v1(50%) / v2(50%)
4. v1(10%) / v2(90%)
5. v1(0%) / v2(100%)