다음을 통해 공유


배포 실패 완화 전략 설계에 대한 권장 사항

Power Platform Well-Architected 운영 효율성 체크리스트 권장 사항에 적용됩니다.

OE:11 배포 실패 완화 전략을 구현하여 신속한 복구를 통해 예상치 못한 롤아웃 중간 문제를 해결합니다. 롤백, 기능 비활성화 또는 배포 패턴의 기본 기능 사용과 같은 여러 접근 방식을 결합합니다.

이 가이드에서는 배포 실패를 효과적으로 처리하기 위한 표준화된 전략을 설계하기 위한 권장 사항을 설명합니다. 다른 워크로드 문제와 마찬가지로 배포 실패는 워크로드 수명 주기의 불가피한 부분입니다. 이러한 사고방식을 통해 배포 실패를 처리하기 위한 잘 설계되고 의도적인 전략을 수립하여 사전 대응할 수 있습니다. 이러한 전략을 통해 워크로드 팀은 사용자에게 미치는 영향을 최소화하면서 오류를 효율적으로 완화할 수 있습니다.

그러한 계획이 없으면 문제에 대한 혼란스럽고 잠재적으로 해로운 대응으로 이어질 수 있으며, 이는 팀과 조직의 응집력, 고객 신뢰 및 재정에 심각한 영향을 미칠 수 있습니다.

주요 디자인 전략

개발 방식이 성숙했음에도 불구하고 배포 문제가 발생하는 경우가 있습니다. 안전한 배포 방법을 사용하고 강력한 워크로드 공급망을 운영하면 배포 실패 빈도를 최소화하는 데 도움이 될 수 있습니다. 또한 실패한 배포가 발생할 때 이를 처리하기 위한 표준화된 전략을 설계해야 합니다.

배포 실패 완화 전략은 다음과 같은 5가지 광범위한 단계로 구성됩니다.

  1. 감지: 실패한 배포에 대응하려면 먼저 실패를 감지해야 합니다. 감지는 실패한 스모크 테스트, 사용자 보고서 또는 모니터링 플랫폼에서 생성하는 경고와 같은 여러 형태를 취할 수 있습니다.
  2. 결정: 특정 오류 유형에 가장 적합한 완화 전략이 무엇인지 결정해야 합니다.
  3. 완화: 식별된 완화 작업을 수행해야 합니다. 완화는 대체, 롤백 또는 롤포워드의 형태를 취할 수 있습니다.
  4. 통신: 관련자 및 영향을 받는 사용자는 비상 대응 계획에서 요구하는 대로 문제를 감지하고 해결할 때 상태를 인식해야 합니다.
  5. 사후 분석: 비난 없는 사후 분석은 워크로드 팀이 개선 영역을 식별하고 학습 내용을 적용할 계획을 세울 수 있는 기회를 제공합니다.

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

검색

배포와 관련된 문제를 신속하게 식별하려면 배포와 관련된 강력한 테스트 및 모니터링 방법이 필요합니다. 변칙을 신속하게 감지하려면 애플리케이션 성능 관리 도구를 사용하고 계측을 통해 로깅하여 워크로드 모니터링 및 경고를 보완할 수 있습니다.

스모크 테스트 및 기타 품질 테스트는 출시의 각 단계에서 수행되어야 합니다. 한 배포 그룹의 성공적인 테스트는 후속 그룹의 테스트 결정에 영향을 주어서는 안 됩니다.

사용자 문제를 배포 단계와 연관시키는 원격 분석을 구현할 수 있습니다. 그러면 특정 사용자가 어떤 롤아웃 그룹에 연결되어 있는지 빠르게 식별할 수 있습니다. 이 접근 방식은 배포의 특정 지점에서 사용자 기반 전체에 걸쳐 여러 구성이 실행될 수 있으므로 점진적 노출 배포에 특히 중요합니다.

사용자가 보고한 문제에 즉시 대응할 준비가 되어 있어야 합니다. 가능하다면 전체 지원팀이 있는 근무 시간 중에 롤아웃 단계를 배포하세요. 지원 담당자가 적절한 라우팅을 위해 배포 문제를 에스컬레이션하는 방법에 대해 교육을 받도록 합니다. 에스컬레이션은 워크로드 비상 대응 계획에 맞춰 이루어져야 합니다.

결정

