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

  • 아티클

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

OE:12 신속한 복구를 통해 예기치 않은 중간 출시 문제를 해결하는 배포 실패 완화 전략을 구현합니다. 롤백, 기능 사용 안 함 또는 배포 패턴의 네이티브 기능 사용과 같은 여러 방법을 결합합니다.

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

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

주요 디자인 전략

경우에 따라 개발 관행의 완성도에도 불구하고 배포 문제가 발생합니다. 안전한 배포 사례를 사용하고 강력한 워크로드 공급망을 운영하면 실패한 배포 빈도를 최소화할 수 있습니다. 그러나 실패한 배포가 발생할 때 처리하도록 표준화된 전략을 설계해야 합니다.

점진적 노출 배포 모델을 표준 사례로 사용하는 경우:

  • 배포가 실패할 때 고객 또는 내부 사용자에게 미치는 영향을 최소화하기 위한 올바른 기반이 있습니다.
  • 문제를 효율적으로 완화할 수 있습니다.

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

  1. 검색: 실패한 배포에 응답하려면 먼저 오류를 검색해야 합니다. 감지는 실패한 스모크 테스트, 사용자가 보고한 문제 또는 모니터링 플랫폼에서 생성하는 경고와 같은 여러 가지 형태를 취할 수 있습니다.

  2. 결정: 특정 오류 유형에 가장 적합한 완화 전략이 무엇인지 결정해야 합니다.

  3. 완화: 식별된 완화 작업을 수행합니다. 완화는 대체, 롤백, 롤 포워드 또는 런타임 구성을 사용하여 잘못된 함수를 우회하는 형식을 사용할 수 있습니다.

  4. 커뮤니케이션: 이해 관계자와 영향을 받는 최종 사용자는 긴급 대응 계획에 따라 문제를 감지하고 해결할 때 상태 알고 있어야 합니다.

  5. 사후 관리: 책임 없는 사후 시스템은 워크로드 팀이 개선 영역을 식별하고 학습을 적용할 계획을 만들 수 있는 기회를 제공합니다.

다음 섹션에서는 이러한 단계에 대한 자세한 권장 사항을 제공합니다. 이 섹션에서는 하나 이상의 사용자 또는 시스템 그룹에 변경 내용을 배포한 후 롤아웃 계획의 모든 그룹을 업데이트하기 전에 문제를 감지한다고 가정합니다.

감지

배포와 관련된 문제를 신속하게 식별하려면 배포와 관련된 강력한 테스트 및 가시성 사례가 필요합니다. 변칙을 신속하게 검색하려면 다음 단계를 수행하여 워크로드 모니터링 및 경고를 보완할 수 있습니다.

  • 애플리케이션 성능 관리 도구를 사용합니다.
  • 계측을 통해 로깅을 사용하도록 설정합니다.

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

사용자 문제와 배포 단계의 상관 관계를 지정하는 원격 분석을 구현할 수 있습니다. 그런 다음 특정 사용자가 연결된 롤아웃 그룹을 빠르게 식별할 수 있습니다. 이 방법은 배포의 지정된 지점에서 사용자 기반에서 여러 구성이 실행될 수 있으므로 점진적 노출 배포에 특히 중요합니다.

사용자가 보고한 문제에 즉시 대응할 준비가 되어 있어야 합니다. 실용적일 때마다 전체 지원 팀을 사용할 수 있는 경우 근무 시간 동안 출시 단계를 배포합니다. 적절한 라우팅을 위해 배포 문제를 에스컬레이션하는 방법에 대해 지원 담당자가 학습되었는지 확인합니다. 에스컬레이션은 워크로드 긴급 대응 계획과 일치해야 합니다.

의사 결정

지정된 배포 문제에 대한 적절한 완화 전략을 결정하려면 다음을 비롯한 여러 요인을 고려해야 합니다.

  • 사용하는 점진적 노출 모델의 유형입니다. 예를 들어 파란색-녹색 모델 또는 카나리아 모델을 사용할 수 있습니다.

    파란색-녹색 모델을 사용하는 경우 뒤로 떨어지는 것이 롤백보다 더 실용적입니다. 업데이트되지 않은 구성을 실행하는 스택으로 트래픽을 쉽게 다시 이동할 수 있습니다. 그런 다음 문제가 있는 환경에서 문제를 해결하고 적절한 시간에 배포를 다시 시도할 수 있습니다.

  • 문제를 우회하기 위해 사용할 수 있는 메서드입니다. 예를 들어 기능 플래그, 환경 변수 또는 설정/해제할 수 있는 다른 유형의 런타임 구성 속성을 사용합니다.

    경우에 따라 기능 플래그를 끄거나 설정을 전환하여 문제를 쉽게 무시할 수 있습니다. 이 경우 다음을 수행할 수 있습니다.

    • 롤아웃을 진행합니다.
    • 뒤로 물러서지 마십시오.
    • 잘못된 코드를 수정하는 동안 롤백합니다.

  • 코드에서 수정을 구현하는 데 필요한 작업 수준입니다.

    코드를 수정하기 위한 노력 수준이 낮은 경우 핫 픽스를 구현하여 롤 포워드하는 것이 특정 시나리오에 적합한 선택입니다.

  • 영향을 받는 워크로드에 대한 중요도 수준입니다.

    중요 비즈니스용 워크로드는 항상 블루-그린 모델과 같이 병렬 방식으로 배포되어야 가동 중지 시간 배포를 달성할 수 있습니다. 결과적으로 이러한 유형의 워크로드에 대해 대체가 바람직한 완화 전략입니다.

  • 워크로드에서 사용하는 인프라 유형(변경 가능 또는 변경할 수 없음)입니다.

    워크로드가 변경 가능한 인프라를 사용하도록 설계된 경우 인프라를 업데이트해야 하므로 롤 포워드하는 것이 합리적일 수 있습니다. 반대로 변경할 수 없는 인프라를 사용할 때 롤백하거나 뒤로 물러나는 것이 합리적일 수 있습니다.

