[Kubernetes] Kubernetes 배포 전략 (RollingUpdate, Blue/Green, Canary)

In-place Deployment

• 사용 중인 환경에 새로운 변경 사항이 포함된 애플리케이션만 반영하는 방법
• 배포 그룹의 각 환경(인스턴스)에 있는 애플리케이션을 일시정지한 후, 최신 상태의 애플리케이션의 변경 사항이 설치되면 새 버전의 앱을 실행하는 형식으로 이루어짐
• 로드 밸런서를 사용하면 각 인스턴스가 배포 중이더라도 등록을 해제할 수 있으며, 배포 완료 후에 이전 버전으로 복원도 가능
• 이것은 배포 방식 상 EC2, 온프레미스 환경에만 사용 가능한 배포 전략
• 쿠버네티스에서는 Recreate라고 함

Rolling Update Deployment

• 여러 개의 가동중인 서버(인스턴스)를 갖춘 환경에서 한 번에 정해진 수만큼의 서버에 새로운 변경 사항이 포함된 애플리케이션을 배포하는 방법
• 구 버전에서 새 버전으로 트래픽을 점진적으로 전환하며, 구 버전의 인스턴스도 점차 삭제됨
• 그렇기 때문에 서버 수의 제약이 있을 경우에는 유용한 방법이 될 수 있지만 배포 중 인스턴스의 수가 감소 되기 때문에 서버 처리 용량을 미리 고려해야 함
• EC2, 온프레미스의 경우, 인플레이스 배포가 롤링 배포와 혼합된 방식을 따르고 있고, Lambda나 ECS의 경우는 롤링 배포가 기본적인 배포 방식이 됨

Blue / Green Deployment

• 새로운 변경사항이 포함된 애플리케이션을 위한 새로운 환경을 구축하고 교체하는 방법
• 흔히 블루/그린 배포를 “구 버전의 환경을 새 버전의 환경으로 똑같이 구축해서 한 번에 전환한다” 라고 생각하는데, 사실 이것은 Red/Black 배포의 정의임
• 그래서 실제로는 “신 버전과 구 버전의 어플리케이션이 한 순간이라도 공존하였다” 라고 하는 것이 더 올바르다고 할 수 있음
• 블루/그린 배포는 하나의 버전만 프로덕션 되기 때문에 버전 관리 문제를 방지할 수 있고, 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새 버전 테스트가 가능
• 또, 주로 인플레이스 배포와 비교될 때 언급되는 장점으로 새 버전으로 전환 후에 문제가 생겼을 시에 구 버전으로 되돌리기 위한 롤백도 인플레이스 배포보다 더 빠르다는 점이 있음
• 단, 구 버전과 새 버전 두 환경 모두 갖출 필요가 있기 때문에 시스템 자원이 두 배로 필요해지며, 비용이 그만큼 비싸지기 때문에 비용을 고려한 구성을 필요로 함
  • 이런 단점은 AWS와 같은 클라우드 서비스에서는 종량 과금이라는 메리트가 있어 큰 부담 요소로 작용되지 않으니 그리 신경 쓸 부분은 아님

Canary Deployment

• 가동 중인 서버들의 일부에만 새로운 앱을 배포하여, 일부 트래픽을 새 버전의 환경으로 분산하는 방법
• A/B 테스트가 가능하고, 오류율 및 성능 모니터링에 유용하게 사용할 수 있다는 장점이 있음
• 트래픽을 분산시킬 라우팅은 임의적 또는 사용자 프로필 등을 기반으로 분류할 수 있음
• 분산 후에 결과에 따라 새 버전이 운영 환경을 대체할 수도 있고, 다시 구 버전으로 되돌릴 수도 있음