티스토리 뷰

728x90
반응형

배포 전략

비즈니스 환경 변화에 탄력있게 대응하기 위해 많은 기업들이 Agile, DevOps, MSA 등 다양한 기반 기술을 도입하고 있지만, 실상은 많은 시행착오를 겪고 있는 것도 사실이다.

서비스는 사용자 경험 향상을 위해 하루에도 수번에서 수십번 버전을 업그레이드하거나, 버그를 픽스하는 등 여러 경우에서 변화가 발생할 수 있다. 이때 사용자가 느끼지 못할 정도로 서비스의 중단 없이 배포를 진행해야 하는 경우가 있고, 때로는 다운타임을 가져가야 할 경우도 있다.

서비스를 제공하는 제공자 입장에서 어플리케이션의 새 버전을 성공적으로 릴리즈하기 위해 어플리케이션 특성과 리소스, 비용 등을 종합적으로 고려하여 다양한 배포 전략을 고민해야 한다. 각각의 배포 방식은 특징을 갖고 있고, 적합한 환경과 프로젝트에서 제공되는 상황에 따라 선택할 수 있다.

  • Blue-Green Deploy
  • Canary Deployment
  • Recreate
  • Rolling Update
  • A/B Testing
  • Shadow

지금부터 어플리케이션을 사용하는 고객 중심에서 이 새로운 버전을 원활하게 배포하는 방법에 대해서 알아보도록 하자. 또한, SI가 진행되는 과정에서 어떤 배포 방식을 선택하는 것이 좋을지도 함께 고민해 보자.


Blue-Green Deploy

Blue-Green 배포는 동일한 환경을 갖춘 두 개(Blue 환경과 Green 환경)의 버전을 배포하고, 트래픽을 일괄 전환하는 방식이다. 새롭게 출시할 버전이 있는 경우 Green 환경에 배포하고 Blue 환경은 그대로 유지하며 트래픽을 처리한다. Green 환경으로의 전환은 대체로 서비스 절체가 가능한 수준인 도메인 단위가 될 수 있지만, 필요시 Context 단위가 될 수도 있다.

Tester의 테스트 단위는 구간별 로드밸런싱을 처리하는 대상을 기준으로 선정할 수 있다.

  • 외부망 구간 L4
  • DMZ 구간 WEB Server
  • 내부망 구간 Ingress

외부망 구간 L4

DNS 서버의 Domain 분리 방식을 적용하여 외부망 구간을 포함하여 테스트할 경우 End to End Test가 용이하다는 장점이 있다. 특히 차세대 급 SI 프로젝트가 진행되는 경우 전체 인프라부터 망까지 분리하여 구축하는 경우가 있는데, 이때 단순 서비스의 점검만 이루어지는 것이 아닌 구간에 대한 인터페이스 점검, H/W, S/W 점검 역시 진행되어야 한다. 이 경우 E2E 대역을 점검할 수 있어 가장 바람직한 방법이 될 수 있다.

  • Blue 영역(AS-IS) : stable.waspro.co.kr(예시) > L4 > AS-IS WEB > AS-IS Container Mgmt > DB
  • Green 영역(TO-BE) : newer.waspro.co.kr(예시) > L4 > TO-BE WEB > TO-BE Container Mgmt > DB

반대로 외부망 대역에 도메인이 노출되어 출시 전 서비스를 외부 대역의 불특정 다수가 접근할 수 있어 보안에 문제가 발생할 수 있다. 이를 방어하기 위한 특정 대역의 사용자 또는 특정 ID만 접근 가능하도록 차단하는 어플리케이션 레벨의 방어로직이 필요하지만, 이 역시 완전한 방어책이 될 수는 없다.

DMZ 구간 WEB Server

DMZ 구간을 포함하여 테스트 하는 방식은 외부망에 직접적인 노출을 피한다는 점을 제외하고 전체 구간 테스트와 비슷하다. 이 경우 화이트리스트 정책을 적용하여, WEB Server에서 특정 구간의 사용자만 접근이 가능하도록 허용하는 방식을 통해 출시 전 서비스에 대한 보안을 강화할 수 있다. 또한, 필요 시 Tester의 위치에 따라, WEB Server IP를 사용하여 직접 접근하여 테스트할 수도 있다.

  • Blue 영역(AS-IS) : stable.waspro.co.kr/stable(예시) > L4 > AS-IS WEB > AS-IS Container Mgmt > DB
  • Green 영역(TO-BE) : stable.waspro.co.kr/newer(예시) > TO-BE WEB > TO-BE Container Mgmt > DB

