무중단 배포란?
무중단 배포란, 말 그대로 애플리케이션의 중단 없이 배포를 하는 것을 말한다.
⇒ CI/CD 파이프라인을 구축 할 때 CD. 즉, 지속적인 제공 및 배포를 위하여 무중단 배포를 활용하는 경우를 많이 찾아볼 수 있었다. 때문에 CI/CD 파이프라인 구축 프로젝트를 진행하며 사용할 무중단 배포 방법을 찾아보았다.
애플리케이션이 중단되는 시점은 언제일까?
V1 서비스가 실행 중일 때 V2 버전을 다운로드 받게 되는데, 이때 V1 서비스를 종료 시키는 시점부터 V2를 시작하기 전까지 애플리케이션이 중단된다.
이렇게 서비스가 중단되는 시간을 다운타임(Downtime)이라고 한다.
서비스 중단 문제를 해결하기 위하여 무중단 배포라는 개념이 등장하였고 아래와 같은 방법이 존재한다.
- Rolling Update
- Blue/Green Deployment
- Canary Release
Rolling Update
롤링 배포는 사용 중인 인스턴스의 전체를 한 번에 업데이트 하는 것이 아닌, 인스턴스 내에서 새 버전을 순차적으로 업데이트하는 것으로 무중단 배포의 가장 기본적인 방식이다. 전체 시스템의 일부만 동시에 업데이트 되며 이를 통해 서비스 중단이 없이 배포가 가능하다.
서비스 중인 인스턴스 하나를 로드밸런서에서 라우팅하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅 하도록 한다. 이를 반복하여 모든 인스턴스에 새 버전의 애플리케이션을 배포한다.
아래의 그림을 통해 설명하자면
서비스 중인 인스턴스를 위와 같다고 치자.
그 중 하나(일부)를 로드밸런서에서 라우팅하지 않도록 떼어낸 상태에서 해당 서버의 애플리케이션을 새 버전으로 교체한다.
⇒ 이 경우 해당 서버에는 트래픽이 도달하지 않게 된다.
업데이트 버전이 배포가 끝나면 다시 라우팅을 시작한다.
⇒ 이러한 과정을 남은 2개의 인스턴스에도 반복하여 진행한다.
이를 통해 무중단으로 배포가 가능하다.
장점
- 새 버전에서 문제 발생 시 영향을 최소화 할 수 있다.
- 문제가 발생한 인스턴스만 롤백하여 전체 시스템의 안정성 유지가 가능하다.
- 추가적인 인스턴스를 늘리지 않아도 무중단 배포가 가능하다.
단점
- 새 버전을 배포할 때 인스턴스의 수가 감소하기 때문에 사용중인 인스턴스에 트래픽이 몰릴 수 있다. 즉, 서비스 처리 용량을 고려해야 한다. 위에 보인 예시 그림에서 3개의 인스턴스에서 감당하던 트래픽이 2개의 인스턴스로 몰리는 경우이다.
- 배포가 진행되는 동안 구버전과 신버전이 공존하기 때문에 호환성 문제가 발생할 수 있다.
Blue/Green Deployment
두 개의 환경(블루, 그린)을 이용하여 운영중인 구버전과 동일하게 신버전의 인스턴스를 구성한 후 로드밸런서를 통해 모든 트래픽을 한 번에 신버전 쪽으로 전환하는 방식이다. 이 때 블루는 구버전, 그린은 신버전을 의미한다.
블루 그린 배포는 서버 단위와 서버 내에서 이루어 질 수 있는데 두 방법 모두 아래의 그림과 함께 설명해보겠다.
서버 단위의 블루 그린 배포
Auto Scaling 그룹으로 여러 대의 인스턴스를 사용하는 경우에는 서버 단위의 블루/그린 배포를 진행해야 한다.
위와 같이 두 대의 서버로 요청을 나누어 처리하고 있고 기존 버전의 서비스를 새 버전으로 배포하려는 상황이다. 이 때 두 개의 그룹(블루/그린)을 가지고 배포가 진행되는데, 여기서 얘기하는 그룹은 대상 그룹이 될 수도 있고, Auto Scaling 그룹이 될 수도 있다.
기존 버전의 서버 인스턴스를 갖고 있는 그룹은 블루 그룹이며, 아무런 서버도 갖고 있지 않은 그룹은 그린 그룹이다. 이 때 그린 그룹에 블루 그룹과 같은 수의 서버 인스턴스를 생성하고 해당 인스턴스에 새 버전을 배포해 둔다.
새 버전의 배포가 완료되면 그린 그룹도 로드 밸런서에 등록하여 클라이언트의 요청을 블루 그룹과 나누어 처리하게 한다.
그 후 로드 밸런서에서 블루 그룹을 제외하여 모든 요청이 그린 그룹에 가도록 한다.
마지막으로 블루 그룹에 존재하는 인스턴스들을 모두 종료하여 배포를 종료시킨다. 이러한 과정을 통해 무중단 배포가 가능하게 되는 것이다.
기존 버전과 새 버전의 블루, 그린으로 부르는 것이기에 새 버전이였던 그린 그룹은 또 다른 업데이트가 진행 되는 시점에서는 처음과 같은 상황이기에 블루 그룹이 되는 것이다. 블루와 그린으로 생각하기 보다는 두 그룹을 통해 기존 버전과 새 버전을 관리한다고 생각하면 좋을 것 같다.
서버 내 블루/그린 배포
Auto Scaling 그룹 없이 1대에서 2대 정도의 적은 수의 서버를 운영하는 경우에는 서버 내의 웹 서버를 이용해 블루/그린 배포를 진행할 수도 있다.
서버 단위의 블루/그린 배포는 로드 밸런서를 이용해 트래픽을 각 그룹으로 라우팅 했다면 서버 내 블루/그린 배포는 웹 서버를 이용해 각 포트로 라우팅하는 방식이다.
기존 버전의 서비스를 서버 내의 8080번 포트를 리스닝하여 클라이언트와 로드밸런서를 거쳐온 요청이 전달되도록 한다.
새 버전의 코드를 새롭게 배포하고 8081번 포트를 리스닝 하도록 서비스한다. (이 때까지는 새 버전의 서비스에는 요청이 오지 않는다.)
웹 서버의 설정을 변경하여 클라이언트에서 받은 요청을 새 버전인 8081번 포트에 전달하도록 수정한다. (이 때 부터 모든 요청은 새 버전의 서비스로 오게된다.)
일정 시간동안 새 버전의 배포에 문제가 없다면 기존 버전의 애플리케이션을 종료한다. 다음 버전을 배포할 때에는 8080 포트에 최신 버전을 배포하고 8081 포트를 종료하면 되는 것이다.
블루 그린 배포 기법은 두 그룹을 두고 요청을 포워딩 한다는 개념이기에 서버 단위가 아닌 서버 내에서 웹 서버와 포트를 이용해 진행할 수 있는 것이다.
장점
- 구버전의 인스턴스가 그대로 남아있어서 쉽게 롤백이 가능하다.
- 구버전의 환경을 다음 배포에 재사용 할 수 있다.
- 운영 환경에 영향을 주지 않고 실제 프로덕션 환경과 동일한 조건으로 새 버전 테스트가 가능하다.
- 구버전과 새버전의 호환성 문제가 발생하지 않는다.
단점
- 시스템 자원이 두 배로 필요하다.
- 새로운 환경에 대한 테스트가 전제되어야 한다.
Canary Release
옛날 광부들이 유독 가스에 민감한 카나리아 새를 이용해 가스 누출 위험을 감지했던 것에서 유래한 것으로 잠재적 문제 상황을 미리 발견하기 위한 방식이다.
신버전을 소수의 유저들에게만 배포해보고 문제가 없는 것을 확인하면 많은 유저들에게 배포하는 기법이다.
블루 그린 배포와 유사하지만 블루 그린처럼 트래픽을 한 번에 바꾸는 것이 아니라 단계적으로 전환한다.
기존 버전에 모든 요청이 가고 있던 상태에서
소수의 유저만 새 버전을 사용하도록 한다. 이 소수 유저에게 정상적으로 서비스가 배포되고 운영된다면
전체 트래픽을 새 버전으로 전환하는 방식이다.
장점
- 실제 사용자 테스트와 무중단 배포를 동시에 할 수 있다.
- 문제 상황을 빠르게 감지하고 위험을 최소화 할 수 있다.
- 문제 발생 시 롤백을 통해 서비스 중단을 최소화 할 수 있다.
단점
- 롤링 배포와 마찬가지로 두 버전이 함께 존재하기 때문에 호환성 문제가 발생할 수 있다.
- 트래픽 제어에 부담이 있다.
중단 배포
중단 배포란, 무중단 배포와 반대로 서비스를 잠시 중단하고 새 버전으로 배포를 진행하는 방식이다. 앞서 설명한 내용은 다운타임이 생기지 않아야 사용자들에게 좋은 서비스를 제공할 수 있기에 무중단 배포를 사용한다는 것인데, 다운타임이 생기더라도 무중단 배포가 아닌 중단 배포를 사용해야 하는 경우가 있다.
- 무중단 배포의 큰 비용 부담이 어려운 경우
- 애플리케이션의 코드, 데이터베이스 스키마 등으로 인해 구버전과 신버전이 동시에 서비스되면 안되는 경우
2번째 경우에 대한 설명을 추가하자면, 이미 존재하는 기능이 아닌 추가적인 기능이 추가되는 경우는 무중단 배포를 사용하여도 괜찮지만, 존재하는 기능의 데이터베이스 테이블이 다른 테이블로 변경되는 경우가 생긴다면 두 서비스가 무중단 배포에서는 동시에 떠 있기에 데이터베이스의 정합성이 깨지게 된다. 또는 테이블의 스키마가 완전히 변경되는 경우에는 기존 버전의 코드를 가진 서버 인스턴스에서 에러가 발생할 수도 있다.
이런 경우가 존재하기에 중단 배포를 진행하거나, 무중단 배포를 위해 변경 사항을 저장해두는 임시 테이블을 만들어서 차이값을 마이그레이션 하는 방법을 선택해야 한다.
중단 배포는 온라인 게임 서버에서 많이 일어나는데, 구버전의 서버와 신버전의 서버가 동시에 떠 있으면 게임의 정책이 달라 게임을 서비스할 수 없기 때문에 게임 서비스는 정기 점검을 걸고 중단 배포나 강제 업데이트를 많이 한다.
참고 문헌
https://digitalbourgeois.tistory.com/231
https://hstory0208.tistory.com/entry/무중단-배포란-무중단-배포-전략에-대해-알아보자
'Project > Cloud' 카테고리의 다른 글
파이프라인 Security에 집중한 DevOps 구현 - VPC + 서브넷 생성 (3) (1) | 2025.01.27 |
---|---|
파이프라인 Security에 집중한 DevOps 구현 - CodeBuild + ECR 생성 (2) (0) | 2025.01.27 |
파이프라인 Security에 집중한 DevOps 구현 - 아키텍처 개요 (1) (1) | 2025.01.26 |
DevOps란? (0) | 2024.12.20 |
클라우드란? (2) | 2024.12.05 |