안전한 배포 방법에 대한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:11 워크로드의 안전한 배포 사례를 명확하게 정의합니다. 작고 증분적인 품질 제어 릴리스 방법의 이상을 강조합니다. 최신 배포 패턴 및 점진적 노출 기술을 사용하여 위험을 제어합니다. 일상적인 배포 및 긴급 또는 핫픽스 배포를 고려합니다.

이 가이드에서는 SDP(안전한 배포 사례)를 사용하기 위한 권장 사항을 설명합니다. 안전한 배포 프로세스 및 절차는 워크로드를 안전하게 변경하고 배포하는 방법을 정의합니다. SDP를 구현하려면 위험 관리의 렌즈를 통해 배포에 대해 생각해야 합니다. 배포에서 사용자 오류의 위험을 최소화하고 SDP를 구현하여 사용자에게 문제가 있는 배포의 영향을 제한할 수 있습니다.

주요 디자인 전략

안전한 배포 사례를 구현할 때 유의해야 할 네 가지 중요한 지침이 있습니다.

  • 안전 및 일관성: 프로덕션 워크로드에 대한 모든 변경 내용은 본질적으로 위험하며 안전 및 일관성에 중점을 두어야 합니다.

  • 점진적 노출: 점진적 노출 배포 모델을 채택하여 배포로 인한 문제의 잠재적인 폭발 반경을 최소화할 수 있습니다.

  • 상태 모델: 배포는 점진적 노출의 각 단계를 시작하기 전에 상태 검사를 통과해야 합니다.

  • 문제 검색: 문제가 감지되면 배포를 즉시 중지하고 복구를 시작해야 합니다.

다음 섹션에서는 이러한 각 사항에 대한 자세한 권장 사항을 제공합니다.

안전 및 일관성

애플리케이션 코드, IaC(Infrastructure as code), 기능 플래그 또는 구성 업데이트에 업데이트를 배포하는 경우 워크로드에 위험이 발생합니다. 프로덕션에 대한 위험 수준이 낮은 배포는 없습니다. 모든 배포는 표준 패턴을 따라야 하며 일관성을 적용하고 사용자 오류의 위험을 최소화하기 위해 자동화되어야 합니다. 워크로드 공급망 및 배포 파이프라인은 안정적이고 안전하며 배포 표준을 명확하게 정의하는 것이 중요합니다. 모든 배포를 가능한 위험으로 처리하고 모든 배포에 동일한 수준의 위험 관리를 적용합니다. 위험에도 불구하고 워크로드에 정기적인 변경 내용을 계속 배포해야 합니다. 정기적인 업데이트를 배포하지 못하면 배포를 통해 해결해야 하는 보안 취약성과 같은 다른 위험이 발생합니다. 자세한 내용은 워크로드 개발 공급망 설계에 대한 권장 사항을 참조하세요.

자주 사용되는 소규모 배포는 자주 대규모 배포를 사용하는 것이 좋습니다. 작은 변경은 문제가 발생하고 자주 배포하는 경우 resolve 팀이 배포 프로세스에 대한 신뢰를 구축하는 데 도움이 됩니다. 배포 중에 변칙이 발생할 때 워크로드 프로세스를 검토하여 프로덕션에서 학습하는 것도 중요합니다. 인프라 또는 롤아웃 디자인에서 약점을 발견할 수 있습니다. 배포 중에 문제가 발생하는 경우 흠 없는 사후 시스템이 인시던트에 대한 교훈을 캡처하는 SDP 프로세스의 일부인지 확인합니다.

점진적 노출 배포

배포 문제가 발생하면 최종 사용자에게 미치는 영향을 최소화하기 위해 가능한 한 빨리 catch하는 것이 목표입니다. 점진적 노출 모델이라고도 하는 점진적 출시 배포 모델을 구현하여 이 목표를 달성합니다. 카나리아 배포는 점진적 노출의 일반적인 예입니다. 이 배포 모델에서는 소수의 내부 또는 외부 사용자가 먼저 새 기능을 받습니다. 첫 번째 그룹이 문제 없이 새 버전을 실행하면 전체 사용자 모집단이 새 버전을 실행할 때까지 기능이 연속적으로 더 큰 그룹에 배포됩니다. 기능 플래그는 일반적으로 카나리아 배포에서 대상 사용자에게 새 버전을 사용하도록 설정하는 데 사용됩니다.

