[기술적 선택] 무중단 배포 아키텍처 개념 및 Blue-Green 도입한 이유

개요

필자는 로컬 프로젝트를 4~5번 정도 진행을 해봤고 서비스 배포 프로젝트는 3번을 진행해봤다. 그 중 2번은 인프라를 직접 담당하며 CI&CD의 역할을 하였다. 첫 인프라를 담당하였을 때 EC2 서버 안에서 도커 가상화 환경의 이해와 컨테이너의 포트 연결, Nginx, Jenkins 등 여러 학습이 필요한 상태라 시간이 많이 소요되었다. 

 

특히, 첫 인프라를 담당하였을 때 아키텍처 설계 완료 후 새로운 프로젝트가 빌드 될 때 웹 어플리케이션 서버(컨테이너)가 다운되고 새로 만들어진 프로젝트 기반의 도커 이미지를 가지고 컨테이너를 생성하게 된다. 이때 기존의 서버는 다운되고 새로운 서버가 로딩되는 그 시점에 서비스는 중단된다. 이러한 문제는 지속적인 서비스가 중단되고 사용자에게 불편함을 끼칠 수 있는 상태이다. 해당 문제점을 해결하기 위해 무중단 배포(Downtime-Zero)를 구현하게 되었다. 

 

먼저 서버가 1대일 경우 언제 서비스가 중단되는지에 대해서 알아보자. 

 

서버 1대

EC2 서버의 과금 부담을 피해 EC2 서버는 딱 한대만 운영하였다. 해당 서버에서 여러 애플리케이션 서버를 띄우기 위해서 도커를 활용하였고 프로젝트를 기반으로 한 도커 이미지 생성 후 해당 이미지를 이용해 웹 어플리케이션 서버 컨테이너를 생성했다.

 

 

먼저 서비스가 정상적으로 운영되고 있을 때 A팀원이 새로운 로직이나 기술을 도입하여 프로젝트에 새로운 코드가 반영된다고 가정해보자. 그렇게된다면 수정된 코드들이 공유 브랜치로 병합되고 이때 젠킨스에서 깃랩 Webhook 설정을 통해 자동적으로 통합하게 된다. 이때 해당 프로젝트 소스를 기반으로 빌드하고 JVM 파일이 생성되고 해당 파일은 배포 폴더(EC2 서버 경로)로 이동하게 된다.

 

이후 JVM 파일을 기반으로 한 도커 이미지를 생성함과 동시에 도커 컴포즈에 작성된 정보(포트, 볼륨 설정 등)를 가지고 컨테이너가 생성된다. 이때 같은 도커 컴포즈를 공유하다보니 이전 프로젝트에서 사용했던 포트를 가지고 똑같은 컨테이너를 생성하게 된다. 같은 포트 번호로 새로운 컨테이너가 생성될 시 기존에 존재하던 컨테이너는 자동으로 꺼지게 되고 새로운 도커 컨테이너가 띄워지게 된다. 도커 컨테이너가 띄워지는 그 시간동안 해당 컨테이너 서버로 API 통신을 하는 모든 서비스는 먹통이 된다. 

 

이를 해결하기 위해 무중단 배포를 도입하였다.

 

무중단 배포 

 

 

무중단 배포를 진행하려면 위의 그림처럼 서버를 2대 이상 확보해야한다. 그리고 로드밸런서(미들웨어)를 클라이언트와 웹 서버 사이에 위치시켜야 한다. 즉, 리버스 프록시를 서버 앞단에 배치하여 요청을 분배시킨다. 필자는 'Blue-Green' 무중단 배포 전략을 사용하기 이전에 다른 배포 전략을 보면서 어떤 것을 사용할지 학습하였다. 어떠한 전략이 있는지 학습한 내용 또한 같이 포스팅하고자 한다. 

 

 

롤링

일반적인 배포 방식을 의미하며, 단순하게 서버를 구성하여 배포하는 전략이다. 간단하게 설명하자면 구버전에서 신버전으로 점진적으로 서버 하나씩 전환하는 방식이다. 

 

 

