영역 리소스 및 영역 복원력

Azure에서 영역 리소스는 단일 영역에 고정된 리소스입니다. 영역 리소스는 단일 가용성 영역에 있으므로 영역 복원력이 없습니다. 리소스가 포함된 영역에 문제가 있으면 리소스에 가동 중지 시간이 발생할 수 있습니다.

일부 Azure 서비스에서는 영역 리소스를 배포해야 하거나 배포할 수 있는 경우가 있습니다. 대기 시간 고려 사항 또는 특정 서비스 요구 사항으로 인해 리소스를 영역별로 배포하도록 선택할 수 있습니다. 개별 리소스 또는 관련 리소스 집합을 단일 영역에 고정할 수 있습니다.

이 문서에서는 영역 중복 리소스 대신 영역 리소스를 배포하도록 선택할 수 있는 시나리오를 간략하게 설명합니다. 또한 솔루션이 영역 중단에 대한 복원력을 유지할 수 있도록 하는 데 필요한 고려 사항 및 책임을 강조합니다.

리소스 배포 유형

Azure에서는 일부 배포 유형만 영역 복원력을 제공합니다. 다음 표에서는 세 가지 리소스 배포 유형을 비교하고 영역 복원력, 영역 배포, 구성 옵션 및 권장 사항을 설명합니다.

가용성 영역 및 리소스 배포에 대한 자세한 내용은 가용성 영역을 참조하세요.

영역 중복 및 영역 전용 리소스를 결합하는 워크로드

많은 워크로드가 영역 중복 리소스와 영역 별 리소스를 결합합니다. 예를 들어 워크로드에는 데이터베이스 계층에 대한 영역 VM(가상 머신) 집합, Azure App Service에서 호스트되는 영역 중복 웹 서버 및 데이터베이스 VM에 트래픽을 보내는 영역 중복 부하 분산 장치가 포함될 수 있습니다.

워크로드에서 영역 및 영역 중복 리소스를 결합하는 경우 가용성 영역에 문제가 있는 경우 각 리소스와 전체 솔루션의 작동 방식을 고려합니다. 일반적으로 영역 중복 서비스는 최소 데이터 손실이나 데이터 손실 없이 영역 중단으로부터 자동으로 복구되며, Microsoft에서 전체 프로세스를 관리합니다. 영역 리소스의 경우 자동화된 장애 조치(failover)를 구성하거나 수동 복구 작업을 수행해야 합니다. 영역 다운 시나리오에서 각 서비스가 어떻게 동작하는지 알아보려면 책임과 Microsoft 책임에 대해 이해하고 영역 다운 이벤트 중에 서비스의 상태를 모니터링하려면 서비스의 안정성 가이드를 참조하세요.

영역 배포를 사용하는 경우

명확한 필요성이 있는 경우에만 영역 리소스를 사용합니다. 단일 영역 배포의 일반적인 원인으로는 리소스가 영역이어야 하거나, 특정 영역에서만 서비스를 사용할 수 있거나, 워크로드가 영역 간 대기 시간에 매우 중요한 경우가 있습니다.

영역 배포가 필요한 리소스

일부 Azure 서비스는 영역 배포만 지원하며 영역 중복 배포를 제공하지 않습니다.

VM은 영역 리소스입니다. 가상 머신 확장 집합을 사용하여 VM 집합을 만들 수 있습니다. Virtual Machine Scale Sets는 영역 스패닝으로 구성할 수 있습니다. 즉, 스케일 세트 내 VM이 여러 영역에 분산됩니다. 확장 집합은 많은 VM 기반 워크로드에 대한 영역 복원력을 달성하는 좋은 방법입니다.

또 다른 예로 볼륨을 단일 영역으로 배포할 수 있는 Azure NetApp Files가 있습니다. 또한 이 서비스는 여러 영역 볼륨 간에 복제할 수 있는 방법을 제공합니다.

일부 서비스는 특정 영역에서만 사용할 수 있는 옵션을 제공합니다. 예를 들어 GPU(고급 그래픽 처리 장치)를 사용하는 특정 VM 유형은 지역 내의 특정 영역에서만 사용할 수 있습니다. 즉, 여러 영역에 배포할 수 없습니다. 필요한 VM 유형을 지원하는 지역 및 영역을 확인하려면 다음 리소스를 사용합니다.

• 각 지역에서 사용할 수 있는 VM 유형을 확인하려면 지역별 사용 가능한 제품을 참조하세요.

• 특정 지역의 각 영역 내에서 지원되는 VM 유형 및 크기를 확인하려면 VM SKU 가용성 확인을 참조하세요.

