무중단 배포 전략 ?
소프트웨어나 애플리케이션의 변경사항을 사용자에게 서비스 중단 없이 지속적으로 배포하는 전략 입니다.
애플리케이션의 중단 시점
운영중인 서버가 하나일 경우
v1 서비스가 현재 실행중이고 새 버전인 v2를 다운로드를 받습니다.
v1 서비스를 종료시키는 시점부터 v2 서비스를 시작하기 전까지 서비스는 중단됩니다. (Downtime)
문제점은?
V2가 실행되기 전까지 빨간색 "X"로 표시된 부분은 애플리케이션을 사용할 수 없게됩니다.
실제 가동중인 애플리케이션이라면 사용자는 중단하는 그 시간동안 기다려야만 할까? 그건 있어서는 안될 일입니다.
서비스를 중단없이 새로운 버전으로 계속 배포하는 방법을 찾아봅니다.
무중단 배포 전략에는 Rolling, Blue-Green, Canary 방식이 있는데 그 전에 알아야 할 용어들을 정리해 봅니다.
로드 밸런싱(부하 분산)
로드 밸런싱은 하나의 서버에서 받아야 할 요청을 여러 서버로 분산하는 장치 혹은 기술 (트래픽 분산) 입니다.
이러한 역할을 하는 웹서버는 Nginx가 있습니다. Nginx는 리버스 프록시의 역할도 수행합니다.
리버스 프록시(Reverse Proxy)
클라이언트와 웹 서버간 전달 역할을 하는 중간 서버로 클라이언트 요청을 대신 받아 내부 서버로 대신 전달해줍니다.
그리고 이를 다시 클라이언트에게 돌려줍니다.
이 과정에서 클라이언트는 웹 서버의 존재를 알 수 없으며, 리버스 프록시는 웹 서버의 대리인 역할을 수행합니다.
Nginx의 예시 (설정)
upstream samplecluster {
server 111.111.111.111:8080;
server 222.222.222.222:8080;
server 333.333.333.333:8080;
}
server {
listen 80;
location / {
proxy_pass http://samplecluster;
}
}위의 예시처럼 upstream을 통해 로드 밸런싱 대상 서버를 설정할 수 있습니다.
무중단 배포방식
4-1. Rolling Update 방식
애플리케이션의 새로운 버전을 서비스 중단 없이 순차적으로 새로운 버전으로 배포하는 배포 전략 중 하나입니다. 서비스의 지속적 가용성을 보장하면서 업데이트를 수행하는데 사용됩니다.
장점
- 롤백 용이 : 새로운 버전의 애플리케이션 배포 중에 문제가 발생하면, 이전 버전으로 간단하게 롤백할 수 있습니다. 단계적 배포를 통해 문제가 발생한 단계에서만 롤백하면 되므로 복구 작업이 간단하고 안정적입니다.
- 부하 분산 : 단계적으로 업데이트를 진행하며, 각 단계에서 일부 노드 또는 인스턴스만 업데이트되므로 전체 서버에 부하가 집중되지 않고 균등하게 분산됩니다.
단점
- 배포 시간 증가 : 여러 단계를 거쳐 진행되기 때문에 전체 배포 시간이 더 오래 걸릴 수 있습니다. 대규모 업데이트에서 테스트하는데 시간이 소요될 수 있습니다.
- 버전 호환성 문제 : 새로운 버전과 이전 버전이 호환되지 않는 경우, 롤백을 하더라도 문제가 발생할 수 있습니다.
- 리소스 과부하 : 일시적으로 이전 버전과 새로운 버전의 리소스가 동시에 사용될 수 있으므로, 메모리나 디스크 공간 등의 리소스 사용량이 증가할 수 있습니다.
4-2. Blue - Green Deployment
애플리케이션의 이전 버전(Blue)과 새로운 버전(Green)을 완전히 분리하여 새로운 환경에 배포하는 배포 전략 중 하나입니다.
롤링 업데이트 방식의 장점처럼 무중단 배포와 롤백을 간단하게 수행할 수 있도록 지원합니다. 기존의 운영 중인 서비스는 블루 환경에 배포되어 있고, 새로운 버전의 서비스는 그린 환경에 배포됩니다.
장점
- 빠른 롤백 : 롤링 배포와 마찬가지로 빠른 롤백이 가능합니다.
- 검증 및 미리 테스트 : 구 버전과 동일한 환경에서 신 버전 인스턴스를 구성하기 때문에 실제 서비스 환경에서 신 버전을 미리 테스트 할 수 있습니다.
- 재사용 : 배포가 완료된 후 남아있는 구 버전 환경을 다음 배포에 재사용 할 수 있습니다.
- 신 버전 배포가 진행되는 동안 서버 과부하가 일어날 확률이 적습니다.
단점
- 배포 시간 / 비용 증가 : 시스템 자원이 롤링보다 2배 이상으로 필요하여 비용 등의 문제가 발생할 수 있습니다.
4-3 Canary 방식
잠재적 위험을 빠르게 감지할 수 있는 배포 전략입니다. 이미 배포된 버전과 새 버전 간에 트래픽을 분할하여 완전히 배포되기 전에 일부 사용자에게 배포하는 애플리케이션의 점진적 출시입니다.
장점
- 빠른 피드백: 문제가 발생한 경우에도 피드백을 빠르게 수집하고 조치할 수 있습니다. 이로 인해 빠른 반응과 대응이 가능해집니다.
- 롤백 용이성: 카나리아 배포에서 문제가 발생하면 트래픽에 대해 신규 버전을 중단하고, 이전 버전으로 롤백할 수 있습니다.
- Blue-Green 처럼 신 버전 배포 전에 실제 운영 환경에서 미리 테스트할 수 있다.
단점
- 테스트 범위 한정 : 일부 예외적인 상황이나 성능 이슈 등의 문제를 발견하기 어려울 수 있습니다.
- 초기 배치 시간: 새로운 환경을 미리 배치하고 구성하는데 시간이 소요됩니다. 초기 배치 시간이 존재하며, 이후에도 환경 복제 및 데이터 동기화 등이 필요합니다.
- 복잡성 : 두 개의 환경을 운영하고 트래픽을 관리하기 때문에 블루-그린 배포에 비해 좀 더 복잡합니다.
참고
https://www.samsungsds.com/kr/insights/1256264_4627.html
https://hudi.blog/load-balancing-with-nginx/
https://loosie.tistory.com/781#1._%EB%A1%A4%EB%A7%81(Rolling_Update)_%EB%B0%A9%EC%8B%9D
https://cloud.google.com/deploy/docs/deployment-strategies/canary?hl=ko
