무중단 배포

무중단 배포는 말그대로 중단하지 않고 배포를 진행하는 것을 의미합니다. 보통은 애플리케이션을 업데이트 한 뒤, 배포를 하게 될 경우 애플리케이션을 중단시키고 배포하게 됩니다. 이럴경우 사용자는 배포가 완료되는 시간 동안 애플리케이션 사용에 제한이 생기게 됩니다. 이렇게 서비스가 중단되는 시간을 다운타임(Downtime)이라고 하며, 이러한 다운타임을 없애고자 생긴것이 무중단 배포입니다.

무중단 배포를 하기 위해서는 두대 이상의 서버가 필수적으로 필요합니다. 실제로 서비스 중인 서버 한대와 새롭게 배포한 서버 한대를 사용하여 무중단 배포를 할 수 있습니다. 최근에는 서비스를 더 작게 만들고 더 자주 배포하는 방식으로 변화하고 있습니다. 그만큼 변경 사항이 생겼을 때 더 빠르게 반영할 수 있지만 그만큼 장애 위험이 따르게 됩니다. 그래서 이에 따른 여러 배포 전략이 생겨나게 되었습니다.

가장 대표적은 무중단 배포 전략은 아래와 같습니다.

  • Rolling Update
  • Blue / Green
  • Canary

 

Rolling Update

구 버전에서 새 버전으로 트래픽을 점진적으로 전환하며, 구 버전의 인스턴스도 점차 삭제됩니다. 그렇기 때문에 서버 수의 제약이 있을 경우에는 유용한 방법이 될 수 있지만 배포 중 인스턴스의 수가 감소 되기 때문에 서버 처리 용량을 미리 고려해야 합니다.

이 방식을 사용하고 있는 서비스는 Elastic Beanstalk와 CodeDeploy입니다. CodeDeploy는 공식문서에서 직접적으로 서술된 부분이 없기 때문에 알기 어렵지만 기본적으로 롤링 배포를 하도록 설정되어있습니다. 그래서 EC2, 온프레미스의 경우 롤링 배포 방식을 따르고 있고, Lambda나 ECS의 경우에도 롤링 배포가 기본적인 배포 방식이 되겠습니다.
덤으로 Elastic Beanstalk의 배포 방법을 보면, 롤링이 그냥 롤링과 추가 배치를 사용한 롤링으로 나뉩니다. 둘 다 구 버전에서 새 버전으로 점진적으로 전환되는 것은 동일하지만, 추가 배치를 사용한 롤링의 경우는 새 버전의 인스턴스를 배포한 후 바로 시작하여 배포 프로세스 중에도 모든 용량이 유지되도록 합니다.

 

Blue / Green

Blue / Green 배포는 이전 버전에서 새로운 버전으로 한번에 배포하는 방식이며, 이전버전을 Blue, 새로운 버전을 Green이라 칭합니다. Blue / Green 배포방식은 이전 버전과 새로운 버전을 모두 존재하기에 롤백이 쉬우며 Downtime을 없앨 수 있습니다. 또한, Rolling Update 방식에서 이전버전과 새로운 버전의 공존하는 시간이 존재한다는 문제점을 해결할 수 있습니다. 하지만 Rolling Update 방식보다 2배의 자원을 사용해야 하므로 더 많은 비용이 발생하게 됩니다.

 

Canary

Canary 방식의 어원은 '카나리아'라는 새에서 나오게 되었습니다.

카나리아는 메탄, 일산화탄소에 매우 민감한 새입니다. 과거에 광부들이 안전하게 일 할 수 있도록 카나리아를 이용하였습니다. 카나리아가 노래를 계속하고 있는 동안 광부들은 안심하고 일 할 수 있었으며, 만약 카나리아가 죽게 되면 곧바로 탄광을 탈출하여 광부들의 생명을 보존할 수 있었습니다. Canary 방식은 카나리아 새처럼 위험을 빠르게 감지할 수 있는 방식입니다. 특정 서버나 소수의 유저들만 새로운 버전을 사용시키고 안전하다고 판단이 되면 그 후에 모든 서버에 새로운 버전을 배포하는 방식입니다. 이런 전략은 A/B 테스트가 가능하며, 성능 모니터링에 유용합니다.

 

'설계 > Infrastructure' 카테고리의 다른 글

MSA에서 BFF(Backend for Frontend) 패턴  (0) 2022.08.10