자기 치유 및 자기 보존을 위한 아키텍처 전략

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

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

자체 보존 기능은 워크로드에 복원력을 추가합니다. 전체 가동 중단 가능성을 줄이고 오류가 발생할 때 워크로드가 정상적으로 작동하거나 성능이 저하된 상태로 작동할 수 있습니다. 자동 복구 기능을 사용하면 오류 감지 및 자동 수정 작업을 빌드하여 오류에 대응하여 가동 중지 시간을 방지할 수 있습니다.

정의

중복성을 위한 디자인

오작동으로부터 워크로드를 보호하는 가장 효과적인 전략 중 하나는 모든 구성 요소에 중복성을 구축하고 단일 실패 지점을 방지하는 것입니다. 구성 요소 또는 전체 워크로드를 중복 리소스로 장애 조치(failover)할 수 있으면 시스템의 대부분의 오류를 효율적으로 처리할 수 있습니다.

여러 수준에서 중복성을 구축하고, 컴퓨팅, 네트워크 및 스토리지와 같은 중복 인프라 구성 요소를 고려하고, 솔루션의 여러 인스턴스를 배포하는 것이 좋습니다. 비즈니스 요구 사항에 따라 단일 지역 또는 지역 간에 중복성을 구축할 수 있습니다. 복구 요구 사항을 충족하기 위해 활성-활성 또는 활성-수동 디자인이 필요한지 여부를 결정할 수도 있습니다. 자세한 내용은 가용성 영역 및 지역을 사용하기 위한 중복성 및 아키텍처 전략을 디자인하기 위한 아키텍처 전략을 참조하세요.

자기 보존을 위한 디자인

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

인프라 디자인 지침 및 패턴

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

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

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

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

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

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

업계에서 입증된 패턴을 사용하여 설계 표준을 개발하고 아키텍처의 측면을 간소화할 수 있습니다. 안정성을 지원하는 데 도움이 되는 디자인 패턴은 안정성 패턴 문서에서 찾을 수 있습니다.

자체 복구를 위한 디자인

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

인프라 디자인 지침

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

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

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

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

애플리케이션 디자인 지침

안정성 을 지원하는 디자인 패턴을 사용하는 것 외에도 자가 복구 메커니즘을 개발하는 데 도움이 되는 다른 전략은 다음과 같습니다.

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

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

정상 성능 저하 모드 구현

자기 보존 및 자가 복구 메커니즘에도 불구하고 하나 이상의 구성 요소가 일정 시간 동안 사용할 수 없게 될 정도로 오작동하는 상황이 발생할 수 있습니다. 이러한 경우 워크로드가 성능이 저하된 상태에서 비즈니스에 충분한 기능을 유지할 수 있는 것이 좋습니다. 이를 가능하게 하려면 정상적인 성능 저하 모드를 디자인하고 구현합니다. 실패한 구성 요소에 대한 반응으로 사용하도록 설정된 고유한 워크플로입니다. 디자인 및 구현에 대한 고려 사항은 다음과 같습니다.

• 오류 검색 및 자동화된 시작: 모니터링 및 경고 시스템은 성능이 저하되고 실패한 구성 요소를 검색해야 하므로 이러한 신호를 사용하여 정상 성능 저하 모드로 전환해야 하는 시기를 결정하는 워크플로를 빌드합니다. 그런 다음 워크플로는 영향을 받는 구성 요소에 대한 호출의 경로를 자동으로 대체 구성 요소 또는 기타 유사한 작업으로 다시 라우팅해야 합니다.
• 성능이 저하된 사용자 환경을 구현합니다. 정상 성능 저하 모드에 있는 사용자에 대한 알림 메커니즘을 포함시켜 남은 기능과 변경된 기능을 알 수 있도록 합니다. 예를 들어 카트에 항목을 추가할 때 팝업과 같이 워크로드의 다양한 함수에 연결된 메시지에 일반적으로 반영됩니다.
• 워크로드의 필수 기능을 완료하는 대체 경로를 빌드합니다. 워크로드의 중요한 흐름을 반영하고 핵심 구성 요소를 사용할 수 없을 때 이러한 흐름을 유지할 수 있는 방법을 결정합니다. 예를 들어 데이터베이스가 다운된 경우 애플리케이션은 캐시된 데이터를 사용하여 읽기 전용 모드로 전환할 수 있습니다. 이 예제를 자세히 설명하기 위해 결제 게이트웨이가 다운된 경우 캐시된 데이터를 사용하면 사용자가 카트를 저장하고 나중에 구매를 완료할 수 있습니다.

일시적인 오류를 처리하기 위한 메커니즘 구현

네트워크 시간 제한과 같은 일시적인 오류는 클라우드 워크로드의 일반적인 문제이므로 이를 처리하는 메커니즘이 있으면 프로덕션 환경에서 워크로드를 운영할 때 가동 중지 시간과 문제 해결 작업을 최소화할 수 있습니다. 일시적 오류로 인해 실패하는 대부분의 작업은 작업을 다시 시도하기 전에 충분한 시간이 허용되는 경우 성공하므로 재시도 메커니즘을 사용하는 것이 일시적인 오류를 처리하는 가장 일반적인 방법입니다. 재시도 전략을 설계할 때 다음을 고려합니다.

권장 사항 및 고려 사항에 대한 전체 검토는 일시적인 오류 디자인 가이드를 참조하세요.

백그라운드 작업 구현

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

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

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

권장 사항 및 고려 사항에 대한 전체 검토에 대한 자세한 지침은 백그라운드 작업 디자인 가이드를 참조하세요.

Azure 지원

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

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

Example

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

관련 링크

• 안정성 패턴
• 일시적인 오류 처리
• 백그라운드 작업 개발
• 클라우드 디자인 패턴
• 자가 복구를 위한 디자인

안정성 검사 목록

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