특정 Azure 서비스에 대한 복원력 검사 목록

복원력은 오류를 복구하여 계속 작동하는 시스템 기능입니다. 모든 기술에는 고유한 특정 오류 모드가 있습니다. 이 기능은 애플리케이션을 디자인하고 구현할 때 고려해야 합니다. 이 검사 목록을 사용하여 특정 Azure 서비스에 대한 복원력 고려 사항을 검토합니다. 복원력 있는 애플리케이션 설계에 대한 자세한 내용은 안정적인 Azure 애플리케이션 설계를 참조하세요.

App Service

표준 또는 프리미엄 계층을 사용합니다. 이러한 계층은 스테이징 슬롯 및 자동화된 백업을 지원합니다. 자세한 내용은 Azure App Service 계획 심층 개요를 참조하세요.

확장 또는 축소를 피합니다. 그 대신에 일반적인 부하에서 성능 요구 사항에 맞는 계층 및 인스턴스 크기를 선택한 다음 규모 확장하여 트래픽 분량의 변화를 처리합니다. 확장 및 축소는 애플리케이션 다시 시작을 트리거할 수 있습니다.

구성을 앱 설정으로 저장합니다. 앱 설정을 사용하여 구성 설정을 앱 설정으로 저장합니다. Resource Manager 템플릿에 설정을 정의하거나 PowerShell을 사용하여 해당 설정을 자동화된 배포 / 업데이트 프로세스의 일부로 적용할 수 있도록 합니다(이 방법이 신뢰성이 더 높음). 자세한 내용은 Azure App Service에서 웹앱 구성을 참조하세요.

프로덕션 및 테스트에 대해 별도의 앱 서비스 계획을 만듭니다. 테스트를 위한 프로덕션 배포에 슬롯을 사용하지 마십시오. 동일한 App Service 계획 내의 모든 앱은 같은 VM 인스턴스를 공유합니다. 프로덕션과 테스트 배포를 동일한 계획에 배치하면 프로덕션 배포에 부정적 영향을 줄 수 있습니다. 예를 들어 부하 테스트는 라이브 프로덕션 사이트의 성능을 떨어뜨릴 수 있습니다. 테스트 배포를 별도의 계획에 배치하여 프로덕션 버전과 격리합니다.

웹앱을 웹 API와 분리합니다. 솔루션에 웹 프런트 엔드 및 웹 API가 모두 포함된 경우 이들을 별도의 App Service 앱으로 분해하는 것을 고려합니다. 이 설계를 통해 워크로드별로 솔루션을 분해하기가 더 쉬워집니다. 웹앱과 API를 별도의 App Service 계획에서 실행할 수 있으므로 이들을 독립적으로 크기 조정할 수 있습니다. 처음에 이러한 수준의 확장성이 필요하지 않은 경우 앱을 동일한 계획에 배포하고 필요한 경우 나중에 별도의 계획으로 이동할 수 있습니다.

영역 중복 App Service 계획을 배포합니다. 지원되는 지역에서는 App Service 계획을 영역 중복으로 배포할 수 있습니다. 즉, 인스턴스가 가용성 영역에 자동으로 분산됩니다. App Service는 영역 간에 트래픽을 자동으로 분산하고 영역에서 중단이 발생하는 경우 장애 조치(failover)를 처리합니다. 자세한 내용은 App Service를 가용성 영역 지원으로 마이그레이션을 참조 하세요.

앱 서비스 백업 기능을 사용하여 Azure SQL 데이터베이스를 백업하는 것을 피하십시오. 그 대신에 SQL Database 자동화된 백업을 사용합니다. App Service 백업은 데이터베이스를 SQL BACPAC 파일에 내보내는데, 이때 DTU 비용이 발생합니다.

스테이징 슬롯에 배포 스테이징을 위한 배포 슬롯을 만들 수 있습니다. 애플리케이션 업데이트를 스테이징 슬롯에 배포하고 프로덕션으로 교환하기 전에 배포를 확인합니다. 이렇게 하면 프로덕션에서 잘못된 업데이트의 기회가 감소합니다. 또한 모든 인스턴스가 프로덕션으로 교환되기 전에 확실히 준비되기도 합니다. 많은 애플리케이션에는 중요한 준비 및 콜드 부팅 시간이 있습니다. 자세한 내용은 Azure App Service에서 웹앱에 대한 스테이징 환경 설정을 참조하세요.

