배포 전략

DevOps 방식에는 여러 가지 방법으로 조직과 최종 사용자에게 이점을 제공하는 빈번한 릴리스 주기가 포함됩니다. 개별 배포가 더 작기 때문에 더 빠르고 스트레스가 덜하지만 여전히 문제가 발생할 수 있습니다. 문제가 발생할 가능성을 줄이려면 조직의 요구 사항에 가장 적합한 배포 전략을 채택해야 합니다.

“빅뱅” 전략이라고도 하는 “대규모 배포” 방식은 이미 알고 있을 것입니다. 아시다시피 이 방법이 최신 애플리케이션에서는 제대로 작동하지 않습니다. 최신 ops의 컨텍스트에서 널리 사용되는 다양한 배포 전략이 있으며, 각 전략에는 상황에 따라 고유한 장단점이 있습니다.

롤링 배포 전략

롤링 배포 전략은 새로운 버전의 코드를 도입하는 데 점진적인 접근 방식을 이용합니다. 새 버전은 일정 기간 동안 단계적으로 진행되며, 이전의 인스턴스를 줄이면서 새 코드의 인스턴스가 점차 증가합니다. 따라서 이전 인스턴스와 새 인스턴스는 롤아웃 중에 배포 대상 간에 공존합니다. 예를 들어 한 번에 하나의 서버, 가상 머신 또는 컨테이너에서 소프트웨어를 업그레이드할 수 있습니다.

이 전략의 장점은 프로덕션 환경에서 새 코드를 모니터링하여 광범위하게 배포되기 전에 성능, 보안, 안정성 및 기타 표준을 충족하는지 확인하는 것입니다.

파랑-녹색 배포 전략

청록색 배포 전략은 가능한 한 비슷하게 유지되고 프로덕션 트래픽을 처리할 수 있는 두 개의 별도 환경을 사용합니다. 한 환경은 현재 프로덕션 부하를 처리하고 다른 환경은 새 버전의 소프트웨어를 호스트하므로 트래픽을 이동하기 전에 유효성을 검사할 수 있습니다. 새 버전이 정상 상태인 경우 한 번에 트래픽을 전환하거나 결과를 모니터링하는 동안 새 환경으로 가는 트래픽의 점유율을 점진적으로 늘릴 수 있습니다.

파란색 환경은 현재 프로덕션 트래픽을 제공하는 환경입니다. 녹색 환경은 이에 상응하는 대등한 환경입니다. 먼저 새 버전의 소프트웨어를 녹색으로 배포하고 유효성을 검사한 다음 프로덕션 트래픽을 파란색에서 녹색으로 라우팅합니다. 전환 후 역할을 바꿀 수 있습니다. 그린은 라이브 환경이 되고 블루는 다음 릴리스를 위해 준비할 수 있습니다.

이 전략의 장점은 가동 중지 시간이 거의 또는 전혀 없는 경우 빠르게 전환할 수 있다는 것입니다. 또한 새 환경이 라이브 상태가 된 후 문제가 발생하는 경우 트래픽을 이전 환경으로 다시 전송하는 것도 비교적 쉽습니다.

카나리아 배포 전략

카나리아 배포 전략은 롤링 배포의 일부 요소를 블루-그린 배포와 결합한 것입니다. 한 번에 전환하는 것이 아니라 프로덕션 환경의 제한된 부분에 새 버전을 배포한 다음 모든 트래픽을 새 버전으로 점진적으로 이동하는 것입니다. 이 소프트웨어는 정상적으로 작동하는지 확인할 때까지 제한된 수의 인스턴스 또는 사용자에게 증분 단계로 배포한 다음 인프라의 나머지 부분을 배포합니다.

이 이름은 석탄 광산에서 카나리아를 초기 경고 시스템으로 사용하는 방법에서 나온 것입니다. 카나리아 배포에서는 자동화된 테스트를 수행하고 모니터링 및 분석을 사용하여 인스턴스 또는 사용자의 하위 집합 내에서 새 버전의 문제에 대한 조기 경고를 받을 수 있습니다. 이 방법으로 전체 프로덕션 환경에 영향이 미치지 않도록 합니다.

기능 플래그

기능 플래그 개념은 개발자의 일부에 대해 약간 더 복잡성이 요구되는 또 다른 전략입니다. 동일한 소프트웨어의 두 가지 개별 버전(이전 버전과 새 기능이 있는 새 버전)을 사용하는 대신 이전 동작과 새 변경 내용이 포함된 단일 버전을 제공합니다. 새 변경 내용은 기본적으로 휴면 상태이며 해당 "기능 플래그"가 활성화될 때까지 표시되지 않습니다. 플래그는 구성 파일의 줄, 명령줄 인수 또는 원격 구성 서비스에서 검색되고 런타임에 평가되는 값을 포함하여 여러 가지 형태를 취할 수 있습니다.

이 방법의 강력한 장점은 문제가 발생할 경우 롤백의 용이성과 변경 내용을 천천히 롤아웃하는 용이성입니다. 대부분의 경우 기능을 노출하거나 숨기기 위해 새 릴리스를 제공할 필요가 없습니다. 적절한 플래그를 해제하거나 켜고 실행 중인 애플리케이션이 새 설정에 반응하도록 할 수 있습니다.

Azure Azure App Configurationfeature management 기능은 .NET, Java, Python, JavaScript 및 Go에 대한 SDK 지원을 통해 애플리케이션이 런타임에 읽을 수 있는 관리되는 기능 플래그 저장소를 제공합니다.

링 기반 배포

링 기반 배포는 Microsoft 및 Azure 내에서 널리 사용되는 점진적 롤아웃의 구조화된 형태입니다. 새 코드는 "링" 시퀀스로 릴리스됩니다. 예를 들어 내부 또는 자체 테스트 링, 초기 사용자 링, 광범위한 배포 링 및 마지막으로 일반 공급 링이 있습니다. 각 링은 이전 링보다 크며 현재 링의 상태 신호가 정의된 조건을 충족한 후에만 배포가 다음 링으로 진행됩니다. 링 기반 배포는 카나리아 배포의 점진적 노출과 명시적인 명명된 대상 그룹 및 링 간의 승인 게이트를 결합합니다.

점진적 배달

위의 전략(카나리아, 링 기반, 기능 플래그)은 종종 점진적 전달이라는 포괄적 용어로 그룹화됩니다. 통합된 개념은 릴리스가 제어된 상태에서 점차 증가하는 청중에게 노출되고, 상태 및 비즈니스 메트릭으로 계측되며, 이러한 신호에 따라 자동으로 진행되거나 롤백된다는 것입니다. 점진적 배달은 개별 변경의 폭발 반경을 제한하기 때문에 안정성이 높은 클라우드 서비스의 기본 모델이 점점 더 많아지고 있습니다.

배포 모범 사례

사용하는 배포 전략에 관계없이 새 소프트웨어 또는 새 버전의 기존 소프트웨어를 배포할 때 위험을 최소화하는 데 도움이 되는 몇 가지 모범 사례는 다음과 같습니다.

• Azure Pipelines 또는 GitHub Actions 같은 적절한 도구를 사용하여 연속 통합 및 배포 파이프라인을 만듭니다.

• 자동화된 테스트 통합.

• 통신 채널을 사용하여 올바른 당사자에게 테스트 결과를 알립니다. 예를 들어 배포가 실패하거나 문제가 발생할 때 팀에 경고합니다.

• 배포 직후에 발생하는 문제를 모니터링합니다.

• 새 버전이 상태 검사를 통과하지 못하거나 제대로 작동하지 않는 경우 롤백할 계획을 세워야 합니다.