중복성을 디자인하기 위한 아키텍처 전략

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

이 가이드에서는 복원력을 최적화하는 여러 워크로드 계층에서 중요한 흐름 전체에 중복성을 추가하기 위한 권장 사항을 설명합니다. 컴퓨팅, 데이터, 네트워킹 및 기타 인프라 계층에 적절한 수준의 중복성을 적용하여 정의된 안정성 목표의 요구 사항을 충족합니다. 이 중복성을 적용하여 워크로드에 강력하고 신뢰할 수 있는 기반을 구축합니다. 인프라 중복 없이 워크로드를 빌드하는 경우 잠재적인 오류로 인해 가동 중지 시간이 길어질 위험이 높습니다.

정의

안정성의 컨텍스트에서 중복성을 사용하여 단일 리소스에 영향을 주는 문제를 포함하고 이러한 문제가 전체 시스템의 안정성에 영향을 주지 않도록 합니다. 중요한 흐름 및 안정성 대상에 대해 식별한 정보를 사용하여 각 흐름의 중복성에 필요한 정보에 입각한 결정을 내립니다.

예를 들어 한 번에 실행되는 여러 웹 서버 노드가 있을 수 있습니다. 지원하는 흐름이 중요한 경우 문제가 전체 데이터 센터 중단과 같은 전체 풀에 영향을 주는 경우 모든 노드에 트래픽을 즉시 허용할 수 있는 복제본이 필요할 수 있습니다. 또는 대규모 문제가 드물고 전체 복제본 집합을 배포하는 데 비용이 많이 들기 때문에 문제를 해결할 때까지 흐름이 저하된 상태로 작동하도록 제한된 수의 복제본을 배포할 수 있습니다.

성능 효율성 컨텍스트에서 중복성을 위해 디자인할 때 부하를 여러 중복 노드에 분산하여 각 노드가 최적으로 수행되도록 합니다. 안정성 측면에서, 하나 이상의 노드에 영향을 미치는 오류 또는 오작동을 흡수하기 위해 예비 용량을 확보합니다. 영향을 받는 노드를 복구하는 데 필요한 전체 시간 동안 예비 용량이 오류를 흡수할 수 있는지 확인합니다. 이러한 차이점을 염두에 두고 두 전략이 함께 작동해야 합니다. 성능을 위해 두 노드에 트래픽을 분산하고 둘 다 60% 사용률에서 실행되고 하나의 노드가 실패하는 경우 나머지 노드는 120%작동할 수 없기 때문에 과부하가 발생할 위험이 있습니다. 다른 노드를 사용하여 부하를 분산하여 성능 및 안정성 목표를 유지할 수 있도록 합니다.

절상:

• 워크로드 중복성이 많을수록 더 많은 비용이 발생합니다. 중복성을 추가하는 것을 신중하게 고려하고 아키텍처를 정기적으로 검토하여 특히 오버프로비전을 사용하는 경우 비용을 관리하고 있는지 확인합니다. 과잉 프로비전을 복원 전략으로서 사용할 때 비용 비효율성을 최소화하기 위해 명확히 정의된 크기 조정 전략과 균형을 맞추십시오.

• 높은 수준의 중복성으로 빌드할 때 성능이 저하될 수 있습니다. 예를 들어 가용성 영역 또는 위치에 분산된 리소스는 웹 서버 또는 데이터베이스 인스턴스와 같은 중복 리소스 간에 대기 시간이 긴 연결을 통해 트래픽을 보내야 하므로 성능에 영향을 줄 수 있습니다.

• 동일한 워크로드 내의 흐름에 따라 안정성 요구 사항이 다를 수 있습니다. 흐름별 중복 디자인은 잠재적으로 전체 디자인에 복잡성을 초래할 수 있습니다.

• 짧은 대기 시간 중복 디자인은 모든 인스턴스를 오프라인으로 전환할 수 있는 지리적 재해와 같은 대규모 이벤트가 발생할 경우 해당 구성 요소를 잃을 위험을 감수한다는 것을 의미합니다. DR(지리적으로 먼 재해 복구) 환경은 이러한 위험을 완화하는 데 도움이 되지만 비용을 증가합니다.

