자기 치유 및 자기 보존을 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:07 자기 보존 및 자가 복구 조치를 구현하여 워크로드의 복원력과 복구 가능성을 강화합니다. 인프라 기반 안정성 패턴 및 소프트웨어 기반 디자인 패턴을 사용하여 구성 요소 오류 및 일시적인 오류를 처리하여 솔루션에 기능을 빌드합니다. 시스템에 기능을 빌드하여 솔루션 구성 요소 오류를 감지하고 워크로드가 전체 또는 축소된 기능에서 계속 작동하는 동안 자동으로 수정 작업을 시작합니다.

관련 가이드:백그라운드 작업 | 일시적인 오류

이 가이드에서는 안정성을 최적화하기 위해 애플리케이션 아키텍처에 자체 복구 및 자체 보존 기능을 빌드하기 위한 권장 사항을 설명합니다.

자체 보존 기능은 워크로드에 복원력을 추가합니다. 전체 가동 중단 가능성을 줄이고 실패한 구성 요소를 복구하는 동안 워크로드가 저하된 상태로 작동할 수 있도록 합니다. 자동 복구 기능을 사용하면 오류 감지 및 자동 수정 작업을 빌드하여 다양한 오류 유형에 대응하여 가동 중지 시간을 방지할 수 있습니다.

이 가이드에서는 자기 보존 및 자기 치유에 초점을 맞춘 디자인 패턴에 대해 설명합니다. 워크로드에 통합하여 복원력과 복구 가능성을 강화합니다. 패턴을 구현하지 않으면 불가피한 문제가 발생할 때 앱이 실패할 위험이 있습니다.

정의

용어 정의
자동 복구 영향을 받는 구성 요소를 복구하고 필요한 경우 중복 인프라로 장애 조치(failover)하여 문제를 자동으로 resolve 워크로드의 기능입니다.
자기 보존 워크로드가 잠재적인 문제에 대해 복원력을 줍니다.

주요 디자인 전략

자기 보존 지침

자체 보존을 위해 워크로드를 설계하려면 인프라 및 애플리케이션 아키텍처 디자인 패턴을 따라 워크로드의 복원력을 최적화합니다. 전체 애플리케이션 중단이 발생할 가능성을 최소화하려면 단일 실패 지점을 제거하고 오류의 폭발 반경을 최소화하여 솔루션의 복원력을 높입니다. 이 문서의 디자인 방법은 워크로드의 복원력을 강화하고 워크로드의 정의된 안정성 목표를 충족하는 몇 가지 옵션을 제공합니다.

인프라 디자인 지침 및 패턴

인프라 수준에서 중복 아키텍처 디자인 은 가용성 영역 또는 지역에 배포된 리소스를 사용하여 중요한 흐름을 지원해야 합니다. 가능 하면 자동 크기 조정을 구현합니다 . 자동 크기 조정은 예기치 않은 활동 버스트로부터 워크로드를 보호하여 인프라를 더욱 강화하는 데 도움이 됩니다.

배포 스탬프 패턴 또는 격벽 패턴을 사용하여 문제가 발생할 때 폭발 반경을 최소화합니다. 이러한 패턴은 개별 구성 요소를 사용할 수 없는 경우 워크로드를 계속 사용할 수 있도록 도와줍니다. 자동 크기 조정 전략과 함께 다음 애플리케이션 디자인 패턴을 사용합니다.

  • 배포 스탬프 패턴: 여러 워크로드 또는 테넌트를 호스트하고 운영하기 위해 다양한 리소스 그룹을 프로비전, 관리 및 모니터링합니다. 각 개별 복사본을 스탬프라고 부르며 간혹 서비스 단위, 배율 단위 또는 셀이라고도 합니다.

  • 격벽 패턴: 소비자 부하 및 가용성 요구 사항에 따라 서비스 인스턴스를 풀이라고 하는 여러 그룹으로 분할합니다. 이 디자인은 오류를 격리하는 데 도움이 되며, 오류 발생 시에도 일부 소비자의 서비스 기능을 유지할 수 있습니다.

애플리케이션 디자인 지침 및 패턴

