[Kubernetes] Deploy Strategy (배포 전략)

✔️ Six Strategies for Application Deployment

Six Strategies for Application Deployment – The New Stack
쿠버네티스에서만 쓰는 전략이 아니며 모든 어플리케이션을 배포할 때 사용한다.

 

쿠버네티스의 Deployment는 다음 2가지 방식을 지원한다.

• Recreate : Version A is terminated then version B is rolled out.
• Ramped (also known as rolling-update or incremental): Version B is slowly rolled out and replacing version A.

 vagrant@k8s-node1  ~/deploy  kubectl explain deploy.spec.strategy
FIELDS:
   rollingUpdate        <Object>
     Rolling update config params. Present only if DeploymentStrategyType =
     RollingUpdate.

   type <string>
     Type of deployment. Can be "Recreate" or "RollingUpdate". Default is
     RollingUpdate.

전략의 타입으로 Recreate, RollingUpdate 두가지를 선택할 수 있으며 기본값은 RollingUpdate이다.

 

✔️ Recreate

구성요소를 Client와 LB(SVC) 그리고 RS이라고 생각할 수 있다. 복제본의 파드들이 3개 있다.
클라이언트가 서비스에 접근하면 부하 분산이 발생하는 형태이다.

 

개발자가 App을 개발해서 이미지에 넣었을 것이고 현재 이미지의 태그가 V1이다.

그렇다면 두번째 버전을 배포할 때는 어떻게 할 것인가 ?

V1을 지우고 새로운 V2 RS를 만들어서 연결시킨다. 기존의 것을 지우고 새롭게 만들어서 연결시킨다.

가장 단순하면서 가장 확실한 전략이다.

 

Pros:

• 설정이 쉽다.
• App의 상태가 완전히 갱신된다.

Cons:

• 기존의 것을 지우고 아무리 빠르게 만들어도 일정 시간은 downtime이 발생할 수 밖에 없다.

이런 전략은 보통 Planned Downtime에 주로 사용한다.
ex) 게임 서버의 정기 정검 시간
서비스를 중단하고 진행하므로 downtime이 발생해도 크게 문제되지 않는다.

 

✔️ Ramped (Rolling Update)

V1과 V2가 공존하는 상태에서 기존의 복제본 3개 중 1개를 지우고 V2를 새로 만들었다.
해당 파드들의 레이블이 같다면 로드밸런서 서비스가 레이블 셀렉팅을 할 수 있다.

그렇다면 어떤 클라이언트는 V1으로 어떤 클라이언트는 V2로 접근할 것이다.

 

Rolling Update : 하나씩 순차적으로 업데이트 하는 형태

V1 하나를 지우고 V2 하나를 생성하는 작업을 반복하면 V1은 모두 지워지고 모든 트래픽은 V2로 향한다.

 

Pros:

• 무중단 시스템
• Easy to set up
• Version is slowly released across instances.
• Convenient for stateful applications that can handle rebalancing of the data.

Cons:

• Rollout/rollback can take time.
  • Rollout : V1 → V2로 완벽히 이동하는 것
  • Rollback : 변경한 버전에 문제가 발생해서 다시 원복하는 것
• Supporting multiple APIs is hard.
  • 기능이 개선됐기 때문에 API가 바뀌었을 수도 있는데 두 API를 동시에 지원할 수 있어야 한다. 만약 Backend에 DB가 있었다면 V1에서 사용하는 DB, V2에서 사용하는 DB를 고려해야 한다. 둘다 데이터를 문제없이 읽고 쓸 수 있게 만들어줘야 한다.
• No control over traffic.
  • 로드밸런서에 의해 어떤 사용자는 V1으로 가고 어떤 사용자는 V2로 가는 것을 제어할 수 있는 방법이 없다. 최대한 빠른 시간내에 Rollout을 해야한다.

 

✔️ Blue/Green

트래픽이 모두 V1으로 향하는 상태에서 V2를 미리 만들어 놓는다.
Recreate 방식과 다른 점은 Recreate는 기존의 것을 모두 지워버리고 새롭게 만든다면 Blue/Green는 먼저 만들어놓고 나중에 지운다. 그리고 바로 트래픽을 V2로만 전송시킨다.

 

Recreate VS Blue/Green
Blue/Green의 단점 → 리소스가 더 많이 필요하므로 비용이 많이 든다.
작동 시스템이 BM이라고 하면 순간적이지만 6개의 시스템이 필요하다.

 

Pros:

• Instant rollout/rollback.
• Avoid versioning issue, the entire application state is changed in one go.

Cons:

• Expensive as it requires double the resources.
• Proper test of the entire platform should be done before releasing to production.
• Handling stateful applications can be hard.

 

✔️ Canary

미리 만들어놓는다는 개념은 같으나 LB 기능이 중요하다.
LB가 처음에는 100 : 0으로 시작해서 조금씩 V2로 트래픽을 흘려보낸다.
일부 사람들의(약 10%) 트래픽을 확인하고 log를 확인해서 이상이 없다고 판단되면 점점 V2로의 비율을 늘린다. 최종적으로는 0 : 100으로 만들고 V1을 지운다.

트래픽을 조금씩 흘려보냈는데 log에 문제가 있다고 판단되면 다시 트래픽을 100 : 0으로 만든다.

Canary는 LB에 네트워크 트래픽을 일정 비율로 분산할 수 있는 기능이 있어야 한다.

k8s의 LB는 해당 기능을 가지고 있지 않다.

 

✔️ A/B testing

일반 PC와 mobile로 접속하면 HTTP Header에 Browser의 종류, 버전 그리고 User-agent라는 항목에 OS가 나온다.
서버에서는 접속 장치가 PC인지 mobile인지 해당 정보를 보고 구별한다.

 

PC 사용자는 V1으로 mobile 사용자는 V2로 트래픽을 보내 특정 종류만 테스트한다.

• By browser cookie
  • AWS의 토글
• Query parameters
• Geolocalisation
  • IP
  • GPS
• Technology support: browser version, screen size, operating system, etc.
• Language

특정 대상 그룹을 새로운 버전의 테스터로 사용할 수 있다.

 

✔️ Shadow

트래픽이 V1, V2 모두에 전송된다. 요청과 응답은 V1에서만 받는다.
내부적으로 로드밸런서가 트래픽을 양쪽으로 전송시키고 V2에서는 로그 모니터링을 통해 클라이언트로부터 트래픽이 전달되면 이상이 발생하는지 체크한다.
이상이 없다면 트래픽을 V2로 전송시킨다.

 

하지만 구현 자체가 어렵다.
로드밸런서는 양쪽에 트래픽을 전송시키면 되고 V2에서의 응답을 차단하면 되는 것처럼 보이지만
App 레벨에서 이 동작을 테스트하도록 구현하는 것이 쉽지 않다.
또한 시스템 리소스가 2배가 사용된다.