필요한 VM 유형이 사용하는 지역 내의 단일 영역에서만 사용할 수 있는 경우 해당 VM에 대한 영역 배포를 고려한 다음 VM을 영역 중단에 복원할 수 있는 다른 방법을 찾을 수 있습니다. 그러나 솔루션의 다른 부분이 영역 복원력이 있는지 계속 확인해야 합니다.

자세한 내용은 가용성 영역을 지원하는 Azure 서비스를 참조하세요.

영역 간 대기 시간

비정상적으로 대기 시간이 중요한 워크로드가 있는 경우 서비스가 영역 중복 배포를 지원하는 경우에도 영역 중복 리소스 대신 영역 리소스를 사용할 수 있습니다.

대기 시간이 짧은 네트워크는 가용성 영역을 연결하며, 영역 간 왕복 대기 시간은 일반적으로 2밀리초 미만입니다. 대부분의 워크로드에서 영역 간 대기 시간은 문제가 되지 않습니다. 가용성 영역 간에 리소스를 분산하는 복원력 이점은 영역 간에 트래픽을 보내는 최소 성능 영향보다 더 중요합니다. 그러나 일부 워크로드는 영역 간 대기 시간에 매우 민감합니다. 이러한 워크로드에는 다음 시나리오가 포함될 수 있습니다.

• 레거시 온-프레미스 애플리케이션: 일부 레거시 워크로드에는 원래 온-프레미스 환경을 위해 설계된 애플리케이션이 포함될 수 있습니다. 이러한 워크로드는 데이터베이스 및 기타 애플리케이션 및 서비스와 같은 구성 요소가 동일한 호스트 또는 가까운 물리적 근접 위치에 배치되어 있다고 가정합니다.

• 매우 대규모 동기 복제: 상태 저장 애플리케이션 및 데이터베이스는 때때로 동기 복제를 사용하여 매우 많은 수의 쓰기를 수행합니다. 동기 복제는 쓰기 작업이 완료된 것으로 간주되기 전에 데이터가 여러 복제본 에 기록됨을 의미합니다. 가용성 영역에 복제본을 배포하면 복원력이 향상되지만 동기 복제를 사용하면 영역 간 대기 시간이 워크로드의 쓰기 대기 시간을 증가시킬 수 있습니다. 이 증가된 대기 시간은 일반적으로 중요하지 않지만 일부 애플리케이션을 설계하는 방법 때문에 경우에 따라 대규모로 문제가 될 수 있습니다.

영역 간 대기 시간이 워크로드에 영향을 주는 것으로 의심되는 경우 특정 워크로드에 대해 다음 단계를 수행하여 실제 환경에서 영향을 테스트합니다.

1. 허용되는 성능 요구 사항을 정의합니다. 영역 간 트래픽은 약간의 대기 시간을 추가하지만 대부분의 워크로드에서는 무시할 수 있습니다. 워크로드에 적절한 성능을 정의하십시오.

2. 단일 가용성 영역 내에서 성능 테스트를 실행합니다. 기준 성능 메트릭 집합을 설정합니다.

   중요합니다

   애플리케이션, 프로토콜, 구성 및 Azure 지역을 포함하여 워크로드를 테스트합니다. 실제 부하를 사용합니다. 벤치마크 및 가상 테스트는 솔루션이 실제로 작동하는 방식을 보여주지 않기 때문에 충분하지 않습니다.

3. 영역 간 복제를 사용하도록 설정합니다. 사용하는 구성 요소에 따라 영역 중복을 사용하도록 설정하거나 영역 간에 복제본을 이동할 수 있습니다.

4. 성능 테스트를 다시 실행합니다. 이전에 수집한 것과 동일한 메트릭을 수집합니다.

5. 요구 사항과 성능 영향을 비교합니다. 요구 사항 및 성능 데이터를 사용하여 대기 시간과 영역 중단에 대한 복원력 간의 장단점에 대한 정보에 입각한 결정을 내릴 수 있습니다.

   테스트에서 워크로드의 대기 시간이 허용할 수 없을 정도로 높다는 것을 보여 주는 경우 다음 작업을 수행하는 것이 좋습니다.

   • 다른 영역 집합을 사용해 보세요. 서로 다른 물리적 거리를 가질 수 있으므로 서로 다른 영역 간의 대기 시간에 약간의 가변성이 있을 수 있습니다.

     팁 (조언)

     Azure 구독 간에 테스트할 경우, 예상하는 물리적 영역 세트를 테스트하고 있는지 확인하기 위해 논리적 영역과 물리적 영역 간의 매핑을 검토하십시오.

   • 데이터 보존 및 기타 요인에 대한 전반적인 요구 사항을 충족하는 다른 Azure 지역이 있는 경우 해당 지역에서 여러 영역을 사용해 보세요.

   • 필요한 영역 간 통신을 최소화하기 위해 애플리케이션을 다시 디자인할 수 있는지 여부를 고려합니다. 예를 들어 여러 개의 작은 데이터베이스 작업을 단일 작업으로 통합할 수 있습니다. 이 방법은 워크로드에 대한 대기 시간 영향을 줄일 수 있습니다.

   이러한 작업 중 어느 것도 도움이되지 않는 경우 영역 VM 및 기타 지원되는 Azure 서비스를 사용하여 단일 가용성 영역 내에서 특정 워크로드 또는 구성 요소를 실행하는 것이 좋습니다. 그런 다음 영역 구성 요소를 영역 중단에 대한 복원력 있게 만드는 역할을 담당합니다. 이 문서의 나머지 부분을 검토하여 책임과 고려해야 할 몇 가지 방법을 이해합니다.

