요즘은 MSA 아키텍처를 많이 지향하고 있는 추세이다. 이런 트렌드에 맞춰
배포 전략도 다양하게 개발되고 발전하여 변화하고 있다.
여기서 우리가 오늘 살펴볼 내용은 여러가지 배포 전략과 테스트 방법이다.
롤링(Rolling)
일반적인 배포를 의미하며, 단순하게 서버를 구성하여 배포하는 전략이다.
다시 말해 구 버전에서 신 버전으로 트래픽을 점진적으로 전환하는 배포이다.
관리가 편하지만, 배포 중 한쪽 인스턴스의 수가 감소되므로 서버 처리 용량을
미리 고려해야 한다.
Blue-Green Deployment
일반적인 서비스 배포 과정에서 항상 맞딱드리게 되는 문제가 있다. 배포 전에 서비스를 잠시 중단 시키고 배포를 진행하려고 할때 서비스가 중단되면 사용자들의 불편함이 생기게 될 것이고, 특정 영역의 업무에서는 꽤나 큰 위험성이 발생 될 수도 있다.
그렇기 때문에 무중단 배포 전략이 필요하게 되었고 그 중에서 특히, Blue-Green 배포는 이미 Amazon에서 10년이 넘는 기간동안 이루어졌다.
그만큼 안정적이고
검증된 배포 프로세스이며 기본적으로 릴리즈와 관련된 모든 downtime을 줄이기 위한
Apllication Release 기술이다.
아래 그림을 보면서 시나리오로 예를 들어보자.
먼저 파란색이 실제 운영중인 환경이라고 가정해보자. 새로운 버전의 소프트웨어를 릴리즈 하고 싶은 경우, 그 소프트웨어의 테스트가 필요하다. 그 테스트는 초록색에서 진행하게 된다.
초록색에서 테스트를 무사히 마친다면 이제 소프트웨어 버전을 업데이트 할 차례이다.
여기서 파란색으로 들어가는 모든 Reqeust를 초록색으로 향하도록 라우터 설정을
변경해 준다.
이때, 초록색으로 향하는 요청은 파란색에도 동시에 요청을 라우팅한다( 백업 용도 )
그럼 여기서 요청이 더 이상 없는 파란색은 어떤 역할을 할까?
-
1. 그 다음 릴리즈를 진행 할 때 소프트웨어를 업데이트하기 전 테스트 환경으로 사용 할 수 있다. 이전에 초록색이 담당했던 업무이다. 즉, 역할이 릴리즈 할 때마다 그린, 블루가 Swapping 된다. -
2. 배포가 완료되고 나서 초록색이 잘 동작하다가 오류가 난다면, 이 때 이전 버전으로 다시 되돌리기 위한 백업 서버 역할을 하기도 한다.
2 번의 경우를 흔히 롤백(roll-back)이라고 부른다. 문제가 발생하면 다시 모든 요청들을 파란색으로 보냄으로써, 빠르고 간단하게 문제를 해결한다.
하지만 여전히 문제가 있다. 바로 초록색에 문제가 있는지 몰랐을 때 초록색으로
이동함으로써 유실된 요청들(여기서 트랜잭션이라고 하겠다) 에 대한 처리가 필요하게 된다.
이 문제도 Blue-Green 배포전략에서는 해결책을 가지고 있다. 들어오는 모든 요청들을
항상 파란색과 초록색 양방향으로 보낸다.
실질적으로는 한 쪽만 사용자에게 비춰지겠지만, 요청되는 모든 트랜잭션들은 다 공유하고 있자는 전략이다.
Blue Green 배포의 장점을 다시 한번 정리해보자.
1 .Zero Downtime
위에서 언급한 것처럼, 가장 핵심적인 장점은 무중단 배포이다.
유저가 업데이트를 체감하지 못하게 함으로써, 유저의 불편함이나 이탈을 최소화 할 수 있다.
2 .쉬운 롤백(roll-back)
Blue Green 배포 방식이 아닌, 중단 후 배포 방식을 선택했다고 가정해보자.
배포 후 신규 버전에서 치명적인 결함이 발결되었다면 어떻게 조치할까?
신규 버전에는 이미 활성 사용자들이 있기 때문에,
서버를 다시 닫고, 데이터를 백업 한 후 기존 서버로 롤백하고 다시 서버를 연다.
하는 방식으로 롤백이 수행되어야 한다.
Blue Green 배포 방식은 이와 같은 문제를 발생시키지 않는 최적의 롤백 환경을
제공한다.
3. 최종단계 테스트
새로운 기능을 추가하여 신규 배포하는 일은, 개발자들에게 여전히
부담스러운 일임이 분명하다.
새 버전이 어떤 오류를 발생시킬지 예측하기 어렵기 때문이다.
Blue Green 배포 방식을 채택할 경우 아래의 장점이 있다.
초록색에서 테스트를 마치고 파란색으로 라우팅을 서서히 변경할 때, 초록색과
파란색이 서로 트랜잭션을 공유하고 있기 때문에 이 시간을 최대한 길게
유지하는 방식으로 최종 단계 테스트를 해 볼 수 있다.
이론적으로 완벽한 이 배포 방법에도 고려해야 할 점이 있다.
Green과 Blue 똑같은 환경을 지닌 인프라를 2 Set 준비를 해야 한다. 당연히 Blue-Green을 활용하기 위해서는 현재 운영 중인 인프라의 2배의 리소스가 필요하다.
A/B Testing
많은 사람들이 A/B Testing과 Blue-Green Deployment를 구분하지 못한다.
간단히 말해 A/B Testing은 기능적으로 Upgrade된 적용이 아닌, 서로 다른 두 가지 버전의
Application 중 유용성, 인기도, 눈에 띄는 정도 등과 같은 다양한 이유로 Application 기능을
테스트 하는 방법이다.
Blue-Green 배포와 A/B Testing의 차이점은 A/B Test는 단지 App의 기능을
측정하는 도구로 사용된다는 것이고, Blue-Green 배포는 새로운 버전의 기능을
안전하게 Release하고, 예상대로 Rollback하는 것을 목표로 삼는다는 것이다.
Canary Release
‘Canary’라는 용어의 어원을 알면 이해가 더 쉽다. Canary는 카나리아 라는 새를 일컫는 말인데, 이 새는 일산화탄소 및 유독가스에 매우 민감하다고 한다. 그래서 과거 광부들이 이 새를 옆에 두고 광산에서 일을 하다가 카나리아가 갑자기 죽게 되면 대피를 했다고 한다.
Canary 배포는 새로운 버전의 Application을 Production 환경으로 보내어 어떻게
동작하는지 모니터링 하는 도구로 사용될 수 있다.
예를들어, 다른 Application과의 연계, CPU, MEM, DISK 사용량 등을 미리
검증할 수 있다.
새로운 버전의 앱을 Production 환경에 보내어, LB에서 일부 세션이 그 곳에 물리도록 만든다. 만약 이상 동작을 한다면 바로 Canary를 철수 시켜 정상적인 버전으로 새로운 세션을 맺게 만들어 준다.
이 Release를 이용하여 Full Release 전에 발생할 수 있는 여러가지 Issue를 검증할 수 있다.
Reference
https://jason-lim.tistory.com/3
https://wallees.wordpress.com/2018/04/22/blue-green-%EB%B0%A9%EC%8B%9D/
https://artist-developer.tistory.com/26