단점으로는 실 이행 시 DNS 전환에 대한 면밀한 검토가 필요하다. 예를 들어, DNS 캐시 갱신 주기 등으로 인해 일시적인 오류가 발생할 수도 있고, 이행 절체에 대한 시나리오 수행도 사전 테스트를 통해 진행해 봐야 한다는 점 등이 있지만, 대체로 SI 수행에 적합한 방식이라 볼 수 있다.

내부망 구간 Ingress

내부망 구간에서 직접 테스트 하는 방식은 서비스 중심의 테스트라고 볼 수 있다. 내부망 구간의 DNS를 통해 Routing 되어야 할 Ingress Node를 결정하거나, hosts 파일을 통해 직접 접근하여 테스트할 수 있다. 

  • Blue 영역(AS-IS) : stable.waspro.co.kr(예시) > L4 > AS-IS WEB > AS-IS Container Mgmt > DB
  • Green 영역(TO-BE) : ingress_domain:port(예시) > TO-BE Container Mgmt > DB

이 경우, 서비스 런칭 전까지 외부 노출없이 안정적으로 테스트 할 수 있지만, 위 두가지 테스트와 다르게 외부 연계에 대한 인터페이스 점검이 어렵다는 단점이 있다. 다만, SI 초기 내부망 구간에서 점검하기 적합한 방식으로 솔루션 간의 인터페이스, Legacy 인터페이스를 점검하는 차원에서 활용된다.

배포 및 테스트가 완료되면, Green 환경에 트래픽을 유입하기 위한 서비스 전환 절차를 진행한다.

도메인 전환 이후 정상적으로 테스트가 완료되면, 기존 Blue는 삭제되고, Green이 Blue가 되며, 이후 신규 서비스를 런칭하기 위해 준비하는 과정이 반복된다고 보면 된다. 반면에 테스트 과정에서 원하는데로 동작하지 않거나, 크리티컬한 버그가 발견되었을 경우, 2번에서 1번 상태로 신속하게 도메인만 변경하면, 롤백을 완료할 수 있다. 이렇게 하면 EndUser 입장에서는 배포가 발생하지 않은 것처럼 롤백된다.

이 전략의 가장 큰 장점은 새로운 애플리케이션 버전의 빠른 업데이트 또는 출시가 가능하다는 점이다. 반면에 새 버전과 이전 버전을 동시에 실행해야 하기 때문에 유지 비용이 많이 든다는 단점이 있다. 이는 매몰비용의 증가로 인해 신속한 출시가 중요한 마이크로서비스 환경과 클라우드 환경 특히 Public 환경의 사용량 기반 비용 지불이 가능한 환경을 활용할 경우 보다 유의미하게 활용할 수 있다.


Canary Deployment

Canary Deployment는 newer 버전을 전체의 일부에 Production 환경에 배포하고, 점진적으로 비율(트래픽)을 늘려 나가는 방식이다. Blue-Green과는 다르게 두개의 버전이 동시에 운영되는 방식으로, 트래픽을 늘려나가기 위한 성공 기준을 수립하는 것이 중요하다.

Canary Deployment는 신규 버전의 어플리케이션을 일정 비율로 배포하며, 이는 동시에 동일 도메인을 갖는 서비스가 양쪽으로 분산되는 방식으로 하나의 완전한 버전의 어플리케이션이 배포 된다고 볼 수 있다.

배포 분산 방식은 Kubernetes Service를 통한 분산이 일반적이나, Service Mesh 또는 API Gateway를 통해 트래픽을 분산할 수도 있다.

  • Kubernetes Service 분산
  • Service Mesh 분산
  • API Gateway 분산

Kubernetes Service 분산

동일 Domain에 동일 context로 호출하더라도, Kubernetes Service의 Label Selector를 활용하여 multi deployment for single service 형태를 구현할 수 있다.

  • Kubernetes Canary Serivce Label Selector > Stable Deployment Replicas: 9
  • Kubernetes Canary Serivce Label Selector > Newer Deployment Replicas: 1

위와 같이 동일 Domain에 동일 context로 호출하더라도, Kubernetes Service의 Label Selector를 활용하여 multi deployment for single service 형태를 구현할 수 있다.

이 경우, 트래픽 비율을 조정하기 어렵기 때문에 대체로 Replicas 수를 통해 트래픽량을 분산한다.

Service Mesh 분산

Service Mesh를 활용하면, 위와 같이 Kubernetes Service로는 제한적인 Routing Rule을 여러 조건으로 분배할 수 있다. 예를 들면 다음과 같다.

  • 여러 버전에 가중치 기반 라우팅 처리 가능
  • HTTP 헤더값 기반 라우팅 처리 가능
  • Fault Inejction 처리 가능 (Request 중 5%는 HTTP 400 에러 발생하도록 트래픽 리턴)

  • Istio VirtualSerivce RoutingRule v1 & Weight 90 > Istio DestinationRule Subset v1 > ENVOY Proxy
  • Istio VirtualSerivce RoutingRule v2 & Weight 10 > Istio DestinationRule Subset v2 > ENVOY Proxy