또 다른 일반적인 배포 모델은 파란색-녹색 접근 방식입니다. 이 모델에서는 워크로드 인프라의 두 개의 동일한 집합 또는 풀이 배포됩니다. 두 풀 모두 전체 프로덕션 부하를 처리할 수 있습니다. 첫 번째(파란색) 풀은 모든 사용자가 도착하는 배포의 현재 버전을 실행합니다. 두 번째(녹색) 풀은 새 기능으로 업데이트되고 내부적으로 테스트됩니다. 내부 테스트 후 프로덕션 트래픽의 하위 집합이 파란색 풀에서 녹색 풀로 라우팅됩니다. 카나리아 배포와 마찬가지로 연속적으로 더 큰 롤아웃 웨이브에서 더 많은 트래픽을 녹색 풀로 이동하면 롤아웃이 진행됩니다. 롤아웃을 완료하면 업데이트 풀이 파란색 풀이 되고 녹색 풀이 다음 배포를 위해 준비됩니다. 두 풀은 오작동으로부터 보호하기 위해 논리적으로 서로 분리됩니다. 한 번에 하나의 스탬프에 배포하여 배포 스탬프 디자인 패턴을 사용하는 워크로드에서 파란색-녹색 모델의 변형을 배포할 수 있습니다.

이러한 두 모델에서 롤아웃의 각 단계 사이의 시간은 워크로드의 상태 메트릭을 모니터링할 수 있을 만큼 충분히 길어야 합니다. 다른 지역의 사용자 또는 다른 작업을 수행하는 사용자가 정상 용량에서 워크로드를 사용할 시간을 갖도록 하려면 출시 그룹 간에 충분한 베이킹 시간, 시간을 제공해야 합니다. 베이킹 시간은 분이 아닌 시간과 일로 측정해야 합니다. 하루 동안 다른 표준 시간대 및 사용 패턴을 고려할 수 있도록 각 출시 그룹에 대한 베이킹 시간도 증가해야 합니다.

상태 모델

가시성 플랫폼 및 안정성 전략의 일부로 강력한 상태 모델을 개발합니다. 상태 모델은 워크로드의 구성 요소 및 전반적인 상태에 대한 심층적인 가시성을 제공해야 합니다. 롤아웃 중에 최종 사용자와 관련된 상태 변경에 대한 경고를 받으면 롤아웃이 즉시 중지되고 경고의 원인에 대한 조사를 수행하여 다음 작업 과정을 결정해야 합니다. 최종 사용자가 보고한 문제가 없고 모든 상태 지표가 베이킹 시간 내내 녹색으로 유지되는 경우 롤아웃은 계속되어야 합니다. 사용자가 보고한 문제 및 부정적인 상태 신호가 문제를 숨기지 않도록 하려면 상태 모델에 사용 메트릭을 포함해야 합니다. 자세한 내용은 상태 모델 빌드를 참조하세요.

문제 검색

배포로 인해 롤아웃 그룹 중 하나에서 문제가 발생하면 롤아웃이 즉시 중지되어야 합니다. 경고가 수신되는 즉시 문제의 원인과 효과의 심각도에 대한 조사를 수행해야 합니다. 문제 복구에는 다음이 포함될 수 있습니다.

  • 배포에서 변경한 내용을 실행 취소하고 마지막으로 알려진 작업 구성으로 되돌려 배포를 롤백합니다.

  • 롤아웃 중에 문제를 해결하여 배포를 롤아웃합니다. 핫픽스를 적용하거나 문제를 최소화하여 출시 중간에 발생하는 문제를 해결할 수 있습니다.

  • 마지막으로 알려진 작업 구성을 사용하여 새 인프라를 배포합니다.

변경 내용, 특히 데이터베이스, 스키마 또는 기타 상태 저장 구성 요소 변경 내용을 롤백하는 것은 복잡할 수 있습니다. SDP 지침은 워크로드의 데이터 자산 디자인에 따라 데이터 변경 내용을 처리하는 방법에 대한 명확한 지침을 제공해야 합니다. 마찬가지로 SDP가 무시되지 않고 핫픽스 또는 기타 최소화 작업이 안전하게 수행되도록 롤 포워드를 신중하게 처리해야 합니다.