운영 부담을 줄이기 위해 서버리스 및 완전 관리형 서비스를 선호합니다.

서버리스, SaaS(Software as a Service) 및 PaaS(Platform as a Service) 솔루션을 활용하여 데이터 복제 또는 장애 조치(failover) 작업을 관리할 필요 없이 워크로드에 중복성을 쉽게 추가합니다. 이러한 서비스는 중복성을 투명하게 구현하여 고유한 중복 메커니즘을 설계하고 유지 관리하는 운영 부담을 제거합니다. 서비스 옵션을 평가할 때 수동 중복 구성이 필요한 인프라 기반 접근 방식보다 중복성을 자동으로 처리하는 관리되는 서비스의 우선 순위를 지정합니다.

Azure 관리형 서비스는 다양한 모델을 통해 중복성을 제공합니다. 각 모델은 다양한 수준의 추상화 및 운영 편의성을 제공합니다.

기본 제공 중복성이 있는 글로벌 서비스: Microsoft Entra ID, Azure DNS 및 Azure Key Vault와 같은 서비스는 여러 지역에서 자동 중복성을 가진 글로벌 서비스로 작동합니다. 이러한 서비스는 중복 구성을 요구하지 않고 내재된 복원력을 제공합니다. 장애 조치(failover) 및 복구 시나리오를 투명하게 자동으로 처리합니다.

추상화된 용량 모델: Azure Cosmos DB, Azure Databricks 및 Azure OpenAI 관리형 엔드포인트와 같은 제품은 용량 단위, DTU 또는 기타 논리적 메트릭 뒤에 있는 기본 인프라 복잡성을 추상화합니다. 이러한 서비스는 간소화된 청구 및 관리 모델을 제시하면서 여러 인스턴스, 영역 및 지역에 워크로드를 자동으로 분산합니다. 개별 중복 인스턴스를 관리하는 대신 용량 요구 사항을 지정합니다.

솔루션을 설계할 때 인프라 기반 중복성을 구현하기 전에 각 구성 요소에 대해 관리 서비스 옵션이 있는지 평가합니다. 관리되는 서비스는 운영 오버헤드를 줄이고 사용자 지정 솔루션보다 더 강력한 중복 구현을 제공하는 경우가 많지만, 제어의 장단위와 각 용량 단위에 대한 잠재적으로 더 높은 비용이 포함될 수 있습니다.

여러 구성 요소 인스턴스를 사용하여 워크로드에 중복성 빌드

워크로드에 필요한 복원력을 달성하기 위해 인프라 구성 요소 및 서비스의 여러 인스턴스를 배포합니다. 이 기본 중복 전략은 한 인스턴스가 실패할 경우 다른 인스턴스가 워크로드를 계속 처리할 수 있도록 합니다. 여러 방법을 통해 여러 인스턴스를 달성할 수 있습니다. 일부 시나리오에서는 여러 Azure ExpressRoute 회로와 같은 여러 리소스를 개별적으로 배포하거나 여러 지역에서 Azure Traffic Manager를 구성하여 중복성을 수동으로 구성해야 합니다. 다른 서비스는 Azure Virtual Machine Scale Sets를 5개의 인스턴스로 설정하거나 10개의 인스턴스를 실행하도록 Azure App Service를 구성하는 등 여러 인스턴스를 직접 지원하도록 설계되었습니다. 가능하면 중복 관리가 간소화되고 안정성 및 성능 요구 사항에 모두 대응할 수 있으므로 여러 인스턴스 및 자동 크기 조정 기능에 대한 기본 제공 지원을 제공하는 서비스를 선호합니다.

중복 인프라 구성 요소를 배포할 때 안정성 목표를 충족하는 각 구성 요소의 인스턴스 수를 결정합니다. 모든 구성 요소의 여러 인스턴스가 필요한지 또는 특정 중요 구성 요소만 필요한지 여부를 고려하고 복원력 요구 사항을 충족하기 위해 해당 인스턴스의 지리적 분포를 결정합니다. 중복 인프라를 배포하는 경우 다음 권장 사항을 고려하세요.

컴퓨팅 리소스:

