무중단 배포 (롤링, 블루그린, 카나리)와 어플리케이션 종료 전략

Prologue

서비스를 사용하던 중, 갑자기 서비스가 중단되어 이용할 수 없는 상황에 놓인다면 사용자 경험 측면에서 매우 좋지 않은 경험이 될 것이다. 서비스에서 주기적으로 중단이 발생할 수 있는 요인으로는, 서비스/네트워크 장애가 있을 수 있지만 조금 더 주기적인 측면으로는 신규 버전 배포 과정에서의 중단이 있을 수 있다. 특히, 애자일 방식으로 바뀌며 릴리즈 주기가 매우 짧아짐에 따라 배포가 더 자주 일어나고 있다.

이러한 환경에서 자주 일어나는 배포마다 중단이 발생한다면 과연 사람들은 점차 그 서비스를 사용하지 않을 것이다. 이를 위한 방법으로 무중단 배포(Zero downtime deployment)전략이 있고, 이에 대해 정리하려고 한다.

무중단 배포란?

개발 완료된 소스코드를 고객에게 제공하려면 서버에 배포해야하고, 아무리 고가용성을 보장하는 인프라 환경에 배포한다고 하여도 서비스를 멈춰야 한다. 이처럼 버전 업데이트를 위해 기존의 어플리케이션을 종료하고 새로운 어플리케이션을 실행하는 동안 그 사이에 갭이 발생하는데, 이를 다운타임이라고 한다.

다운타임은 시스템을 이용할 수 없는 시간을 일컫는다. 시스템이 오프라인이거나 사용할 수 없는 상황에 놓이는 상태를 가리킨다

https://ko.wikipedia.org/wiki/%EB%8B%A4%EC%9A%B4%ED%83%80%EC%9E%84

 

이러한 서비스의 중단(다운타임)없이 새로운 버전의 소프트웨어를 배포하는 것을 무중단 배포라고 한다.

 

핵심요소

무중단 배포의 핵심 요소는 로드밸런서를 통해 연결된 두 개 이상의 인스턴스에 트래픽을 제어해 배포하는것이다. 즉, 무중단 배포를 위해서는 안정적인 로드밸런서와 고가용성의 시스템 인프라가 필요하다.

배포 전략

롤링(Rolling) 배포

 

롤링배포는 무중단 배포의 가장 기본적인 방식으로, 서버를 여러 배치로 나누고 순차적으로 새 버전을 배포하는 방법이다. 롤링배포는 가용 자원(인스턴스)가 제한적일 경우 사용하고, 새 버전을 배포할때 구 버전의 인스턴스 수가 감소하기 때문에 서비스 처리 용량을 고려해야한다.

 

장점

• 롤백이 쉬움
• 자원 절약 (운영에서 사용하는 인스턴스 수 유지)

단점

• 호환성 문제 (구버전과 신버전간 격리가 없음)
• 배포시간이 오래 걸림

블루/그린(Blue/Green) 배포 

구버전을 블루, 신버전을 그린으로 지칭하여 붙여진 이름으로, 운영 환경에 구버전과 동일한 인스턴스로 신버전을 구성한 후 로드밸런서를 통해 신버전으로 모든 트래픽을 전환하는 방법이다. 

 

장점

• 빠른 롤백이 가능하다
• 운영 환경 테스트 가능 (구버전과 동일한 운영 환경을 구축하고, 배포 전 미리 테스트해볼 수 있다)

단점

• 시스템 자원이 2배로 필요함

카나리(Canary) 배포

옛날 광부들이 유독 가스에 민감한 카나리아 새를 이용해 가스 누출 위험을 감지했던 것에서 유래됨

 

구버전과 신버전을 모두 배포하고, 로드밸런서를 통해 신버전과 구버전 간 트래픽을 조절하여 점진적으로 신버전으로 전환하는 방식을 말한다. 트래픽을 점진적으로 전환하는 과정에서 신버전의 사용자로부터 오류를 확인할 수 있고, 오류가 발생하면 트래픽을 구버전으로 전환하여 롤백이 가능하다.

 

장점

• 위험 감지 (A/B 테스트)

단점

• 호환성 문제

롤링배포와 카나리배포의 차이점

언뜻 보면, 두 버전을 점진적으로 전환한다는 점에서 두 전략이 같은게 아닌가? 라는 생각이 들 수 있다. 하지만, 실제 전환 주체와 관점의 차이가 있다.

무엇을 점진적으로 전환하는가?

• 롤링 배포는 인스턴스(서버/Pod) 교체를 점진적으로 진행한다. 교체된 인스턴스(신버전)은 즉시 트래픽을 받기 시작한다.
• 카나리배포는 인스턴스가 아닌 신버전의 인스턴스를 배포한 후 트래픽을 점진적으로 전환하는 방식이다.

즉, 롤링 배포는 운영중인 인스턴스 환경에서 벗어나지 않고 인스턴스를 전환하는 반면, 카나리 배포는 운영중인 인스턴스 환경과 무관하게 트래픽을 전환한다.

오류 발생 대응

그리고 신버전에서 오류가 발생했을때 대응 전략에서도 차이가 발생한다.

• 롤링 배포는 롤백 과정도 점진적으로 진행되어 그 동안에는 계속 노출되게 된다.
• 카나리 배포는 트래픽 가중치를 조절하여 즉시 영향을 최소화 할 수 있다.

서버에서 요청을 처리중엔 어떻게 종료해야하지?

무중단 배포는 알겠으나, 결국 구버전의 인스턴스는 종료되어야한다. 특히 롤링배포의 경우 인스턴스를 점진적으로 변경하는 과정에서 구버전의 인스턴스가 요청을 처리중인 상황에서 종료해야할 수 있을것이다. 

Hard Shutdown

기본적으로 설정되어 있는 방법으로, 종료 요청이 발생하면 처리중인 요청이 있음에도 애플리케이션을 종료하는것이다. 간편하고 빠르게 종료할 수 있다는 장점이 있지만, 요청한 사용자는 중간에 끊겨 오류를 경험할 것이다.

Graceful Shutdown

Hard Shutdown과는 다르게, 종료 요청이 발생하면 더 이상 새로운 요청은 받지 않고, 현재 처리 중인 요청만 마무리한 후 종료하는 방식이다.

Spring boot에서 Graceful Shutdown 사용하는 방법

사용방법은 매우 간단하다. Spring boot에는 내장 톰캣이 Graceful Shutdown을 지원하고, 이를 사용하려면 application.yaml파일에 아래와 같이 추가하면 된다.

server:
	shutdown: graceful # 기본은 immediate임
spring:
	lifecycle:
    	timeout-per-shutdown-phase:5s # 기본은 30초임

References

• https://www.youtube.com/watch?v=kgvBlruQEKU
• https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html
• https://www.samsungsds.com/kr/insights/1256264_4627.html
• https://coding-review.tistory.com/428