[배포] CI/CD 배포전략에는 무엇이 있고 상황에 따라 어떤 방법이 좋은가?

 

 

 

참조 사이트

 

https://russell-seo.tistory.com/32

[Jenkins] 배포전략(Rolling, Canary, Blue/Green)

 

https://velog.io/@gehwan96/CICD-%EB%B0%B0%ED%8F%AC-%EC%A0%84%EB%9E%B5-

 

 

https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/in-place-deployments.html

In-place deployments - Overview of Deployment Options on AWS

 

https://youngswooyoung.tistory.com/10

[Server] In-place deploy / 현재위치 배포 방식

 

 

https://blog.naver.com/classmethodkr/222540331678

[CI/CD] 매번 헷갈리는 CI/CD 배포 전략 정리해버리기

 

 

 

---

배포전략이란?

배포전략은 애플리케이션을 운영 환경에 배포하는 환경을 정의한 접근법이다.
예전에는 수개월~수년에 한번씩 서버를 릴리스 했지만, 최근엔 MSA(마이크로 서비스)가 추세가 되고 애자일 방법론으로 개발을 많이하며 더 자주 배포하는 방식으로 변화하고 있다.

그로인해 변경 사항이 생겼을 때 더 빠르게 반영이 가능하지만 그에 대응하여 배포전략을 구상해야 한다.

대표적인 4가지 방식의 배포전략을 알아보고 비교해보자 한다.

무중단 배포(Zero-downtime Deployment)

말 그대로 서비스가 중단되지 않은 상태로 새로운 버전을 사용자들에게 배포하는 것을 뜻한다.

즉, 시스템을 이용할 수 없는 시간인 Downtime이 거의 없음을 뜻한다.
전략에 따라 다르지만, 최소 서버가 2대가 있어야 중단없이 배포를 할 수 있다.

In-Place

현재위치 배포라고도 하며, 현재 가동중인 서버를 그대로 무중단 배포로 구현해 In-place라고 한다.

방식은 아래와 같다.

1. 로드밸런서와 일부 서버의 연결을 해제함(ex. 4대중 2대)
2. 연결이 해제된 서버들을 새 버전으로 업데이트함
3. 업데이트된 서버들을 로드밸런서에 다시 연결하고 남은 서버들도 같은 방식으로 업데이트하고 연결함.

배포 방식때문에 EC2, 온프레미스 환경에서만 사용가능한 전략임.

장점

• 현재 사용가능한 자원을 그대로 이용하며 배포가능
• 서버를 증축할 필요가 없고 구현이 간단하고 리소스 소비가 적다.
• 로드밸런서에서 해제 및 연결작업을 이용해 배포를 쉽게 끝낼 수 있음.

단점

• 업데이트 도중에 서버를 필연적으로 끊어야 하기 때문에 다른서버에 과부하가 생김
• 롤백이 복잡하고, 롤백과 업데이트를 수차례 반복해야 한다면 효율적이지 못함.
• 배포 도중 문제가 발생하면 서비스 중지 시간이 길어질 수 있음.

Rolling

말아가는 것 처럼(Rolling) 서버를 한번에 정해진 수만큼 순차적으로 업데이트 하는 방식.
구 버전을 하나씩 종료하고, 새 버전으로 순차적으로 배포하는 방식으로, 일부 K8s의 기본 배포 전략이기도 하다.
기본적인 무중단 배포 방식.

1. 신버전을 새 인스턴스에 배포
2. 로드밸런서에서 구버전 인스턴스 1대 제외
3. 신버전 인스턴스 1대 추가
4. 3-4를 반복해 전체를 교체

장점

• 인스턴스마다 차례로 배포를 진행하기에 상황에 따라 롤백이 쉬움
• 추가적인 인스턴스가 필요없음
• 관리가 간편하고 다운타임이 거의 없음.
• 트래픽이 안정적으로 분산됨

단점

• 새 버전을 배포할 때 인스턴스의 수가 감소하기 때문에 사용중인 인스턴스에 트래픽이 몰릴 수 있음
• 배포가 진행되며 구버전&신버전이 공존해 호환성 문제 발생 가능
• 전체 배포 완료까지 시간이 많이 걸림

Blue/Green

Blue: 기존버전, Green: 새로 배포될 버전을 뜻함.
신버전을 Green 인스턴스 환경에 배포하고 일제히 전환해 모든 연결이 신버전을 바라보게 함.

1. Green 환경에 신버전 배포 및 테스트
2. 로드밸런서 트래픽에서 Blue -> Green으로 전환
3. 문제 발생시 즉시 Blue으로 복귀하며, 다음 배포시 Blue를 재활용(Blue가 있는 공간에 다음신버전 배포)

장점

• 구버전의 인스턴스가 남아있어 롤백이 쉬움
• 운영환경에 영향을 주지 않고 새 버전 테스트 가능
• 다운타임이 거의 없고 트래픽 스위칭만으로 롤백이 가능(안정성&신속성 확보가능)
• K8s등 플랫폼 기본

단점

• 시스템 자원이 두배가 필요하다
• 새로운 환경에 대한 테스트가 전제 되어야 함
• 데이터 동기화 문제가 발생할 수 있음

Canary

카나리의 어원은 카나리아라는 새에서 따온건데, 이 새는 유독가스에 민감해 광부들이 광산에서 가스 누출 위험을 감지하는 용도로 사용했음.
이러한 뜻을 가져와 잠재적 문제 상황을 미리 발견할 수 있는 배포 전략임.
지정한 서버 또는 특정 유저에게만 배포했다가 정상적일 경우 전체를 배포함.
Blue/Green과 유사해 보이지만 트래픽을 한번에 바꾸는 것이 아니라 단계적으로 전환함

1. 트래픽을 특정 %(ex. 5%)만큼 신버전으로 라우팅함.
2. 모니터링(오류나 성능지표를 확인)해 문제가 없으면 %를 확대함 ex. 25% -> 50% -> 100%
3. 이상이 생길 시 즉시 롤백

장점

• 문제 상황을 빠르게 감지할 수 있어 성능 모니터링에 유용함
• 장애 영향 범위를 최소화 할 수 있음
• A/B테스트가 가능함.

단점

• 트래픽 제어 시스템이 복잡함
• 장기간 구&신버전이 공존해 관리 복잡도가 증가

상황에 따른 배포 전략 선택

주로 실무에서는 카나리 - 롤링 배포 전략을 사용한다고 한다.
먼저 서버 한대를 배포해 보고, 정상적으로 실행 및 동작을 할 경우, 전체 인프라에 대해 롤링 배포를 진행하는 방식

시나리오	최적 전략	핵심 이유
예산이 적을 때	In-place Rolling	추가 인프라 이용 X
배포중 구&신버전이 공존하면 안될 때	Blue/Green	즉각적 롤백 및 완전한 테스트 가능
운영환경에서 최소한으로 테스트 해보고 싶을 때(A/B테스트)	Kanary	실제 사용자 피드백 수집 가능
즉각적 롤백이 필요할 때	Blue/Green	이전 버전을 유지하고 있으므로 롤백이 빠름
지속적 소규모 업데이트가 필요할 때	Rolling	단계적 적용으로 리스크 분산

---

틀린 부분이 있거나 인용한 부분에 대해 문제가 있을 시
댓글로 알려주시면 감사하겠습니다.