마지막으로 성공한(LKG) 배포를 저장하는 배포 슬롯을 만듭니다. 업데이트를 프로덕션에 배포하는 경우 이전 프로덕션 배포를 LKG 슬롯으로 이동합니다. 이렇게 하면 잘못된 배포를 롤백하기가 더 쉬워집니다. 나중에 문제가 발견되면 LKG 버전으로 신속하게 되돌릴 수 있습니다. 자세한 내용은 기본 웹 애플리케이션을 참조하세요.

애플리케이션 로깅 및 웹 서버 로깅을 포함하여 진단 로깅 설정합니다. 로깅은 모니터링 및 진단을 위해 중요합니다. Azure App Service에서 웹앱에 대한 진단 로깅 설정 참조

Blob Storage에 기록합니다. 이렇게 하면 보다 쉽게 데이터를 수집 및 분석할 수 있습니다.

로그에 대한 별도의 스토리지 계정을 만듭니다. 로그와 애플리케이션 데이터에 동일한 스토리지 계정을 사용하지 마세요. 이렇게 하면 로깅이 애플리케이션의 성능을 감소시키는 것을 방지하는 데 도움이 됩니다.

성능을 모니터링합니다. New Relic 또는 Application Insights 같은 성능 모니터링 서비스를 사용하여 애플리케이션 성능 및 부하를 받을 때의 동작을 모니터링합니다. 성능 모니터링은 애플리케이션에 대한 실시간 통찰력을 제공합니다. 문제를 진단하고 실패의 근본 원인 분석을 수행할 수 있습니다.

Azure Load Balancer

표준 SKU를 선택합니다. 표준 Load Balancer 가용성 영역 및 영역 복원력과 같은 Basic에서 제공하지 않는 안정성 차원을 제공합니다. 즉, 영역이 다운될 때 영역 중복 표준 Load Balancer는 영향을 받지 않습니다. 이렇게 하면 배포가 지역 내의 영역 오류를 견딜 수 있습니다. 또한 표준 Load Balancer는 글로벌 부하 분산을 지원하여 애플리케이션이 지역 장애의 영향도 받지 않도록 합니다.

인스턴스를 두 개 이상 프로비전합니다. 백 엔드에 인스턴스가 두 개 이상 있는 Azure LB를 배포합니다. 단일 인스턴스로 인해 단일 실패 지점이 발생할 수 있습니다. 크기 조정을 위해 빌드하기 위해 LB를 Virtual Machine Scale Sets와 페어링할 수 있습니다.

아웃바운드 규칙을 사용합니다. 아웃바운드 규칙은 SNAT 포트 고갈로 인해 연결 오류가 발생하지 않도록 합니다. 아웃바운드 연결에 대한 자세한 정보 아웃바운드 규칙은 중소 규모 배포의 솔루션을 개선하는 데 도움이 되지만 프로덕션 워크로드의 경우 표준 Load Balancer 또는 서브넷 배포를 VNet NAT와 결합하는 것이 좋습니다.

Application Gateway

인스턴스를 두 개 이상 프로비전합니다. 애플리케이션 게이트웨이를 두 개 이상의 인스턴스와 함께 배포합니다. 단일 인스턴스는 단일 실패 지점입니다. 중복성 및 확장성을 위해 인스턴스를 두 개 이상 사용합니다. SLA에 대한 자격을 얻으려면 중, 두 개 이상의 보통 이상의 인스턴스를 두 개 이상 프로비전해야 합니다.

Azure Cosmos DB

영역 중복성을 구성합니다. 영역 중복을 사용하는 경우 Azure Cosmos DB는 가용성 영역에서 모든 쓰기를 동기적으로 복제본(replica). 영역 중단 시 자동으로 장애 조치(fails over)됩니다. 자세한 내용은 Azure Cosmos DB의 고가용성 달성을 참조하세요.