어떤 선택을 하든 의사 결정 프로세스에 적절한 승인을 포함하고 의사 결정 트리에 명문화해야 합니다.

완화 방법

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

    전체 워크로드 팀이 마지막으로 알려진 좋은 것의 의미에 대해 동의하는 것이 중요합니다. 이 식은 배포가 시작되기 전에 정상 상태였던 워크로드의 마지막 상태를 의미하며, 이는 반드시 이전 애플리케이션 버전이 아닙니다.

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

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

    카나리아 배포를 사용하면 인프라 및 앱 디자인에 따라 뒤로 물러나는 것이 간단하거나 불가능할 수 있습니다. 업데이트되지 않은 시스템의 부하를 처리하기 위해 크기 조정을 수행해야 하는 경우 축소하기 전에 해당 크기 조정을 수행합니다.

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

    함수를 우회하는 장단점이 명확하게 이해되어야 하며, 이해 관계자에게 이러한 절충을 전달할 수 있어야 합니다. 관련자는 진행 계획을 승인해야 합니다. 관련자는 성능이 저하된 상태에서 작동하기 위해 허용되는 시간을 결정해야 합니다. 또한 잘못된 코드를 수정하고 배포하는 데 필요한 예상 시간에 대해 해당 결정을 저울질해야 합니다.

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

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

절충:

  • 일반적으로 대체될 수 있다는 것은 두 버전의 워크로드 구성을 동시에 처리하기에 충분한 인프라 용량이 필요하다는 것을 의미합니다. 또한 워크로드 팀은 프로덕션에서 두 버전을 동시에 지원할 수 있어야 합니다.
  • 효과적으로 롤백할 수 있는 경우 워크로드의 요소를 리팩터링해야 할 수 있습니다. 예를 들어 함수를 분리하거나 데이터 모델을 변경해야 할 수 있습니다.

통신

인시던트 중에 혼란을 최소화하는 데 도움이 되도록 커뮤니케이션 책임을 명확하게 정의하는 것이 중요합니다. 이러한 책임은 워크로드 팀이 응급 대응 관리자와 같은 지원 팀, 이해 관계자 및 응급 대응 팀 담당자와 협력하는 방법을 설정해야 합니다.

워크로드 팀이 상태 업데이트를 제공하기 위해 따르는 주기를 표준화합니다. 관련자가 업데이트를 예상할 시기를 알 수 있도록 이 표준을 알고 있는지 확인합니다.

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

사후 분석

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

사후 평가는 사건에 연루된 개인이 개선될 수 있는 것에 대한 관점을 공유할 때 안전하다고 느낄 수 있도록 항상 흠이 없어야 합니다. 사후 관리 리더는 확인된 개선 사항을 구현하고 워크로드 백로그에 이러한 계획을 추가하기 위한 계획을 따라야 합니다.

고려 사항 및 일반 권장 사항

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

롤백하거나 롤백할 때 관리 및 데이터 평면과의 일관성을 유지합니다. 리소스 및 정책과 관련된 키, 비밀, 데이터베이스 상태 데이터 및 구성은 모두 scope 있어야 하며 고려해야 합니다. 예를 들어 마지막으로 잘 알려진 배포에서 인프라 크기 조정 설계에 주의하세요. 코드를 다시 배포할 때 해당 구성을 조정해야 하는지 여부를 결정합니다.

자주 변경되지 않는 대규모 변경보다 작고 자주 변경하는 것을 선호하므로 새 배포와 마지막으로 알려진 배포 간의 델타가 작습니다.

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 미리 보기 는 카오스 엔지니어링을 사용하여 클라우드 애플리케이션 및 서비스 복원력을 측정, 이해 및 개선하는 데 도움이 되는 관리형 서비스입니다.

운영 우수성 검사 목록

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

운영 우수성 검사 목록