• 중복성을 기본적으로 지원하는 서비스를 선호합니다. 이러한 서비스를 사용하면 필요한 인스턴스 수를 지정할 수 있으며 해당 인스턴스의 배포 및 관리를 처리할 수 있습니다.

• 요청을 제공하는 개별 노드가 언제든지 삭제, 오류 또는 교체될 수 있으므로 컴퓨팅 계층을 상태 정리합니다.

• 중복 접근 방식과 일치하도록 크기 조정 전략을 디자인하고 테스트합니다.

데이터 리소스:

• 지역 간 데이터를 복제하여 지역 가동 중단 및 치명적인 오류에 대한 복원력을 제공합니다.

• 사용하는 상태 저장 플랫폼 서비스의 기본 제공 복제 및 중복 기능을 이해합니다 .

• 워크로드의 기능에 동기 또는 비동기 데이터 복제가 필요한지 여부를 확인합니다. 자세한 내용은 가용성 영역 및 지역 사용에 대한권장 사항을 참조하세요.

• 지리적으로 지역화된 오류의 영향을 최소화하기 위해 서비스에서 지원하는 대로 지리적으로 데이터를 배포합니다.

• 데이터베이스 인스턴스 실패 후 장애 조치(failover)를 자동화합니다. 여러 Azure PaaS 데이터 서비스에서 자동화된 장애 조치(failover)를 구성할 수 있습니다. Azure Cosmos DB와 같은 다중 지역 쓰기를 지원하는 데이터 저장소에는 자동화된 장애 조치(failover)가 필요하지 않습니다. 자세한 내용은 DR 전략 설계에 대한 권장 사항을 참조하세요.

• 가장 적합한 데이터 저장소을 데이터에 사용하세요. 데이터 저장소 기술의 조합을 사용하는 다각형 지속성 또는 솔루션을 수용합니다. 데이터에는 지속형 애플리케이션 데이터 이상이 포함됩니다. 애플리케이션 로그, 이벤트, 메시지 및 캐시도 포함됩니다.

• 데이터 일관성 요구 사항을 고려하고 요구 사항이 허용되는 경우 최종 일관성 사용합니다. 데이터가 분산되면 적절한 조정을 사용하여 강력한 일관성 보장을 적용합니다. 조정은 처리량을 줄이고 시스템을 긴밀하게 결합시켜 약해질 수 있습니다. 예를 들어 작업이 단일 트랜잭션 범위에 배치하는 대신 두 데이터베이스를 업데이트하는 경우 시스템이 최종 일관성을 수용할 수 있는 경우 더 좋습니다.

• 가용성을 위한 파티션 데이터입니다. 데이터베이스 분할 확장성을 향상시키고 가용성을 향상시킬 수도 있습니다. 한 샤드가 다운되면 다른 샤드에 여전히 접근 가능합니다. 하나의 분할된 데이터베이스에서 오류가 발생하면 총 트랜잭션의 하위 집합만 중단됩니다.

• 분할이 옵션이 아닌 경우 CQRS(명령 쿼리 책임 분리) 패턴을 사용하여 읽기-쓰기 및 읽기 전용 데이터 모델을 구분할 수 있습니다. 더 많은 복원력을 제공하기 위해 중복 읽기 전용 데이터베이스 인스턴스를 더 추가합니다.

네트워킹 리소스:

• 안정적이고 확장 가능한 네트워크 토폴로지를 결정합니다. 허브 및 스포크 모델 또는 Azure Virtual WAN 모델을 사용하여 클라우드 인프라를 논리 패턴으로 구성하여 중복성 디자인을 더 쉽게 빌드하고 확장할 수 있습니다.

• 지역 내 또는 지역 간에 요청을 분산하고 리디렉션하려면 적절한 네트워크 서비스 선택합니다. 가능한 경우 전역 또는 영역 중복 부하 분산 서비스를 사용하여 안정성 목표를 충족합니다.

• 스케일 아웃 요구 사항을 포함하여 계획된 사용량을 고려하여 가상 네트워크 및 서브넷에 충분한 IP 주소 공간을 할당했는지 확인합니다.