지역에 걸쳐 데이터베이스를 복제합니다. Azure Cosmos DB를 사용하면 개수에 관계없이 Azure 지역을 원하는 만큼 Azure Cosmos DB 데이터베이스 계정에 연결할 수 있습니다. Azure Cosmos DB 데이터베이스에는 하나의 쓰기 지역과 여러 읽기 지역이 있을 수 있습니다. 쓰기 지역에 오류가 있으면 다른 복제본에서 읽을 수 있습니다. 클라이언트 SDK는 이 작업을 자동으로 처리합니다. 또한 쓰기 지역을 다른 지역으로 장애 조치할 수도 있습니다. 자세한 내용은 Azure Cosmos DB로 데이터를 전역적으로 배포하는 방법을 참조하세요.

Event Hubs

검사점 사용. 이벤트 소비자는 미리 정의된 간격으로 영구 스토리지에 현재 위치를 기록해야 합니다. 이렇게 하면 소비자에게 오류가 발생하는 경우(예: 소비자에게 충돌이나 호스트 장애가 발생하는 경우) 새 인스턴스가 마지막으로 기록된 위치에서 스트림 읽기를 다시 시작할 수 있습니다. 자세한 내용은 이벤트 소비자를 참조하세요.

중복 메시지 처리. 이벤트 소비자가 실패하면 메시지 처리가 기록된 마지막 검사점에서 다시 시작됩니다. 마지막 검사점 이후에 이미 처리된 메시지가 다시 처리됩니다. 따라서 메시지 처리 논리가 idempotent이거나 애플리케이션이 메시지를 중복할 수 있어야 합니다.

예외 처리. 이벤트 소비자는 일반적으로 루프에 있는 메시지를 일괄 처리합니다. 단일 메시지에 예외가 발생하는 경우 전체 메시지의 일괄 처리가 손실되지 않도록 하려면 이 처리 루프 내에서 예외를 처리해야 합니다.

배달하지 못한 편지 큐 사용. 메시지를 처리하여 일시적이지 않은 오류가 발생한 경우 상태를 추적할 수 있도록 배달 못 한 편지 큐에 메시지를 배치합니다. 시나리오에 따라 메시지를 나중에 다시 시도하거나, 보정 트랜잭션을 적용하거나, 다른 작업을 수행할 수 있습니다. Event Hubs에는 기본 제공 배달하지 못한 편지 큐 기능이 없습니다. Azure Queue Storage 또는 Service Bus를 사용하여 배달하지 못한 편지 큐를 구현하거나 Azure Functions 또는 다른 이벤트 메커니즘을 사용할 수 있습니다.

영역 중복성을 구성합니다. 네임스페이스에서 영역 중복성을 사용하도록 설정하면 Event Hubs는 여러 가용성 영역 간에 변경 내용을 자동으로 복제본(replica). 하나의 가용성 영역이 실패하면 장애 조치(failover)가 자동으로 수행됩니다. 자세한 내용은 가용성 영역을 참조 하세요.

보조 Event Hubs 네임스페이스에 장애 조치하여 재해 복구 구현. 자세한 내용은 Azure Event Hubs 지역 재해 복구를 참조하세요.

Azure Cache for Redis

영역 중복성을 구성합니다. 캐시에서 영역 중복성을 사용하도록 설정하면 Azure Cache for Redis는 캐시를 호스트하는 가상 머신을 여러 가용성 영역에 분산합니다. 영역 중복은 데이터 센터 가동 중단 시 고가용성 및 내결함성을 제공합니다. 자세한 내용은 Azure Cache for Redis에 대한 영역 중복성 사용을 참조 하세요.

지역에서 복제 구성. 지역 복제는 두 개의 프리미엄 계층 Azure Cache for Redis 인스턴스를 연결하는 메커니즘을 제공합니다. 기본 캐시에 작성된 데이터는 읽기 전용 보조 캐시에 복제됩니다. 자세한 내용은 Azure Cache for Redis에 대한 지역 복제를 구성하는 방법을 참조하세요.

데이터 지속성 구성. Redis 지속성을 사용하면 Redis에 저장된 데이터를 유지할 수 있습니다. 또한 스냅샷을 만들고, 하드웨어 오류 시 로드할 수 있게 데이터를 백업할 수 있습니다. 자세한 내용은 프리미엄 계층 Azure Cache for Redis에 대한 데이터 지속성을 구성하는 방법을 참조하세요.

Azure Cache for Redis를 영구 저장소가 아닌 임시 데이터 캐시로 사용하는 경우 이러한 권장 사항이 적용되지 않을 수 있습니다.

Cognitive Search