애플리케이션 디자인에서 모놀리식 애플리케이션을 빌드하지 않습니다. 잘 정의된 표준을 통해 서로 통신하는 느슨하게 결합된 서비스 또는 마이크로 서비스를 사용하여 단일 구성 요소에 오작동이 발생할 때 광범위한 문제의 위험을 줄입니다. 예를 들어 모든 비동기 통신을 처리하기 위해 Service Bus 사용을 표준화할 수 있습니다. 통신 프로토콜을 표준화하면 애플리케이션 디자인이 일관되고 간소화되어 워크로드가 더 안정적이고 오작동이 발생할 때 문제를 보다 쉽게 해결할 수 있습니다. 실용적이면 배달 못 한 편지와 같은 시간 제한 문제를 최소화하기 위해 동기 통신보다 구성 요소 간의 비동기 통신을 선호합니다. 다음 디자인 패턴은 워크로드를 구성하고 비즈니스 요구 사항을 가장 잘 충족하는 방식으로 구성 요소 간의 통신을 정의하는 데 도움이 됩니다.

  • 앰배서더 패턴: 비즈니스 논리를 네트워킹 코드 및 복원력 논리와 분리합니다. 소비자 서비스 또는 애플리케이션을 대신하여 네트워크 요청을 전송하는 도우미 서비스를 만듭니다. 이 패턴을 사용하여 재시도 메커니즘 또는 회로 중단을 구현할 수 있습니다.

  • 비동기 Request-Reply 패턴: 백 엔드 처리가 비동기적이어야 하지만 프런트 엔드에 명확한 응답이 필요한 경우 프런트 엔드 호스트에서 백 엔드 처리를 분리합니다.

  • Cache-Aside 패턴: 데이터 저장소에서 캐시로 요청 시 데이터를 로드합니다. 이 패턴은 성능을 향상시키고 캐시에 저장된 데이터와 기본 데이터 저장소에 있는 데이터 간의 일관성을 유지하는 데 도움이 될 수 있습니다.

  • 회로 차단기 패턴: 회로 차단기를 사용하여 작업이 진행되도록 허용할지 아니면 최근 오류 수에 따라 예외를 반환할지를 사전에 결정합니다.

  • 클레임 확인 패턴: 큰 메시지를 클레임 검사 페이로드로 분할합니다. 클레임 검사 메시징 플랫폼으로 보내고 페이로드를 외부 서비스에 저장합니다. 이 패턴을 사용하면 메시지 버스를 보호하고 클라이언트가 과부하되거나 느려지는 것을 방지하면서 큰 메시지를 처리할 수 있습니다.

  • 경쟁 소비자 패턴: 여러 동시 소비자가 동일한 메시징 채널에서 수신되는 메시지를 처리할 수 있도록 합니다. 시스템은 여러 메시지를 동시에 처리하여 처리량을 최적화하고, 확장성 및 가용성을 향상시키고, 워크로드의 균형을 맞출 수 있습니다.

  • 요청 시간 제한 구성: 서비스 또는 데이터베이스 호출에 대한 요청 시간 제한을 구성합니다. 데이터베이스 연결 시간 제한은 일반적으로 30초로 설정됩니다.

  • 게이트키퍼 패턴: 전용 호스트 instance 사용하여 클라이언트와 애플리케이션 또는 서비스 간의 요청을 조정하여 애플리케이션 및 서비스를 보호합니다. 브로커는 요청의 유효성을 검사하고 삭제하며 시스템의 공격 표면을 제한하는 추가 보안 계층을 제공할 수 있습니다.

  • 큐 기반 부하 평준화 패턴: 각 작업을 비동기적으로 실행할 수 있도록 큐를 사용하여 솔루션의 서비스에서 작업을 분리합니다. 큐를 호출하는 작업과 서비스 간의 버퍼로 사용하여 서비스가 실패하거나 작업이 시간 초과될 수 있는 간헐적인 과도한 부하를 원활하게 처리할 수 있습니다. 이 패턴은 작업 및 서비스에 대한 가용성 및 응답성에 대한 최대 수요의 영향을 최소화하는 데 도움이 될 수 있습니다.

  • 제한 패턴: 애플리케이션, 개별 테넌트 또는 전체 서비스의 instance 사용하는 리소스의 사용을 제어합니다. 이 패턴을 사용하면 수요 증가로 리소스에 대한 부하가 매우 많은 경우에도 시스템이 SLA(서비스 수준 계약)를 계속 작동하고 충족할 수 있습니다.

  • 일시적인 오류 처리 패턴 및 다시 시도 패턴: 일시적인 오류를 처리하는 전략을 구현하여 워크로드에 복원력을 제공합니다. 일시적인 오류는 클라우드 환경에서 일반적이고 예상되는 발생입니다. 일시적인 오류의 일반적인 원인으로는 일시적인 네트워크 연결 손실, 데이터베이스 연결 끊기 또는 서비스가 사용 중인 시간 제한이 있습니다. 재시도 전략 개발에 대한 자세한 내용은 이 시리즈의 일시적인 오류 처리 가이드를 참조하세요.

