들어가며
지난 글에서 Argo Rollouts를 이용해서 Blue/Green 배포를 하는 법을 확인해봤다.
간단히 리뷰해보면 그 내용은 아래와 같다.
•
기본적으로 preview stable/active 2개의 서비스가 생겨나고, 평상시에는 2개의 서비스가 모두 하나의 replicaSet으로 트래픽이 전달된다.
•
변경이 발생하는 경우 신규 replicaSet이 생성되며 preview 서비스를 통해 연결된다.
•
kubectl argo rollouts promote 명령어를 통해 preview 버전을 stable/active 로 변경하는 작업을 수행한다.
실제 운영 적용을 위한 고려 사항
개념적으로 Blue/Green 배포를 하기위해서는 위 내용이면 충분해보이지만, 이를 실제 운영에 적용하려면 조금 더 디테일하게 검토해야할 사항들이 있다.
•
Blue/Green 버전 간에 트래픽을 실시간으로 스위칭이 가능한가?
•
promote 후 신규 버전에서 이슈가 발생하여 빠른 롤백을 위해 기존 버전이 유지가 되는가?
•
Blue/Green 버전이 동일한 쿠버네티스 리소스로 구성되야 하는가?(리소스 절감 차원)
그 밖에도, 실제 운영에서는 예측할 수 없는 상황이 너무나도 다양하지만 중요한 몇가지를 추려보았다.
이제 위 내용에 대해서 검토한 내용들을 살펴보자.
Blue/Green 버전 간 트래픽 실시간 스위칭 여부
이 내용은 사실 Argo Rollouts를 사용한다면 크게 문제되지 않는 것으로 생각된다.
이전 글에서도 언급했듯이, 굳이 Argo Rollouts를 사용하지 않아도 Blue/Green 배포 전략을 충분히 사용할 수 있다.
다만, Argo Rollouts와는 다르게 1개의 서비스를 2개의 배포에 selector 를 통해 스위칭하게 되는 방식으로 Blue/Green 버전 간에 스위칭을 하는 도중에 트래픽이 잘못 전달될 가능성이 존재할 수도 있으며, 수작업으로 selector 내용을 변경하기 때문에 위험성이 있다.
그에 반해 Argo Rollouts는 기본적으로 2개의 서비스를 기본으로 갖고, 상황에 따라 2개의 서비스가 하나의 배포를 가리키키도 하고, 각각의 배포를 가리키기도 한다.
애초에 서비스가 2개로 분리되어 있기 때문에, 실제 트래픽은 무조건 stable/active 서비스로 연결하고, 테스트를 위한 트래픽은 preview 로 연결되도록 고정해두면 서비스를 스위칭할 필요가 없어지며, 요청하는 쪽에서 어떤 서비스를 호출할지만 명확하게 알고 있으면 된다.
또한 2개의 서비스가 어떤 replicaSet와 연결될지는 Argo Rollouts가 관리해주기 때문에 실수의 위험성이 적다.
사실은 Argo Rollouts를 사용하지 않더라도, 2개의 서비스를 사용하도록 구성한다면 큰 문제 없을 것 같지만, 어쨌든 별도로 selector 를 수정하는 작업이 필요하기 때문에 자동으로 관리되는 Argo Rollouts를 사용하는 것이 좋아보인다.
Promote 후, 기존 버전의 유지 여부
아무리 preview 버전을 테스트를 마쳤다고 하더라도, 운영 상황에서는 예측할 수 없는 상황이 발생할 수 있다. 다행히 이전 버전 replicaSet이 유지가 되고 있기 때문에 큰 문제 없이 롤백이 가능하다.
그러나, 이전 버전 Pod 가 다시 쿠버네티스에 생성되는 동안, Down Time이 발생할 수도 있다.
최소한, 직전 버전의 Pod 들이 promote 후에도 종료되지 않고 남아있다면, 문제가 생겼을 때 바로 트래픽을 이전 버전의 Pod 로 보낼수 있을 것이다.
Rollouts 의 Spec에는 이에 해당하는 설정 값은 특별히 없지만, 비슷하게 사용할 수 있는 값이 있다.
# Adds a delay before scaling down the previous ReplicaSet. If omitted,
# the Rollout waits 30 seconds before scaling down the previous ReplicaSet.
# A minimum of 30 seconds is recommended to ensure IP table propagation
# across the nodes in a cluster.
scaleDownDelaySeconds: 30
YAML
복사
scaleDownDelaySeconds 값은 이전 버전의 replicaSet 이 scale down 되는 것을 지연시키는 설정이다.
기본적으로는 30초 후에 scale down되도록 되어있지만, 사용에 따라서 긴 시간 동안 scale down되는 것을 방지할 수 있다.
아래는 scaleDownDelaySeconds: 43200 로 설정하여 12시간 후에 scale down이 되도록 설정한 경우 예시이다.
revision: 1 에 해당하는 replicaSet이 11시간의 delay를 갖고 있는 것을 확인할 수 있다.
Name: rollout-bluegreen
Namespace: default
Status: ✔ Healthy
Strategy: BlueGreen
Images: argoproj/rollouts-demo:blue
argoproj/rollouts-demo:green (stable, active)
Replicas:
Desired: 1
Current: 2
Updated: 1
Ready: 1
Available: 1
NAME KIND STATUS AGE INFO
⟳ rollout-bluegreen Rollout ✔ Healthy 3m35s
├──# revision:2
│ └──⧉ rollout-bluegreen-75695867f ReplicaSet ✔ Healthy 2m29s stable,active
│ └──□ rollout-bluegreen-75695867f-lq4x9 Pod ✔ Running 2m29s ready:1/1
└──# revision:1
└──⧉ rollout-bluegreen-5ffd47b8d4 ReplicaSet ✔ Healthy 3m35s delay:11h
└──□ rollout-bluegreen-5ffd47b8d4-b6db9 Pod ✔ Running 3m35s ready:1/1
YAML
복사
Preview 버전이 완벽하게 동일한 구성을 해야하는가
실제 운영 환경은 stable 버전이 상당히 많은 수의 Pod로 구성되어 있을 확률이 많다.
Blue/Green 배포 전략을 사용할 경우, 두 배포를 동일하게 배포되는 시점이 있을 수 밖에 없고, 만약 많은 수의 Pod로 구성되는 서비스라면 리소스 사용량에 부담이 될 수 있다. (클라우드 서비스를 이용중이라면 비용의 문제도 생각해 볼 수 있다.)
이를 조정하기 위한 값을 Argo Rollouts 에서 제공하고 있다. Rollouts 리소스 Spec을 참고하면, previewReplicaCount 라는 값을 확인할 수 있다. previewReplicaCount 는 preview 버전 replicaSet의 Pod 갯수를 지정하는 옵션이다. 이 값을 활용하여 업데이트 전에 테스트할 preview 환경의 크기를 조정할 수 있다.
# The number of replicas to run under the preview service before the
# switchover. Once the rollout is resumed the new ReplicaSet will be fully
# scaled up before the switch occurs +optional
previewReplicaCount: 1
YAML
복사
preview 버전 교체 가능 여부
새로운 버전인 preview 버전을 테스트 중에 오류를 발견하고, 수정 후에 새로운 preview 버전으로 바꾸는 경우가 있다.
이 경우 원래 방법대로 이미지를 바꿔서 manifest 를 업데이트하면, 기존의 preview 버전은 scale down되고 revision이 변경되며 새로운 preview 버전이 배포된다.
이에 관련된 설정 값은 revisionHistoryLimit 이며 쿠버네티스 기본 설정인 10개와 동일하다.
아래는 revisionHistoryLimit: 2 로 적용 후, preview 버전을 계속 바꾸어 테스트한 결과이다.
•
stable 버전은 revision: 1
•
preview 버전을 계속 교체하자, revision 값이 변경되며 preview 에 해당하는 replicaSet 도 변경된다.
•
revisionHistoryLimit: 2 로 설정했기 때문에, 계속된 preview 업데이트로 인해 revision: 2 는 제거되었고, revision:3 , revision: 4 만 남아있는 상태를 확인할 수 있다.
Name: rollout-bluegreen
Namespace: default
Status: ॥ Paused
Message: BlueGreenPause
Strategy: BlueGreen
Images: alpine:3.17
argoproj/rollouts-demo:blue (stable, active)
nginx:alpine-slim (preview)
Replicas:
Desired: 1
Current: 3
Updated: 1
Ready: 1
Available: 1
NAME KIND STATUS AGE INFO
⟳ rollout-bluegreen Rollout ॥ Paused 5m24s
├──# revision:5
│ └──⧉ rollout-bluegreen-56746bc54b ReplicaSet ✔ Healthy 77s preview
│ └──□ rollout-bluegreen-56746bc54b-4dt7f Pod ✔ Running 77s ready:1/1
├──# revision:4
│ └──⧉ rollout-bluegreen-5668c9d9f9 ReplicaSet ◌ Progressing 2m49s delay:10s
│ └──□ rollout-bluegreen-5668c9d9f9-9xg2r Pod ✔ Completed 2m49s
├──# revision:3
│ └──⧉ rollout-bluegreen-66558dd869 ReplicaSet • ScaledDown 3m53s
└──# revision:1
└──⧉ rollout-bluegreen-5ffd47b8d4 ReplicaSet ✔ Healthy 5m24s stable,active
└──□ rollout-bluegreen-5ffd47b8d4-lk6g8 Pod ✔ Running 5m24s ready:1/1
YAML
복사
마치며
Argo Rollouts 는 Argo CD 를 사용하고있다면, 다양한 배포전략을 쉽게 적용할 수 있도록 도와주는 유용한 플러그인이다.
다만 운영 환경 배포가 민감한 서비스라면, 이 글에서 살펴본 것과 같이 여러가지 상황에 대해 고려하고 적용하는 것이 좋을 것 같다.
참고
•
•