• 애플리케이션이 선택한 애플리케이션 호스팅 플랫폼의 포트 제한 내에서 확장할 수 있는지 확인합니다. 애플리케이션이 여러 개의 TCP(아웃바운드 전송 제어 프로토콜) 또는 UDP(사용자 데이터그램 프로토콜) 연결을 시작하는 경우 사용 가능한 모든 포트가 소진되어 애플리케이션 성능이 저하될 수 있습니다.

• SKU를 선택하고 대역폭 및 가용성 요구 사항을 충족할 수 있는 네트워킹 서비스를 구성합니다. VPN 게이트웨이의 처리량은 해당 SKU에 따라 다릅니다. 영역 중복에 대한 지원은 일부 부하 분산 장치 SKU에서만 사용할 수 있습니다.

• DNS(도메인 이름 시스템)를 처리하기 위한 디자인이 복원력에 중점을 두고 빌드되고 중복 인프라를 지원하는지 확인합니다.

배포 스탬프 패턴을 사용하여 중복성 접근 방식 간소화

개별 인프라 구성 요소 및 서비스에 대한 중복성 외에도 전체 워크로드 또는 논리 리소스 그룹의 여러 인스턴스를 배포하여 중복성 전략을 워크로드 수준으로 확장합니다. 배포 스탬프 디자인 패턴을 따라 특정 사용자 또는 요구 사항의 하위 집합에 워크로드를 제공하는 데 필요한 모든 리소스를 포함하는 반복 가능한 자체 포함 단위를 만듭니다.

배포 스탬프는 구성 요소 수준에서 워크로드 수준 중복으로의 전환을 나타냅니다. 각 스탬프는 독립적으로 작동할 수 있는 컴퓨팅, 스토리지, 네트워킹 및 종속성 등 필요한 모든 리소스를 포함하는 전체 규모의 단위 역할을 합니다. 이 방법은 폭발 반경을 포함하는 격리된 오류 도메인, 개별 구성 요소 크기 조정 대신 추가 스탬프 배포를 통한 수평 크기 조정, 지리 또는 요구 사항에 따른 유연한 분할, 동일한 반복 가능한 단위를 통한 간소화된 작업 등 주요 이점을 제공합니다.

활성-활성 모델(모든 스탬프가 동시에 트래픽을 제공하는 경우) 또는 활성-수동 모델(한 스탬프가 트래픽을 처리하는 반면 다른 스탬프는 대기 상태로 유지됨)에 스탬프를 배포하든 관계없이 각 스탬프를 지정된 워크로드를 독립적으로 처리할 수 있는 완전하고 자급자족적인 배포로 디자인합니다.

활성-활성 중복을 통해 가동 중지 시간 0 달성

활성-활성 배포는 워크로드의 여러 인스턴스를 동시에 실행하여 서비스 가용성을 최대화하며, 각 인스턴스는 트래픽을 적극적으로 처리합니다. 이 설정은 즉각적인 장애 조치(failover)를 보장하고, 가동 중지 시간을 제거하고, 모든 인스턴스의 생산성을 유지하여 리소스 사용을 최적화합니다. 하나의 인스턴스가 실패하면 트래픽이 서비스를 중단하지 않고 정상 인스턴스로 자동으로 다시 라우팅됩니다.

예를 들어 성수기 동안 전자 상거래 플랫폼은 하나의 배포에 문제가 발생하더라도 원활한 운영을 유지할 수 있습니다. 활성-활성 구성은 중단 없는 가용성이 필요하지만 인프라 비용과 복잡성이 더 높은 중요 업무용 워크로드에 적합합니다. 여러 라이브 환경을 관리하고, 데이터 일관성을 보장하며, 모든 인스턴스에서 업데이트를 조정하려면 고급 운영 전략이 필요합니다.

다음 섹션에서는 활성-활성 배포에 대한 구성 옵션에 대해 설명합니다.

