무중단배포

목표

• 운영 서버의 다운타임 (downtime) 제거 → gitlab으로 배포 시 발생했었던
• 소프트웨어 개발 방법이론이 Agile 방식으로 바뀌면서 배포 빈도가 높아졌다.
• MicroService로 모듈화되어 독립적으로 개발하고 동시에 배포하고 있다.
  

로드밸런싱 (부하 분상)

• 다수의 자원 (중앙처리장치 등)이 작업을 나누어 처리하는 것
• 외부의 사용자로부터 들어오는 다수의 요청을 여러 서버에게 배분하여 나누어 처리하게 하는 것
• 외부로부터 요청을 서버가 직접받지 않고 ‘부하분산 network switch’ 혹은 ‘소프트웨어’가 받은 후 이를 서버로 적절히 나누어 주는 것

구현 방식

• AWS에서 Blue-Greem 무중단 배포
• 도커를 이용한 무중단 배포
• L4, L7 스위치를 이용한 무중단 배포
• Nginx를 이용한 무중단 배포

배포 방식 / 아키텍처

1️⃣ Rolling 배포

• 트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식

• 방법1

  1. 인스턴스를 추가하고, 새로운 버전으로 실행한다.
  2. 로드밸런서에 인스턴스를 연결하고 구버전 인스턴스를 하나 줄인다.
     

• 방법2

  1. V1이 실행되고 있는 인스턴스에 트래픽을 끊고, V2로 교체한다.
  2. 이 과정을 반복하여 나머지 서버도 교체한다.
     → 물리적인 서버에 적용 가능하다.
     

✅ 장점

1. k8s, elastic beanstalk과 같은 많은 오케스트레이션 도구에서 지원하여 간편하다.
2. 많은 서버 자원을 확보하지 않아도 된다.
3. 점진적으로 새로운 버전이 사용자에게 노출되어, 배포로 인한 위험성이 줄어들 수 있다.
4. 인스턴스마다 차례로 배로하기 때문에 롤백이 가능하다.
5. 배포가 빠르다.

✅ 단점

1. 방법2의 경우 배포 도중 인스터스 수가 줄어들어 나머지 서버에 대한 부담이 늘어날 수 있다.
2. 구버전과 신버전이 공조하여 호환성 문제가 발생할 수 있다.

2️⃣ Blue/Green 배포

• 트래픽을 한번에 구버전에서 신버전으로 옮기는 방법이다.
• Blue : 현재 운영중인 서비스 환경 Green : 새로 배포할 환경
  

• Blue와 Green을 동시에 구성하고 로드 밸런서가 트래픽을 일제히 전환시킨다.
• Green 버전 배포가 성공적으로 완료되었고, 문제가 없을 때 Blue를 제거할 수 있다.

✅ 장점

1. 호환성 문제가 발생하지 않는다.
2. 구버전과 동일한 운영 환경으로 신버전의 인스턴스를 구성하기 때문에 실제 서비스 환경에서 신버전을 미리 테스트할 수 있다.
3. 빠른 롤백이 가능하다.

✅ 단점

1. 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야 한다. → 클라우드 환경에 적합
2. 새로운 환경에 대한 테스트가 전제되어야 한다.

3️⃣ Canary 배포

• 점진적으로 구버전의 트래픽을 신버전으로 옮긴다는 점은 롤링 배포 방식과 비슷다.

• 새로운 버전에 대한 오류를 조기에 감지한다.

• 소수 인원 (예, 모바일 사용자) 만 새로운 버전에 옮겨둔 상태에서 서비스를 운영하며 모니터링 및 피드백 과정을 거친다.

• 새로운 버전에 이상이 없다고 판단하였을 경우에만 모든 트래픽을 신규 버전으로 옮긴다.

✅ 장점

1. 신버전의 배포 전에 실제 운영 환경에서 미리 테스트한다는 점은 블루-그린과 유사하다.
2. 단계적인 전환 방식을 통해 위험성을 최소화하고, 상황에 따라 트래픽 양을 늘리거나 롤백할 수 있다.
3. A/B 테스트 진행하기 적합하다.

✅ 단점

1. 신/구버전의 호환성 문제가 생길 수 있다.

---

참고

https://www.samsungsds.com/kr/insights/1256264_4627.html
https://hudi.blog/zero-downtime-deployment/