Downtime

서비스를 운영하다 보면 새로운 기능들을 개발하고, 이를 배포하여 기능들을 제공해야 합니다. 배포가 이루어지는 일반적인 방식을 생각해보죠.

위 그림 처럼, 이미 제공되는 서버를 종료 한 뒤 새로운 버전의 어플리케이션을 등록하게 됩니다.
이 과정에서, 이전 버전을 종료하고 새로운 버전의 등록 하는 시간 동안 서비스를 제공할 수 없게 됩니다.
이 사이에서 발생하는 서비스 제공 불가 시간을 다운타임이라고 합니다.

무중단 배포(Zero-downtime Deployment)

앞서 언급한 다운타임은 사용자에게 불편함과 치명적인 손실을 유발 할 수 있습니다.
이런 다운타임을 최소화 혹은 없도록 하는 배포 방식을 무중단 배포(Zero-downtime deployment라고 합니다.

무중단 배포 전략

리서치를 해보면, 다음과 같은 3가지 무중단 배포 전략들이 나옵니다.

• 롤링 배포
• 블루-그린 배포
• 카나리 배포

롤링 배포

새로운 버전을 점진적으로 적용하는 방식입니다.
새로운 버전이 등록 되는 서버에서는 다운타임이 발생 할 수 있으므로 로드 밸런서가 일시적으로 트래픽을 보내지 않다가 배포가 완료된 후 다시 트래픽을 보내는 방식을 통해 새로운 버전을 배포 하는 전략입니다.

이 과정에서, 구 버전과 신 버전이 동시에 존재하여 요청을 처리하기 때문에 호환성에 문제가 발생할 수 있습니다. 또, 위 예시처럼 인스턴스 3개의 성능을 수행하던 기존 서비스에서 일시적으로 인스턴스 2개의 성능으로 줄어든다는 점도 고려해야 합니다.

블루-그린 배포

이전 버전을 Blue, 새로운 버전을 Green이라 불러 붙혀진 이름입니다.
가장 직관적인 무중단 배포 전략이라 생각합니다.
배포 할 때, 이전 버전을 바로 종료하는 것이 아닌 새로운 버전의 어플리케이션이 준비될 때 까지 기다린 후 종료하는 전략입니다.
신 버전(green)이 정상적으로 실행되었다고 판단한 후, 로드밸런서를 통해 이후 요청을 green으로 요청을 리디렉션합니다.

이 과정에서 로드밸런서와 동일한 스케일의 추가적인 서버 사용량이 발생할 수 있습니다.

카나리 배포

롤링 배포와 유사하게 점진적인 배포가 이루어집니다. 가장 큰 차이는 새로운 버전을 일부분만 운영한 뒤 정상임을 확인 한 후 모두 배포하는 방식입니다.

특정 서버 또는 특정 사용자에게만 배포하여 정상임을 확인하기 때문에 빠르게 오류 사항들을 확인 할 수 있다는 장점이 있습니다. 이런 전략은 A/B 테스트와 비교 모니터링에 유용합니다.
롤링배포와 동일하게, 서로 다른 두 버전이 존재하므로 호환성 문제가 발생 할 수 있습니다.

출처 및 참고
https://hudi.blog/zero-downtime-deployment/
https://www.samsungsds.com/kr/insights/1256264_4627.html