⇥ DevOps Tech 🙋🏻‍♀️/✏️ CICD

Rollback (Semver, Rolling, blue/green)

배포를 하다 보면 나가면 안 되는 사항이 배포되거나, 문제로 인해서 되돌려야 하는 상황이 있다. 이에 대한 정책을 롤백이라고 하며 각 배포 방식에서 롤백은 어떻게 진행되는지에 대해서 간단히 정리하고자 하는 문서이다.

SemVer 란 ?

그렇다면 우리는 어디까지가 이전에 배포되었던 코드이며, 어디부터 되돌려야 하는지 같은 기준점이 필요하다.
기준점을 관리하기 위한 제안을 위해 도입된 정책이며 다양한 곳에서 사용 중인 Semantic Versioning 기법이다.

SemVer -> Semantic versioning

체계적인 버전관리를 위한 제안, 배포 정책이나 시기에 따라서 버전이 매겨지거나, 의미 없는 버전 상승을 지양하여 버저닝에 대한 명확한 의미를 부여

버전의 형식 : Major.Minor.Patch
이전 버전과 호환되지 않는 API 변경은 MAJOR 버전 증가, 이전 버전과 호환되면서 기능 변경, 추가의 경우엔 MINOR 버전 증가, 단순한 버그 수정은 PATCH 버전이 증가된다.
이러한 방식은 버전만 보고도 호환이 가능한지 불가능한지 어디까지 배포가 진행되었으며 버그 패치가 되었는지 한눈에 확인할 수 있도록 해준다.

Rollback 방안

SemVer로 인해 버저닝이 되고 있는 상황에서 롤백이 필요한 상황이 있을 수 있다.
롤백에 사용되는 Artifact는 기존에 빌드된 것을 사용하는 방법, 버저닝 된 정보를 이용하여 재빌드 롤백 하는 방법 2가지가 존재한다.
각 방법 역시 장단점이 존재하며, 상황에 맞는 방안을 선택해야 한다.

빨간 선 (기존 빌드된 아티팩트 사용) 은 Git clone , build 등의 동작이 skip 되어 빠른 롤백이 가능하다. 그리고 기존에 배포되어 운영되던 아티팩트라는 점에서 정상 동작을 보장할 수 있기 때문에 신뢰성이 비교적 높은 롤백 방법이다.
하지만 이전 Artifact를 모두 저장하고 있어야 할 공간이 필요하며 저장 기간, 보관할 버전의 개수 등 정책을 정하는 등 관리포인트가 늘어나는 단점을 가지고 있다.

파란 선 (버저닝 된 시점의 빌드 진행) 은 기존에 배포했던 코드로 돌아가서 빌드를 다시 진행하는 방법이다. 모든 버전으로 롤백이 가능하며 별도로 저장할 공간이 필요 없다는 장점을 가지고 있다. 하지만 빌드 과정부터 다시 하기 때문에 롤백 속도가 느리다는 단점을 가지고 있다.

상황에 따라 관리가 용이하고 넉넉한 저장소를 가지고 있다면 빨간 선으로 롤백하는 것이 좋다. 롤백은 빠르게 이루어져야 하기 때문에 빌드 과정이 스킵된다는 것은 큰 차이를 가지고 있기 때문이다. 하지만 별도의 저장소나 관리 포인트가 많아지는 것을 경계한다면 파란 선의 방안을 선택해야 한다. 가장 좋은 방법은 배포 과정에서 여러 번의 확인을 거쳐서 롤백하는 일이 없도록 하는 것이 가장 좋다.

Rolling 배포 에서의 롤백

배포 도중 문제가 발생하여 롤백하는 경우

배포 도중에 에러가 발생하여, 배포가 안 되는 경우에 진행되는 롤백이다.
이러한 경우는 stage까지 배포하여 확인했지만 실제 운영 환경을 고려하지 않은 부분이 있을 때 발생할 수 있다. 즉 테스트 단계에서 고려되지 않은 부분이 발생할 경우 배포 도중 긴급히 롤백을 진행해야 한다.
이전 tagging Version으로 git clone 하여 빌드를 진행한다. 앞서 Rollback 시 tagging Version을 사용하는 경우 아티팩트를 모두 저장하고 있지 않고 롤백할 때 빌드하여 사용한다고 하였기 때문에 build 가 다시 일어나게 된다.

api01 인스턴스 배포를 하다가 에러가 발생한 상황이기 때문에 Load Balancer의 멤버 투입은 제외되어 있을 것이고 빠르게 이전에 정상 적용되어 있던 (api02, api03에 배포되어 있는) 아티팩트로 롤백하여 원상 복구하는 방식이다.

운영 도중 문제가 발생하여 롤백하는 경우

이러한 경우는 이미 배포되어 운영 중이나, 어떤 결함이 발생하여 기존 버전으로 되돌려야 하는 상황에 진행된다.
이전 tagging Version을 다시 clone, build 과정이 수행되고 빌드된 artifact를 모든 인스턴스에 재배포하는 방식으로 진행된다.

Blue/green 배포에서의 롤백

blue green 은 롤백에 최적화된 배포 방식이다. 롤링 방식은 각 인스턴스가 전환되는 시간이 있기 때문에 많은 인스턴스일수록 배포 속도가 느릴수록 많은 시간이 걸리지만 blue/green 은 LB 컨트롤만으로 쉽게 롤백을 할 수 있다.

B 그룹에 신규 버전을 배포한다. 이때 배포되는 B 그룹은 Load Balancer 멤버에서 제외되어 있고 A 그룹으로만 운영되고 있는 서비스.
신규 버전 배포가 완료되었다면 Load Balancer는 트래픽을 B 그룹으로 향하도록 조정한다. 이렇게 되면 모든 인스턴스가 한 번에 버전 업그레이드 되기 때문에 업데이트 역시 빠르게 가능하다.

하지만 이때 문제가 발생하여 롤백이 필요한 상황이 있을 수 있다.

git clone, build 과정을 다시 진행할 필요 없이, 신속하게 Load Balancer의 트래픽을 B그룹에서 A그룹으로 바꿔주는 것 만으로 롤백이 완료된다. 빠르게 롤백이 가능하고 기존 운영되던 환경을 그대로 재사용하는 것이기 때문에 문제가 발생할 확률이 적지만 운영의 2배 환경을 보유하고 있어야 하기 때문에 비용적 측면에서 단점을 가지고 있다.

썸네일 정보

작가 vectorjuice 출처 Freepik