배포 전략
1. 블루/그린 배포
블루/그린배포는 애플리케이션 또는 마이크로서비스의 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한
새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 모델이다.
블루/그린 배포가 필요한 이유
배포를 자동화할 때 겪는 어려움중 하나는 소프트웨어를 최종 테스트 단계에서 실제 프로덕션 단계로 전환하는 컷오버
자체이다. 일반적으로 다운 타임을 최소화하려면 이 작업을 신속하게 수행해야한다.
즉, 블루/그린 배포는 가능한 동일한 2가지 프로덕션 환경을 확보함으로써 이를 실현시킬 수 있다.
#컷오버: 기존에 운영되던 환경을 중단시키고, 새로 구축된 환경을 오픈하는 것
블루/그린의 배포 방식
만약 블루가 실제 운영중인 환경이라면,
- 새로운 버전을 릴리스하고 싶은 경우 그린 환경에서 테스트를 진행한다.
- 테스트가 정상완료되면 블루 환경에서 들어가던 모든 요청을 그린 환경으로 변경한다.
- 이후 블루는 이전 그린 환경의 역할을 가져감과 동시에 그린이 잘 작동하지 않을때 사용할 수 있는 백업 서버로의 역할도 수행이 가능하게 된다.
- 결과적으로 무중단 배포가 가능해지면서 기존의 배포에서 서비스를 중단하는 일이 불필요해지게 된다.
블루/그린 배포의 원칙
두 환경은 다르지만 최대한 동일해야한다.
- 경우에 따라 하드웨어의 다른 부분일 수도 있고 동일한(또는 다른) 하드웨어에서 실행되는 다른 가상 머신일 수도 있다. 또한 두 슬라이에 대해 별도의 IP주소를 사용하여 별도의 영역으로 분할된 단일 운영 환경이 될 수도 있다.
- 무중단 배포여야한다.
- 한 시점에 하나의 버전만 액티브 상태여야 하며, 롤백이 쉬워야한다.
블루/그린 배포의 장점
- 동일하게 구성된 환경을 하나 더 추가함으로써 서비스의 가동 중단 시기를 최소화시킬 수 있다.
- 서비스가 되고있는 환경(블루 or 그린)에 문제가 발생한 경우 백업 서버로 사용할 수 있다.
- 다음 배포를 위한 최종 테스트 단계의 스테이징 환경으로 사용할 수 있다.
#스테이징 환경: 운영환경과 거의 동일한 환경을 만들어놓고, 운영 환경으로 이전하기 전에 여러가지
비 기능적인부분(보안, 성능, 장애)등을 검증하는 환경을 뜻한다.
2. 롤링 배포
롤링 배포는 애플리케이션이 실행 중인 인프라를 완전히 교체하여 이전 버전의 애플리케이션을 새로운 버전의 애플리케이션으로 서서히 교체하는 배포전략이다.
롤링 배포는 가용 자원이 제한적일 경우에 사용된다.
롤링 배포의 방식
- 사용중인 인스턴스(v1) 내에서 새 버전(v2)을 점진적으로 교체하게 된다.
롤링 배포의 장점
- 업그레이드 과정에서 문제가 발견되면 일반적으로 롤링 배포를 reverse로 이동하여 새 버전의 앱을 제거하고 이전 버전을 다시 시작할 수 있다.
- Downtime이 없다.
롤링 배포의 단점
- 배포가 진행되는 동안 구버전과 신버전이 공존하기 때문에 호환성에 문제가 발생할 수 있다.
- 배포중인 서버는 서비스가 중단된 상태이기 때문에 서버 부하량을 체크하며 배포를 진행해야한다.
카나리 배포
카나리 배포는 전체 인프라에 새로운 소프트웨어 버전을 릴리즈하여 모든 사용자가 사용할 수 있도록 하기 전에
변경 사항을 천천히 릴리즈함으로써 프로덕션 환경에 새로운 소프트웨어 버전을 도입하는 위험을 줄이는 기술이다.
블루/그린 배포와 유사하게 사용자가 라우팅되지 않는 인프라의 하위 집합에 새 버전의 소프트웨를 배포하는 것으로
시작된다.
이 기법의 이름 광부들이 광산으로 들어갈 때 새장에 카나리를 넣어 가져가는 것에서 유래한 것으로 잠재적 문제를
초기에 발견하여 전체 운영환경이나 사용자에게 영향을 미치는 것을 방지한다.
카나리 배포 방식
블루/그린 방식과 유사하지만 특정 서버에만 배포를 진행하여 오류 여부를 확인하고 문제가 없다면 모든 서버에 새로운 버전을 단계적으로 배포하는 방식이다.
카나리 배포의 장점
- 문제 발생 시 먼저 배포가 진행되었던 서버만 롤백하면 됨으로 비교적 롤백이 간편하다.
- 운영 환경에서 신규 버전을 테스트할 수 있다.
- 부하를 서서히 증가시키며 신규 버전이 운영 환경에서 어떠한 반응을 보이는지 모니터링하고 수치를 측정할 수 있다.
- 특정 서버로 먼저 배포를 진행하기 때문에 문제 발생 시 리스크가 비교적 적다.
참고레퍼런스
https://www.redhat.com/ko/topics/devops/what-is-blue-green-deployment