귀하의 영역 배포에 대한 책임

영역 리소스는 가용성 영역에서 중단이 발생할 때 가동 중지될 위험이 있습니다. 영역 리소스를 배포할 때 영역 수준 오류에 대한 복원력 있는 워크로드를 만들 책임이 있습니다.

영역 리소스를 영역 복원력 있게 만들려면 다음 책임을 고려합니다.

• 여러 리소스의 배포 및 구성: 다른 영역 또는 지역에 별도의 영역 리소스를 수동으로 배포합니다. 각 리소스에서 구성을 일관되게 유지하는 방법을 결정합니다. 여러 동일한 리소스를 신속하게 배포할 수 있으므로 IaC(Infrastructure as Code)를 사용하는 것이 가장 좋습니다.

• 트래픽 라우팅 및 배포: 부하 분산 장치 구성 요소를 선택하고, 영역 복원력이 있는지 확인하고, 다른 영역의 리소스 간에 트래픽을 보내도록 구성해야 합니다. 일반적으로 라우팅 정책(예: 활성-활성 또는 활성-수동), 자동화된 상태 검사 및 장애 조치(failover) 프로세스를 구성합니다. 자세한 내용은 부하 분산 옵션을 참조하세요.

• 복제 또는 데이터 백업: 상태 저장 리소스의 경우 저장되는 데이터를 보호하고 여러 영역에 안전하게 보관되도록 해야 합니다. 일반적인 방법은 다른 가용성 영역에서 다른 서비스 인스턴스로의 복제를 구성하는 것입니다. 경우에 따라 백업을 대신 사용할 수 있습니다. 그러나 백업에는 영역 실패 시 복구 시간이 더 길어야 하므로 RTO(복구 시간 목표)가 더 높아야 합니다. 또한 더 많은 데이터 손실이 발생하므로 RPO(복구 지점 목표)가 더 높아집니다.

• 영역 오류 검색 및 응답 프로세스 구현: 영역 리소스의 상태를 모니터링하고, 비정상으로 표시하는 조건을 정의하고, 다른 영역 또는 지역의 작업 복원과 같은 응답 작업을 트리거하는 방법을 결정해야 합니다.

• 영역 복구 프로세스: 영역이 복구된 후에는 기본 영역의 리소스로 전환 등 필요한 복구 작업을 담당합니다.

영역 배포 복원력에 대한 일반적인 접근 방식

영역 리소스에 대한 영역 복원력을 달성하는 방법에 대해 정보에 입각한 결정을 내리려면 다음 요소를 고려합니다.

• 전체 워크로드를 검토합니다. 영역 다운 이벤트 시 각 구성 요소가 어떻게 동작하는지 이해합니다. 이를 위해 영역 중복 리소스, 영역 리소스 및 비지역 리소스를 포함합니다. 각 서비스에 대한 안정성 가이드를 사용하여 영역 다운 시나리오 중에 서비스가 작동하는 방식과 영역 다운 이벤트에 대한 서비스 상태를 모니터링하는 방법을 알아봅니다.

• 영역 실패 시 허용되는 데이터 손실을 이해합니다. RPO는 허용할 수 있는 데이터 손실을 지정합니다.

  많은 Azure 영역 중복 리소스는 영역 오류에 대해 0의 RPO를 제공하므로 데이터 손실이 발생하지 않습니다. 일반적으로 영역 전체의 모든 변경 내용을 동기적으로 복제하여 이 RPO를 달성합니다.

  영역 배포를 계획할 때 영역이 실패할 때 워크로드의 RPO 요구 사항을 충족할 수 있는지 확인해야 합니다.

