모두 중복으로 구성

단일 실패 지점을 피하도록 애플리케이션에 중복성을 구축합니다.

복원력 있는 애플리케이션은 장애가 발생해도 라우팅됩니다. 애플리케이션에서 중요한 경로를 식별합니다. 경로의 각 지점에 중복성이 있나요? 하위 시스템에 오류가 발생하면 애플리케이션이 장애 조치(Failover)되나요?

완벽한 구현에서 균일한 중복성을 추가하면 시스템의 가용성이 기하급수적으로 증가할 수 있습니다. 예를 들어 다음과 같은 동등하고 균형이 잡힌 구성 요소가 있다고 상상해 N 보세요.

• 는 독립적으로 오작동할 수 있으며 풀에서 동시에 제거될 수 있습니다.
• 상태가 동일하거나 상태가 없음
• 오작동 중에 영구적으로 손실되는 진행 중인 작업이 없습니다.
• 기능에서 동일합니다.
• 서로 종속성이 없음
• 추가 오작동 없이 용량 감소 처리

각 개별 구성 요소의 A가용성이 있는 경우 수식을 1 - (1 - A)^N사용하여 전체 시스템 가용성을 계산할 수 있습니다.

권장 사항

비즈니스 요구 사항 고려. 시스템에 기본 제공되는 중복성 수준은 비용 및 복잡성에 영향을 미칠 수 있습니다. 아키텍처는 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 같은 비즈니스 요구 사항에 따라 알려야 합니다. 또한 성능 요구 사항과 복잡한 리소스 집합을 관리하는 팀의 기능을 고려해야 합니다.

다중 영역 및 다중 지역 아키텍처를 고려합니다. 가용성 영역 및 지역이 복원력과 다양한 아키텍처 절충을 제공하는 방법을 이해해야 합니다.

Azure 가용성 영역은 지역 내의 격리된 데이터 센터 집합입니다. 가용성 영역을 사용하면 단일 데이터 센터 또는 전체 가용성 영역의 오류에 탄력적일 수 있습니다. 가용성 영역을 사용하여 비용, 위험 완화, 성능 및 복구 가능성 간의 절충을 수행할 수 있습니다. 예를 들어 아키텍처에서 영역 중복 서비스를 사용하는 경우 Azure는 지리적으로 구분된 인스턴스 간에 자동 데이터 복제 및 장애 조치(failover)를 제공하여 다양한 유형의 위험을 완화합니다.

중요 업무용 워크로드가 있고 지역 전체 중단의 위험을 완화해야 하는 경우 다중 지역 배포를 고려하세요. 다중 지역 배포는 지역 재해에 대해 격리되지만 비용이 발생합니다. 다중 지역 배포는 단일 지역 배포보다 비용이 많이 들고 관리하기가 더 복잡합니다. 장애 조치(failover) 및 장애 복구(failback)를 처리하려면 운영 절차가 필요합니다. RPO 요구 사항에 따라 지역 간 데이터 복제를 사용하도록 설정하려면 약간 더 낮은 성능을 허용해야 할 수 있습니다. 일부 비즈니스 시나리오에서는 추가 비용 및 복잡성이 정당화될 수 있습니다.

팁

많은 워크로드의 경우 영역 중복 아키텍처는 최상의 절충을 제공합니다. 비즈니스 요구 사항에 따라 지역 전체 가동 중단의 위험을 완화해야 하며 이러한 접근 방식과 관련된 절충을 수용할 준비가 된 경우 다중 지역 아키텍처를 고려합니다.

가용성 영역 및 지역 사용에 대한 권장 사항을 참조하여 가용성 영역 및 지역을 사용하도록 솔루션을 설계하는 방법에 대한 자세한 내용을 확인하세요.

부하 분산 장치 뒤에 VM 배치 중요한 워크로드에 단일 VM을 사용하지 마세요. 대신, 부하 분산 장치 뒤에 여러 VM을 배치합니다. VM를 사용할 수 없는 경우 부하 분산 장치는 나머지 정상 VM에 트래픽을 분산합니다.