위는 Service Mesh의 가중치 기반 라우팅 처리 방식이다. subset 기준 1:9의 라우팅 비율로 요청을 분배하여 전달한다. 비율을 확산해 나가는 방법은 대시보드 상 구현되어 있는 것이 효과적이나, Jenkins와 같은 CD 도구를 활용할 수도 있다.

그 밖에 Header 기반 라우팅 방식은 Client Side의 특정 사용자에게만 접근권한 즉, 특정 Header 정보를 넣어야만 접속이 가능하도록 구성할 수 있다. 이를 통해 라이브 환경에서 사용자 테스트를 수행할 수 있다. 예를 들어, Client Header에 version=v2라는 헤더를 달고 들어올 경우에만 해당 Pod로 라우팅하고, Header가 없는 경우 현재 운영 중인 환경으로 라우팅한다.

API Gateway 분산

API Gateway는 VM 또는 Pod로 구성할 수 있다. API Gateway에서 동일한 API를 두개 이상의 서비스로 각각 라우팅할 수 있도록 구성한다.

  • API Gateway > Routing A 90 > Service A > Deployment A
  • API Gateway > Routing B 10 > Service B > Deployment B

그 밖에 Canary 배포는 더 나은 성능 모니터링이 가능하다. 또한 새 버전이 실패할 경우 더 빠르고 더 나은 소프트웨어 롤백을 지원한다. 다만, 점진적인 비율 확장으로 인해 릴리즈 속도가 느리고 배포 주기가 길다는 단점이 있다.

Canary Deployment는 크리티컬한 시스템에는 적용할 수 없다. 마케팅 용도의 신규 기능을 정식 출시하기 전 사용자의 반응을 확인하기 위해 일부 사용자를 대상으로만 기능을 오픈하여 테스트 한다.


Recreate

Recreate는 이전 버전의 어플리케이션을 완전히 종료하고 새 버전의 어플리케이션을 배포하는 방식으로 배포 사이에 시스템 중단 시간이 발생한다.

신규 서비스를 출시하는 회사입장에서 별도 환경이 필요하지 않아 저렴하게 배포환경을 구성할 수 있다. 또한, 트래픽 이동이 필요하지 않아 별도로 라우터를 구성할 필요가 없다.

  • 1) AS-IS APP CON DOWN
  • 2) NEWER APP CON BOOT

그러나 이 배포방식은 다운 타임으로 인해 사용자에게 큰 영향을 미친다. 따라서 Product 환경에서는 적용이 매우 제한적이거나, 사용하지 않으며, 개발/테스트 환경 기준 버전 별 명확한 테스트를 구분하고자 하는 경우(두 버전이 일시적이라도 중복되지 않도록 해야 하는 경우) 배포 속도가 빠른 서비스를 대상으로 적용하는 것이 바람직하다.


Rolling Update

이 배포 전략은 이전 버전을 새 버전으로 점진적으로 변경하는 방식이다. Canary Deployment와는 다르게 이전 버전의 인스턴스를 한 번에 정해진 수의 인스턴스만큼 새 버전의 인스턴스로 교체하여 전환한다.

이 배포 방식은 제로 다운타임을 제공하고 성능 모니터링도 가능하다. 다만, 예상치 못한 이벤트가 발생할 경우를 대비하여 롤백 기간이 길다는 단점이 있다. 따라서 이는 Graceful Redeploy와 함께 기동이 오래 걸리는 서비스나 VM 환경에 적용된 서비스에 적용하기 적합하다.


Shadow

Shadow 배포는 이전 버전과 함께 새 버전을 배포하지만, 사용자는 새 버전에 다이렉트로 접속할 수 없으며, 테스트를 위해 이전 버전이 받은 요청을 Shadow 버전으로 포워딩하는 방법을 사용한다.

사용자는 기존 트래픽을 처리하되 주황색 라인의 별도 서비스가 호출되는지는 알지 못한다. Shadow 호출을 통해 시스템 성능을 모니터링하고 안정성 테스트를 수행할 수 있다. 반대로 구성이 복잡하고, 비용이 많이 발생하며 때로 이 환경으로 인해 시스템에 심각한 장애를 유발하는 경우도 있다.

해당 테스트는 SI 수행과정보다는 운영관리 시점의 이행 이후 신규 서비스 출시 시점에 사용한다.


A/B Testing