배포 문제에 대한 적절한 완화 전략을 결정하려면 다음과 같은 요소를 고려해야 합니다.

  • 사용하는 점진적 노출 모델의 유형입니다. 예를 들어 블루-그린 모델이나 카나리아 모델을 사용할 수 있습니다. 블루-그린 모델을 사용하는 경우 롤백보다 폴백이 더 실용적입니다. 업데이트되지 않은 구성을 실행하는 스택으로 트래픽을 쉽게 다시 이동할 수 있습니다. 그런 다음 문제가 있는 환경에서 문제를 수정하고 적절한 시점에 배포를 다시 시도할 수 있습니다.

  • 문제를 우회하기 위해 사용할 수 있는 방법입니다. 기능 플래그, 환경 변수 또는 켜고 끌 수 있는 다른 유형의 런타임 구성 속성의 사용을 예로 들 수 있습니다. 때로는 기능 플래그를 끄거나 설정을 전환하여 문제를 쉽게 우회할 수 있습니다. 이 경우 다음을 수행할 수 있습니다.

    • 롤백을 진행하세요.
    • 폴백하지 마십시오.
    • 문제가 있는 코드를 수정하는 동안 롤백하세요.
  • 코드에 수정 사항을 구현하는 데 필요한 노력의 수준입니다. 코드를 수정하는 데 필요한 노력 수준이 낮다면 핫픽스를 구현하여 롤포워드하는 것이 특정 시나리오에 적합한 선택입니다.

  • 영향을 받는 워크로드의 중요도 수준입니다. 다운타임 없는 배포를 달성하려면 비즈니스에 중요한 워크로드를 항상 블루-그린 모델과 같이 병렬 방식으로 배포해야 합니다. 결과적으로 폴백은 이러한 유형의 워크로드에 선호되는 완화 전략입니다.

완화

다음은 몇 가지 일반적인 완화 전략입니다.

  • 롤백: 롤백 시나리오에서는 업데이트된 시스템을 마지막으로 알려진 양호한 구성 상태로 되돌립니다.

    전체 워크로드 팀이 "마지막으로 알려진 양호"의 의미에 동의하는 것이 중요합니다. 이 식은 배포가 시작되기 전에 정상 상태였던 워크로드의 마지막 상태를 나타내며, 반드시 이전 애플리케이션 버전일 필요는 없습니다.

    롤백은 특히 데이터 변경과 관련되어 복잡할 수 있습니다. 스키마 변경으로 인해 롤백이 위험해질 수 있습니다. 이를 안전하게 구현하려면 상당한 계획이 필요할 수 있습니다. 일반적인 권장 사항에 따르면 스키마 업데이트는 추가되어야 합니다. 레코드를 새 레코드로 바꾸면 안 됩니다. 대신, 오래된 레코드는 더 이상 사용되지 않아야 하며 더 이상 사용되지 않는 레코드를 안전하게 제거할 때까지 새 레코드와 공존해야 합니다.

  • 폴백: 폴백 시나리오에서는 업데이트된 시스템이 프로덕션 트래픽 라우팅에서 제거됩니다. 모든 트래픽은 업데이트되지 않은 스택으로 전달됩니다. 이 저위험 전략은 추가 중단 없이 코드 문제를 해결할 수 있는 방법을 제공합니다.

    카나리아 배포를 사용하면 인프라 및 앱 디자인에 따라 대체가 간단하지 않거나 불가능할 수도 있습니다. 업데이트되지 않은 시스템의 로드를 처리하기 위해 크기 조정을 수행해야 하는 경우 폴백하기 전에 해당 크기 조정을 수행하십시오.

  • 문제가 되는 함수 우회: 기능 플래그 또는 다른 유형의 런타임 구성 속성을 사용하여 문제를 우회할 수 있는 경우 롤아웃을 계속하는 것이 문제에 적합한 전략이라고 결정할 수 있습니다.

    함수 우회의 장단점을 명확하게 이해하고 해당 장단점을 이해 관계자에게 전달할 수 있어야 합니다. 이해 관계자는 향후 계획을 승인해야 합니다. 이해 관계자는 저하된 상태에서 작동하는 데 허용되는 시간을 결정해야 합니다. 또한 문제가 있는 코드를 수정하고 배포하는 데 필요한 시간 추정치와 해당 결정을 비교해야 합니다.

  • 긴급 배포(핫픽스): 출시 중간에 문제를 해결할 수 있는 경우 핫픽스가 가장 실용적인 완화 전략일 수 있습니다.

    다른 코드와 마찬가지로 핫픽스는 안전한 배포 방법을 거쳐야 합니다. 그러나 핫픽스를 사용하면 타임라인이 상당히 빨라집니다. 환경 전반에 걸쳐 코드 승격 전략을 사용해야 합니다. 또한 모든 품질 게이트에서 핫픽스 코드를 확인해야 합니다. 그러나 베이킹 시간을 획기적으로 단축해야 할 수도 있고 이를 가속화하기 위해 테스트를 수정해야 할 수도 있습니다. 배포 후 가능한 한 빨리 업데이트된 코드에 대해 전체 테스트를 실행할 수 있는지 확인하세요. 품질 보증 테스트를 높은 수준으로 자동화하면 이러한 시나리오에서 테스트를 효율적으로 만드는 데 도움이 됩니다.