• 용량에서 활성-활성: 둘 이상의 위치에 미러된 배포 스탬프가 있으며, 각 위치는 서비스하는 위치 또는 위치에 대한 프로덕션 워크로드를 처리하도록 구성되고 지역 가동 중단이 발생할 경우 다른 위치의 부하를 처리하도록 확장 가능합니다.

  • 네트워킹:대기 시간 또는 가중치가 적용된 글로벌 라우팅을 사용하여 위치 간에 트래픽을 분산합니다.

  • 데이터 복제 및 일관성: 다중 지역 읽기 및 쓰기 기능을 위해 Azure Cosmos DB 와 같은 전역 분산 데이터 저장소를 사용합니다. 관계형 데이터베이스의 경우 읽기 전용 연결 문자열과 함께 읽을 수 있는 복제본을 사용합니다.

  • 이 디자인의 이점: 과도하게 프로비전된 디자인보다 운영 비용이 낮습니다.

  • 이 디자인의 단점은 다음과 같습니다 . 다른 위치에서 중단이 발생하는 경우 전체 부하의 요구를 충족하기 위해 확장할 때 사용자 환경의 성능이 저하할 수 있습니다.

• 활성-활성 오버프로비전: 둘 이상의 위치에 미러된 배포 스탬프가 있으며, 각 위치는 서비스하는 위치 또는 위치에 대한 프로덕션 워크로드를 처리하고 지역 가동 중단이 발생하는 경우 다른 위치의 부하를 처리하기 위해 과도하게 프로비전됩니다.

  • 네트워킹:대기 시간 또는 가중치가 적용된 글로벌 라우팅을 사용하여 위치 간에 트래픽을 분산합니다.

  • 데이터 복제 및 일관성: 다중 지역 읽기 및 쓰기 기능을 위해 Azure Cosmos DB 와 같은 전역 분산 데이터 저장소를 사용합니다. 관계형 데이터베이스의 경우 읽기 전용 연결 문자열과 함께 읽을 수 있는 복제본을 사용합니다.

  • 이 디자인의 이점: 가능한 가장 복원력 있는 디자인입니다.

  • 이 디자인의 단점은 다음과 같습니다 . 확장성 있는 디자인보다 운영 비용이 높습니다.

• 두 디자인의 일반적인 이점: 복원력이 높고 전체 워크로드 중단 위험이 낮습니다.

• 두 디자인의 일반적인 단점은 다음과 같습니다. 애플리케이션 상태 및 데이터의 동기화 관리 필요성을 포함하여 다양한 요인으로 인해 운영 비용 및 관리 부담이 높아질 수 있습니다.

활성-수동 아키텍처 디자인을 사용하여 DR 복원력 제공

활성-수동 배포 구성은 보조 인스턴스를 유휴 상태로 유지하면서 모든 트래픽을 처리하는 기본 인스턴스를 실행하여 DR을 보장하는 비용 효율적인 방법을 제공합니다. 이러한 대기 인스턴스는 주 인스턴스가 실패하거나 유지 관리를 받는 경우에만 활성화됩니다. 이 방법은 안정적인 장애 조치(failover) 기능을 제공하면서 리소스 사용량을 최소화합니다.

예를 들어 금융 거래 플랫폼은 이 설정을 사용하여 서비스 연속성을 유지할 수 있습니다. 기본 시스템은 모든 트랜잭션을 관리하지만 보조 시스템은 백그라운드에서 동기화된 상태로 유지됩니다. 주 시스템이 중단되면 보조 시스템은 중단을 최소화하면서 작업을 신속하게 인수하고 복원합니다. 이 방법은 안정성과 비용의 균형을 맞추기 때문에 활성-활성 배포의 복잡성이나 비용 없이 짧은 복구 시간을 허용할 수 있는 워크로드에 적합합니다.

활성-수동 배포에 대해 다음 구성 옵션을 고려합니다.

• 웜 스페어: 하나의 기본 위치와 하나 이상의 보조 위치. 보조 위치는 가능한 최소 컴퓨팅 및 데이터 크기 조정으로 배포되고 로드 없이 실행됩니다. 이 위치를 따뜻한 예비 위치라고 합니다. 장애 조치(failover) 후 컴퓨팅 및 데이터 리소스는 기본 위치에서 부하를 처리하도록 크기가 조정됩니다.

  • 네트워킹:우선 순위 글로벌 라우팅을 사용합니다.

  • 데이터 복제 및 일관성: 수동 위치에 데이터베이스를 복제하고 Azure Cosmos DB 및 AzureSQL Database와 같은 PaaS 솔루션의 자동 장애 조치 기능을 사용합니다.

  • 이 디자인의 이점: 활성-수동 디자인 중 가장 짧은 복구 시간입니다.

  • 이 디자인의 단점은 다음과 같습니다 . 활성-수동 디자인 중에서 가장 높은 운영 비용입니다.