백그라운드 작업

백그라운드 작업은 UI(사용자 인터페이스)에서 작업을 분리하여 시스템의 안정성을 향상시키는 효과적인 방법입니다. 사용자 입력 또는 피드백이 필요하지 않고 UI 응답성에 영향을 주지 않는 경우 작업을 백그라운드 작업으로 구현합니다.

백그라운드 작업의 일반적인 예는 다음과 같습니다.

  • 복잡한 계산 수행 또는 구조 모델 분석과 같은 CPU 집약적 작업
  • 여러 스토리지 작업 실행 또는 대용량 파일 인덱싱과 같은 I/O 집약적인 작업입니다.
  • 데이터를 정기적으로 업데이트하거나 특정 시간에 작업을 처리하는 등의 일괄 처리 작업입니다.
  • 주문 완료 또는 서비스 및 시스템 프로비전과 같은 장기 실행 워크플로.

자세한 내용은 백그라운드 작업에 대한 권장 사항을 참조하세요.

자가 복구 지침

자동 복구를 위해 워크로드를 설계하려면 자동 응답이 트리거되고 중요한 흐름이 정상적으로 복구되도록 오류 검색을 구현합니다. 로깅을 사용하도록 설정하여 오류의 특성 및 복구 성공에 대한 운영 인사이트를 제공합니다. 중요한 흐름에 대해 자체 복구를 수행하는 방법은 해당 흐름에 대해 정의된 안정성 목표 와 흐름의 구성 요소 및 종속성에 따라 달라집니다.

인프라 디자인 지침

인프라 수준에서 중요한 흐름은 이를 지원하는 구성 요소에 대해 자동화된 장애 조치(failover)가 사용하도록 설정된 중복 아키텍처 설계 에서 지원되어야 합니다. 다음 유형의 서비스에 대해 자동화된 장애 조치(failover)를 사용하도록 설정할 수 있습니다.

  • 컴퓨팅 리소스: Azure Virtual Machine Scale Sets 및 대부분의 PaaS(Platform as a Service) 컴퓨팅 서비스를 자동 장애 조치(failover)에 대해 구성할 수 있습니다.

  • 데이터베이스: 관계형 데이터베이스는 Azure SQL 장애 조치(failover) 클러스터, Always On 가용성 그룹 또는 PaaS 서비스를 사용하는 기본 제공 기능과 같은 솔루션을 사용하여 자동 장애 조치(failover)를 위해 구성할 수 있습니다. NoSQL 데이터베이스에는 PaaS 서비스에 대한 유사한 클러스터링 기능과 기본 제공 기능이 있습니다.

  • 스토리지: 자동 장애 조치(failover)와 함께 중복 스토리지 옵션을 사용합니다.