커뮤니케이션

인시던트 발생 시 혼란을 최소화하려면 의사소통 책임을 명확하게 정의하는 것이 중요합니다. 이러한 책임은 워크로드 팀이 지원 팀, 이해 관계자 및 비상 대응 관리자와 같은 비상 대응팀 직원과 협력하는 방법을 설정해야 합니다.

워크로드 팀이 상태 업데이트를 제공하기 위해 따르는 흐름을 표준화합니다. 이해 관계자가 이 표준을 인지하여 언제 업데이트가 필요한지 알 수 있도록 하십시오.

워크로드 팀이 사용자와 직접 통신해야 하는 경우 공유에 적합한 정보 유형 및 세부 정보 수준을 명확히 합니다. 또한 이러한 사례에 적용되는 다른 요구 사항도 워크로드 팀에 전달하세요.

사후 분석

사후 분석은 예외 없이 실패한 모든 배포를 따라야 합니다. 모든 실패한 배포는 학습의 기회입니다. 사후 분석은 배포 및 개발 프로세스의 약점과 인프라의 잘못된 구성을 식별하는 데 도움이 될 수 있습니다.

사후 분석은 인시던트에 연루된 개인이 개선 가능한 부분에 대한 관점을 공유할 때 안전함을 느낄 수 있도록 항상 비난할 여지가 없어야 합니다. 사후 분석 리더는 식별된 개선 사항을 구현하고 이러한 계획을 워크로드 백로그에 추가하기 위한 계획을 후속 조치해야 합니다.

고려 사항 및 일반적인 권장 사항

마지막으로 알려진 양호한 구성을 쉽게 배포할 수 있도록 배포 파이프라인이 고유한 버전을 매개 변수로 허용할 수 있는지 확인하세요.

롤백하거나 롤포워드할 때 관리 및 데이터 영역의 일관성을 유지하세요. 리소스 및 정책과 관련된 키, 비밀, 데이터베이스 상태 데이터 및 구성은 모두 범위 내에 있어야 하고 설명되어야 합니다. 예를 들어, 마지막으로 알려진 양호한 배포에서 인프라 확장의 설계에 주의를 기울이십시오. 코드를 재배포할 때 해당 구성을 조정해야 하는지 여부를 결정하세요.

드물게 발생하는 큰 변경보다 작고 빈번한 변경을 선호하여 새 배포와 마지막으로 성공한 배포 간의 차이를 최소화합니다.

CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인에 대해 실패 모드 분석을 수행하면 완화 노력을 복잡하게 만들 수 있는 문제를 식별하는 데 도움이 됩니다. 전체 워크로드와 마찬가지로 파이프라인을 분석하여 지정된 완화 유형을 시도할 때 문제가 될 수 있는 영역을 식별할 수 있습니다.

자동화된 롤백 기능을 신중하게 사용하십시오.

  • Azure DevOps와 같은 일부 CI/CD 도구에는 자동 롤백 기능이 내장되어 있습니다. 실질적인 가치를 제공하는 경우 이 기능을 사용해 보세요.
  • 파이프라인을 철저하고 정기적으로 테스트한 후에만 자동 롤백 기능을 채택해야 합니다. 자동 롤백이 트리거되는 경우 추가 문제가 발생할 수 있을 만큼 파이프라인이 충분히 성숙한지 확인하세요.
  • 자동화는 필요한 변경 사항만 배포하고 필요한 경우에만 트리거된다는 점을 신뢰해야 합니다. 이러한 요구 사항을 충족하도록 트리거를 신중하게 설계하세요.

롤백 중에 플랫폼에서 제공하는 기능을 사용하십시오. 예를 들어 백업 및 특정 시점 복원은 스토리지 및 데이터 롤백에 도움이 될 수 있습니다. 또는 가상 머신을 사용하여 애플리케이션을 호스트하는 경우 인시던트 직전의 검사점으로 환경을 복원하는 것이 도움이 될 수 있습니다.

