배포 전략
DevOps 방식에는 여러 가지 방법으로 조직과 최종 사용자에게 이점을 제공하는 빈번한 릴리스 주기가 포함됩니다. 개별 배포가 더 작기 때문에 더 빠르고 스트레스가 덜하지만 여전히 문제가 발생할 수 있습니다. 문제가 발생할 가능성을 줄이려면 조직의 요구 사항에 가장 적합한 배포 전략을 채택해야 합니다.
“빅뱅” 전략이라고도 하는 “대규모 배포” 방식은 이미 알고 있을 것입니다. 아시다시피 이 방법이 최신 애플리케이션에서는 제대로 작동하지 않습니다. 최신 ops의 컨텍스트에서 널리 사용되는 다양한 배포 전략이 있으며, 각 전략에는 상황에 따라 고유한 장단점이 있습니다.
롤링 배포 전략
롤링 배포 전략은 새로운 버전의 코드를 도입하는 데 점진적인 접근 방식을 이용합니다. 새 버전은 일정 기간 동안 단계적으로 진행되어 새 코드의 인스턴스가 점점 늘어나지만, 동시에 기존 코드의 인스턴스는 줄어듭니다. 즉, 기존 인스턴스와 새 인스턴스가 조직 내에서 함께 사용됩니다. 예를 들어 한 번에 하나의 서버, 가상 머신 또는 컨테이너에서 소프트웨어를 업그레이드할 수 있습니다.
이 전략의 장점은 프로덕션 환경에서 새 코드를 모니터링하여 광범위하게 배포되기 전에 성능, 보안, 안정성 및 기타 표준을 충족하는지 확인하는 것입니다.
파랑-녹색 배포 전략
파랑-녹색 배포 전략은 서로 동일한 두 개의 개별 환경을 사용합니다. 하나는 소프트웨어의 새 버전이 포함된 테스트 환경이고, 다른 하나는 현재 프로덕션 환경입니다. 소프트웨어가 제대로 작동하고 표준을 충족하는 데 만족스러우면 현재 모든 프로덕션 트래픽을 처리하도록 프로덕션 환경에서 새 환경으로 완전히 전환할 수 있습니다.
파란색 환경은 현재 프로덕션 환경입니다. 녹색 환경이 정확히 중복된 환경입니다. 먼저 소프트웨어의 최신 버전을 녹색 환경에 배포하고 준비가 되면 파란색 환경에서 녹색으로 애플리케이션 트래픽을 라우팅합니다. 이제 녹색 환경이 프로덕션 환경입니다.
이 전략의 장점은 중단 시간 없이 거의 전환할 수 있다는 것입니다. 또한 녹색 환경을 라이브로 전환한 후 문제가 발생하는 경우 파란색으로 다시 쉽게 전환할 수 있습니다.
카나리아 배포 전략
카나리아 배포 전략은 롤링 배포의 일부 요소를 파란색-녹색 배포와 결합합니다. 한 번에 전환하는 것이 아니라 프로덕션 환경의 제한된 부분에 새 버전을 배포한 다음 모든 트래픽을 새 버전으로 점진적으로 이동하는 것입니다. 이 소프트웨어는 정상적으로 작동하는지 확인할 때까지 제한된 수의 인스턴스 또는 사용자에게 증분 단계로 배포한 다음 인프라의 나머지 부분을 배포합니다.
이 이름은 석탄 광산에서 카나리아를 초기 경고 시스템으로 사용하는 방법에서 나온 것입니다. 카나리아 배포에서는 자동화된 테스트를 수행하고 모니터링 및 분석을 사용하여 인스턴스 또는 사용자의 하위 집합 내에서 새 버전의 문제에 대한 조기 경고를 받을 수 있습니다. 이 방법으로 전체 프로덕션 환경에 영향이 미치지 않도록 합니다.
기능 플래그
기능 플래그 개념은 개발자의 일부에 대해 약간 더 복잡성이 요구되는 또 다른 전략입니다. 동일한 소프트웨어의 두 버전, 즉 이전 버전과 새 버전을 사용하는 대신 기존 소프트웨어와 새로운 변경 사항(기능 등)이 모두 포함된 소프트웨어 버전을 제공하는 것입니다. 새 변경 사항은 기본적으로 유휴 상태이며, 해당 변경 사항에 대한 “기능 플래그”가 플래그 전환으로 활성화될 때까지 표시되지 않습니다. 이 플래그는 구성 파일의 한 줄, 명령줄 인수, 소프트웨어가 시작될 때 소프트웨어에서 조회하는 온라인 서버의 특별한 응답 등 여러 형태를 취할 수 있습니다.
이 방법의 추가적인 강력한 장점은 문제가 있는 경우 쉽게 롤백할 수 있거나 변경 사항을 느리게 출시하는 것이 용이하다는 것입니다. 다운그레이드하거나 업그레이드하기 위해 그러한 비트가 모두 포함된 새 릴리스를 서버나 고객에게 보낼 필요 없이 적절한 플래그를 설정하거나 해제하기만 하면 됩니다.
배포 모범 사례
사용하는 배포 전략에 관계없이 새 소프트웨어 또는 기존 소프트웨어의 새 버전을 배포할 때 위험을 최소화하는 데 도움이 되는 몇 가지 모범 사례가 있습니다.
Azure Pipelines와 같은 적절한 도구를 사용하여 연속 통합 및 배포 파이프라인을 만듭니다.
자동화된 테스트 통합.
통신 채널을 사용하여 테스트 결과를 적절한 당사자에게 알립니다. 즉, 배포에 실패하거나 문제가 발생한 경우 팀에 경고합니다.
배포 직후에 발생하는 문제를 모니터링합니다.
새 버전 배포가 상태 검사를 통과하지 않거나 제대로 작동하지 않는 경우 롤백 계획을 세웁니다.