(CS) 무중단 배포

프로젝트나 서비스 개발에 백엔드 개발자로 참여하였을 때, 로컬이 아닌 실제 환경에서 개발한 기능들을 테스트하고 또 사용하기 위해서 반드시 진행해야 하는 작업이 있다. 그것은 바로 배포이다.

1년이 넘는 시간 동안 백엔드 개발을 많이 진행하였기에 여러 번 배포를 진행하였지만, 무중단 배포에 대해서는 들어만 보았을 뿐 정확하게 어떤 방식으로 진행되는지에 대한 학습조차 되어 있지 않았다. 현재 진행 중인 프로젝트에서 무중단 배포를 진행해 볼 기회를 얻어서 이에 대해 학습 후 정리해보고자 한다.

배포란?

무중단 배포에 대해 정리하기에 앞서 배포가 무엇인지 먼저 간단하게 알아보고자 한다.

배포라는 단어 자체는 원래 신문이나 책자 등을 널리 나누어주는 행동을 나타내는 말이다. 소프트웨어 관점에서 말하는 배포도 역시 비슷한 의미라고 할 수 있겠다.

 

소프트웨어 배포는 서버의 특정 URL을 지원하는 것과 같이 소프트웨어 시스템을 사용할 수 있도록 하는 하나의 애플리케이션 또는 애플리케이션 제품군을 설치, 구성, 업데이트 및 활성화하는 프로세스이다.

물론 위에서 언급한 정의는 기업에서 내린 정의이기에 간단한 프로젝트에서 진행한 배포보다는 훨씬 큰 개념일 것이다. 학생들이 진행하는 토이 프로젝트 레벨에서의 배포는 간단하게 말해서 개발을 마친 하나의 애플리케이션(서버, 프론트, 앱 등등)을 사용자들을 위해 활성화하는 것이다. 활성화의 방법으로는 외부에서 접근 가능한 컴퓨터에 프로그램을 실행해 두는 방법과 앱 스토어에 애플리케이션을 출시하여 사용자가 다운로드할 수 있도록 하는 방법 등을 예시로 들 수 있다.

위의 그림은 실제로 필자가 진행한 프로젝트의 구조도이다. 만약 위 프로젝트의 사용자 입장에서 서비스를 사용하려고 한다면, 프론트 페이지(React)에 접속하고, 백엔드 서버(NestJS)의 API를 통해 필요한 데이터를 받음으로써  서비스를 완전하게 사용할 수 있다. 이는 서비스의 개발자들이 프론트 페이지를 Cloudflare를 사용해서 배포를 하였고, 백엔드 서버도 AWS EC2를 통해 배포를 해두었기에 가능한 일이다. 배포를 진행하지 않았다면, 외부의 사용자는 서비스를 사용할 수도, 애초에 접속할 수도 없다. 이처럼 배포는 서비스 사용자를 위한 활성화의 개념으로 생각할 수 있다.

무중단 배포란?

그렇다면 무중단 배포(Zero-Downtime Deployment)는 무엇일까? 무중단 배포는 말 그대로 배포를 하되 중단 없이 배포를 진행하는 것이다. 사용자가 배포된 애플리케이션을 계속 사용하면서 업데이트를 적용하는 전체적인 프로세스를 무중단 배포라고 한다.

 

보통 우리가 일반적으로 진행하는 배포 방식은 서버를 중지하고 업그레이드 버전의 코드를 다시 배포하는 방식으로 이루어지기에 필연적으로 배포와 배포 사이에 중단이 발생할 수밖에 없다. 이러한 방식은 사용자에게 서비스 중단으로 인한 비효율적인 서비스 이용 경험을 제공한다는 치명적인 단점을 가진다.

이러한 문제를 해결하기 위해 새로운 버전을 배포하는 동안에도 계속해서 서비스를 제공할 수 있는 무중단 배포를 사용한다.

실생활에서 예시를 들어보면 은행 서비스나 게임의 점검으로 인한 사용 중단을 들 수 있겠다. 은행 서비스나 게임의 경우에는 보통 새벽 시간에 점검을 진행하여 그 시간 동안에는 해당 서비스의 사용이 불가능하다. 이런 경우에 급하게 돈을 송금해야 하거나 게임을 즐기고 싶은 사용자가 있다면, 원하는 대로 애플리케이션을 사용할 수 없기에 그 사용자에게 큰 불편함을 줄 수밖에 없다. 무중단 배포를 사용하지 않아 배포 도중 중단이 발생한 경우와 비슷하게 생각할 수 있다.