애플리케이션 디자인 지침 및 패턴

  • 잘못된 행위자 차단: 클라이언트를 제한한다고 해서 클라이언트가 악의적으로 행동했다는 의미는 아닙니다. 클라이언트가 서비스 할당량을 초과했음을 의미할 수 있습니다. 그러나 클라이언트가 지속적으로 할당량을 초과하거나 잘못 동작하는 경우 클라이언트를 차단할 수 있습니다. 클라이언트가 차단 해제를 요청하는 대역 외 프로세스를 정의합니다.

  • 회로 차단기 패턴: 재시도 메커니즘이 시작된 후에도 오류가 지속되면 증가하는 호출 백로그로 인해 연속 오류가 발생할 위험이 있습니다. 재시도 메커니즘을 사용하도록 설계된 회로 차단기는 앱이 실패할 가능성이 있는 작업을 반복적으로 실행하지 못하도록 하여 연속 오류의 위험을 제한합니다.

  • 보상 트랜잭션 패턴: 일련의 단계로 구성된 최종적으로 일관된 작업을 사용하는 경우 보상 트랜잭션 패턴을 구현합니다. 하나 이상의 단계가 실패하는 경우 이 패턴을 사용하여 단계가 수행한 작업을 실행 취소할 수 있습니다.

  • 정상적으로 성능 저하: 경우에 따라 문제를 해결할 수 없지만 기능을 줄일 수 있습니다. 책 카탈로그를 표시하는 애플리케이션을 생각해 보세요. 이 애플리케이션은 표지의 썸네일 이미지를 검색할 수 없으면 자리 표시자 이미지를 표시할 것입니다. 전체 하위 시스템은 애플리케이션에 중요하지 않을 수 있습니다. 예를 들어 전자 상거래 웹 사이트의 경우 제품 권장 사항을 표시하는 것이 주문 처리보다 덜 중요할 수 있습니다. 정상 성능 저하에는 자동 장애 조치(failover) 작업도 포함될 수 있습니다. 주 instance 문제로 인해 데이터베이스가 복제본(replica) 자동으로 장애 조치되면 짧은 시간 동안 성능이 저하됩니다.

  • 리더 선거 패턴: 작업을 조정해야 하는 경우 한 코디네이터가 단일 실패 지점이 아니도록 리더 선거를 사용하여 코디네이터를 선택합니다. 한 코디네이터가 실패하면 새 코디네이터가 선택됩니다. 리더 선거 알고리즘을 처음부터 구현하는 대신 ZooKeeper와 같은 기성 솔루션을 고려합니다.

  • 테스트 패턴: 표준 테스트 절차의 일부로 구현하는 패턴의 테스트를 포함합니다.

  • 장기 실행 트랜잭션에 검사점 사용: 장기 실행 작업이 실패하면 검사점이 복원력을 제공할 수 있습니다. 작업이 다시 시작될 때(예: 다른 가상 머신에서 선택한 경우) 마지막 검사점에서 다시 시작할 수 있습니다. 작업에 대한 상태 정보를 정기적으로 기록하는 메커니즘을 구현하는 것이 좋습니다. 작업을 실행하는 프로세스의 모든 instance 액세스할 수 있는 지속성 스토리지에 이 상태를 저장합니다. 프로세스가 종료되면 다른 instance 사용하여 마지막 검사점에서 수행한 작업을 다시 시작할 수 있습니다. NServiceBus 및 MassTransit와 같은 이 기능을 제공하는 라이브러리가 있습니다. 간격이 Azure Service Bus 큐의 메시지 처리와 일치하는 상태를 투명하게 유지합니다.

자동화된 자동 복구 작업

자동 복구에 대한 또 다른 방법은 미리 결정된 상태 상태 변경 내용이 검색될 때 모니터링 솔루션에 의해 트리거되는 자동화된 작업을 사용하는 것입니다. 예를 들어 모니터링에서 웹앱이 요청에 응답하지 않는 것을 감지하는 경우 PowerShell 스크립트를 통해 자동화를 빌드하여 앱 서비스를 다시 시작할 수 있습니다. 팀의 기술 집합 및 기본 개발 기술에 따라 웹후크 또는 함수를 사용하여 보다 복잡한 자동화 작업을 빌드합니다. 함수를 사용하여 데이터베이스 제한에 응답하는 예제는 이벤트 기반 클라우드 자동화 참조 아키텍처를 참조하세요. 자동화된 작업을 사용하면 신속하게 복구하고 사람의 개입 필요성을 최소화할 수 있습니다.

Azure 촉진

대부분의 Azure 서비스 및 클라이언트 SDK는 재시도 메커니즘을 제공합니다. 그러나 각 서비스에는 서로 다른 특성과 요구 사항이 있으므로 각 재시도 메커니즘은 특정 서비스에 맞게 조정됩니다. 자세한 내용은 일시적인 오류 처리에 대한 권장 사항을 참조하세요.

이메일, 음성 또는 SMS와 같은 알림에 Azure Monitor 작업 그룹을 사용하고 자동화된 작업을 트리거합니다. 실패 알림이 표시되면 Azure Automation Runbook, Azure Event Hubs, Azure 함수, 논리 앱 또는 웹후크를 트리거하여 자동화된 복구 작업을 수행합니다.

고려 사항

각 패턴에 대한 고려 사항을 숙지합니다. 구현하기 전에 패턴이 워크로드 및 비즈니스 요구 사항에 적합한지 확인합니다.

예제

일부 패턴의 사용 사례는 .NET에 대한 신뢰할 수 있는 웹앱 패턴을 참조하세요. 다음 단계에 따라 참조 구현을 배포합니다.

안정성 검사 목록

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

안정성 검사 목록