복제본을 두 개 이상 프로비전합니다. 읽기 고가용성을 위해서는 복제를 두 개 이상, 또는 읽기-쓰기 고가용성을 위해서는 세 개 이상 사용합니다.

영역 중복을 사용합니다. Cognitive Search 복제본(replica) 여러 가용성 영역에 배포할 수 있습니다. 이 방법을 사용하면 데이터 센터 가동 중단이 발생하더라도 서비스가 다시 작동할 기본 있습니다. 자세한 내용은 Azure Cognitive Search의 안정성을 참조하세요 .

다중 지역 배포의 경우 인덱서를 구성합니다. 다중 지역 배포를 설정한 경우 옵션에 대해 인덱싱의 지속성을 고려합니다.

• 데이터 원본이 지역 복제본(replica) 있는 경우 일반적으로 각 지역 Azure Cognitive Search 서비스의 각 인덱서가 로컬 데이터 원본 복제본(replica) 가리키도록 해야 합니다. 그러나 Azure SQL Database에 저장된 대형 데이터 세트의 경우 이 방법이 권장되지 않습니다. 그 이유는 Azure Cognitive Search가 보조 SQL Database 복제본(replica) 기본 복제본(replica) 증분 인덱싱을 수행할 수 없기 때문입니다. 그 대신에 모든 인덱서가 주 복제본을 가리킵니다. 장애 조치(failover) 후 새 기본 복제본(replica) Azure Cognitive Search 인덱서를 가리킵니다.

• 데이터 원본이 지역 복제본(replica) 없는 경우 여러 지역의 Azure Cognitive Search 서비스가 데이터 원본에서 지속적으로 독립적으로 인덱싱되도록 동일한 데이터 원본에서 여러 인덱서를 가리킵니다. 자세한 내용은 Azure Search 성능 및 최적화 고려 사항을 참조하세요.

Service Bus

프로덕션 워크로드에 프리미엄 계층 사용. Service Bus 프리미엄 메시지는 처리 전용으로 예약된 리소스와 예측 가능한 성능 및 처리량을 지원하기 위한 메모리 용량을 제공합니다. 또한 프리미엄 메시지 계층은 처음에는 프리미엄 고객만 사용할 수 있는 새로운 기능을 제공합니다. 예상 워크로드에 따라 메시징 단위 수를 결정할 수 있습니다.

중복 메시지 처리. 게시자가 메시지를 보낸 직후에 실패하거나 네트워크 또는 시스템 문제가 발생하면 메시지가 전송된 것을 기록하지 못할 수 있고, 동일한 메시지를 시스템에 두 번 보낼 수 있습니다. Service Bus는 중복 검색을 사용하여 이 문제를 처리할 수 있습니다. 자세한 내용은 중복 검색을 참조하세요.

예외 처리. 메시지 API는 사용자 오류, 구성 오류 또는 기타 오류가 발생할 때 예외를 생성합니다. 클라이언트 코드(발신자 및 수신자)는 코드에서 이러한 예외를 처리해야 합니다. 이는 예외 처리를 사용하여 메시지의 일괄 처리 전체 손실을 방지할 수 있는 일괄 처리 프로세싱에서 특히 중요합니다. 자세한 내용은 Service Bus 메시징 예외를 참조하세요.

재시도 정책. Service Bus를 사용하면 애플리케이션에 가장 적합한 재시도 정책을 선택할 수 있습니다. 기본 정책은 최대 9회까지 재시도를 허용하고 30초 동안 기다리는 것이지만, 추가로 조정할 수 있습니다. 자세한 내용은 재시도 정책 - Service Bus를 참조하세요.

배달 못한 편지 큐 사용. 여러 번의 재시도 후 처리할 수 없거나 수신자에게 전달할 수 없는 메시지는 배달 못한 편지 큐로 이동됩니다. 배달 못한 편지 큐에서 메시지를 읽고, 검사하고, 문제를 해결하는 프로세스를 구현하세요. 시나리오에 따라 메시지를 있는 그대로 다시 시도하거나, 변경 후 다시 시도하거나, 메시지를 삭제할 수 있습니다. 자세한 내용은 Service Bus 배달 못한 편지 큐의 개요를 참조하세요.