• 영역 실패 시 허용되는 가동 중지 시간을 이해합니다. RTO는 허용할 수 있는 가동 중지 시간을 지정합니다.

  Azure 영역 중복 리소스는 일반적으로 영역 오류에 대해 매우 낮은 RTO를 제공하며 일반적으로 몇 초의 가동 중지 시간만 필요합니다.

  영역 배포를 계획할 때 워크로드의 RTO 요구 사항을 충족할 수 있는지 확인해야 합니다. RTO가 낮은 경우 자동화된 검색 및 복구 프로세스에 의존해야 할 수 있습니다. RTO가 높을수록 응답 프로세스에 더 많은 유연성이 제공됩니다.

• 비용을 이해합니다. 영역 리소스는 일반적으로 개별적으로 청구되므로 여러 영역 리소스를 배포하면 리소스 비용이 증가할 수 있습니다.

복원력을 위한 영역 배포 디자인

복원력을 위해 영역 배포를 디자인할 때 가용성 영역을 사용하여 고가용성 또는 재해 복구를 달성할지 여부를 고려합니다. 이러한 개념의 차이는 RTO 및 RPO 요구 사항을 기반으로 합니다.

RTO가 낮고 RPO 요구 사항이 낮은 경우 가용성 영역을 고가용성 구문으로 처리해야 합니다. 그러나 RTO 및 RPO가 더 높은 경우 가용성 영역을 재해 복구 구문으로 처리하도록 선택할 수 있습니다. 자세한 내용은 비즈니스 연속성, 고가용성 및 재해 복구를 참조하세요. 워크로드 계층은 요구 사항 및 필요한 작업을 결정하는 데 도움이 될 수 있습니다.

고가용성을 위한 디자인

여러 영역에 고가용성 아키텍처를 배포하는 것이 좋습니다. 고가용성 아키텍처를 사용하려면 여러 영역에 배포된 구성 요소 간에 자동화되고 빈번한 데이터 복제가 필요하며 영역 오류가 발생하는 경우 해당 구성 요소 간에 자동 장애 조치(failover)가 필요합니다.

영역 VM에 배포하는 일부 애플리케이션은 복제본 인식과 같은 기본 제공 고가용성 지원을 제공합니다. 예를 들어 Azure VM에서 SQL Server를 사용하는 경우 가용성 그룹은 트래픽 라우팅 및 장애 조치 기능을 제공합니다. 동기 또는 비동기 복제를 사용할지 여부를 선택할 수 있습니다. 자세한 내용은 Azure VM의 SQL Server에 대한 비즈니스 연속성, 고가용성 및 재해 복구를 참조하세요.

재해 복구를 위한 디자인

재해 복구는 재해 시나리오에서 더 큰 가동 중지 시간과 데이터 손실이 허용되기 때문에 고가용성과 다릅니다. RTO 및 RPO는 일반적으로 시간 이상으로 측정됩니다.

재해 복구 계획은 다양한 시나리오를 준비하고 자동화된 프로세스와 수동 프로세스의 조합을 사용하여 대응하는 방법을 정의하는 데 도움이 됩니다.

다음 재해 복구 방법은 영역 배포를 계획할 때 도움이 될 수 있습니다.

• Azure Site Recovery 영역 및 영역 간의 재해 복구: 이 방법은 서로 다른 영역에 있는 VM 간에 디스크 수준 비동기 복제가 필요한 경우에 유용합니다. 자세한 내용은 가용성 영역 간에 Azure VM 재해 복구 사용을 참조하세요.

• Site Recovery 지역 간 재해 복구: Site Recovery는 지역 간 재해 복구를 지원하고 비동기 복제를 사용합니다. 이 접근 방식은 기본 지역의 다른 영역이 아닌 다른 Azure 지역의 영역으로 장애 조치를 수행할 수 있게 합니다. 자세한 내용은 다른 Azure 지역에 Azure VM 복제를 참조하세요.

• 백업 기반 재해 복구: 솔루션이 높은 RTO 및 높은 RPO를 허용할 수 있는 경우 백업을 재해 복구 전략으로 사용하는 것이 좋습니다. 영역에서 중단이 발생하는 경우 백업을 다른 영역이나 지역으로 복원할 수 있습니다. 또한 솔루션에서 다른 Azure 리소스를 미리 생성할지, 아니면 장애 조치(failover) 프로세스 중에 리소스를 만드는지도 고려해야 합니다.

  영역 아키텍처에서는 종종 이러한 백업을 저장하고 복제할 책임이 있습니다.

  Azure Backup 은 널리 사용되는 관리되는 백업 서비스입니다. 쌍을 이루는 Azure 지역에서 영역 중복 백업 및 지역 복제 백업을 지원합니다. Azure VM의 SQL Server와 같은 일부 애플리케이션에는 기본 제공 애플리케이션별 백업 기능도 포함됩니다.

다음 단계

• Azure Well-Architected Framework에서 가용성 영역 및 지역 사용에 대한 권장 사항