실제 은행 서비스나 게임 점검과는 다르게, 만약 무중단 배포를 사용한다면 송금이 급한 사용자나 게임을 얼른 즐기고 싶은 사용자나 원하는 작업을 중단 없이 진행할 수 있었을 것이다.

무중단 배포 방법

기본적인 무중단 배포의 방식부터 알아보자. 

무중단 배포의 기본 구성은 위와 같다. 여기서 가장 핵심은 역시 로드밸런서(Load Balancer)라고 할 수 있다. 로드 밸런서를 통해 연결된 두 개 이상의 인스턴스에 들어가는 트래픽을 제어하며 배포하는 것이다. 여러 개의 인스턴스 뿐만 아니라 고객의 수가 많아진다면 로드밸런서 또한 다중화가 필요해진다. 즉, 무중단 배포를 위해서는 고가용성의 시스템 인프라가 구성되어야 있어야 한다.

 

실제로 사용되는 무중단 배포의 방식으로는 크게 2가지를 뽑을 수 있다. 제한된 자원 내에서 하나씩 배포하며 변경 해가는 롤링 배포(Rolling Deployment) 방식과 현재 사용 중인 버전의 인스턴스 수만큼 새 버전의 인스턴스를 준비한 후 로드밸런서로 스위칭을 하는 블루-그린 배포(Blue-Green Deployment) 방식이다. 추가적으로 블루-그린 배포 방식의 소프트한 버전인 카나리 배포(Canary Deployment) 방식도 존재한다.

롤링 배포

먼저 롤링 배포이다. 현재 사용 중인 이전 버전의 인스턴스들을 천천히 하나씩 업그레이드하여 최종적으로 모든 인스턴스에서 새로운 버전을 배포하도록 만드는 방법이다. 당연히 특정 인스턴스에서 배포를 진행하는 도중에는 그 인스턴스로 로드밸런서가 라우팅하지 않도록 하는 작업이 필요할 것이다.

 

롤링 배포는 제한된 자원 내에서도 진행할 수 있으며, 일부 인스턴스에서 새로운 버전 배포 후 문제가 발생한다면 빠르게 일부만 롤백하면 된다는 장점이 존재한다. 하지만 새로운 버전과 이전 버전이 서버에 공존하기에 호환성 문제가 발생할 수 있으며, 하나씩 배포를 진행하기 때문에 전체적인 배포 속도가 느리다는 단점이 존재한다.

블루-그린 배포

블루-그린 배포는 이전 버전을 나타내는 블루 버전과 새로운 버전을 나타내는 그린 버전에서 이름을 따왔으며, 운영 환경에 이전 버전의 인스턴스와 동일한 새로운 버전의 인스턴스들을 구성한 후에 로드밸런서로 트래픽을 새로운 버전의 인스턴스로 한번에 전환하는 방법이다.

 

블루-그린 배포는 실제 프로덕션 환경에서 새로운 버전을 테스트 해볼 수 있으며, 문제가 발생하면 트래픽을 다시 이전 버전으로 한번에 전환하면 되기에 롤링 배포와 마찬가지로 빠르게 롤백이 가능하다는 장점을 가진다. 하지만 이전 버전의 인스턴스들이 존재하는 상태로 새로운 인스턴스들을 준비해야 하기에 두 배의 시스템 자원이 필요하기에 자원과 비용 측면에서 단점을 가질 수 있다.

카나리 배포

카나리 배포는 블루-그린 배포 방식과 유사하지만, 블루-그린 배포처럼 한 번에 새로운 버전으로 전환하는 것이 아닌 점차 새로운 버전의 비율을 늘려가면서 피드백과 모니터링을 함께 진행하며 배포한다. 과거 광부들이 유독가스에 민감한 카나리아 새를 이용해 가스 누출을 감지했던 것에서 유래하였다.

 

로드밸런서를 통해 새로운 버전을 경험하는 사용자를 조절해가며 오류를 검출하거나 안정성을 검증할 수 있다는 장점을 가진다. 그 외 장단점은 블루-그린 배포와 동일하다.

참고 링크

What is Application Deployment? | VMware Glossary

 

에스코어