-
Rolling Deployment
SPOF(single point of failure)를 대비하기 위해서는 로드밸런서도 두개가 필요 
Rolling Deployment 진행도 *single point of failure : 단일장애점은 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소
High Availability(고가용성 : 서버와 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질, "절대 고장나지 않음")을 위해 프로덕션 환경은 2대 이사으이 서버로 구성한다.
이런 환경에서 무중단 배포하기 가장 간단한 방법이 바로 Rolling Deployment 이다.
시나리오
1. 서버1을 로드밸런서에서 뺀다.
2. 서버1에 배포한다.
3. 서버1을 다시 로드 밸런서에 넣는다.
4. 서버2를 로드 밸런서에서 뺀다.
5. 서버2에 배포 한다.
6. 서버2를 다시 로드 밸런서에 넣는다.
위와 같이 하면 다운타임 없이 배포가 가능하다.
배포해야할 서버가 너무 많다면 1대씩 배포하면 너무 느리니 N대 단위로 배포하기도 한다.
하지만 배포가 끝나기 전까지는 이전 버전을 서비스 받는 유저와 신규 버전을 서비스 받는 유저가 공존하는 등의 문제가 존재
한다. 또한 1대에 배포하는 거보다 최소 2배 이상 느리다. (최소 2번 이상의 배포가 진행되기 때문에)
배포를 위해 서버 일부가 로드 밸런서에서 제외되어 일부 서버에 트래픽이 몰리기 때문에 서버 처리 용량을 고려해야한다.
Canary Deployment
Canary Deployment 진행도 광부들이 광산에서 유독가스가 나오는 것을 알아내기 위해서 가스에 민감한 카나리아(조류)를 광산 안에서 키원다고 해서 유래된 배포이다. 소수의 유저(혹은 사내)만 사용하는 환경(Canary 환경)에 신규 버전을 배포하고 문제가 없다고 판단됐을 때 다른 모든 서버에 배포한다. Canary 환경은 QA Phase가 될 수도 있고, 랜덤하게 유저를 Canary 환경으로 라우팅시킬 수도 있고 구현하기 나름이다.
Blue/Green Deployment
실제로 서비스 중인 환경(Blue)과 새롭게 배포할 환경(Green)을 세트로 준비해서 배포하는 방식을 말한다.
장점으로는 새롭게 배포할 환경에만 배포하면 되기 때문에 배포 속도가 매우 빠르다. (배포할 서버가 N대라 하더라도 N대의 Green서버에 동시에 배포하면 되기 때문에)
또한 언제나 Green 환경이 떠있기 때문에 만약에 잘못된 버전으로 배포를 했을 경우에 신속하게 롤백이 가능하다.(수 백대의 서버에 거의 수초 이내에 롤백이 가능함.)
물론 언제나 Green 환경이 떠있어야하기 때문에 비용이 두 배로 든다는 단점도 있다.
또한 Green 환경에서 Scheduler와 같은 배치성 Job이 도는 경우에 레거시 버전으로 돌기 때문에 장애가 발생할 가능성도 존재한다.
그림에서는 Nginx를 프록시 서버로 사용했지만 Apache 등을 사용해도 무방하다.
또한 하나의 서버에 두 대의 어플리케이션을 띄우는 걸로 설명했지만 별도의 서버에 하나의 어플리케이션만 각각 띄워서 구성해도 된다.
Deployment
젠킨스와 같은 CI를 사용하여 Green 환경에 배포를 완료 
Nginx와 같은 프록시 서버에서 80포트로 들어오면 Green 환경으로 라우팅하도록 설정 Rollback 방안
새로 배포한 Blue 환경에서 버그가 발생했다고 가정 
이 때 프록시 서버에서 80포트의 라우팅을 Green 환경으로만 옮겨서 Blue와 Green을 바꾸기만하면 롤백이 완료 
Green 환경이 죽은 상태에서는 롤백이 불가능 
Blue/Green Deployment 진행도 참고
https://perfectacle.github.io/2019/04/21/non-stop-deployment/