1. 개요
이 사용방법(예제)에서는 가장 일반적인 6가지 배포 전략에 대해 설명합니다.
2. 배포 전략
애플리케이션을 배포할 때마다 프로세스를 신중하게 계획해야 합니다. 다양한 측면과 그것이 사용자 경험에 미치는 영향을 고려해야 합니다. 배포는 다운타임 없이 사용자 경험을 방해하지 않고 애플리케이션을 설치하거나 업그레이드하는 것을 목표로 합니다.
배포 전략은 이러한 업그레이드를 수행하는 방법에 대한 프로세스를 설명합니다.
3. 배포 전략 재작성
우리가 논의하는 가장 기본적인 전략은 "재작성" 배포 전략입니다. 이름에서 알 수 있듯이 애플리케이션을 중지한 다음 다시 만듭니다. 새로 생성된 배포는 애플리케이션의 업데이트된 버전을 실행합니다.
새 버전이 실행되기 전에 애플리케이션을 중지해야 하기 때문에 사용자는 약간의 가동 중지 시간을 경험하게 됩니다. 원래 버전이 종료되고 새 버전이 시작되는 동안에는 응용 프로그램을 사용할 수 없습니다.
반면에 이 전략은 설정하기 쉽습니다. 서로 다른 두 버전의 애플리케이션을 동시에 관리할 필요가 없습니다. 이 접근 방식을 선택하면 모든 사용자가 업데이트된 애플리케이션을 즉시 사용할 수 있습니다. 새 버전이 응용 프로그램에 버그를 도입할 수 있고 사용자도 버그를 볼 수 있기 때문에 여기에는 단점이 있습니다.
이전 작업 버전으로 완전히 롤백해야 할 수도 있습니다. 안타깝게도 롤백으로 인해 다운타임도 발생합니다. 배포를 되돌리려면 업데이트된 애플리케이션을 중지하고 원래 애플리케이션을 다시 만들어야 합니다.
결론적으로 이 배포 전략은 설정 및 관리가 매우 간단하지만 사용하기 전에 단점을 고려해야 합니다.
4. 블루-그린 배포
논의할 다음 배포 전략은 "블루-그린" 배포입니다. 이 경우 다른 애플리케이션 버전에 다른 색상을 할당합니다. 그것이 이름의 유래입니다. 원래의 이전 버전을 블루 환경이라고 하고 새로 업데이트된 버전을 그린 환경이라고 합니다.
이 전략이 어떻게 작동하는지 봅시다. 첫째, 푸른 환경이 있습니다. 이것은 모든 사용자 트래픽을 처리하는 기존 애플리케이션입니다. 다운타임 없이 애플리케이션을 업데이트하고 싶습니다. 이를 달성하기 위해 거의 동일한 환경을 만듭니다. 하지만 차이가 있습니다. 새 환경에는 업데이트된 애플리케이션 버전이 포함됩니다. 이제 두 환경 모두 애플리케이션을 실행하고 있지만 사용자는 여전히 이전 버전을 사용하고 있습니다.
위의 이미지는 이미 새 버전을 시작했지만 사용자는 여전히 블루 환경을 사용하고 있는 상태를 보여줍니다. 다음 단계는 모든 사용자 트래픽을 녹색 환경으로 전송하여 녹색 환경으로 전환하는 것입니다. 이 전환은 매우 빠르게 발생할 수 있으므로 사용자는 다운타임을 경험하지 않습니다. 또한 이전과 동일한 방식으로 애플리케이션을 사용할 수 있으며 업데이트된 애플리케이션에서 요청을 처리하고 있는지 알지 못합니다.
변경 사항을 롤백해야 하는 경우 트래픽을 원래의 블루 환경으로 라우팅하여 즉시 롤백할 수 있습니다. 배포가 완료되고 롤백하지 않으려면 이전 블루 환경을 제거할 수 있습니다. 그런 다음 업데이트된 버전의 이름을 녹색에서 파란색으로 바꿉니다. 다음 릴리스는 동일한 절차를 따를 수 있습니다.
가동 시간과 롤백 가능성 측면에서 이 프로세스가 더 낫다는 것을 알 수 있습니다. 그러나 단점도 있습니다. 두 개의 거의 동일한 환경을 만들기 때문에 더 높은 리소스 요구 사항이 있습니다. 이는 설정하는 데 비용과 시간이 많이 소요될 수 있습니다. 둘째, 새 버전이 이전 버전과 호환되지 않는 변경 사항을 만드는 경우 롤백에 문제가 발생할 수 있습니다. 예를 들어 데이터베이스의 변경 사항입니다.
5. 롤링 업데이트
다음 전략은 "롤링 업데이트"입니다. 응용 프로그램의 여러 인스턴스가 있는 경우에만 적용됩니다.
처음에는 모든 인스턴스가 이전 버전을 실행하고 있으며 모두 사용자 요청을 처리할 수 있습니다. 프로세스가 인스턴스를 제거하고 나머지 인스턴스는 다운타임을 방지하기 위해 사용자에게 서비스를 제공할 수 있어야 하기 때문에 여기에서 중요합니다.
먼저 업데이트된 버전을 실행하는 새 인스턴스를 만듭니다. 이 새 인스턴스가 시작되면 애플리케이션의 일부로 간주하므로 사용자 요청이 이미 처리되었을 수 있습니다.
그런 다음 이전 버전을 실행하는 인스턴스에서 하나를 제거합니다. 이렇게 하면 이전 버전을 실행하는 인스턴스 2개와 업데이트된 버전을 실행하는 인스턴스 1개가 있습니다. 이는 이 배포 전략을 사용하려면 동시에 다른 버전을 지원할 수 있어야 함을 나타냅니다. 그렇지 않으면 이전 또는 새 인스턴스가 예상대로 작동하지 않을 수 있습니다.
프로세스는 계속해서 새 버전을 실행하는 인스턴스를 추가하고 해당 쌍을 제거합니다.
마지막 인스턴스가 업데이트된 인스턴스로 교체되면 배포가 완료되고 애플리케이션이 예상대로 작동하는지 확인했습니다. 물론 업데이트 중에도 테스트할 수 있습니다. 문제가 발견되면 모든 변경 사항을 롤백할 수 있습니다.
이 배포 전략은 요구 사항에 더 잘 맞도록 매개 변수화할 수 있습니다. 일반적으로 한 번에 업데이트할 인스턴스 수를 설정할 수 있습니다. 둘 이상이 될 수 있습니다. 단순성을 위해 예제에서 이 값을 사용했습니다.
6. 카나리아 배포
우리가 검토 하는 다음 배포 방법을 "카나리아 배포"라고 합니다. 주요 아이디어는 업데이트를 반복적으로 더 많은 사용자에게 배포한다는 것입니다.
처음에는 소수의 사용자만 업데이트를 받습니다. 이 단계 후에 시스템을 테스트하여 변경 후 응용 프로그램이 제대로 작동하는지 확인합니다. 이렇게 하면 위험을 줄일 수 있으며 시스템에 버그를 도입하더라도 일부 사용자만 볼 수 있습니다.
업데이트가 성공했다고 확신하면 모든 사용자에게 롤아웃을 계속할 수 있습니다. 이것은 점진적으로 발생할 수도 있습니다. 즉, 업데이트가 점점 더 많은 사용자에게 점진적으로 전달됩니다. 예를 들어 25%, 50%, 75%, 100%입니다. 증분할 때마다 시스템을 다시 테스트할 수도 있습니다.
테스트 중에 응용 프로그램이 제대로 작동하지 않는 것을 알 수 있습니다. 이 경우 이전 예제와 유사한 변경 사항을 롤백해야 합니다.
카나리아 배포는 높은 수준의 제어를 제공하지만 구현하기 어려울 수 있습니다. 제한된 수의 사용자만 업데이트를 받을 수 있도록 해야 합니다. 한 환경에서 다른 환경으로 트래픽을 전환하기만 하면 되는 청록색 배포와 비교할 때 이는 더 어렵습니다. 반면에 더 많은 유연성을 제공하고 위험을 줄입니다.
이 프로세스는 환경을 복제하지 않기 때문에 블루-그린 배포만큼 많은 리소스가 필요하지 않습니다. 그러나 새 응용 프로그램 버전이 데이터베이스에서 몇 가지 중요한 변경 사항을 만드는 경우 동일한 문제에 직면합니다.
카나리아 배포 전략에는 또 다른 흥미로운 측면이 있습니다. 먼저 업데이트를 받는 대상 고객을 선택해야 합니다. 이상적으로는 업데이트에서 문제를 발견하면 보고할 대상 그룹입니다. 그러나 인구 통계, 물리적 위치, 장치 유형 등에 따라 사용자를 선택할 수 있습니다.
7. A/B 테스트
A/B 테스트는 카나리아 배포와 매우 유사합니다. 그것의 변형으로 간주 될 수 있습니다. 이 프로세스는 카나리아 배포와 마찬가지로 사용자 하위 집합에 업데이트를 배포합니다. 그러나 A/B 테스트는 주로 사용자로부터 변경 사항에 대한 피드백을 받는 것입니다. 사용자 중 일부는 애플리케이션의 "버전 A"를 계속 사용하고 다른 일부는 "버전 B"를 사용합니다.
우리의 목표는 업데이트를 모든 사용자에게 롤아웃할지 여부를 결정하는 것입니다. 이것은 복잡한 과정일 수 있습니다. 애플리케이션 성능과 같은 기술적인 측면을 고려해야 하지만 변경 사항이 마음에 드는지 여부에 대한 사용자의 피드백을 받고 싶을 수도 있습니다. 예를 들어 A/B 테스트를 통해 버튼의 텍스트를 교체하면 사용자가 버튼을 클릭할 가능성이 더 높은지 측정할 수 있습니다.
8. 섀도우 배치
섀도 배포는 두 개의 동일한 환경을 사용한다는 점에서 청록색 배포와 유사합니다. 그 중 하나는 원래 프로덕션 환경입니다. 다른 하나는 그림자입니다.
그러나 이전 배포 전략과는 다릅니다. 이전의 모든 접근 방식에서 사용자 요청은 업데이트된 환경에서 제공되었습니다. 섀도우 배포를 사용하면 두 환경 모두 요청을 받지만 응답은 원래 애플리케이션 버전에서 옵니다.
이렇게 하면 로드 중인 새 버전을 모니터링하고 테스트할 수 있는 동안 시스템에 버그를 도입할 위험이 없습니다.
반면에 두 개의 배포를 갖는 것은 비용이 많이 들고 관리하기 어려울 수 있습니다. 또한 새 버전에 부작용이 없는지 확인해야 합니다. 예를 들어 결제를 처리하는 경우 사용자에게 두 번 청구하지 않도록 새로운 환경에서 결제 서비스를 모의 처리해야 합니다.
업데이트된 버전이 안정적이라고 확신하면 이전 버전을 대체할 수 있으며 사용자 트래픽을 이 버전으로 리디렉션할 수 있습니다.
9. 결론
이 문서에서는 배포 전략이 무엇인지 설명하고 6가지 전략을 비교했습니다.
시스템에서 사용할 항목을 선택하기 전에 여러 측면을 고려하고 가능한 배포 전략을 비교해야 합니다.