전체 배포 실패 완화 전략을 자주 테스트하십시오. 비상 대응 계획 및 재해 복구 계획과 마찬가지로 배포 실패 계획은 팀이 이에 대한 교육을 받고 정기적으로 실행하는 경우에만 성공합니다. 카오스 엔지니어링 및 결함 주입 테스트는 배포 완화 전략을 테스트하는 데 효과적인 기술이 될 수 있습니다.

Power Platform 간편 사용

Power Platform 관리 센터의 배포 페이지는 관리자가 엔터프라이즈 규모로 파이프라인 배포 관리를 포함하여 ALM(Power Platform 애플리케이션 수명 주기 관리) 워크로드를 관리하는 복잡성을 탐색하는 데 도움이 되는 간소화된 환경을 제공합니다. 관리자는 테넌트의 모든 배포를 볼 수 있으며 배포 요청을 승인하고 문제를 해결할 수 있습니다.

Power Platform의 파이프라인은 ALM 자동화 및 CI/CD(연속 통합 및 지속적인 업데이트) 기능을 서비스에 도입하여 Power Platform 및 Dynamics 365 고객을 위한 ALM(애플리케이션 수명 주기 관리)을 민주화하는 것을 목표로 합니다.

Azure DevOps용 Microsoft Power Platform 빌드 도구를 사용하여 Power Platform에 빌드된 앱과 관련된 공통 빌드 및 배포 작업을 자동화할 수 있습니다.

Power Platform용 GitHub Actions를 사용하면 개발자가 자동화된 소프트웨어 개발 라이프사이클 워크플로를 구축할 수 있습니다. Microsoft Power Platform용 GitHub Actions를 사용하면 리포지토리에서 워크플로를 만들어 앱을 빌드, 테스트, 패키징, 릴리스 및 배포할 수 있으며 자동화를 수행하여 Microsoft Power Platform에 빌드된 봇 및 기타 구성 요소를 관리할 수 있습니다.

ALM 가속기는 연속 통합 및 지속적인 업데이트 프로세스를 자동화하도록 설계된 일련의 애플리케이션, 스크립트 및 파이프라인으로 구성된 오픈 소스 도구입니다.

Azure Pipelines으로 테스트 자동화.

Power CAT Copilot Studio Kit를 사용하여 에이전트 및 테스트를 구성합니다. Copilot Studio API(Direct Line)에 대해 개별 테스트를 실행하여 에이전트 응답을 예상 결과에 대해 평가합니다.

솔루션의 환경 변수는 매개 변수 키와 값을 저장하며, 이는 다른 애플리케이션 개체에 대한 입력으로 사용됩니다. 사용 개체에서 매개 변수를 분리하면 동일한 환경 내에서 또는 솔루션을 다른 환경으로 마이그레이션할 때 값을 변경할 수 있습니다.

Power Platform 환경은 롤백에 도움이 되는 특정 시점 복원 기능을 제공합니다.

Power Platform은 Application Insights와 통합되며, 이는 Azure Monitor 에코시스템의 일부입니다. 이 통합을 다음에 사용할 수 있습니다.

  • Application Insights에서 Dataverse 플랫폼이 캡처한 진단 및 성능에 대한 원격 측정을 받을 수 있습니다. 애플리케이션이 Dataverse 데이터베이스 및 모델 기반 앱 내에서 수행하는 작업에 대한 원격 분석을 받아볼 수 있습니다. 이 원격 분석은 오류 및 성능과 관련된 문제를 진단하고 해결하는 데 사용할 수 있는 정보를 제공합니다.

  • Application Insights에 캔버스 앱을 연결하세요. 이러한 분석을 사용하여 문제를 진단하고 사용자가 앱으로 무엇을 하는지 이해할 수 있습니다. 더 나은 비즈니스 결정을 내리고 앱 품질을 개선하는 데 도움이 되는 정보를 수집할 수 있습니다.

  • Power Automate 원격 분석을 Application Insights로 흐르도록 구성합니다. 예를 들어, 클라우드 흐름 실행을 모니터링하고 클라우드 흐름 실행 실패에 대한 알림을 생성합니다.

  • Microsoft Copilot Studio 에이전트에서 원격 분석 데이터를 수집하여 Azure Application Insights에서 사용합니다. 이 원격 분석을 사용하여 에이전트와 주고받는 기록된 메시지 및 이벤트, 사용자 대화 중에 트리거되는 주제 및 주제에서 보낼 수 있는 사용자 지정 원격 분석 이벤트를 모니터링할 수 있습니다.

운영 효율성 체크리스트

전체 권장 사항 세트를 참조하세요.