• 콜드 스페어: 하나의 기본 위치와 하나 이상의 보조 위치. 보조 위치는 전체 부하를 처리하도록 크기가 조정되지만 모든 컴퓨팅 리소스가 중지됩니다. 이 위치를 콜드 스페어 위치라고 합니다. 장애 조치(failover) 전에 리소스를 시작해야 합니다.

  • 네트워킹:우선 순위 글로벌 라우팅을 사용합니다.

  • 데이터 복제 및 일관성: 수동 위치에 데이터베이스를 복제하고 Azure Cosmos DB 및 SQL Database와 같은 PaaS 솔루션의 자동 장애 조치 기능을 사용합니다.

  • 이 디자인의 이점: 웜 스페어 디자인보다 운영 비용이 낮습니다.

  • 이 디자인의 단점은 다음과 같습니다 . 웜 스페어 디자인보다 복구 시간이 더 깁니다.

근접 독립 인프라에 워크로드 배포

근처의 독립 데이터 센터 또는 데이터 센터 섹터에 워크로드를 배포하면 성능을 손상시키지 않으면서 중복성을 제공합니다. 지리적으로 가깝지만 물리적으로 분리된 기능을 사용하여 이 설정은 대기 시간 영향을 최소화하면서 오류 격리를 보장합니다. 단일 사이트 배포의 응답성을 유지하면서 분산 인프라의 복원력을 제공합니다. Azure에서 가용성 영역은 이 기능을 제공합니다. 가용성 영역은 내결함성이 있고 대기 시간이 짧은 워크로드를 쉽게 배포할 수 있도록 설계된 물리적으로 독립적인 데이터 센터 또는 데이터 센터 섹터입니다.

실시간 게임과 같은 대기 시간에 민감한 애플리케이션의 경우 이 접근 방식을 통해 원활한 장애 조치(failover)와 중단 없는 사용자 환경을 구현할 수 있습니다. 로컬 데이터 센터에 분산된 게임 서버는 중단 시 트래픽을 즉시 다시 라우팅할 수 있으며, 투명한 부하 분산 및 거의 실시간 데이터 복제로 게임 플레이 연속성을 유지할 수 있습니다. 그러나 대규모 지역 이벤트는 모든 사이트에 동시에 영향을 줄 수 있으므로 이 전략에는 약간의 위험이 수반됩니다.

지리적으로 먼 배포를 사용하여 내결함성 강화

지리적으로 분산된 데이터 센터에 배포하면 수백 또는 수천 마일 떨어진 지역에 워크로드를 분산하여 대규모 재해에 대한 가장 강력한 보호를 제공합니다. 이 접근 방식은 자연 재해, 인프라 오류 또는 전체 대도시 지역에 영향을 줄 수 있는 지정학적 중단과 같은 이벤트 중에 비즈니스 연속성을 보장합니다. Azure에서 워크로드를 전 세계에 분산된 지역에 배포할 수 있습니다. 이 디자인 방법을 사용하는 경우 사용자와 가깝지만 지리적으로 먼 지역(예: 미국 서부 및 미국 동부)을 선택합니다.

예를 들어 글로벌 금융 플랫폼은 한 영역에서 큰 중단이 발생하는 경우 영향을 받지 않는 지역으로 트래픽을 라우팅하여 중단 없는 서비스를 유지할 수 있습니다. 이 접근 방식은 복원력을 최대화하고 관할 지역 전체에서 규정 준수를 지원하지만 대기 시간이 길어지고 데이터 일관성 요구 사항이 복잡하며 운영 오버헤드가 증가합니다. 글로벌 중복성의 이점에 대해 이러한 요인을 신중하게 고려해야 합니다.

Azure 지원

Azure 플랫폼을 사용하면 다음 작업을 수행하여 워크로드의 복원력을 최적화하고 중복성을 추가할 수 있습니다.

