무중단 배포 전략( Zero-downtime Deployment )

클라이언트 입장에서 서비스가 끊어지지 않으면서(Zero-downtime) 새로운 버전을 업데이트

---

배포 전략

1. 롤링 배포 ( Rolling Deployment )

일반적인 방식, 점진적으로 배포 버전을 바꾸는 방식

배포 스크립트를 짤 때, 배포 순서별로 딜레이를 준다.

ex) 리눅스 sleep 사용을 사용하여 구현

1번 서버 다운 → 30분 뒤에 2번 서버 다운 (그 사이에 1번 서버가 버젼 업)

• 장점
  많은 오케스트레이션 도구에서 지원하여 간단하다.
  많은 서버 자원을 확보하지 않아도 무중단 배포가 가능
  점진적으로 버전을 바꾸니 배포에 의한 위험성이 다소 줄어든다.

오케스트레이션?
여러 개의 컴퓨터 시스템, 애플리케이션 및/또는 서비스를 조율하고 관리하는 것

• 단점
  배포 중 문제가 발생하거나 했을 때 처리가 까다로움
  → '순서대로 진행 중인데 배포 과정에서 오류가 생긴다면?'
  서비스 중인 인스턴스 수가 줄어들어 인스턴스 별로 부담하는 트래픽 양 증가
  2가지 버전이 동시 서비스하는 과정에서 호환성 문제 발생 이슈
  

2. 블루/그린 배포 ( Blue/Green Deployment )

<현재 운영 중인 서비스 버전 : 블루 / 새롭게 배포할 버전 : 그린>

블루/그린 버전을 나란히 구성해둔 상태에서
로드 밸런서가 트래픽을 블루에서 그린으로 모두 변경하는 방식

• 장점
  한번에 트래픽을 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않음.
  롤백이 용이하다. (그린 서버에서 문제 발생 시, 트래픽을 블루로 옮기면 된다.)
  -> 문제가 없다면 블루 서버를 제거한다.
  

• 단점
  실제 운영에 필요한 서버보다 2배 많은 리소스를 확보해야한다.
  -> 클라우드 환경을 통해 단점이 많이 희석됨.

3. 카나리 배포 ( Canary Deployment )

Rolling Deployment + Blue/Green Deployment
+ 새로운 버전에 대한 오류를 조기에 감지 (A/B테스트)

블루/그린 버전을 나란히 구성 ( Blue/Green )
점진적으로 블루에서 그린으로 트래픽을 옮김 ( Rolling )
-> 유저군 / 가중치에 따라 일부만 그린 버전으로 트래픽을 보냄. ( A/B테스트 )

A/B테스트?
	두 가지 또는 그 이상의 시안을 실험하여
    비즈니스에 최상의 결과를 가져오는 버전을 알아내는 웹 사이트 최적화 방법

• 장점
  A/B 테스트를 통한 모니터링
  -> 새로운 버전으로 인한 위험을 최소화할 수 있다.
  

• 단점
  롤링 배포와 마찬가지로 호환성 문제가 발생할 수 있다.