영역 중복을 사용합니다. 네임스페이스에서 영역 중복성을 사용하도록 설정하면 Service Bus는 여러 가용성 영역 간에 변경 내용을 자동으로 복제본(replica). 하나의 가용성 영역이 실패하면 장애 조치(failover)가 자동으로 수행됩니다. 자세한 내용은 Service Bus 중단 및 재해에 대한 애플리케이션 격리 모범 사례를 참조 하세요.

지리적 재해 복구 사용. 지리적 재해 복구를 사용하면 재해로 인해 Azure 지역 또는 데이터 센터 전체를 사용할 수 없게 되더라도 다른 지역 또는 데이터 센터에서 데이터 처리가 계속 작동합니다. 자세한 내용은 Azure Service Bus 지역 재해 복구를 참조하세요.

스토리지

영역 중복 스토리지를 사용합니다. ZRS(영역 중복 저장소) 는 기본 지역에 있는 3개의 Azure 가용성 영역에서 데이터를 동기적으로 복사합니다. 가용성 영역에서 중단이 발생하면 Azure Storage가 자동으로 대체 영역으로 장애 조치(fail over)됩니다. 자세한 내용은 Azure Storage 중복성을 참조하세요.

지역 중복성을 사용하는 경우 읽기 액세스를 구성합니다. 다중 지역 아키텍처를 사용하는 경우 전역 중복성에 적합한 스토리지 계층을 사용합니다. RA-GRS 또는 RA-GZRS를 사용하면 데이터가 보조 지역에 복제본(replica). RA-GRS는 주 지역에서 LRS(로컬 중복 스토리지)를 사용하는 반면 RA-GZRS는 주 지역에서 ZRS(영역 중복 스토리지)를 사용합니다. 두 구성 모두 보조 지역의 데이터에 대한 읽기 전용 액세스를 제공합니다. 주 지역에 스토리지 중단이 있는 경우 이 가능성을 위해 설계한 경우 애플리케이션이 보조 지역에서 데이터를 읽을 수 있습니다. 자세한 내용은 Azure Storage 중복성을 참조하세요.

VM 디스크의 경우 관리 디스크를 사용합니다.관리 디스크는 단일 실패 지점을 피하기 위해 디스크가 서로 충분히 격리되어 있기 때문에 가용성 집합의 VM에 더 나은 안정성을 제공합니다. 또한 관리 디스크는 스토리지 계정에서 만든 VHD의 IOPS 제한이 적용되지 않습니다. 자세한 내용은 Azure에서 Windows 가상 머신의 가용성 관리를 참조하세요.

Queue Storage의 경우 다른 지역에 백업 큐를 만듭니다. Queue Storage의 경우 항목을 큐에 대기하거나 큐에서 제거할 수 없으므로 읽기 전용 복제본(replica) 사용이 제한됩니다. 그 대신에 다른 지역의 스토리지 계정에 백업 큐를 만듭니다. Azure Storage 중단이 있는 경우 애플리케이션은 주 지역을 다시 사용할 수 있을 때까지 백업 큐를 사용할 수 있습니다. 이렇게 하면 애플리케이션이 중단 중에 새 요청을 계속 처리할 수 있습니다.

SQL Database

표준 또는 프리미엄 계층을 사용합니다. 이러한 계층은 더 긴 지정 시간 복원 기간(35일)을 제공합니다. 자세한 내용은 SQL Database 옵션 및 성능을 참조하세요.

SQL Database 감사 사용 감사를 사용하면 악의적 공격 또는 인적 오류를 진단할 수 있습니다. 자세한 내용은 SQL 데이터베이스 감사 시작을 참조하세요.

활성 지역 복제 사용 활성 지역 복제를 사용하여 서로 다른 지역에 읽을 수 있는 보조 복제를 만듭니다. 주 데이터베이스가 실패하거나 단순히 오프라인으로 전환해야 하는 경우 보조 데이터베이스로 장애 조치를 수행합니다. 장애 조치(failover)될 때까지 보조 데이터베이스는 읽기 전용으로 유지됩니다. 자세한 내용은 SQL Database 활성 지역 복제를 참조하세요.

분할을 사용합니다. 분할을 사용하여 데이터베이스를 가로로 분할하는 것을 고려합니다. 분할은 오류 격리를 제공할 수 있습니다. 자세한 내용은 Azure SQL Database를 사용하여 분할을 참조하세요.