• Azure 지역 선택 가이드를 사용하여 다중 지역 아키텍처에 가장 적합한 Azure 지역을 선택할 수 있습니다.

• 많은 PaaS 및 SaaS 솔루션과 함께 기본 제공 중복성을 제공하며, 그 중 일부는 구성할 수 있습니다.

• 구성 없이 중복성을 투명하게 구현하는 Microsoft Entra ID, Azure DNS 및 Key Vault와 같은 글로벌 관리형 서비스를 제공합니다.

• 가용성 영역 및 지역 간 중복성을 사용하여 지역 내 중복성을 디자인하고 구현할 수 있습니다.

• VM(가상 머신)을 배포할 때 가용성 영역에 컴퓨팅을 균등하게 분산할 수 있는 Virtual Machine Scale Sets와 같은 영역 중복 컴퓨팅 솔루션을 제공합니다.

• Azure Application Gateway, AzureFront Door 및 Azure Load Balancer와 같은 복제본 인식 부하 분산 서비스를 제공합니다.

• SQL Database에 대한 활성 지역 복제와 같이 쉽게 구현 되는 지역 복제 솔루션을 제공합니다. Azure Cosmos DB를 사용하여 전역 배포 및 투명한 복제를 구현합니다. Azure Cosmos DB는 충돌하는 쓰기를 처리하기 위한 두 가지 옵션을 제공합니다. 워크로드에 가장 적합한 옵션을 선택합니다.

• 여러 PaaS 데이터 서비스에 대한 PITR(지정 시간 복원) 기능을 제공합니다.

• Azure NAT 게이트웨이 또는 Azure Firewall을 통해 포트 고갈을 완화합니다.

DNS 특정 Azure 지원

• 내부 이름 확인 시나리오의 경우 기본 제공 영역 중복성 및 지역 중복성이 있는 Azure DNS 프라이빗 영역을 사용합니다. 자세한 내용은 Azure DNS 프라이빗 영역 복원력 참조하세요.

• 외부 이름 확인 시나리오의 경우 기본 제공 영역 중복성 및 지역 중복성이 있는 Azure DNS 공용 영역을 사용합니다.

• 공용 및 프라이빗 Azure DNS 서비스는 영역 데이터를 전역적으로 사용할 수 있기 때문에 지역 가동 중단에 탄력적인 글로벌 서비스입니다.

• 온-프레미스 환경과 클라우드 환경 간의 하이브리드 이름 확인 시나리오의 경우 Azure DNS Private Resolver를 사용합니다. 이 서비스는 워크로드가 가용성 영역을 지원하는 지역에 있는 경우 영역 중복을 지원합니다. 영역 전체 중단은 영역 복구 중에 아무런 조치도 필요하지 않습니다. 서비스는 정상 영역을 활용하기 위해 자동으로 자체 치유 및 균형을 조정합니다. 자세한 내용은 Azure DNS Private Resolver의 복원력을 참조하세요.

• 단일 실패 지점을 제거하고 지역 간에 보다 복원력 있는 하이브리드 이름 확인을 달성하려면 여러 지역에 둘 이상의 Azure DNS 프라이빗 해결 프로그램을 배포합니다. 조건부 전달 시나리오에서 DNS 장애 조치는 확인자를 기본 DNS 서버로 할당하여 수행됩니다. 다른 지역의 다른 확인자를 보조 DNS 서버로 할당합니다. 자세한 내용은 프라이빗 확인자를 사용하여 DNS 장애 조치 설정하기를 참조하세요.

본보기

다중 지역 중복 배포의 예는 기준 고가용성 영역 중복 웹 애플리케이션참조하세요.

다음 다이어그램은 또 다른 예제를 보여 주는 다이어그램입니다.

참조 구현의 아키텍처를 보여 주는

관련 링크

중복성에 대한 자세한 내용은 다음 리소스를 참조하세요.

• Azure 지역 안내서
• Azure Storage 중복성
• 영역 중복 스토리지
• SQL Database 활성 지역 복제
• 관리되는 두 인스턴스 간의 복제 구성

안정성 검사 목록

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