[Kubernetes] 무중단 배포

무중단 배포

서비스를 사용자에게 배포할 때 변경사항이 생겨서, 중단 -> 수정 -> 배포 과정을 거치게 된다면 다시 배포되기 전까지 사용자는 서비스를 사용할 수 없다.

하지만 당연하게도 중단 -> 수정 -> 배포보다는 수정 -> 배포 과정만 반복하고, 중단 과정이 없는 “무중단 배포”가 서비스 사용자들 입장에선 훨씬 좋지 않을까?

쿠버네티스는 이러한 무중단 배포 아키텍처를 여러가지 제공한다.

롤링 배포(Rolling Deployment)

롤링 배포는 전체 서버에서

일부분을 “ 라우팅 중단 -> 새로운 버전으로 업데이트 -> 배포 “

하여 일부분을 새로운 버전으로 업데이트 한다.

이렇게 되면 Version 1 과 Version 2 서버가 공존하게 되고, 새로 업데이트 한 Version2 가 문제 없이 잘 작동한다면 또 다시 일부분의 라우팅을 중단하고, 새로운 버전으로 업데이트하고, 배포하는 과정을 반복해서

전체 서버를 Version 2 로 업데이트 하는 것이다.

그리고 이 롤링 배포는 쿠버네티스에서 Default 배포 방식이다.

블루-그린 배포(Blue-Green Deployment)

블루-그린 배포는 블루를 구 버전, 그린을 신 버전으로 생각해서 만들어진 이름이다.

정상적으로 잘 작동하고 있던 Version 1(블루) 서버에 더해서 새로운 Version 2(그린) 서버를 준비한다.

이후 그린 서버를 테스트 해보고 그린 서버로 라우팅을 바꿔버리면 끝이다.

대신 블루 서버와 그린 서버, 두 서버를 감당해야 하므로 cost 가 많이 들어가는것은 당연하다.

카나리 배포(Canary Deployment)

카나리 배포는 롤링 배포와 상당히 유사하다.

처음 설명을 읽을 때 카나리 배포와 롤링 배포의 차이점을 구분하지 못해서 여기저기 찾아서 읽어보았다.

“아니 이거 롤링 배포 천천히하면 그게 카나리 배포 아닌가?” 라는 생각이 계속 들었는데 대부분의 포스트에서는 카나리 배포가 블루-그린 배포랑 유사하다는 말이 많아서 더욱 헷갈렸다.

나처럼 헷갈리는 사람들을 위해 조금 더 설명해보자면, 롤링 배포는 그냥 임의의 서버들을 Version2 로 올리는거라면 카나리 배포는 소수의 특정 집단 “유저” 를 타게팅해서 바꾸는 것이다.

서버가 아니라 유저를 타게팅한다는 점이 중요하다.

예를 들어서, 내가 만든 어플리케이션이 한국, 일본, 미국, 그 외 나라에 서비싱 중이라고 가정해보자. 이번에 어플리케이션의 작동 속도를 대폭 상승 시킨 버전을 업데이트 하려고 한다. 아무래도 빨리빨리 문화가 우세한 한국에서는 다른 나라에 비해 이번 업데이트에 더 tolerant 하지 않을까?

그러므로 한국에 먼저 업데이트를 올려보고 한국 사용자들의 comment 를 면밀히 살펴보는 것이다.

임의의 서버에 배포하는 롤링 배포보다, 내가 배포한 유저들에 대한 control 이 훨씬 좋고 이슈나 버그들도 훨씬 잘 찾아주리라 기대 된다.

참고한 포스트에서 든 또다른 예시로는, 실 유저에게 배포하기 전에 회사 내부에 먼저 배포하는 것을 예시로 들었다.

출처

쿠버네티스 공식 문서

Codefresh