위의 그림을 보면서 이해해보자 먼저 서버 1을 Version2로 로딩 시킨다. 그때 로드밸런서는 서버1로 가리키는 연결을 중단하고 서버 2와 서버 3으로만 보낸다. 이후 서버 1이 로딩이 완료되면 원래대로 라우팅한다. 이후 나머지 서버도 똑같은 방식으로 새로운 버전으로 바꿔준다. 

 

| 장점 

- 많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다. 

- 점진적으로 새로운 버전이 사용자에게 출시되므로 안정적인 배포가 가능해진다. 

 

| 단점 

- 배포 중 서버 인스턴의 수가 감소되므로, 다른 서버가 대신하여 감당해야할 트래픽의 양이 늘어난다. 

- 구버전과 신버전의 애플리케이션이 동시에 서비스되기 때문에 호환성 문제가 발생할 수 있다. 

 

 

Blue-Green

 

먼저 구버전인 Version 1의 서버로 로드밸런서가 연결되어있다. 새로운 신버전에 대한 서버 인스턴스가 3개를 로딩하고 배포가 완료되면 구버전과 신버전 동시에 연결이 된다. 이후 기존에 연결된 구버전 서버를 종료시킨 후 , 연결을 끊고 신버전의 서버들로만 통신하게 된다. 

 

| 장점 

- 롤링 배포 전략과 달리 한번에 트래픽을 신버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다. 

- 빠른 롤백이 가능하고, 운영환경에 영향을 주지 않고 실제 서비스 환경으로 신버전 테스트가 가능하다. 

 

| 단점 

- 시스템 자원이 2배로 필요하게되어, 비용이 훨씬 발생한다. 즉, 실제 운영에 필요한 서버 리소스에 대비해 2배의 리소스를 확보해야한다. 

 

 

 

카나리 

카나리 배포는 위험을 빠르게 감지할 수 있는 배포 전략이다. 지정한 서버 또는 특정 User에게만 배포해서 서비를 운영하다가, 버그가 없고 정상적이라고 판단되면 전체에게 배포하는 방식이다. 즉, 서버의 트래픽을 일부를 신 버전으로 분산하여 오류 여부를 확인해보는 전략이다. 이때 트래픽을 새로운 버전으로 옮기는 기준은 랜덤으로 진행하거나, 또는 팀원들과 정한 규칙에 따라서 진행하면 된다. 

 

 

| 장점 

- 트래픽 비율을 조정해서 버그 테스트를 안정적으로 진행 가능하다. 

 

| 단점

- 롤링 배포전략과 마찬가지로 호환성 문제가 발생한다. 

 

 

Blue Green 무중단 배포 선택 이유 

Blue-Green 전략은 언급했듯이 호환성 문제를 걱정할 필요가 없다. 기존 운영 환경과 새로운 운영 환경을 병렬로 구축하기 때문에 호환성 문제를 최소화하고 안정적인 배포를 보장하기 때문이다.

 

무중단 배포를 실현하는 또 다른 방법으로 카나리 방식을 고려하였다. 만약, 여러 서버를 갖추고 있다면 구버전 트래픽 설정 비율과 신버전 트래픽 설정 비율을 조절하여 오류 여부를 확인해보는 전략도 재밌을거 같다는 생각이 들었기 때문이다. 하지만, 현재 EC2 서버가 한 대이며 웹 어플리케이션 서버 컨테이너도 1대로 운영 중이기 때문에 가장 간단하고 효율적인 방법으로 Blue-Green이 적합하다는 생각이다. 즉, 카나리 방식은 여러 서버를 가지고 있는 환경에서 더 적합하며, 우리 프로젝트의 서버 환경을 고려하여 Blue-Green 방식으로 무중단 배포를 성공적으로 실현한 것이다.

 

요약하자면, EC2 서버 한대와 웹 어플리케이션 서버 컨테이너 1대로 운영 중인 상황에서는 Blue-Green 배포를 선택함으로써 무중단 배포를 간편하게 실현할 수 있었다. 이 방법은 서비스 중단 없이 새로운 버전의 컨테이너를 배포하며, 호환성 문제도 최소화하여 안정적인 서비스 제공을 가능케 한다. 

 

Blue-Green 배포를 어떻게 진행하였는지는 아래의 링크를 참고해보자. 

 

[Infra] 6. 무중단 배포 - HelloWorld Project