지정 시간 복원을 사용하여 인적 오류에서 복구합니다. 지정 시간 복원은 데이터베이스를 이전 시점으로 되돌려 놓습니다. 자세한 내용은 자동화된 데이터베이스 백업을 사용하여 Azure SQL 데이터베이스 복구를 참조하세요.

지리적 복원을 사용하여 서비스 중단에서 복구합니다. 지리적 복원은 지역 중복 백업에서 데이터베이스를 복원합니다. 자세한 내용은 자동화된 데이터베이스 백업을 사용하여 Azure SQL 데이터베이스 복구를 참조하세요.

Azure Synapse Analytics

지역 백업을 비활성화하지 마십시오. 기본적으로 Synapse Analytics는 재해 복구를 위해 24시간마다 전용 SQL 풀에서 데이터의 전체 백업을 수행합니다. 이 기능을 해제하는 것은 권장되지 않습니다. 자세한 내용은 지역 백업을 참조하세요.

VM에서 실행되는 SQL Server

데이터베이스를 백업합니다. 이미 Azure Backup을 사용하여 VM을 백업하는 경우 DPM을 사용하는 SQL Server용 Azure Backup 워크로드의 사용을 고려합니다. 이 방법에서는 조직에 대한 백업 관리자 역할 하나와 VM 및 SQL Server에 대한 통합 복구 절차가 있습니다. 그렇지 않으면 Microsoft Azure에 대한 SQL Server 관리 백업을 사용합니다.

Traffic Manager

수동 장애 복구를 수행합니다. Traffic Manager 장애 조치 후 자동으로 장애 복구하는 대신 수동 장애 복구를 수행합니다. 장애 복구 전에 모든 애플리케이션 하위 시스템이 정상 상태인지 확인합니다. 그렇지 않으면 애플리케이션이 데이터 센터 간에 앞뒤로 뒤집어지는 상황이 발생할 수 있습니다. 자세한 내용은 고가용성을 위해 여러 지역에서 VM 실행을 참조하세요.

상태 프로브 엔드포인트를 만듭니다. 애플리케이션의 전반적인 상태에 관하여 보고하는 사용자 지정 엔드포인트를 만듭니다. 이렇게 하면 단지 프런트 엔드뿐만 아니라 중요 경로가 고장인 경우 Traffic Manager가 장애 조치할 수 있습니다. 엔드포인트는 중요 의존성이 비정상 상태이거나 도달할 수 없는 경우 HTTP 오류 코드를 반환해야 합니다. 그러나 중요하지 않은 서비스에 대해서는 오류를 보고하지 마세요. 그렇지 않으면 상태 프로브가 필요하지 않을 때 장애 조치를 트리거하여 가양성이 발생할 수 있습니다. 자세한 내용은 Traffic Manager 엔드포인트 모니터링 및 장애 조치를 참조하세요.

Virtual Machines

단일 VM에서 프로덕션 워크로드를 실행하지 않습니다. 단일 VM 배포는 계획되거나 계획되지 않은 유지 관리에 탄력적으로 대처할 수 없습니다. 그 대신에 부하 분산 장치를 전면에 배치한 상태에서 여러 VM을 가용성 집합 또는 가상 머신 확장 집합에 배치합니다.

VM을 프로비전할 때 가용성 집합을 지정합니다. 현재 VM이 프로비전된 후 VM을 가용성 집합에 추가하는 방법은 없습니다. 기존 가용성 집합에 새 VM을 추가하는 경우 VM에 대한 NIC를 만들고 부하 분산 장치의 백 엔드 주소 풀에 NIC를 추가해야 합니다. 그렇지 않으면 부하 분산 장치가 네트워크 트래픽을 해당 VM에 경로 설정하지 않습니다.

각 애플리케이션 계층을 별도의 가용성 집합에 배치합니다. N 계층 애플리케이션에서 서로 다른 계층의 VM을 동일한 가용성 집합에 배치하지 마세요. 가용성 집합의 VM은 장애 도메인(FD) 및 업데이트 도메인(UD)에 걸쳐 배치됩니다. 그러나 FD와 UD의 중복성 이점을 활용하려면 가용성 집합의 모든 VM이 동일한 클라이언트 요청을 처리할 수 있어야 합니다.

