이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.
배포 전략
로드밸런서의 등장으로 인해 수평적 확장을 사용해 다수의 웹 서버를 동시에 운용할 수 있게 되었다. 따라서 웹 애플리케이션의 버전 변경을 위한 재배포에서 하나의 웹 서버만 바꾸는 것이 아니라모든 다수의 웹 서버를 새로운 버전으로 바꾸는 재배포가 필요하다. 이에 다음과 같은 배포 전략들이 등장하였다.
Rolling
Rolling 배포 방식 구버전 서버를 하나 죽이기 -> 신버전 서버를 하나 살리기 반복
버전 간 트래픽이 섞이지 않는다.
이미 갖고 있는 인스턴스 수 안에서 점진적 배포가 되기 때문에, 추가 비용이 발생하지 않고 수용성(capacity)이 좋다.
Rolling은 Rolling with Additional Batch나 Immutable 전략과 함께 사용되기도 한다.
Rolling with Additional Batch
Rolling with Additional Batch
Rolling with Additional Batch는 구버전 서버를 죽이는 동안트래픽을 분산시키기 위해서추가적인 인스턴스를 임시로만들어서 사용하는 것이다. 위 그림에서처럼 구버전 서버를 죽이기 전에 신버전 서버를 미리 만들어서 트래픽이 몰리는 것을 방지했다. 세번째 줄의 서버는 신버전 서버의 배포가 모두 완료된 후 삭제된다.
격리를 위해서 구버전 서버들과 신버전 서버들의 그룹을 나눈다. 즉, 구버전 서버들은 하나의 ASG(Auto Scaling Group)으로 묶여있고,구버전 서버의 갯수만큼 신버전 서버들을 만들어서 또 다른 ASG로 묶는다.
신버전 서버 ASG를 배포시킨 후, 로드 밸런서가 신버전의 ASG를 가리킬 수 있도록 하고 구버전 서버 ASG의 구버전 서버들은 종료시킨다.
Immutable 전략은무중단 배포(Down time = 0)이다. 기존 서버에 신버전을 배포하는 대신 새로운 서버에 신버전을 배포한 후, 구버전 서버들을 신버전 서버로 모두 갈아 끼워서 무중단 배포를 가능케 한다. 기존 서버의 갯수와 동일하게 서버를 늘리기 때문에높은 비용이 요구되지만, 재배포 과정에서의 트래픽을 분산시킬 수 있기 때문에 수용성(capacity)이 높다.
만약 신버전에서 오류가 발생하더라도 신버전 서버 ASG를 종료시키고 기존 버전으로 돌아가면 되기 때문에 롤백이 빠르다.
+) ASG는 최소 보장 인스턴스 수를 가진다. ELB에서는 ASG 때문에 인스턴스 수를 유지해야함. 인스턴스 죽이려면 최소 인스턴스 수 0으로 만든 후 죽이기
Canary
canary
신버전 테스트 후 신버전으로 전체 전환을 한다. 의도적으로 버전 간 트래픽을 섞는다. => 버전 간 트래픽이 섞인다.
예시로 A/B 테스트가 있다. 로드밸런서를 사용하여 A안과 B안의 트래픽을 50대 50으로 유지한다. A안과 B안 중 더 나은 것이 무엇인가 유저를 대상으로 일종의 사회실험을 진행하는 것이다.
UI 컴포넌트들의 A/B 테스트를 위해서 각각의 UI 컴포넌트를 API로 처리하기도 한다. 이 경우 API 호출을 내부적으로 하기 위해서 SSR 방식으로 렌더링한다.
Blue-Green
Blue 그룹과 Green 그룹으로 나누어서 그룹별로 버전을 배포한다.
로드 밸런서로 신버전의 그룹으로 트래픽을 전환한다. 만약 신버전 그룹에 문제가 발생하게 되면 다시 구버전 그룹으로 트래픽을 전환하여즉시 롤백이 가능하다는 장점이 있다.
전환이 빠르다는 장점을 가지지만, 서버가 2배이기 때문에 비용도 2배이다.
Canary + Blue-Green
일반적으로 빅테크 기업에서는 Canary + Blue-Green 방식을 합쳐 배포하며, Blue-Green이 Canary 개념을 내포하기도 한다.
Blue-Green과 Canary를 함께 사용하는 경우에는, 구버전 그룹의 부하를 9로 주고, 신버전 그룹의 부하를 1로 주어서 신버전에 문제가 생기면 바로 신버전 그룹의 부하를 주지 않는 방식으로 롤백할 수 있다. 문제가 없다면 신버전 그룹의 부하를 점진적으로 늘린다. 구버전 그룹의 부하가 0이 되는 경우 트래픽 전환 완료되며, 안전한 버전업이 가능하다는 장점을 가진다.
