1.배포 전략이란?

이전에는 소스 배포가 비업무시간, 수주에서 수개월에 한번 수행하는 큰 작업이었으나 최근에는 서비스를 구성할 때 모놀리틱 서비스 환경에서 마이크로 서비스 환경으로 많이 바뀌면서 배포 주기가 짧아지게 되었다. 

 

더 자주 소스를 배포하는 방식으로 변화되고 있는 만큼 변경 사항이 생겼을 때 더 빠르게 반영할 수 있다는 장점은 있지만 소스를 수정하는 것은 항상 리스크가 따르기 때문에 이에 대응한 배포 전략을 구성해야한다.

 

2.배포 기법

2.1  Rolling Strategy

애플리케이션의 이전 버전의 인스턴스를 새로운 버전의 인스턴스로 서서히 대체하는 방식으로 가장 일반적인 배포 방식이다.

Rolling은 일반적으로 이전 구성 요소를 축소하기 전에 준비 상태 점검을 통해 새 POD가 준비될 때까지 일정 비율을 다운하지 않고 대기하고 중대한 문제가 발생하면 Rolling을 중단할 수 있다. Rolling 배포는 Canary 방식의 구축이며, 모든 이전 인스턴스를 교체하기 전에 새로운 버전(카나리아)을 테스트하고 준비 상태 점검이 성공하지 못하면 카나리 인스턴스가 제거되고 배포 구성이 자동으로 롤백(Roll-Backup)된다.

- 장점
  . 서비스 다운타임 없이 새버전의 어플리케이션으로 무중단 배포 가능
  . 순차적으로 진행함으로 손쉽게 롤백이 가능
  . 서버자원이 2배 필요한 Blue/Green 배포방식에 비해 서버 자원 제약시 유리

- 단점
   . 어플리케이션에 대한 복잡한 검사를 구현해야 하는 경우는 부적합
   . 좀 더 긴 배포시간을 요함
   . 배포중인 서버는 중단된 상태로 서버 부하량이 늘어난 상태에서 배포 시작시 나머지 서버 자원들의 부하량이
     늘어나 서비스 전체가 마비 될 수 있음(이벤트 확인 필요)

   . 롤백 과정이 다소 복잡하다

이미지 출처: 'developheo'님 블로그 (https://yongdev91.tistory.com/23) - 순차적 배포

 

2.2  Canary Deployments

사용자나 서버의 일부에 릴리즈를 롤아웃하기 위한 패턴이다. 그 아이디어는 먼저 서버의 작은 서브셋에 변경사항을 배포하고, 테스트한 다음 나머지 서버에 변경사항을 롤아웃하는 것이다.
Canary Deployments는 다운타임에 미치는 영향이 적은 조기 경고 표시기 역할을 한다. 카나리아 구축이 실패해도 나머지 서버들은 영향을 받지 않는다.

- 장점
   . 신버전 배포전 운영환경에 직접 테스트를 진행해 볼 수 있음
   . 단계적인 전환 방식으로 리스크를 최소화하고 상황에 따라 트래픽 양을 늘리거나 롤백이 가능

- 단점
   . 동시에 두개의 서로다른 버전이 운영됨으로 버전 관리 중요

이미지 출처: 'developheo'님 블로그 (https://yongdev91.tistory.com/23)

 

2.3  Blue-Green Deployment

Blue(OLD Version)와 Green(New Version)이라는 동일한 두 운영 환경을 운영하여 다운타임과 리스크를 줄이는 방식으로 모든 서비스 운영 환경은 오직 하나의 환경만 존재한다. 비용상의 문제로 물리서버 대상보다 도커나 컨테이너같은 가상 환경에서 사용한는 것이 유리하다.
어플리케이션의 새 버전을 준비할 때 배포 및 최종 테스트 단계는 라이브가 아닌 환경에서 수행되며, Green에서 어플리케이션을 배포하고 완전히 테스트한 후에는 로드발란서로 전환하여 들어오는 모든 요청을 Blue가 아닌 Green으로 이동 시킨다.
- 장점
   . 운영 다운타임 최소화(사실상 배포방식 중 가장 짧음)
   . 배포시간이 짧음
   . 배포 리스크를 적고 롤백이 단순함(Green으로 유입되는 경로를 Blue로 변경하여 즉시 적용)

- 단점

  . 신버전과 구버전 모두 필요하여 리소스가 두배 이상 필요

  . 롱텀 트랜잭션이 수행 중 일경우 전환시 어떤 방식으로 처리할 지 고려 필요

  . Blue와 Green 두 환경간 migration이 배포때 마다 필요하며, 롤백 수행시에도 고려 필요

이미지 출처: 'developheo'님 블로그 (https://yongdev91.tistory.com/23)

 

2.4  Recreate Strategy

Rolling 이랑은 다르게 새 어플리케이션을 배포시 기존 POD를 모두 삭제한후 배포가 되므로 일반적으로
사용되는 배포방식은 아니다.

Recreate 전략을 사용하는 경우는 다음과 같다. 서비스가 다운되어도 문제가 없는 경우 사용한다.

  1) 새 어플리케이션을 시작하기 전에 마이그레이션 또는 데이터 변환을 실행해야 하는경우
  2) 신규 버전의 어플리케이션 코드를 기존 어플리케이션과 같이 쓸수 없는 경우
  3) 여러 복제본 간에 공유할수 없는 RWO 볼륨을 사용하는 경우

- 장점

  . 다른 배포방식보다 빠른 배포시간

- 단점
  . 서비스 다운 타임이 발생함

이미지 출처: 'developheo'님 블로그 (https://yongdev91.tistory.com/23)

 

2.5  Kubernetes 배포 전략 적용 권고사항

Quota와 Limit Ranges와 같은 리소스 제한 설정을 사용하는 경우, 배포 전략 중 Recreate, Rolling 전략을 사용할 때 배포 오동작을 막기 위한 설정 개선 방안을 제시한다.
Recreate 배포 전략을 사용해서 배포하는 경우, 프로젝트별 Quota의 pod 개수는 실제 자동확장 최대 pod 개수 보다 2 큰 수(deployer pod + builder pod 포함)로 설정할 것을 권고 한다.
Rolling 배포 전략을 사용해서 배포하는 경우, 프로젝트별 Quota의 pod 개수는 실제 자동확장 최대 pod 개수에 deployer pod, builder pod 개수를 포함하고, maxSurge(기본 25%)값 반영하여(autoscale max pod 개수 * (maxSurge 25%)) 산정할 것을 권고 한다.

+ Recent posts