배포 실패 완화 전략 설계를 위한 권장 사항
이 Azure 잘 설계된 프레임워크 운영 우수성 검사 목록 권장 사항에 적용됩니다.
| OE:12 | 빠른 복구를 통해 예기치 않은 중간 롤아웃 문제를 해결하는 배포 실패 완화 전략을 구현합니다. 롤백, 기능 사용 안 함 또는 배포 패턴의 네이티브 기능 사용과 같은 여러 방법을 결합합니다. |
|---|
이 가이드에서는 배포 오류를 효과적으로 처리하기 위한 표준화된 전략을 설계하기 위한 권장 사항을 설명합니다. 다른 워크로드 문제와 마찬가지로 배포 오류는 워크로드 수명 주기의 불가피한 부분입니다. 이러한 사고 방식을 사용하면 배포 실패를 처리하기 위해 잘 디자인된 의도적인 전략을 사용하여 사전 예방적일 수 있습니다. 이러한 전략을 통해 워크로드 팀은 최종 사용자에게 가능한 한 적은 영향을 주지 않으면서 오류를 효율적으로 완화할 수 있습니다.
이러한 계획이 없으므로 문제에 대한 혼란스럽고 잠재적으로 해로운 대응으로 이어질 수 있으며, 이는 팀과 조직의 응집력, 고객 신뢰 및 재정에 큰 영향을 미칠 수 있습니다.
주요 디자인 전략
개발 사례가 완성되더라도 배포 문제가 발생하는 경우도 있습니다. 안전한 배포 사례를 사용하고 강력한 워크로드 공급망을 운영하면 실패한 배포 빈도를 최소화할 수 있습니다. 그러나 실패한 배포가 발생할 때 처리하도록 표준화된 전략을 설계해야 합니다.
점진적 노출 배포 모델을 표준 사례로 사용하는 경우:
- 배포가 실패할 때 고객 또는 내부 사용자에게 미치는 영향을 최소화하기 위한 올바른 기반이 있습니다.
- 문제를 효율적으로 완화할 수 있습니다.
배포 실패 완화 전략은 다음과 같은 5가지 광범위한 단계로 구성됩니다.
검색: 실패한 배포에 응답하려면 먼저 오류를 검색해야 합니다. 감지는 실패한 스모크 테스트, 사용자가 보고한 문제 또는 모니터링 플랫폼에서 생성하는 경고와 같은 여러 가지 형태를 취할 수 있습니다.
결정: 특정 오류 유형에 가장 적합한 완화 전략을 결정해야 합니다.
완화: 식별된 완화 작업을 수행합니다. 완화는 대체, 롤백, 롤 포워드 또는 런타임 구성을 사용하여 잘못된 함수를 우회하는 형태를 취할 수 있습니다.
커뮤니케이션: 긴급 대응 계획에서 요구하는 대로 문제를 감지하고 작업할 때 이해 관계자와 영향을 받는 최종 사용자가 상태를 인식해야 합니다.
사후 관리: 책임 없는 사후 시스템은 워크로드 팀이 개선 영역을 식별하고 학습을 적용할 계획을 만들 수 있는 기회를 제공합니다.
다음 섹션에서는 이러한 단계에 대한 자세한 권장 사항을 제공합니다. 이 섹션에서는 하나 이상의 사용자 또는 시스템 그룹에 변경 내용을 배포한 후 롤아웃 계획의 모든 그룹을 업데이트하기 전에 문제를 감지한다고 가정합니다.
오류 감지 메커니즘 디자인
배포 관련 문제를 신속하게 식별하려면 배포와 관련된 강력한 테스트 및 관찰 사례 가 필요합니다. 변칙을 빠르게 감지하는 데 도움이 되도록 다음 단계를 수행하여 워크로드 모니터링 및 경고를 보완할 수 있습니다.
- 애플리케이션 성능 관리 도구를 사용합니다.
- 계측을 통해 로깅을 사용하도록 설정합니다.
스모크 테스트 및 기타 품질 테스트는 출시의 각 단계에서 수행해야 합니다. 한 배포 그룹의 성공적인 테스트는 후속 그룹에서 테스트할 결정에 영향을 주지 않아야 합니다.
사용자 문제와 배포 단계의 상관 관계를 지정하는 원격 분석을 구현할 수 있습니다. 그런 다음 특정 사용자가 연결된 롤아웃 그룹을 빠르게 식별할 수 있습니다. 이 방법은 배포의 지정된 지점에서 사용자 기반 간에 여러 구성이 실행될 수 있으므로 점진적 노출 배포에 특히 중요합니다.
사용자가 보고한 문제에 즉시 대응할 준비가 되어 있어야 합니다. 실용적일 때마다 전체 지원 팀을 사용할 수 있는 경우 근무 시간 동안 출시 단계를 배포합니다. 적절한 라우팅을 위해 배포 문제를 에스컬레이션하는 방법에 대한 지원 담당자의 교육을 받도록 합니다. 에스컬레이션은 워크로드 비상 대응 계획과 일치해야 합니다.
완화 전략 결정
지정된 배포 문제에 대한 적절한 완화 전략을 결정하려면 다음을 비롯한 여러 요인을 고려해야 합니다.
사용하는 점진적 노출 모델의 유형입니다. 예를 들어 파란색-녹색 모델 또는 카나리아 모델을 사용할 수 있습니다.
청록색 모델을 사용하는 경우 롤백하는 것보다 뒤로 물러나는 것이 더 실용적입니다. 업데이트되지 않은 구성을 실행하는 스택으로 트래픽을 쉽게 다시 이동할 수 있습니다. 그런 다음 문제가 있는 환경에서 문제를 해결하고 적절한 시간에 배포를 다시 시도할 수 있습니다.
문제를 우회하기 위해 사용할 수 있는 메서드입니다. 예를 들어 기능 플래그, 환경 변수 또는 설정/해제할 수 있는 다른 유형의 런타임 구성 속성을 사용합니다.
경우에 따라 기능 플래그를 끄거나 설정을 전환하여 문제를 쉽게 무시할 수 있습니다. 이 경우 다음을 수행할 수 있습니다.
- 롤아웃을 진행합니다.
- 뒤로 물러서지 마십시오.
- 잘못된 코드를 수정하는 동안 롤백합니다.
코드에서 수정을 구현하는 데 필요한 작업 수준입니다.
코드를 수정하기 위한 노력 수준이 낮으면 핫 픽스를 구현하여 롤 포워드하는 것이 특정 시나리오에 적합한 선택입니다.
영향을 받는 워크로드에 대한 중요도 수준입니다.
중요 비즈니스용 워크로드는 항상 청록색 모델처럼 병렬로 배포하여 가동 중지 시간 배포를 달성해야 합니다. 결과적으로 이러한 유형의 워크로드에 대한 권장 완화 전략은 뒤로 물러나는 것입니다.
워크로드에서 사용하는 인프라 유형(변경 가능하거나 변경할 수 없음)입니다.
워크로드가 변경 가능한 인프라를 사용하도록 설계된 경우 인프라를 업데이트해야 하므로 롤 포워드가 합리적일 수 있습니다. 반대로 변경할 수 없는 인프라를 사용할 때 롤백 또는 롤백하는 것이 합리적일 수 있습니다.
어떤 선택을 하든 의사 결정 프로세스에 적절한 승인을 포함하고 의사 결정 트리에 명문화해야 합니다.
완화 전략 구현
롤백: 롤백 시나리오에서 업데이트된 시스템을 마지막으로 알려진 정상 구성 상태로 되돌려야 합니다.
전체 워크로드 팀이 마지막으로 알려진 정상의 의미에 대해 동의하는 것이 중요합니다. 이 식은 배포가 시작되기 전에 정상 상태였던 워크로드의 마지막 상태를 나타냅니다. 이는 반드시 이전 애플리케이션 버전이 아닙니다.
롤백은 복잡할 수 있으며, 특히 데이터 변경과 관련이 있습니다. 스키마를 변경하면 롤백이 위험할 수 있습니다. 안전하게 구현하려면 상당한 계획이 필요할 수 있습니다. 일반적인 권장 사항으로 스키마 업데이트는 가산적이어야 합니다. 대체 변경이 되어서는 안 됩니다. 레코드를 새 레코드로 바꾸면 안 됩니다. 대신 이전 레코드는 더 이상 사용되지 않아야 하며 사용되지 않는 레코드를 안전하게 제거할 때까지 새 레코드와 공존해야 합니다.
대체: 대체 시나리오에서는 업데이트된 시스템이 프로덕션 트래픽 라우팅에서 제거됩니다. 모든 트래픽은 업데이트되지 않은 스택으로 전달됩니다. 이 저위험 전략은 추가 중단 없이 코드의 문제를 해결할 수 있는 방법을 제공합니다.
카나리아 배포의 경우 인프라 및 앱 디자인에 따라 뒤로 물러나는 것이 간단하거나 불가능할 수 있습니다. 업데이트되지 않은 시스템의 부하를 처리하기 위해 크기 조정을 수행해야 하는 경우 축소하기 전에 해당 크기 조정을 수행합니다.
잘못된 함수 무시: 기능 플래그 또는 다른 유형의 런타임 구성 속성을 사용하여 문제를 무시할 수 있는 경우 롤아웃을 계속하는 것이 지정된 문제에 적합한 전략이라고 결정할 수 있습니다.
함수를 우회하는 장단점은 분명히 이해해야 하며, 이해 관계자에게 이러한 절충을 전달할 수 있어야 합니다. 관련자는 진행 계획을 승인해야 합니다. 관련자는 성능이 저하된 상태에서 작동하기 위해 허용되는 시간을 결정해야 합니다. 또한 위반 코드를 수정하고 배포하는 데 필요한 예상 시간에 대해 해당 결정을 평가해야 합니다.
긴급 배포(핫 픽스): 출시 중간에 문제를 해결할 수 있는 경우 핫 픽스(hot fix)가 가장 실용적인 완화 전략일 수 있습니다.
다른 코드와 마찬가지로 핫 픽스는 안전한 배포 사례를 거쳐야 합니다. 그러나 핫 픽스로 타임라인이 상당히 가속화됩니다. 환경 전체에서 코드 승격 전략을 사용해야 합니다. 또한 모든 품질 게이트에서 핫 픽스 코드를 확인해야 합니다. 그러나 베이킹 시간을 크게 단축해야 할 수도 있고 테스트를 수정하여 가속화해야 할 수도 있습니다. 배포 후 가능한 한 빨리 업데이트된 코드에서 전체 테스트를 실행할 수 있는지 확인합니다. 품질 보증 테스트를 높은 수준까지 자동화하면 이러한 시나리오에서 테스트를 효율적으로 만들 수 있습니다.
절충:
- 일반적으로 축소할 수 있다는 것은 두 버전의 워크로드 구성을 동시에 처리하기에 충분한 인프라 용량이 필요하다는 것을 의미합니다. 또한 워크로드 팀은 프로덕션에서 두 버전을 동시에 지원할 수 있어야 합니다.
- 효과적으로 롤백할 수 있는 경우 워크로드의 요소를 리팩터링해야 할 수 있습니다. 예를 들어 함수를 분리하거나 데이터 모델을 변경해야 할 수 있습니다.
인시던트 중 상태 업데이트 표준화
인시던트 중 혼란을 최소화하는 데 도움이 되도록 커뮤니케이션 책임을 명확하게 정의해야 합니다. 이러한 책임은 워크로드 팀이 응급 대응 관리자와 같은 지원 팀, 이해 관계자 및 응급 대응 팀 담당자와 협력하는 방법을 설정해야 합니다.
작업 팀이 상태 업데이트를 제공하기 위해 따르는 주기를 표준화합니다. 관련자가 업데이트를 예상할 시기를 알 수 있도록 이 표준을 알고 있는지 확인합니다.
워크로드 팀이 최종 사용자와 직접 통신해야 하는 경우 사용자와 공유하는 데 적합한 정보 유형 및 세부 수준을 명확히 합니다. 또한 이러한 경우에 적용되는 다른 요구 사항은 워크로드 팀과 통신합니다.
인시던트 사후 관리 수행
사후 시스템은 예외 없이 실패한 모든 배포를 따라야 합니다. 실패한 모든 배포는 학습할 수 있는 기회입니다. 사후 시스템은 배포 및 개발 프로세스의 약점을 식별하는 데 도움이 될 수 있습니다. 인프라의 잘못된 구성을 식별할 수도 있습니다.
사후 평가는 항상 흠이 없어야 하므로 사건에 관련된 개인이 개선 될 수있는 것에 대한 자신의 관점을 공유 할 때 안전하다고 느낄 수 있습니다. 사후 관리 리더는 확인된 개선 사항을 구현하고 워크로드 백로그에 이러한 계획을 추가하는 계획을 후속 조치해야 합니다.
완화 프로세스 운영
마지막으로 알려진 구성을 쉽게 배포할 수 있도록 배포 파이프라인이 고유 버전을 매개 변수로 수락할 수 있는지 확인합니다.
롤백하거나 롤백할 때 관리 및 데이터 평면과의 일관성을 유지합니다. 리소스 및 정책과 관련된 키, 비밀, 데이터베이스 상태 데이터 및 구성은 모두 범위에 있고 고려해야 합니다. 예를 들어 마지막으로 잘 알려진 배포에서 인프라 크기 조정의 디자인에 주의를 기울입니다. 코드를 다시 배포할 때 해당 구성을 조정해야 하는지 여부를 결정합니다.
신규 배포와 마지막으로 알려진 배포 간의 델타가 작도록 자주 변경되지 않는 큰 변경보다 작고 자주 변경되는 것을 선호합니다.
CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인에서 FMA(오류 모드 분석)를 수행하여 완화를 복잡하게 만들 수 있는 문제를 식별합니다. 워크로드 전체와 마찬가지로 파이프라인을 분석하여 지정된 완화 유형을 시도할 때 문제가 될 수 있는 영역을 식별할 수 있습니다.
자동화된 롤백 기능을 신중하게 사용합니다.
- Azure DevOps와 같은 일부 CI/CD 도구에는 기본 제공되는 자동 롤백 기능이 있습니다. 사용자에게 실질적인 가치를 제공하는 경우 이 기능을 사용하는 것이 좋습니다.
- 파이프라인을 철저하고 정기적으로 테스트한 후에만 자동 롤백 기능을 채택해야 합니다. 자동 롤백이 트리거되는 경우 파이프라인이 충분히 성숙하여 추가 문제를 발생시키는지 확인합니다.
- 자동화에서 필요한 변경 내용만 배포하고 필요한 경우에만 트리거된다는 것을 신뢰해야 합니다. 이러한 요구 사항을 충족하도록 트리거를 신중하게 디자인합니다.
롤백하는 동안 플랫폼 제공 기능을 사용합니다. 예를 들어 백업 및 지정 시간 복원은 스토리지 및 데이터 롤백에 도움이 될 수 있습니다. 또는 VM(가상 머신)을 사용하여 애플리케이션을 호스트하는 경우 인시던트 바로 앞에 있는 검사점으로 환경을 복원하는 것이 유용할 수 있습니다.
전체 배포 실패 완화 전략을 자주 테스트합니다. 응급 대응 계획 및 재해 복구 계획과 마찬가지로 배포 실패 계획은 팀에서 학습하고 정기적으로 실행하는 경우에만 성공합니다. 비정상 상황 엔지니어링 및 오류 주입 테스트 는 배포 완화 전략을 테스트하기 위한 효과적인 기술일 수 있습니다.
Azure 촉진
Azure Pipelines는 애플리케이션의 CI/CD를 지원하는 빌드 및 릴리스 서비스를 제공합니다.
Azure Test Plans 는 사용하기 쉬운 브라우저 기반 테스트 관리 솔루션입니다. 이 솔루션은 계획된 수동 테스트, 사용자 승인 테스트 및 예비 테스트에 필요한 기능을 제공합니다. 또한 Azure Test Plans는 관련자로부터 피드백을 수집할 수 있는 방법을 제공합니다.
Azure Monitor 는 클라우드 및 온-프레미스 환경에서 모니터링 데이터를 수집, 분석 및 응답하기 위한 포괄적인 모니터링 솔루션입니다. 모니터에는 강력한 경고 플랫폼이 포함되어 있습니다. 자동 크기 조정 및 기타 자동 복구 메커니즘과 같은 자동 알림 및 기타 작업에 대해 해당 시스템을 구성할 수 있습니다.
Application Insights 는 APM(애플리케이션 성능 모니터링) 기능을 제공하는 모니터의 확장입니다.
Azure Logic Apps 는 앱, 데이터, 서비스 및 시스템을 통합하는 자동화된 워크플로를 실행하기 위한 클라우드 기반 플랫폼입니다. Logic Apps를 사용하여 업데이트할 때마다 새 버전의 애플리케이션을 만들 수 있습니다. Azure는 버전 기록을 유지 관리하며 이전 버전을 되돌리거나 승격할 수 있습니다.
많은 Azure 데이터베이스 서비스는 롤백해야 할 때 도움이 될 수 있는 특정 시점 복원 기능을 제공합니다.
Azure Chaos Studio 미리 보기 는 클라우드 애플리케이션 및 서비스 복원력을 측정, 이해 및 개선하는 데 도움이 되는 비정상 상황 엔지니어링을 사용하는 관리형 서비스입니다.
관련 링크
- 기능 플래그를 사용한 점진적 실험
- 관찰성 프레임워크를 디자인하고 만들기 위한 권장 사항
- 긴급 대응 전략 설계를 위한 권장 사항
- 안정성 테스트 전략 설계를 위한 권장 사항
- 워크로드 개발 공급망 설계에 대한 권장 사항
- 실패 모드 분석을 수행하기 위한 권장 사항
- 안전한 배포 방법에 대한 권장 사항
운영 우수성 검사 목록
전체 권장 사항 집합을 참조하세요.