[DevOps] 무중단 배포 아키텍처와 배포 전략

중단 배포 방식과 다운타임

---

 

서버 한대로 서비스를 운영한다면, 서버 배포 시 어떻게 될까.

 

현재 서버에서 V1 버전이 실행되고 있는 상황이다. 그리고 우리는 여러 기능이 추가된 V2 버전을 새로 개발했다. 이제 사용자들이 V2 버전을 사용할 수 있도록 배포해야 한다.

 

배포를 하려면 우선 기존에 V1 버전이 실행되고 있는 서버를 중지시켜야 한다. V1 버전과 V2 버전은 서로 같은 포트를 사용하므로, V2 버전을 실행하기 전에 먼저 V1 버전의 프로세스를 중단해야 한다. 이 시점부터 사용자들은 서비스를 사용할 수 없게 된다. 사용자가 V2 버전을 사용할 수 있도록 바로 V2 버전을 빌드 후 실행해야 한다. 빌드, 로딩과정을 거치고 V2 버전이 정상적으로 실행되면 사용자들은 서비스를 이용할 수 있게 된다.

 

이러한 배포 방식을 중단 배포라고 하며, V1 버전이 종료되고 V2 버전이 실행되는 그 사이, 즉 사용자가 서비스를 이용할 수 없는 시간을 다운타임(Downtime) 이라고 한다.

 

 

무중단 배포 (Zero-downtime Deployment)

---

무중단 배포는 말 그대로 서비스가 중단되지 않은 상태(zero-downtime)로 새로운 버전을 배포하는 것을 의미한다. 무중단 배포를 하기 위해서는 최소 2대 이상의 서버가 확보되어야 한다.

 

 

롤링(Rolling) 배포

---

Rolling Deployment

롤링 배포란 트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식이다.

 

롤링 배포 방식은 쿠버네티스, AWS Elastic Beanstalk과 같은 많은 오케스트레이션 도구에서 지원하여 간편한 방식이다. 또, 많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다.

점진적으로 새로운 버전을 사용자에게 출시하므로, 배포로 인한 위험성이 다소 줄어들 수 있다.

 

하지만, 배포 도중 서비스 중인 인스턴스의 수가 줄어들게 되므로, 각각의 서버가 부담하는 트래픽의 양이 순간적으로 늘어날 수 있다. 따라서, 전체 트래픽의 양과 단일 서버가 처리할 수 있는 트래픽의 양을 잘 파악하여 배포를 진행해야 한다.

또, 구버전과 신버전이 동시에 서비스되기 때문에 호환성 문제가 발생할 수 있다.

 

 

Blue/Green 배포

---

Blue/Green Deployment

트래픽을 한번에 구버전에서 신버전으로 옮기는 방식이다. 현재 운영중인 서비스 환경을 Blue, 새롭게 배포할 환경을 Green이라고 부른다.

 

Blue 와 Green의 서버를 동시에 나란히 구성한 상태로 배포 시점에 로드 밸런서가 트래픽을 Blue에서 Green으로 일제히 전환시킨다. Green 버전 배포가 성공적으로 완료되었고, 문제가 없다고 판단했을 때에는 Blue 서버를 제거할 수 있다. 혹은 다음 배포를 위해 유지할 수 있다.

 

롤링 배포와 달리 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 트래픽 문제나 호환성 문제가 발생하지 않는다.

 

하지만, 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야 한다. 클라우드 환경에서 운영한다면 필요없는 인스턴스를 바로바로 제거하면 그만이지만, 온프레미스 환경에서는 부담이 클 것이다.

 

 

카나리(Canary) 배포

---

Canary Deployment

점진적으로 구버전에 대한 트래픽을 신버전을 옮기는 것은 롤링 배포와 비슷하지만, 카나리 배포의 핵심은 새로운 버전에 대한 배포를 조기에 감지하는 것이다.

 

소수 인원에 대해서만 트래픽을 새로운 버전으로 옮겨둔 상태에서 서비스를 운영한다. 새로운 버전이 이상이 없다고 판단되면 모든 트래픽을 신규 버전으로 옮긴다. 이 때, 새로운 버전으로 옮기는 기준은 정해진 규칙(특정 유저 등) 혹은 랜덤이다.

 

카나리 배포의 이름은 예전 광부들이 가스에 예민한 카나리아 새를 활용하여 가스 누출을 감지했다는 이야기에서 유례되었다.

 

새로운 버전으로 인한 위험을 최소화할 수 있다는 장점이 있다.

 

하지만, 롤링 배포와 마찬가지로 신/구 버전의 어플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다.

 

 

---

참고

https://www.samsungsds.com/kr/insights/1256264_4627.html

https://onlywis.tistory.com/10

https://hudi.blog/zero-downtime-deployment/