A/B 테스트는 Blue/Green 배포와 같이 배포할 버전을 포함하여 두 버전이 동시에 배포된다. 차이점은 Blue/Green 배포가 임의의 사용자에게 비율에 따라 전달된다면, A/B 테스트는 새 버전에 접속하기 위한 조건이 정해져 있다는 점이다. 예를 들어 사용자의 위치, 장치 유형 등을 헤더 정보에 저장하여 라우팅 조건으로 활용할 수 있다.

이 방법은 새로운 기능에 대해 특정 사용자를 대상으로 테스트를 수행함으로써 보다 완전한 테스트를 수행해 볼 수 있지만, Header 정보를 파싱하는 등 L7 Layer의 로드밸런서가 필요하여, 비용 측면, 복잡도 측면에서 고려되어야 한다.


결론

통상적으로 운영환경에서는 배포 전략이 간편한 Rolling Update를 사용하는 경우가 많지만, 각각의 배포 전략의 특징을 이해하고 적합한 시나리오와 시점에 활용해야 한다.

배포 전략 추천 환경 SI
적용
비용 롤백 다운
타임
운영환경
테스트여부
운영환경
테스트대상
구축
복잡도
Recreate 개발/테스트 환경 개발단계 낮음 길다 발생 - - 낮음
Blue-Green 변경 빈도가 높고, 신속한 롤백이 필요한 중요도가 높은 서비스 운영단계 높음 짧음 없음 - - 중간
Canary 중요도가 상대적으로
낮은 시스템 대상
유지보수
단계
중간 중간 없음 수행 임의
사용자
중간
Rolling Update 개발/테스트 환경
또는 VM 환경
개발/테스트
/운영 단계
중간 길다 없음 - - 낮음
A/B Testing 마케팅 등의 용도로
특정 대상을 위한 서비스
유지보수
단계
중간 중간 없음 수행 특정
사용자
높음
Shadow 실 운영환경에서
검증하고자 하는 경우
유지보수
단계
높음 짧음 없음 수행 모든
사용자
높음

위 내용은 단순 비교 자료이며, 반드시 위와 같이 적용되는 것은 아니지만, 다음과 같이 정리해 볼 수 있을 듯 하다.

"SI 프로젝트를 수행하며, 개발/테스트 단계에서는 Recreate 또는 Rolling Update 방식으로 배포하고, 운영환경은 서비스의 중요도에 따라 Rolling Update 또는 Blue-Green 배포 방식을 적용한다. SI 프로젝트가 종료된 이후 운영사업자는 새로운 서비스 출시를 위해 운영 환경 검증이 가능한 Canary, A/B Testing, Shadow 중 필요에 따라 선택한다."

  • Recreate 배포 방식은 비용과 구축 복잡도가 낮아 손쉽게 구축하고, 소규모 프로젝트에서도 활용이 가능하지만, 다운타임 및 롤백 시간이 오래 걸려 비즈니스 중요도가 높은 서비스에 적용할 수 없다.
  • Blue-Green 배포 방식은 짧은 롤백 시간에 따라 중요도가 높고 빈번한 변화가 발생하는 서비스에 적용하기 용이하나, 비용이 많이 발생하여 상대적으로 매몰 비용이 높아질 수 있다.
  • Canary 배포 방식은 다운 타임 없이 운영환경에서 사전점검을 수행하고 점진적으로 확장해 나갈 수 있으나, 임의 사용자를 대상으로 테스트를 진행하므로, 사용자 경험 측면이나, 운영 환경 오류에 상대적으로 대응이 어렵다.
  • Rolling Update 배포 방식은 다운타임 없이 신속하게 구축이 가능하지만, 롤백 시간이 오래 걸려 비즈니스 중요도가 높은 서비스에 적용은 어렵다.
  • A/B Testing 배포 방식은 다운타임 없이 운영환경에서 특정 사용자 또는 사용자 그룹에게만 요청을 전달하여 테스트를 진행하여, 가장 안정적인 테스트 방식이지만, 높은 비용과 높은 구축 복잡도를 갖게 된다.
  • Shadow 배포 방식은 백그라운드 테스트 방식으로 실 운영환경에서 테스트에 목적으로 두고 배포하는 방식이며, 검증을 위해 운영 어플리케이션에 영향을 주어야 하기 때문에, 적용을 신중하게 검토해야 한다.

때로는 배포 전략 두개 이상을 조합하여 구성하는 경우도 있다. 위와 같은 각 배포 전략의 특징을 이해하고, 팀, 프로젝트, 회사의 요구 사항과 비즈니스 목표를 염두에 두고 배포 전략을 선택해야 한다. 특히 민감한 부분이라 할 수 있는 발생 예상되는 비용과 감당할 수 있는 가동 중지 시간에 대해 비교하여 적합한 전략을 찾아보도록 하자.

728x90
반응형