데이터베이스 복제 Azure SQL Database 및 Azure Cosmos DB는 지역 내에서 데이터를 자동으로 복제하며, 복원력을 높이기 위해 가용성 영역 간에 복제하도록 구성할 수 있습니다. 지역 간 복제를 사용하도록 선택할 수도 있습니다. Azure SQL Database 및 Azure Cosmos DB에 대한 지역 복제는 하나 이상의 보조 지역에 데이터의 보조 읽기 복제본을 만듭니다. 주 지역에서 중단이 발생하면 데이터베이스는 쓰기를 위해 보조 지역으로 장애 조치(failover)할 수 있습니다. 복제 구성에 따라 설명되지 않은 트랜잭션으로 인해 데이터가 손실될 수 있습니다.

IaaS 데이터베이스 솔루션을 사용하는 경우 복제 및 장애 조치(failover)를 지원하는 솔루션(예: SQL Server Always On 가용성 그룹)을 선택합니다.

가용성을 위한 분할 데이터베이스 분할은 확장성을 높이기 위해 자주 사용되지만 가용성을 높이는 결과도 가져올 수 있습니다. 하나의 분할된 데이터베이스가 다운되면 다른 분할된 데이터베이스에 계속 연결할 수 있습니다. 하나의 분할된 데이터베이스가 실패하는 경우 총 트랜잭션의 일부만 중단됩니다.

중복 구성 요소를 테스트하고 유효성을 검사합니다. 단순성 및 중복성 추가를 통해 여러 가지 방법으로 안정성 이점을 얻을 수 있으므로 복잡성이 증가할 수 있습니다. 중복성을 추가하면 실제로 더 높은 가용성이 발생하도록 하려면 다음의 유효성을 검사해야 합니다.

• 시스템이 정상 및 비정상 중복 구성 요소를 안정적 으로 검색하고 구성 요소 풀에서 안전하고 신속하게 제거할 수 있나요?
• 시스템이 안정적으로 확장되고 중복 구성 요소에서 확장할 수 있나요?
• 루틴, 임시 및 응급 워크로드 작업에서 중복성을 처리할 수 있나요?

다중 지역 솔루션

다음 다이어그램에서는 Azure Traffic Manager를 사용하여 장애 조치(Failover)를 처리하는 다중 지역 애플리케이션을 보여 줍니다.

다중 지역 솔루션에서 Traffic Manager 또는 Azure Front Door를 장애 조치(failover) 라우팅 메커니즘으로 사용하는 경우 다음 권장 사항을 고려하세요.

프런트 엔드 및 백 엔드 장애 조치(Failover) 동기화. 라우팅 메커니즘을 사용하여 프런트 엔드를 장애 조치(failover)합니다. 프런트 엔드가 한 지역에서 연결할 수 없게 되면 장애 조치(failover)는 새 요청을 보조 지역으로 라우팅합니다. 백 엔드 구성 요소 및 데이터베이스 솔루션에 따라 백 엔드 서비스 및 데이터베이스 장애 조치(failover)를 조정해야 할 수 있습니다.

자동 장애 조치(Failover)와 수동 장애 복구(Failback) 사용. 장애 조치(failover)에 자동화를 사용하지만 장애 복구에는 사용하지 않습니다. 자동 장애 복구(Failback)는 해당 지역이 완전히 정상 상태가 되기 전에 주 지역으로 전환될 수도 있는 위험을 수반합니다. 대신, 수동 장애 복구(Failback) 전에 모든 애플리케이션 하위 시스템이 정상 상태인지 확인합니다. 또한 장애 복구하기 전에 데이터 일관성을 확인해야 합니다.

이렇게 하려면 장애 조치(failover) 후 기본 엔드포인트를 사용하지 않도록 설정합니다. 프로브의 모니터링 간격이 짧고 허용되는 오류 수가 적으면 장애 조치(failover) 및 장애 복구(failback)가 짧은 시간 안에 발생합니다. 경우에 따라 비활성화가 시간에 완료되지 않습니다. 확인되지 않은 장애 복구(failback)를 방지하려면 모든 하위 시스템이 정상인지 확인할 수 있는 상태 엔드포인트 구현하는 것도 좋습니다. 상태 엔드포인트 모니터링 패턴을 참조하세요.

라우팅 솔루션에 대한 중복성을 포함합니다. 중요 업무용 웹 애플리케이션에 대한 글로벌 라우팅 중복 솔루션을 설계하는 것이 좋습니다.