Azure Site Recovery를 사용하여 VM 복제. Site Recovery를 사용하여 Azure VM을 복제할 때 모든 VM 디스크가 지속적으로 대상 지역에 비동기적으로 복제됩니다. 복구 지점은 몇 분 간격으로 생성됩니다. 이렇게 하면 시간 순으로 RPO(복구 지점 목표)가 제공됩니다. 프로덕션 애플리케이션 또는 진행 중인 복제에 영향을 주지 않고 재해 복구 훈련을 원하는 만큼 수행할 수 있습니다. 자세한 내용은 Azure로 재해 복구 훈련 실행을 참조하세요.

성능 요구 사항을 기반으로 올바른 VM 크기를 선택합니다. 기존 워크로드를 Azure로 이동할 때 온-프레미스 서버와 가장 근접하게 일치하는 VM 크기부터 사용하기 시작합니다. 그런 다음 CPU, 메모리 및 디스크 IOPS에 따라 실제 워크로드의 성능을 측정하고 필요에 따라 크기를 조정합니다. 이렇게 하면 해당 애플리케이션이 클라우드 환경에서 예상한 대로 작동합니다. 또한 여러 NIC가 필요한 경우 각 크기에 대한 NIC 제한을 알아야 합니다.

VHD용 관리 디스크를 사용합니다.관리 디스크는 단일 실패 지점을 방지하기 위해 디스크가 서로 충분히 격리되어 있기 때문에 가용성 집합의 VM에 더 나은 안정성을 제공합니다. 또한 관리 디스크는 스토리지 계정에서 만든 VHD의 IOPS 제한이 적용되지 않습니다. 자세한 내용은 Azure에서 Windows 가상 머신의 가용성 관리를 참조하세요.

애플리케이션을 OS 디스크가 아닌 데이터 디스크에 설치합니다. 이렇게 하지 않으면 디스크 크기 제한에 도달할 수 있습니다.

Azure Backup을 사용하여 VM을 백업합니다. 백업은 실수로 인한 데이터 손실을 방지합니다. 자세한 내용은 Recovery Services 자격 증명 모음으로 Azure VM 보호를 참조하세요.

진단 로그 활성화 기본 상태 메트릭, 인프라 로그 및 부팅 진단을 포함합니다. 부팅 진단은 VM이 부팅할 수 없는 상태로 전환되는 경우 부팅 오류를 진단하는 데 도움이 될 수 있습니다. 자세한 내용은 Azure 진단 로그를 참조하세요.

Azure Monitor 구성 게스트 운영 체제와 그 안에서 실행되는 워크로드를 포함한 Azure Virtual Machines에서 모니터링 데이터를 수집하고 분석합니다. Azure Monitor 및 빠른 시작: Azure Monitor를 참조하세요.

Virtual Network

공용 IP 주소를 허용하거나 차단하려면 서브넷에 네트워크 보안 그룹을 추가합니다. 악의적인 사용자의 액세스를 차단하거나 애플리케이션에 액세스할 권한을 가진 사용자의 액세스만 허용합니다.

사용자 지정 상태 프로브를 만듭니다. 부하 분산 장치 상태 프로브는 HTTP 또는 TCP를 테스트할 수 있습니다. VM에서 HTTP 서버를 실행하는 경우 HTTP 프로브는 TCP 프로브보다 더 나은 상태 표시기입니다. HTTP 프로브의 경우 모든 중요 의존성을 포함하여 애플리케이션의 전반적인 상태를 보고하는 사용자 지정 엔드포인트를 사용합니다. 자세한 내용은 Azure 부하 분산 장치 개요를 참조하세요.

상태 프로브를 차단하지 않습니다. 부하 분산 장치 상태 프로브는 알려진 IP 주소 168.63.129.16에서 전송됩니다. 방화벽 정책 또는 네트워크 보안 그룹에서 IP에 대한 트래픽을 차단하지 마세요. 상태 프로브를 차단하면 부하 분산 장치가 VM을 윤번에서 제거할 것입니다.

부하 분산 장치 로깅을 사용하도록 설정합니다. 로그는 백 엔드의 VM이 실패한 프로브 응답으로 인해 네트워크 트래픽을 수신하지 못하는 횟수를 표시합니다. 자세한 내용은 Azure Load Balancer에 대한 로그 분석을 참조하세요.