가용성 영역 및 하위 지역 사용에 대한 권장 사항
이 Azure 잘 설계된 프레임워크 안정성 검사 목록 권장 사항에 적용됩니다.
| RE:05 | 특히 중요한 흐름의 경우 다양한 수준에서 중복성을 추가합니다. 식별된 안정성 목표에 따라 컴퓨팅, 데이터, 네트워크 및 기타 인프라 계층에 중복성을 적용합니다. |
|---|
관련 가이드: 고가용성 다단계 디자인 | 중복성
이 가이드에서는 가용성 영역 또는 지역에 워크로드를 배포할 시기를 결정하기 위한 권장 사항을 설명합니다.
Azure용 솔루션을 디자인할 때는 지역의 여러 가용성 영역에 배포할지 아니면 여러 지역에 배포할지 결정해야 합니다. 이 결정은 솔루션의 안정성, 비용 및 성능 및 팀의 솔루션 운영 능력에 영향을 줍니다. 이 가이드에서는 의사 결정에 영향을 주는 주요 비즈니스 요구 사항, 고려할 수 있는 접근 방식, 각 접근 방식과 관련된 절충안 및 Azure Well-Architected Framework의 핵심 핵심 핵심 요소에 대한 각 접근 방식의 영향에 대한 정보를 제공합니다.
솔루션에 사용할 최상의 Azure 지역에 대한 결정은 중요한 선택입니다. Azure 지역 선택 가이드에서는 여러 지역에서 선택하고 작동하는 방법을 설명합니다. 솔루션 내에서 지역 및 가용성 영역을 사용하는 방법은 잘 설계된 프레임워크의 몇 가지 핵심 요소에도 영향을 줍니다.
- 안정성: 배포 방법을 선택하면 다양한 유형의 위험을 완화하는 데 도움이 될 수 있습니다. 일반적으로 지리적으로 분산된 영역에 워크로드를 분산하면 복원력을 높일 수 있습니다.
- 비용 최적화: 일부 아키텍처 접근 방식에는 다른 방법보다 더 많은 리소스를 배포해야 하므로 리소스 비용이 증가할 수 있습니다. 다른 접근 방식에는 지리적으로 구분된 가용성 영역 또는 지역에 데이터를 전송하는 것이 포함되며, 이로 인해 네트워크 트래픽 요금이 발생할 수 있습니다. 또한 포괄적인 비즈니스 요구 사항이 있는 경우 일반적으로 더 높은 리소스 관리 비용을 고려하는 것이 중요합니다.
- 성능 효율성: 가용성 영역은 대역폭이 높고 대기 시간이 짧은 네트워크 링크를 통해 함께 연결되며, 이는 대부분의 워크로드가 영역 전체에서 동기 복제 및 통신을 사용하도록 설정하는 데 충분합니다. 그러나 워크로드가 테스트되었으며 영역 간 네트워크 대기 시간에 민감한 경우 통신할 때 대기 시간을 최소화하기 위해 워크로드의 구성 요소를 물리적으로 함께 배치하는 것을 고려해야 할 수 있습니다.
- 운영 우수성: 복잡한 아키텍처는 배포, 구성 및 관리하기 위해 더 많은 노력을 기울입니다. 또한 고가용성 솔루션의 경우 보조 리소스 집합으로 장애 조치(failover)하는 방법을 계획해야 할 수 있습니다. 특히 수동 단계가 필요한 경우 장애 조치, 장애 복구 및 트래픽을 투명하게 리디렉션하는 작업은 복잡할 수 있습니다. 배포 및 관리 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 OE:05 인프라를 코드로, OE:09 작업 자동화, OE:10 자동화 디자인 및 OE:11 배포 사례를 포함하여 운영 우수성 핵심 가이드를 참조하세요.
그러나 솔루션을 디자인하면 보안 핵심 요소도 적용됩니다. 일반적으로 가용성 영역 및 지역을 사용하는지 여부와 방법에 대한 결정은 보안 상태를 변경하지 않습니다. Azure는 모든 지역 및 가용성 영역에 동일한 보안 엄격함을 적용합니다.
팁
많은 프로덕션 워크로드의 경우 영역 중복 배포 는 절충의 최상의 균형을 제공합니다. 비동기 데이터 백업을 사용하여 이 방법을 다른 지역으로 확장할 수 있습니다. 어떤 방법을 선택해야 할지 잘 모르는 경우 이 유형의 배포로 시작합니다.
이러한 접근 방식이 제공하는 특정 혜택이 필요하지만 관련된 장단점에 유의해야 하는 경우 다른 워크로드 접근 방식을 고려합니다.
정의
| 용어 | 정의 |
|---|---|
| 활성-활성 | 솔루션의 여러 인스턴스가 동시에 요청을 적극적으로 처리하는 아키텍처입니다. |
| 활성-수동 | 솔루션의 한 인스턴스가 기본으로 지정되고 트래픽을 처리하는 아키텍처이며, 주 인스턴스를 사용할 수 없는 경우 트래픽을 제공하기 위해 하나 이상의 보조 인스턴스가 배포됩니다. |
| 비동기 복제 | 한 위치에 데이터를 쓰고 커밋하는 데이터 복제 방식입니다. 나중에 변경 내용이 다른 위치로 복제됩니다. |
| 가용성 영역 | 지역 내의 데이터 센터의 구분된 그룹입니다. 각 가용성 영역은 자체 전력, 냉각 및 네트워킹 인프라를 갖춘 다른 가용성 영역과 독립적입니다. 많은 지역에서 가용성 영역을 지원합니다. |
| 데이터 센터 | Azure 리소스 및 워크로드를 지원하는 서버, 네트워킹 장비 및 기타 하드웨어를 포함하는 시설입니다. |
| 로컬 중복 배포 | 리소스가 가용성 영역에 대한 참조 없이 단일 지역에 배포되는 배포 모델입니다. 가용성 영역을 지원하는 지역에서 리소스는 해당 지역의 가용성 영역에 배포될 수 있습니다. |
| 다중 지역 배포 | 리소스가 여러 Azure 지역에 배포되는 배포 모델입니다. |
| 쌍을 이루는 지역 | 두 Azure 지역 간의 관계입니다. 일부 Azure 지역은 특정 유형의 다중 지역 솔루션을 사용하도록 설정하기 위해 다른 정의된 지역에 연결됩니다. 최신 Azure 지역은 쌍으로 연결되지 않습니다. |
| 지역 | 데이터 센터 집합을 포함하는 지리적 경계입니다. |
| 지역 아키텍처 | 가용성 영역 수 및 지역이 다른 지역과 쌍을 이루는지 여부를 포함하여 Azure 지역의 특정 구성입니다. |
| 동기 복제 | 데이터가 여러 위치에 기록되고 커밋되는 데이터 복제 방식입니다. 각 위치는 전체 쓰기 작업이 완료된 것으로 간주되기 전에 쓰기 작업의 완료를 승인해야 합니다. |
| 영역(고정) 배포 | 리소스가 특정 가용성 영역에 배포되는 배포 모델입니다. |
| 영역 중복 배포 | 리소스가 여러 가용성 영역에 배포되는 배포 모델입니다. Microsoft는 영역에서 중단이 발생하는 경우 데이터 동기화, 트래픽 배포 및 장애 조치(failover)를 관리합니다. |
주요 디자인 전략
Azure는 전 세계적으로 큰 공간을 보유하고 있습니다. Azure 지역은 데이터 센터 집합을 포함하는 지리적 경계입니다. Azure 지역 및 가용성 영역을 완전히 이해해야 합니다.
Azure 지역에는 지역 아키텍처라고 도 하는 다양한 구성이 있습니다.
많은 Azure 지역은 데이터 센터의 구분된 그룹인 가용성 영역을 제공합니다. 한 지역 내에서 가용성 영역은 다른 가용성 영역에 대해 대기 시간이 짧은 연결을 가질 수 있을 만큼 충분히 가깝지만 둘 이상의 가용성 영역이 지역 중단이나 날씨의 영향을 받을 가능성을 줄일 수 있을 만큼 충분히 떨어져 있습니다. 가용성 영역에는 독립적인 전원, 냉각 및 네트워킹 인프라가 있습니다. 한 영역에서 중단이 발생하는 경우 지역 서비스, 용량 및 고가용성이 다시 기본 영역에서 지원되도록 설계되었습니다.
다음 다이어그램에서는 몇 가지 Azure 지역 예제를 보여 줍니다. 지역 1 및 2는 가용성 영역을 지원합니다.
가용성 영역이 포함된 Azure 지역에 배포하는 경우 여러 가용성 영역을 함께 사용할 수 있습니다. 여러 가용성 영역을 사용하면 대규모 대도시 지역의 별도 물리적 데이터 센터 내에서 애플리케이션 및 데이터의 별도 복사본을 유지할 수 있습니다.
솔루션에서 가용성 영역을 사용하는 방법에는 두 가지가 있습니다.
- 영역 리소스는 특정 가용성 영역에 고정됩니다. 여러 영역에 걸쳐 여러 영역 배포를 결합하여 높은 안정성 요구 사항을 충족할 수 있습니다. 데이터 복제본(replica)tion을 관리하고 영역 간에 요청을 배포할 책임이 있습니다. 단일 가용성 영역에서 중단이 발생하는 경우 다른 가용성 영역으로 장애 조치(failover)를 수행해야 합니다.
- 영역 중복 리소스는 여러 가용성 영역에 분산됩니다. Microsoft는 영역 간 분산 요청과 영역 간 데이터 복제본(replica)를 관리합니다. 단일 가용성 영역에서 중단이 발생하면 Microsoft는 장애 조치(failover)를 자동으로 관리합니다.
Azure 서비스는 이러한 방법 중 하나 또는 둘 다를 지원합니다. PaaS(Platform as a Service) 서비스는 일반적으로 영역 중복 배포를 지원합니다. IaaS(Infrastructure as a Service) 서비스는 일반적으로 영역 배포를 지원합니다. Azure 서비스가 가용성 영역에서 작동하는 방법에 대한 자세한 내용은 가용성 영역 지원이 있는 Azure 서비스를 참조하세요.
Microsoft가 서비스에 업데이트를 배포할 때 가장 중단이 적은 방법을 사용하려고 합니다. 예를 들어 한 번에 단일 가용성 영역에 업데이트를 배포하는 것을 목표로 합니다. 이 방법은 업데이트가 진행되는 동안 워크로드가 다른 영역에서 계속 실행될 수 있으므로 업데이트가 활성 워크로드에 미칠 수 있는 영향을 줄일 수 있습니다. 그러나 궁극적으로 워크로드 팀은 플랫폼 업그레이드 중에 워크로드가 계속 작동하도록 해야 합니다. 예를 들어 유연한 오케스트레이션 모드 또는 대부분의 Azure PaaS 서비스에서 가상 머신 확장 집합을 사용하는 경우 Azure는 플랫폼 업데이트의 영향을 줄이기 위해 리소스를 지능적으로 배치합니다. 또한 다른 인스턴스를 업그레이드하는 동안 일부 인스턴스를 계속 사용할 수 있도록 리소스 인스턴스를 더 많이 배포하는 오버프로비전을 고려할 수 있습니다. Azure에서 업데이트를 배포하는 방법에 대한 자세한 내용은 안전한 배포 방법 진행을 참조 하세요.
많은 지역에는 쌍을 이루는 지역도 있습니다. 쌍을 이루는 지역은 특정 유형의 다중 지역 배포 방법을 지원합니다. 일부 최신 지역에는 여러 가용성 영역이 있으며 쌍을 이루는 지역이 없습니다. 이러한 지역에 다중 지역 솔루션을 계속 배포할 수 있지만 사용하는 접근 방식은 다를 수 있습니다.
Azure에서 지역 및 가용성 영역을 사용하는 방법에 대한 자세한 내용은 Azure 지역 및 가용성 영역이란?을 참조 하세요.
공유 책임 이해
공동 책임 원칙은 클라우드 공급자(Microsoft)와 사용자 간에 책임을 나누는 방법을 설명합니다. 사용하는 서비스 유형에 따라 서비스 운영에 대한 책임이 많거나 적을 수 있습니다.
Microsoft는 요구 사항에 맞게 솔루션을 디자인하는 방법에 유연성을 제공하기 위해 가용성 영역 및 지역을 제공합니다. 관리되는 서비스를 사용하는 경우 Microsoft는 데이터 복제, 장애 조치(failover), 장애 복구(failback) 및 분산 시스템 운영과 관련된 기타 작업을 포함할 수 있는 리소스에 대한 관리 책임을 더 많이 수행합니다.
사용자 고유의 코드는 오류를 정상적으로 처리하기 위한 권장 사례 및 디자인 패턴이 필요합니다. 이러한 사례는 가용성 영역 또는 지역 장애 조치(failover)가 발생할 때 발생하는 것과 같이 장애 조치(failover) 작업 중에 더욱 중요합니다. 영역 또는 지역 간의 장애 조치(failover)는 일반적으로 애플리케이션이 서비스에 대한 연결을 다시 시도해야 하기 때문입니다.
주요 비즈니스 및 워크로드 요구 사항 식별
솔루션에서 가용성 영역 및 지역을 사용하는 방법에 대한 정보에 입각한 결정을 내리려면 요구 사항을 이해해야 합니다. 이러한 요구 사항은 솔루션 디자이너와 비즈니스 관련자 간의 논의를 통해 이뤄져야 합니다.
위험 허용 범위
조직별로 위험 허용 범위가 다릅니다. 조직 내에서도 위험 허용 범위는 워크로드마다 다른 경우가 많습니다. 대부분의 워크로드에는 매우 높은 가용성이 필요하지 않습니다. 그러나 일부 워크로드는 매우 중요하므로 광범위한 지역에 영향을 주는 주요 자연 재해와 같이 발생할 가능성이 없는 위험을 완화할 가치가 있습니다.
이 표에는 클라우드 환경에서 고려해야 하는 몇 가지 일반적인 위험이 나와 있습니다.
| 위험 | 예제 | Likelihood |
|---|---|---|
| 하드웨어 중단 | 하드 디스크 또는 네트워킹 장비에 문제가 있습니다. 호스트 재부팅. |
높음. 모든 복원력 전략은 이러한 위험을 고려해야 합니다. |
| 데이터 센터 중단 | 전체 데이터 센터에서 전원, 냉각 또는 네트워크 오류가 발생했습니다. 대도시 지역의 한 부분에서 자연 재해. |
중간 |
| 지역 중단 | 광범위한 지리적 영역에 영향을 주는 주요 자연 재해입니다. 전체 지역에서 하나 이상의 Azure 서비스를 사용할 수 없게 만드는 네트워크 또는 서비스 문제입니다. |
낮음 |
모든 워크로드에 대해 가능한 모든 위험을 완화하는 것이 이상적이지만 실용적이거나 비용 효율적이지는 않습니다. 완화해야 하는 위험에 대해 정보에 입각한 결정을 내릴 수 있도록 비즈니스 이해 관계자와 공개 토론을 하는 것이 중요합니다.
팁
안정성 대상에 관계없이 모든 워크로드에는 재해 복구를 위한 몇 가지 완화 방법이 있어야 합니다. 워크로드에 높은 안정성 목표가 요구되는 경우 완화 전략은 포괄적이어야 하며 가능성이 낮은 이벤트의 위험도 줄여야 합니다. 다른 워크로드의 경우 수락할 준비가 된 위험과 완화해야 하는 위험에 대해 정보에 입각한 결정을 내립니다.
복원력 요구 사항
RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 포함하여 워크로드에 대한 복원력 요구 사항을 이해하는 것이 중요합니다. 이러한 목표는 배제할 방법을 결정하는 데 도움이 됩니다. 명확한 요구 사항이 없는 경우 따라야 할 접근 방식에 대해 정보에 입각한 결정을 내릴 수 없습니다. 자세한 내용은 대상 기능 및 비기능 요구 사항을 참조 하세요.
서비스 수준 목표
솔루션의 예상 작동 시간 SLO(서비스 수준 목표)를 이해해야 합니다. 예를 들어 솔루션이 99.9%의 가동 시간을 충족해야 하는 비즈니스 요구 사항이 있을 수 있습니다.
Azure는 각 서비스에 대한 SLA(서비스 수준 계약)를 제공합니다. SLA는 서비스에서 예상해야 하는 가동 시간 수준과 예상되는 SLA를 달성하기 위해 충족해야 하는 조건을 나타냅니다. 그러나 Azure SLA가 서비스의 가용성을 나타내는 방식이 워크로드의 상태를 고려하는 방식과 항상 일치하지는 않습니다.
아키텍처 결정은 솔루션의 복합 SLO에 영향을 줍니다. 일반적으로 솔루션에 빌드하는 중복성이 높을수록 SLO가 높을 가능성이 높습니다. 많은 Azure 서비스는 영역 중복 또는 다중 지역 구성에서 서비스를 배포할 때 더 높은 SLA를 제공합니다. 서비스의 복원력 및 SLA를 최대화하는 방법을 이해하려면 사용하는 각 Azure 서비스에 대한 SLA를 검토합니다.
데이터 보존
일부 조직에서는 데이터를 저장하고 처리할 수 있는 물리적 위치에 제한을 줍니다. 경우에 따라 이러한 요구 사항은 법률 또는 규정 표준을 기반으로 합니다. 다른 상황에서는 조직에서 고객 문제를 방지하기 위해 데이터 보존 정책을 채택하기로 결정할 수 있습니다. 엄격한 데이터 상주 요구 사항이 있는 경우 단일 지역 배포를 사용하거나 Azure 지역 및 서비스의 하위 집합을 사용해야 할 수 있습니다.
참고 항목
데이터 보존 요구 사항에 대해 근거 없는 가정을 하지 않습니다. 특정 규제 표준을 준수해야 하는 경우 해당 표준이 실제로 지정하는 내용을 확인합니다.
사용자 위치
사용자가 어디에 있는지 이해하면 필요에 따라 대기 시간 및 안정성을 최적화하는 방법에 대해 정보에 입각한 결정을 내릴 수 있습니다. Azure는 지리적으로 분산된 사용자 기반을 지원하는 다양한 옵션을 제공합니다.
사용자가 한 영역에 집중된 경우 단일 지역 배포는 운영 요구 사항을 간소화하고 비용을 절감할 수 있습니다. 그러나 단일 지역 배포가 안정성 요구 사항을 충족하는지 여부를 고려해야 합니다. 중요 업무용 애플리케이션의 경우 사용자가 공동 배치된 경우에도 다중 지역 배포를 사용해야 합니다.
사용자가 지리적으로 분산된 경우 여러 지역에 워크로드를 배포하는 것이 합리적일 수 있습니다. Azure 서비스는 다중 지역 배포를 지원하기 위해 다양한 기능을 제공하며, Azure의 글로벌 공간을 사용하여 사용자 환경을 개선하고 애플리케이션을 사용자 기반과 더 가깝게 만들 수 있습니다. 배포 스탬프 패턴 또는 Geodes 패턴을 사용하거나 여러 지역에 리소스를 복제할 수 있습니다.
사용자가 다른 지리적 영역에 있더라도 다중 지역 배포가 필요한지 여부를 고려합니다. Azure Front Door에서 제공하는 가속과 같은 글로벌 트래픽 가속을 사용하여 단일 지역 내에서 요구 사항을 달성할 수 있는지 여부를 고려합니다.
예산
제한된 예산으로 작업하는 경우 중복 워크로드 구성 요소 배포와 관련된 비용을 고려해야 합니다. 이러한 비용에는 추가 리소스 요금, 네트워킹 비용 및 더 많은 리소스를 관리하는 운영 비용과 더 복잡한 환경이 포함될 수 있습니다.
복잡성
솔루션 아키텍처에서 불필요한 복잡성을 방지하는 것이 좋습니다. 복잡성이 많을수록 아키텍처에 대한 결정을 내리는 것이 더 어려워집니다. 복잡한 아키텍처는 작동하기 어렵고, 보안이 어렵고, 성능이 떨어지는 경우가 많습니다. 단순성의 원칙을 따릅니다.
Azure 촉진
Azure에서는 지역 및 가용성 영역을 제공하여 요구 사항에 맞는 배포 방법을 선택할 수 있습니다. 선택할 수 있는 여러 가지 방법이 있으며, 각 방법 중에서 이점을 제공하고 비용이 발생합니다.
사용할 수 있는 배포 방법을 보여 주려면 예제 시나리오를 고려해 보세요. 데이터를 일종의 스토리지에 쓰는 애플리케이션을 포함하는 새 솔루션을 배포하는 방법을 고려하고 있다고 가정해 보겠습니다.
이 예제는 특정 Azure 서비스에만 국한되지 않습니다. 기본 개념을 설명하는 간단한 예제를 제공하기 위한 것입니다.
이 솔루션을 배포하는 방법에는 여러 가지가 있습니다. 각 접근 방식은 다양한 이점 집합을 제공하며 다른 비용이 발생합니다. 높은 수준에서 로컬 중복, 영역(고정), 영역 중복 또는 다중 지역 배포를 고려할 수 있습니다. 이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 로컬 중복 | 영역(고정) | Zone-redundant | 다중 지역 |
|---|---|---|---|---|
| 안정성 | 낮은 안정성 | 접근 방식에 따라 다름 | 높거나 매우 높은 안정성 | 높거나 매우 높은 안정성 |
| 비용 최적화 | 저렴한 비용 | 접근 방식에 따라 다름 | 보통 비용 | 높은 비용 |
| 성능 효율성 | 허용되는 성능(대부분의 워크로드) | 고성능 | 허용되는 성능(대부분의 워크로드) | 접근 방식에 따라 다름 |
| 운영 우수성 | 낮은 운영 요구 사항 | 높은 운영 요구 사항 | 낮은 운영 요구 사항 | 높은 운영 요구 사항 |
이 표에는 사용할 수 있는 방법 중 일부와 아키텍처에 미치는 영향이 요약되어 있습니다.
| 아키텍처 문제 | 로컬 중복 | 영역(고정) | Zone-redundant | 다중 지역 |
|---|---|---|---|---|
| 데이터 보존 준수 | 높음 | 높음 | 높음 | 지역에 따라 다름 |
| 국가별 가용성 | 모든 지역 | 가용성 영역이 있는 지역 | 가용성 영역이 있는 지역 | 지역에 따라 다름 |
이 문서의 나머지 부분에는 앞의 표에 나열된 각 접근 방식에 대해 설명합니다. 방법 목록은 완전하지 않습니다. 여러 접근 방식을 결합하거나 솔루션의 여러 부분에서 다른 접근 방식을 사용하기로 결정할 수 있습니다.
배포 방법 1: 로컬 중복 배포
리소스를 배포할 때 여러 가용성 영역 또는 지역을 지정하지 않는 경우 Azure는 리소스가 단일 데이터 센터에 배포되는지 또는 지역의 여러 데이터 센터에 분할되는지에 대해 어떠한 보장도 하지 않습니다. 경우에 따라 Azure는 가용성 영역 간에 리소스를 이동할 수도 있습니다.
대부분의 Azure 리소스는 기본적으로 높은 SLA와 플랫폼에서 관리되는 데이터 센터 내의 기본 제공 중복성으로 고가용성입니다. 그러나 안정성 관점에서 지역 일부에서 중단이 발생하는 경우 워크로드가 영향을 받을 수 있습니다. 이 경우 솔루션을 사용할 수 없거나 데이터가 손실될 수 있습니다.
대기 시간이 매우 중요한 워크로드의 경우 이 방법을 사용하면 성능이 저하될 수도 있습니다. 워크로드 구성 요소가 동일한 데이터 센터에 공동 배치되지 않을 수 있으므로 지역 내 트래픽에 대한 대기 시간을 관찰할 수 있습니다. 또한 Azure는 가용성 영역 간에 서비스 인스턴스를 투명하게 이동할 수 있으며 이는 성능에 약간 영향을 줄 수 있습니다. 그러나 대부분의 워크로드에는 문제가 되지 않습니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 낮은 안정성. 데이터 센터가 실패하면 서비스가 중단될 수 있습니다. 그러나 다른 유형의 오류에 탄력적이 되도록 애플리케이션을 빌드할 수 있습니다. |
| 비용 최적화 | 최저 비용. 각 리소스의 단일 인스턴스만 있으면 되며 지역 간 대역폭 비용이 발생하지 않습니다. |
| 성능 효율성 | 대부분의 워크로드의 경우: 허용되는 성능입니다. 이 방법은 만족스러운 성능을 제공할 가능성이 높습니다. 대기 시간이 매우 중요한 워크로드의 경우: 성능이 낮습니다. 구성 요소는 동일한 가용성 영역에 있다고 보장되지 않으므로 대기 시간이 매우 중요한 구성 요소의 성능이 저하될 수 있습니다. |
| 운영 우수성 | 높은 운영 효율성. 각 리소스의 단일 인스턴스만 배포하고 관리하면 됩니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 높음. 이 방법을 사용하는 솔루션을 배포하면 선택한 Azure 지역에 데이터가 저장됩니다. |
| 국가별 가용성 | 높음. 이 방법은 모든 Azure 지역에서 사용할 수 있습니다. |
지역 간 백업을 사용하여 로컬 중복 배포
인프라 및 데이터의 정기적인 백업을 보조 지역으로 수행하여 로컬 중복 배포를 확장할 수 있습니다. 이 방법은 주 지역의 중단을 완화하기 위해 추가 보호 계층을 추가합니다. 다음과 같이 나타납니다.
이 방법을 구현할 때 RTO 및 RPO를 신중하게 고려해야 합니다.
- 복구 시간: 지역 가동 중단이 발생하는 경우 복구 시간에 영향을 미치는 다른 Azure 지역에서 솔루션을 다시 빌드해야 할 수 있습니다. 주요 재해가 발생할 경우 다른 지역에 신속하게 다시 배포할 수 있도록 IaC(Infrastructure-as-code) 접근 방식을 사용하여 솔루션을 빌드하는 것이 좋습니다. 배포 도구 및 프로세스가 애플리케이션과 마찬가지로 복원력이 있는지 확인하여 중단이 있더라도 솔루션을 다시 배포하는 데 사용할 수 있도록 합니다. 솔루션을 다시 작업 상태로 복원하는 데 필요한 단계를 계획하고 연습합니다.
- 복구 지점: 백업 빈도에 따라 발생할 수 있는 데이터 손실 양(복구 지점)이 결정됩니다. 일반적으로 RPO를 충족할 수 있도록 백업 빈도를 제어할 수 있습니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 보통 안정성. 데이터 센터가 실패하면 서비스가 중단될 수 있습니다. 데이터는 지리적으로 구분된 지역에 비동기적으로 백업되므로 데이터 손실을 최소화하여 전체 지역 중단의 영향을 줄일 수 있습니다. 전체 지역 가동 중단 시 작업을 다른 지역으로 수동으로 복원할 수 있습니다. 그러나 복구 프로세스는 복잡할 수 있으며 다른 지역으로 수동으로 복원하는 데 시간이 걸릴 수 있습니다. |
| 비용 최적화 | 저가. 일반적으로 다른 지역에 백업을 추가하면 로컬 중복 리소스를 배포하는 것보다 약간 더 많은 비용이 듭니다. |
| 성능 효율성 | 대부분의 워크로드의 경우: 허용되는 성능입니다. 이 방법은 만족스러운 성능을 제공할 가능성이 높습니다. 대기 시간이 매우 중요한 워크로드의 경우: 성능이 낮습니다. 구성 요소는 동일한 가용성 영역에 있다고 보장되지 않으므로 대기 시간이 매우 중요한 구성 요소의 성능이 저하될 수 있습니다. |
| 운영 우수성 | 지역 내 가동 중단 시: 운영 효율성이 낮습니다. 장애 조치(failover)는 사용자의 책임이며 수동 작업 및 재배포가 필요할 수 있습니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 지역 선택에 따라 달라집니다. 데이터는 주로 사용자가 지정한 Azure 지역에 저장됩니다. 그러나 백업을 저장할 다른 지역을 선택해야 하므로 데이터 보존 요구 사항과 호환되는 지역을 선택하는 것이 중요합니다. |
| 국가별 가용성 | 높음. 모든 Azure 지역에서 이 방법을 사용할 수 있습니다. |
배포 방법 2: 영역(고정) 배포
영역 배포에서는 리소스를 특정 가용성 영역에 배포하도록 지정합니다. 이 방법을 영역 고정 배포라고도 합니다.
영역 접근 방식을 사용하면 구성 요소 간의 대기 시간이 줄어듭니다. 그러나 그 자체로 솔루션의 복원력을 증가하지는 않습니다. 복원력을 높이려면 구성 요소의 여러 인스턴스를 여러 가용성 영역에 배포하고 각 인스턴스 간에 트래픽을 라우팅하는 방법을 결정해야 합니다. 이 예제에서는 활성-수동 트래픽 라우팅 방법을 보여 줍니다.
이전 예제에서 부하 분산 장치는 여러 가용성 영역에 배포됩니다. 영역 중단이 해당 영역에 배포된 네트워킹 리소스에도 영향을 줄 수 있으므로 다른 가용성 영역의 인스턴스 간에 트래픽을 라우팅하는 방법을 고려하는 것이 중요합니다. Azure Front Door 또는 Azure Traffic Manager와 같은 전역 부하 분산 장치를 사용하는 것도 고려할 수 있습니다. 이 분산 장치는 지역에 전혀 배포되지 않습니다.
영역 배포 모델을 사용하는 경우 다음과 같은 많은 책임을 맡게 됩니다.
- 각 가용성 영역에 리소스를 배포하고 해당 리소스를 개별적으로 구성하고 관리해야 합니다.
- 가용성 영역 간에 데이터를 복제하는 방법과 시기를 결정한 다음 복제를 구성하고 관리해야 합니다.
- 예를 들어 부하 분산 장치를 사용하여 요청을 올바른 리소스에 배포할 책임이 있습니다. 부하 분산 장치가 복원력 요구 사항을 충족하는지 확인해야 합니다. 또한 활성-수동 또는 활성-활성 요청 배포 모델을 사용할지 여부를 결정해야 합니다.
- 가용성 영역에서 중단이 발생하는 경우 다른 가용성 영역의 리소스로 트래픽을 보내기 위해 장애 조치(failover)를 처리해야 합니다.
여러 가용성 영역에 대한 활성-수동 배포를 지역 내 DR 또는 Metro DR이라고도 합니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 단일 가용성 영역에 배포되는 경우: 낮은 안정성. 영역 배포는 데이터 센터 또는 가용성 영역의 중단에 대한 복원력을 제공하지 않습니다. 높은 복원력을 얻으려면 여러 가용성 영역에 중복 리소스를 배포해야 합니다. 여러 가용성 영역에 배포된 경우: 높은 안정성. 서비스는 데이터 센터 또는 가용성 영역 중단에 대한 복원력을 설정할 수 있습니다. |
| 비용 최적화 | 단일 가용성 영역에 배포되는 경우: 저렴한 비용입니다. 단일 영역 배포에는 각 리소스의 단일 인스턴스만 필요합니다. 여러 가용성 영역에 배포되는 경우: 높은 비용. 리소스의 여러 인스턴스를 배포합니다. 각 인스턴스는 별도로 청구됩니다. |
| 성능 효율성 | 고성능. 요청을 제공하는 구성 요소가 동일한 가용성 영역에 있는 경우 대기 시간이 매우 짧을 수 있습니다. |
| 운영 우수성 | 낮은 운영 효율성. 서비스의 여러 인스턴스를 구성하고 관리해야 합니다. 가용성 영역 간에 데이터를 복제해야 합니다. 가용성 영역 중단 시 장애 조치(failover)는 사용자의 책임입니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 높음. 이 방법을 사용하는 솔루션을 배포하면 선택한 Azure 지역에 데이터가 저장됩니다. |
| 국가별 가용성 | 가용성 영역이 있는 지역입니다. 이 방법은 가용성 영역을 지원하는 모든 지역에서 사용할 수 있습니다. |
이 방법은 일반적으로 가상 머신을 기반으로 하는 워크로드에 사용됩니다. 영역 배포를 지원하는 서비스의 전체 목록은 가용성 영역 서비스 및 지역 지원을 참조하세요.
영역 배포를 계획할 때 사용하려는 Azure 서비스가 사용하려는 가용성 영역에서 지원되는지 확인합니다. 예를 들어 각 가용성 영역에서 사용할 수 있는 가상 머신 SKU를 나열하려면 VM SKU 가용성 확인을 참조 하세요.
팁
특정 가용성 영역에 리소스를 배포할 때 영역 번호를 선택합니다. 영역 번호의 시퀀스는 Azure 구독마다 다릅니다. 여러 Azure 구독에 리소스를 배포하는 경우 각 구독에서 사용해야 하는 영역 번호를 확인합니다. 자세한 내용은 물리적 및 논리적 가용성 영역을 참조하세요.
배포 방법 3: 영역 중복 배포
이 방법을 사용하면 애플리케이션 계층이 여러 가용성 영역에 분산됩니다. 요청이 도착하면 서비스에 기본 제공되는 부하 분산 장치(자체 가용성 영역에 걸쳐)는 각 가용성 영역의 인스턴스 간에 요청을 분산합니다. 가용성 영역에서 중단이 발생하는 경우 부하 분산 장치는 트래픽을 정상 가용성 영역의 인스턴스로 전달합니다.
스토리지 계층도 여러 가용성 영역에 분산됩니다. 애플리케이션 데이터의 복사본은 동기 복제를 통해 여러 가용성 영역에 분산됩니다. 애플리케이션이 데이터를 변경하면 스토리지 서비스는 여러 가용성 영역에 변경 내용을 기록하고 트랜잭션은 이러한 모든 변경이 완료된 경우에만 완료된 것으로 간주됩니다. 이 프로세스는 각 가용성 영역에 항상 데이터의 최신 복사본이 있는지 확인합니다. 가용성 영역에서 중단이 발생하는 경우 다른 가용성 영역을 사용하여 동일한 데이터에 액세스할 수 있습니다.
영역 중복 접근 방식은 데이터 센터 중단과 같은 문제에 대한 솔루션의 복원력을 높입니다. 그러나 데이터가 동기적으로 복제되기 때문에 애플리케이션은 수도권의 다른 부분에 있을 수 있는 여러 개별 위치에 데이터가 기록될 때까지 기다려야 합니다. 대부분의 애플리케이션에서 영역 간 통신에 관련된 대기 시간은 무시할 수 있습니다. 그러나 대기 시간이 매우 중요한 일부 워크로드의 경우 가용성 영역 간 동기 복제가 애플리케이션의 성능에 영향을 줄 수 있습니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 높은 안정성. 서비스는 데이터 센터 또는 가용성 영역의 중단에 복원력이 있습니다. 데이터는 가용성 영역에서 동기적으로 복제되며 지연 없이 복제됩니다. |
| 비용 최적화 | 보통 비용. 사용하는 서비스에 따라 더 높은 서비스 계층에 대해 영역 중복을 사용하도록 설정하는 데 약간의 비용이 발생할 수 있습니다. |
| 성능 효율성 | 대부분의 워크로드의 경우: 허용되는 성능입니다. 이 방법은 만족스러운 성능을 제공할 가능성이 높습니다. 대기 시간이 매우 중요한 워크로드의 경우: 성능이 낮습니다. 일부 구성 요소는 영역 간 트래픽 또는 데이터 복제 시간으로 인해 대기 시간에 민감할 수 있습니다. |
| 운영 우수성 | 높은 운영 효율성. 일반적으로 각 리소스의 단일 논리 인스턴스만 관리해야 합니다. 대부분의 서비스의 경우 가용성 영역 중단 시 장애 조치(failover)는 Microsoft의 책임이며 자동으로 발생합니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 높음. 이 방법을 사용하는 솔루션을 배포하면 선택한 Azure 지역에 데이터가 저장됩니다. |
| 국가별 가용성 | 가용성 영역이 있는 지역입니다. 이 방법은 가용성 영역을 지원하는 모든 지역에서 사용할 수 있습니다. |
이 방법은 Azure Virtual Machine Scale Sets, Azure 앱 Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus 등을 비롯한 많은 Azure 서비스에서 가능합니다. 영역 중복을 지원하는 서비스의 전체 목록은 가용성 영역 서비스 및 지역 지원을 참조하세요.
지역 간 백업을 사용하는 영역 중복 배포
인프라 및 데이터의 정기적인 백업을 보조 지역으로 수행하여 영역 중복 배포를 확장할 수 있습니다. 이 방법은 영역 중복 접근 방식의 이점을 제공하고 보호 계층을 추가하여 전체 지역 중단이 발생할 가능성이 매우 낮은 이벤트를 완화합니다.
이 방법을 구현할 때 RTO 및 RPO를 신중하게 고려해야 합니다.
복구 시간: 지역 가동 중단이 발생하는 경우 복구 시간에 영향을 미치는 다른 Azure 지역에서 솔루션을 다시 빌드해야 할 수 있습니다. 주요 재해 발생 시 다른 지역으로 신속하게 다시 배포할 수 있도록 IaC 접근 방식을 사용하여 솔루션을 빌드하는 것이 좋습니다. 중단이 발생하더라도 솔루션을 다시 배포하는 데 사용할 수 있도록 배포 도구 및 프로세스가 애플리케이션과 마찬가지로 복원력이 있는지 확인합니다. 솔루션을 다시 작업 상태로 복원하는 데 필요한 단계를 계획하고 연습합니다.
복구 지점: 백업 빈도에 따라 발생할 수 있는 데이터 손실 양(복구 지점)이 결정됩니다. 일반적으로 RPO에 맞게 백업 빈도를 제어할 수 있습니다.
팁
이 접근 방식은 종종 모든 아키텍처 문제에 적절한 균형을 제공합니다. 어떤 방법을 사용할지 잘 모르는 경우 이 유형의 배포로 시작합니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 매우 높은 안정성. 서비스는 데이터 센터 또는 가용성 영역의 중단에 복원력이 있습니다. 대부분의 서비스에서 데이터는 영역 간에 자동으로 복제되며 지연 없이 복제됩니다. 데이터는 지리적으로 구분된 지역에 비동기적으로 백업됩니다. 이 백업은 데이터 손실을 최소화하여 전체 지역 중단의 영향을 줄입니다. 전체 지역 가동 중단 후 작업을 다른 지역으로 수동으로 복원할 수 있습니다. 그러나 복구 프로세스는 복잡할 수 있으며 다른 지역으로 수동으로 복원하는 데 시간이 걸릴 수 있습니다. |
| 비용 최적화 | 보통 비용. 일반적으로 다른 지역에 백업을 추가하면 영역 중복을 구현하는 것보다 약간 더 많은 비용이 듭니다. |
| 성능 효율성 | 대부분의 워크로드의 경우: 허용되는 성능입니다. 이 방법은 만족스러운 성능을 제공할 가능성이 높습니다. 대기 시간이 매우 중요한 워크로드의 경우: 성능이 낮습니다. 일부 구성 요소는 영역 간 트래픽 또는 데이터 복제 시간으로 인해 대기 시간에 민감할 수 있습니다. |
| 운영 우수성 | 가용성 영역 중단 중: 높은 운영 효율성. 장애 조치(failover)는 Microsoft의 책임이며 자동으로 수행됩니다. 지역 가동 중단 시: 운영 효율성이 낮습니다. 장애 조치(failover)는 사용자의 책임이며 수동 작업 및 재배포가 필요할 수 있습니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 지역 선택에 따라 달라집니다. 데이터는 주로 지정한 Azure 지역에 저장되지만 백업을 저장할 다른 지역을 선택해야 합니다. 데이터 상주 요구 사항과 호환되는 지역을 선택합니다. |
| 국가별 가용성 | 가용성 영역이 있는 지역입니다. 이 방법은 가용성 영역을 지원하는 모든 지역에서 사용할 수 있습니다. |
배포 방법 4: 다중 지역 배포
여러 Azure 지역을 함께 사용하여 광범위한 지리적 영역에 솔루션을 배포할 수 있습니다. 이 다중 지역 접근 방식을 사용하여 솔루션의 안정성을 개선하거나 지리적으로 분산된 사용자를 지원할 수 있습니다. 여러 지역에 배포하면 단일 지역에서 임시 리소스 용량 제약 조건이 발생할 위험을 줄일 수도 있습니다. 데이터 보존이 솔루션의 중요한 관심사인 경우 요구 사항을 충족하는 위치에만 데이터가 저장되도록 하는 데 사용하는 지역을 신중하게 고려합니다.
활성 및 수동 지역
다중 지역 아키텍처는 복잡하며 여러 가지 방법으로 다중 지역 솔루션을 설계할 수 있습니다. 일부 워크로드의 경우 여러 지역이 동시에 요청을 적극적으로 처리하도록 하는 것이 좋습니다(활성-활성 배포). 다른 워크로드의 경우 하나의 주 지역을 지정하고 장애 조치(failover)(활성-수동 배포)에 하나 이상의 보조 지역을 사용하는 것이 좋습니다. 이 섹션에서는 한 지역이 활성 상태이고 다른 지역이 수동인 두 번째 시나리오에 중점을 둡니다. 활성-활성 다중 지역 솔루션에 대한 자세한 내용은 배포 스탬프 패턴 및 지오데 패턴을 참조하세요.
데이터 복제
지역 간 통신은 지역 내에서 통신하는 것보다 훨씬 느립니다. 일반적으로 두 지역 간의 지리적 거리가 크면 데이터가 이동해야 하는 물리적 거리가 길기 때문에 네트워크 대기 시간이 더 많이 발생합니다. 두 지역 간에 연결할 때 예상되는 네트워크 대기 시간에 대한 Azure 네트워크 왕복 대기 시간 통계를 참조하세요.
지역 간 네트워크 대기 시간은 추가 대기 시간이 데이터 복제 및 기타 트랜잭션에 미치는 영향을 신중하게 고려해야 하기 때문에 솔루션 디자인에 큰 영향을 줄 수 있습니다. 많은 솔루션의 경우 지역 간 아키텍처를 사용하려면 지역 간 트래픽이 성능에 미치는 영향을 최소화하기 위해 비동기 복제가 필요합니다.
비동기 데이터 복제
지역 간에 비동기 복제를 구현하는 경우 애플리케이션은 모든 지역에서 변경 내용을 승인할 때까지 기다리지 않습니다. 주 지역에서 변경 내용이 커밋되면 트랜잭션이 완료된 것으로 간주됩니다. 변경 내용은 나중에 보조 지역에 복제됩니다. 이 방법을 사용하면 지역 간 연결 대기 시간이 애플리케이션 성능에 직접적인 영향을 주지 않습니다. 그러나 복제 지연으로 인해 지역 전체의 중단으로 인해 일부 데이터가 손실될 수 있습니다. 이 데이터 손실은 주 지역에서 쓰기가 완료된 후 다른 지역에 변경 내용을 복제하기 전에 지역이 중단될 수 있기 때문에 발생할 수 있습니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 높은 안정성. 이 솔루션은 데이터 센터, 가용성 영역 또는 전체 지역의 중단에 탄력적입니다. 데이터는 복제되지만 동기식이 아닐 수 있으므로 장애 조치(failover) 시나리오에서 일부 데이터 손실이 발생할 수 있습니다. |
| 비용 최적화 | 높은 비용. 각 지역에 별도의 리소스를 배포해야 하며 각 리소스에는 배포 및 유지 관리 비용이 발생합니다. 지역 간 데이터 복제로 인해 상당한 비용이 발생할 수도 있습니다. |
| 성능 효율성 | 고성능. 애플리케이션 요청에는 지역 간 트래픽이 필요하지 않으므로 트래픽은 일반적으로 대기 시간이 짧습니다. |
| 운영 우수성 | 낮은 운영 효율성. 여러 지역에 걸쳐 리소스를 배포하고 관리해야 합니다. 또한 지역 가동 중단 시 지역 간 장애 조치(failover)를 담당합니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 지역 선택에 따라 달라집니다. 이 방법을 사용하려면 워크로드가 실행되도록 여러 지역을 선택해야 합니다. 데이터 상주 요구 사항과 호환되는 지역을 선택합니다. |
| 국가별 가용성 | 많은 Azure 지역이 쌍으로 연결됩니다. 일부 Azure 서비스는 쌍을 이루는 지역을 사용하여 데이터를 자동으로 복제합니다. 쌍이 없는 지역에서 워크로드를 실행하는 경우 다른 방법을 사용하여 데이터를 복제해야 할 수 있습니다. |
동기 데이터 복제
동기 다중 지역 솔루션을 구현하는 경우 트랜잭션이 완료된 것으로 간주되기 전에 애플리케이션이 각 Azure 지역에서 쓰기 작업이 완료될 때까지 기다려야 합니다. 쓰기 작업을 대기하여 발생하는 대기 시간은 지역 간의 거리에 따라 달라집니다. 많은 워크로드의 경우 지역 간 대기 시간으로 인해 동기 복제 속도가 너무 느려 유용할 수 없습니다.
이 표에서는 몇 가지 주요 문제를 요약합니다.
| 핵심 요소 | 영향 |
|---|---|
| 안정성 | 매우 높은 안정성. 이 솔루션은 데이터 센터, 가용성 영역 또는 전체 지역의 중단에 탄력적입니다. 데이터는 항상 지역 간에 동기화되므로 전체 지역 손실이 발생하더라도 다른 지역에서 데이터를 사용할 수 있고 완료됩니다. |
| 비용 최적화 | 높은 비용. 각 지역에 별도의 리소스를 배포해야 하며 각 리소스에는 배포 및 유지 관리 비용이 발생합니다. 지역 간 데이터 복제로 인해 상당한 비용이 발생할 수도 있습니다. |
| 성능 효율성 | 성능이 낮습니다. 애플리케이션 요청에는 지역 간 트래픽이 필요합니다. 지역 간 거리에 따라 동기 복제는 요청에 상당한 대기 시간을 추가할 수 있습니다. |
| 운영 우수성 | 낮은 운영 효율성. 여러 지역에 걸쳐 리소스를 배포하고 관리해야 합니다. 또한 지역 가동 중단 시 지역 간 장애 조치(failover)를 담당합니다. |
이 표에서는 아키텍처 관점에서 몇 가지 문제를 요약합니다.
| 아키텍처 문제 | 영향 |
|---|---|
| 데이터 보존 준수 | 지역 선택에 따라 달라집니다. 이 방법을 사용하려면 워크로드가 실행되도록 여러 지역을 선택해야 합니다. 데이터 상주 요구 사항과 호환되는 지역을 선택합니다. |
| 국가별 가용성 | 많은 Azure 지역이 쌍으로 연결됩니다. 일부 Azure 서비스는 쌍을 이루는 지역을 사용하여 데이터를 자동으로 복제합니다. 쌍이 없는 지역에서 워크로드를 실행하는 경우 다른 방법을 사용하여 데이터를 복제해야 할 수 있습니다. |
지역 아키텍처
다중 지역 솔루션을 디자인할 때 사용하려는 Azure 지역이 쌍을 이루는지 여부를 고려합니다.
지역이 페어링되지 않은 경우에도 다중 지역 솔루션을 만들 수 있습니다. 그러나 다중 지역 아키텍처를 구현하는 데 사용하는 접근 방식은 다를 수 있습니다. 예를 들어 Azure Storage에서 GRS(지역 중복 스토리지)를 쌍을 이루는 지역과 함께 사용할 수 있습니다. GRS를 사용할 수 없는 경우 Azure Storage 개체 복제와 같은 기능을 사용하거나 여러 지역에 쓰도록 애플리케이션을 디자인하는 것이 좋습니다.
다중 영역 및 다중 지역 접근 방식 결합
비즈니스 요구 사항에 이러한 솔루션이 요구되는 경우 다중 영역 및 다중 지역 문을 결합해야 합니다. 예를 들어 영역 중복 구성 요소를 각 지역에 배포하고 지역 간에 복제를 구성할 수도 있습니다. 일부 솔루션의 경우 이 방법은 매우 높은 수준의 안정성을 제공합니다. 그러나 이러한 유형의 접근 방식을 구성하는 것은 복잡할 수 있으며 이 방법은 비용이 많이 들 수 있습니다.
Important
중요 업무용 워크로드는 여러 가용성 영역 과 여러 지역을 모두 사용해야 합니다. 중요 업무용 워크로드를 디자인할 때 고려해야 하는 고려 사항에 대한 자세한 내용은 중요 업무용 워크로드 설명서를 참조 하세요.
Azure 서비스에서 배포 방법을 지원하는 방법
사용하는 Azure 서비스의 특정 세부 정보를 이해하는 것이 중요합니다. 예를 들어 일부 Azure 서비스는 리소스를 처음 배포할 때 해당 가용성 영역 구성을 구성해야 하는 반면, 다른 서비스는 나중에 배포 접근 방식 변경을 지원해야 합니다. 마찬가지로 일부 서비스 기능은 모든 배포 접근 방식에서 사용할 수 없을 수 있습니다.
각 Azure 서비스에 대해 고려할 특정 배포 옵션 및 접근 방식에 대해 자세히 알아보려면 안정성 허브를 방문하세요.
예제
이 섹션에서는 일반적으로 각 워크로드에 대해 고려해야 하는 몇 가지 일반적인 사용 사례 및 주요 요구 사항에 대해 설명합니다. 각 워크로드에 대해 이 문서에 설명된 요구 사항 및 접근 방식에 따라 하나 이상의 제안된 배포 방법이 제공됩니다.
엔터프라이즈용 기간 업무 애플리케이션
Contoso, Ltd.는 대형 제조 회사입니다. 이 회사는 재무 프로세스의 일부 구성 요소를 관리하는 기간 업무 애플리케이션을 구현하고 있습니다.
비즈니스 요구 사항: 시스템에서 관리하는 정보는 대체하기 어렵기 때문에 데이터를 안정적으로 유지해야 합니다. 설계자는 시스템이 가동 중지 시간을 적게 발생시키고 가능한 한 적은 데이터 손실을 초래해야 한다고 말합니다. Contoso의 직원은 작업 시간 내내 시스템을 사용하므로 팀 구성원이 대기하는 것을 방지하기 위해 고성능이 중요합니다. 재무 팀이 솔루션 비용을 지불해야 하기 때문에 비용도 중요합니다.
제안된 접근 방식: 지역 간 백업을 사용한 영역 중복 배포는 고성능을 통해 여러 계층의 복원력을 제공합니다.
내부 애플리케이션
네 번째 커피는 중소기업입니다. 이 회사는 직원이 작업표를 제출하는 데 사용할 수 있는 새로운 내부 애플리케이션을 개발하고 있습니다.
비즈니스 요구 사항: 이 워크로드의 경우 비용 효율성이 주요 관심사입니다. Fourth Coffee는 가동 중지 시간의 비즈니스 영향을 평가하고 애플리케이션이 복원력 또는 성능의 우선 순위를 지정할 필요가 없다고 결정했습니다. 회사는 Azure 가용성 영역 또는 지역의 중단으로 인해 애플리케이션을 일시적으로 사용할 수 없게 될 위험이 있습니다.
제안된 방법:
- 지역 간 백업을 사용하는 로컬 중복 배포는 비용이 가장 낮지만 상당한 위험이 있습니다.
- 지역 간 백업을 사용한 영역 중복 배포는 복원력이 향상되지만 약간 더 높은 비용을 제공합니다.
레거시 애플리케이션 마이그레이션
Fabrikam, Inc.는 레거시 애플리케이션을 온-프레미스 데이터 센터에서 Azure로 마이그레이션하고 있습니다. 구현은 가상 머신을 기반으로 하는 IaaS 접근 방식을 사용합니다. 애플리케이션은 클라우드 환경을 위해 설계되지 않았으며 애플리케이션 계층과 데이터베이스 간의 통신은 매우 수다스럽습니다.
비즈니스 요구 사항: 성능은 이 애플리케이션의 우선 순위입니다. 복원력도 중요하며, Azure 데이터 센터에서 중단이 발생하는 경우에도 애플리케이션이 계속 작동해야 합니다.
제안된 접근 방식:
- Fabrikan은 먼저 영역 중복 배포를 시도해야 합니다. 성능이 요구 사항을 충족하는지 확인해야 합니다.
- 영역 중복 솔루션의 성능이 허용되지 않는 경우 여러 가용성 영역(지역 내 DR)에서 수동 배포를 사용하는 영역(고정된) 배포를 고려합니다.
의료 애플리케이션
Lamna Healthcare Company는 Azure에서 새로운 전자 건강 기록 시스템을 구현하고 있습니다.
비즈니스 요구 사항: 이 솔루션이 저장하는 데이터의 특성 때문에 데이터 보존이 매우 중요합니다. Lamna는 데이터가 특정 위치에 유지되어야 하는 엄격한 규제 프레임워크에 따라 작동합니다.
제안된 방법:
- Lamna의 데이터 상주 요구 사항에 맞는 여러 지역이 있는 경우 다중 영역 다중 지역 배포
- 요구 사항에 맞는 단일 지역만 있는 경우 지역 간 백업을 사용하여 영역 중복 배포 또는 영역 중복 배포가 단일 지역 솔루션을 제공하는 것을 고려합니다 .
은행 시스템
Woodgrove Bank는 Azure에 배포된 대규모 솔루션에서 핵심 뱅킹 작업을 실행합니다.
비즈니스 요구 사항: 중요 업무용 시스템입니다. 중단이 발생하면 고객에게 큰 재정적 영향을 줄 수 있습니다. 그 결과, Woodgrove Bank는 위험 내성이 매우 낮습니다. 시스템에는 가능한 가장 높은 수준의 안정성이 필요하며 아키텍처는 완화할 수 있는 오류의 위험을 완화해야 합니다.
제안된 접근 방식: 중요 업무용 시스템의 경우 다중 영역 다중 지역 배포를 사용합니다. 지역이 회사의 데이터 상주 요구 사항에 맞는지 확인합니다.
서비스로서의 소프트웨어(SaaS)
Proseware, Inc.는 전 세계 회사에서 사용하는 소프트웨어를 빌드합니다. 회사의 사용자 기반은 지리적으로 널리 분산되어 있습니다.
비즈니스 요구 사항: Proseware는 각 고객이 고객과 가까운 배포 지역을 선택할 수 있도록 해야 합니다. 이 선택을 사용하도록 설정하는 것은 대기 시간 및 고객의 데이터 상주 요구 사항에 중요합니다.
제안된 방법:
- 다중 영역 다중 지역 배포는 특히 배포 스탬프 패턴 내에서 사용되는 경우 SaaS 공급자에게 좋은 선택입니다.
- Azure Front Door와 같은 글로벌 트래픽 가속 솔루션과 함께 단일 지역 영역 중복 배포
관련 링크
다음은 다중 영역 및 다중 지역 솔루션에 대한 몇 가지 참조 아키텍처 및 예제 시나리오입니다.
많은 Azure 서비스는 다음 예제를 포함하여 여러 가용성 영역을 사용하는 방법에 대한 지침을 제공합니다.
- Azure Site Recovery: 가용성 영역 간에 Azure VM 재해 복구 사용
- Azure NetApp Files: Azure NetApp Files의 영역 간 복제 이해
- Azure Storage 중복성
안정성 검사 목록
전체 권장 사항 집합을 참조하세요.