일반 SDP 권장 사항

  • 빌드 아티팩트 간에 버전 관리를 구현하여 필요한 경우 롤백하고 롤백할 수 있도록 합니다.

  • Gitflow 또는 환경 기반 분기 구조 대신 개발 팀 전체에서 긴밀하게 동기화된 협업을 적용하는 릴리스 흐름 또는 트렁크 기반 분기 구조를 사용합니다.

  • 최대한 많은 SDP를 자동화합니다. IaC 및 애플리케이션 CI/CD(연속 통합 및 지속적인 업데이트) 프로세스를 자동화하는 방법에 대한 자세한 지침은 자동화 구현을 위한 권장 사항을 참조하세요.

  • CI 사례를 사용하여 정기적으로 코드 변경 내용을 리포지토리에 통합합니다. CI 사례는 통합 충돌을 식별하고 크고 위험한 병합의 가능성을 줄이는 데 도움이 될 수 있습니다. 자세한 내용은 연속 통합 가이드를 참조하세요.

  • 기능 플래그를 사용하여 프로덕션에서 새 기능 또는 변경 내용을 선택적으로 사용하거나 사용하지 않도록 설정합니다. 기능 플래그는 새 코드의 노출을 제어하고 문제가 발생하는 경우 배포를 신속하게 롤백하는 데 도움이 될 수 있습니다.

  • 프로덕션 환경을 미러 스테이징 환경에 변경 내용을 배포합니다. 연습 환경을 사용하면 라이브 환경에 배포하기 전에 제어된 설정에서 변경 내용을 테스트할 수 있습니다.

  • 코드 검토, 보안 검사 및 규정 준수 검사를 포함하여 배포 전 검사를 설정하여 변경 내용이 안전하게 배포되도록 합니다.

  • 회로 차단기를 구현하여 문제가 발생한 서비스에 대한 트래픽을 자동으로 중지합니다. 이렇게 하면 시스템의 추가 저하를 방지하는 데 도움이 될 수 있습니다.

긴급 SDP 프로토콜

핫픽스 또는 보안 위반 또는 취약성 노출과 같은 긴급 문제에 대해 SDP를 조정하는 방법을 정의하는 규범적 프로토콜을 설정합니다. 예를 들어 긴급 SDP 프로토콜에는 다음이 포함될 수 있습니다.

  • 승격 및 승인 단계 가속.

  • 스모크 테스트 및 통합 테스트 가속.

  • 베이킹 시간 단축.

경우에 따라 비상 사태가 품질 및 테스트 게이트를 제한할 수 있지만 대역 외 운동만큼 게이트를 가능한 한 빨리 실행해야 합니다. 응급 상황에서 SDP 가속을 승인할 수 있는 사용자와 가속화를 승인하기 위해 충족해야 하는 기준을 정의해야 합니다. 모든 비상 사태가 동일한 프로토콜에 따라 처리되도록 응급 SDP 프로토콜을 비상 대응 계획에 맞춥니다.

고려 사항

안전한 배포 사례를 빌드하고 유지 관리하는 것은 복잡합니다. 강력한 표준을 완벽하게 구현하는 데 성공하는 것은 소프트웨어 개발의 여러 영역에서 사례의 완성도에 따라 달라집니다. 자동화 사용, 인프라 변경에 IaC 전용, 분기 전략의 일관성, 기능 플래그 사용 및 기타 많은 사례는 안전한 배포를 보장하는 데 도움이 될 수 있습니다. 이 가이드를 사용하여 워크로드를 최적화하고 사례가 발전함에 따라 개선 계획을 알릴 수 있습니다.

Azure 촉진

  • Azure Pipelines 및 GitHub Actions 승인 게이트를 사용하여 다단계 배포를 지원하므로 배포에 대한 점진적 노출 롤아웃을 설계하는 데 도움이 됩니다.

  • Azure App Service 스테이징 슬롯을 사용하여 코드 버전 간에 쉽게 교환할 수 있습니다. 스테이징 슬롯은 스테이징 환경에서 테스트하는 데 유용하며 파란색-녹색 배포에 사용할 수 있습니다.

  • Azure App Configuration 웹앱 기능 플래그를 저장하고 관리합니다. 이 서비스를 사용하면 통합 관리 평면에서 기능을 만들고, 변경하고, 배포할 수 있습니다.

  • VM 애플리케이션을 사용하여 가상 머신에 워크로드 애플리케이션을 배포합니다.

  • Azure 부하 분산 장치를 사용하여 배포 전략을 구현하고 네이티브 리소스를 사용하여 워크로드 애플리케이션의 상태를 노출합니다.

  • Application Health 확장을 사용하여 Virtual Machine Scale Set instance 내에서 애플리케이션 상태를 보고합니다. 확장은 로컬 애플리케이션 엔드포인트에서 검색하고 애플리케이션에서 받은 TCP/HTTP(S) 응답을 기반으로 상태 상태 업데이트합니다.

  • Azure Logic Apps를 사용하여 업데이트할 때마다 새 버전의 애플리케이션을 만듭니다. Azure는 애플리케이션 버전의 기록을 유지 관리하며 이전 버전으로 되돌리기 또는 승격할 수 있습니다.

  • 많은 Azure Database 서비스는 롤백에 도움이 될 수 있는 특정 시점 복원 기능을 제공합니다. 특정 시점 복원을 지원하는 서비스는 다음과 같습니다.

예제

이 배포 모델을 사용하는 방법에 대한 예제는 AKS(Azure Kubernetes Service) 클러스터 아키텍처 가이드를 참조하세요.

운영 우수성 검사 목록

전체 권장 사항 집합을 참조하세요.

운영 우수성 검사 목록