영역 관련 하드웨어 오류, 네트워크 중단 및 자연 재해에 대한 애플리케이션의 복원력을 향상하려면 영역 복원력을 위해 Azure 워크로드를 디자인하는 것이 중요합니다. 지역 내의 여러 가용성 영역에 리소스를 배포하는 경우 중요한 서비스에 영향을 주는 단일 영역 중단의 위험을 줄입니다.
워크로드의 초기 계획 및 배포 중에 영역 복원력을 해결하는 것이 가장 좋은 방법은지만, 기존의 복원력이 없는 워크로드를 영역 복원력 있는 구성으로 변환하는 것이 일반적입니다. 일반적으로 기존 워크로드에 대해 영역 복원력을 사용하도록 설정하는 처리는 간단하며 Microsoft는 계속해서 프로세스를 간소화합니다. 그러나 워크로드를 변경하면 위험이 발생할 수 있습니다. 관련된 위험을 이해하면 해당 워크로드 내에서 비즈니스에 가장 중요한 워크로드 및 서비스의 우선 순위를 평가하고 우선 순위를 지정한 다음, 가장 영향력 있는 리소스에 영역 복원력을 적용할 수 있습니다.
이 문서에서는 Azure 워크로드에서 영역 복원력을 사용하도록 설정하기 위한 주요 고려 사항을 설명합니다. 또한 보다 복원력 있는 아키텍처로의 성공적인 전환을 계획하고 구현하는 데 도움이 됩니다.
팁 (조언)
현재 워크로드를 디자인하는 중이거나 현재 워크로드에 대한 디자인 검토를 수행하려는 경우 AZURE WAF(Well-Architected Framework)에서 중복성을 디자인하기 위한 권장 사항을 따르는 것이 중요합니다. WAF 권장 사항 가이드는 중요한 워크플로에 중점을 두고 여러 수준에서 워크로드 중복성을 설계하는 데 도움이 됩니다. 가용성 영역 채택을 지원하기 위해 다중 지역 배포 및 배포 스탬프와 같은 전략도 간략하게 설명합니다.
영역 복원력이란?
Azure 서비스는 두 가지 주요 방법을 통해 가용성 영역 중단에 대한 복원력을 높일 수 있습니다.
영역 중복 서비스: 많은 Azure 서비스는 영역 중복을 지원합니다. 이러한 서비스는 가용성 영역 간에 데이터를 자동으로 복제하고, 수신 요청을 분산시키고, 영역 장애 발생 시 다른 영역으로 장애 조치(failover)합니다. 각 서비스는 특정 서비스에 적합한 방식으로 이러한 기능을 지원합니다. 일부 서비스는 기본적으로 영역 중복이지만 다른 서비스는 영역 중복성을 구성해야 할 수 있습니다.
영역 서비스: 일부 Azure 서비스는 영역입니다. 즉, 특정 가용성 영역에 고정할 수 있습니다. 영역 서비스를 사용하여 영역 복원력을 달성하려면 여러 가용성 영역에 서비스의 별도 인스턴스를 배포합니다. 인스턴스 간 트래픽 분산, 데이터 복제, 장애 조치(failover)를 관리해야 할 수도 있습니다.
일부 서비스는 영역 중복 또는 영역 구성으로 배포될 수 있습니다. 대부분의 경우 가능하다면 영역 중복 서비스를 배포하는 것이 가장 좋습니다.
자세한 내용은 가용성 영역 지원 형식을 참조하세요.
영역 사용 설정 절차
다음 단계에 따라 Azure 워크로드를 체계적으로 검토하고, 영역 복원력을 위해 워크로드의 우선 순위를 지정하고, 각 구성 요소에서 영역 복원력을 사용하도록 설정합니다.
필수 조건
시작하기 전에 다음 작업을 수행합니다.
각 워크로드를 식별합니다. 워크로드는 정의된 비즈니스 결과를 달성하기 위해 함께 작동하는 애플리케이션 리소스, 데이터 및 지원 인프라의 컬렉션을 말합니다. 워크로드와 이를 정의하는 방법에 대한 자세한 내용은 Well-Architected Framework 워크로드를 참조하세요.
각 워크로드의 사용자 및 시스템 흐름에 우선 순위를 지정합니다. 워크로드의 중요한 경로 및 종속성을 이해하여 영역을 복원할 구성 요소를 먼저 결정합니다. 중요한 흐름 분석을 사용하여 워크플로의 우선 순위를 지정하는 방법에 대한 자세한 내용은 영역 복원력에 대한 워크로드 우선 순위를 참조하세요.
각 워크로드와 흐름에 중요도 등급을 할당합니다. 이 등급은 잠재적 중단이 비즈니스에 미치는 영향을 이해하고 영역 복원력에 우선 순위를 지정할 워크로드에 대한 결정을 안내하는 데 도움이 됩니다. 또한 워크로드를 다시 구성하는 동안 허용되는 가동 중지 시간을 고려합니다.
분류를 사용하여 중요도에 따라 워크로드를 분류할 수 있습니다. 이러한 방식은 가장 중요한 서비스에 활동을 집중하는 데 도움이 됩니다.
다음 예제 분류법을 참고하여 워크로드를 분류해 보세요.
워크로드 유형 Description 중단의 영향 중대한 임무 높은 신뢰성, 항상 사용 가능, 장애에 대한 복원력, 그리고 운영성이 필요한 중요한 흐름 및 워크로드. 필수 함수가 중단되면 곧바로 엄청난 사업적 피해가 발생할 위험이 있으며, 인명 피해도 발생할 수 있습니다. 중요 비즈니스용 중요한 비즈니스 함수를 운영하는 필수 흐름과 워크로드입니다. 중단으로 인해 재정적 손실이나 브랜드 이미지 손상의 위험이 있습니다. 비즈니스 운영 비즈니스 운영의 효율성에 기여하지만, 고객에게 직접 서비스를 제공하지는 않습니다. 일정 수준의 중단을 허용할 수 있습니다. 관리 내부 프로덕션 흐름과 워크로드가 비즈니스 운영과 일치하지 않습니다. 중단을 허용할 수 있습니다. 워크로드를 중요도 등급에 따라 분류하는 방법에 대한 자세한 내용은 각 흐름에 중요도 등급 지정을 참조하세요.
Azure 리소스가 상주하는 지역이 가용성 영역을 지원하는지 확인합니다. Azure 지역 목록을 참조하세요. 특정 지역이 가용성 영역을 지원하지 않는 경우 가용성 영역을 지원하는 지역으로 리소스를 이전하는 것이 좋습니다. 자세한 내용은 리소스 그룹, 구독 또는 지역 간 Azure 리소스 이동을 참조하세요.
1단계: 영역 복원력을 위해 Azure 서비스의 우선 순위 지정
비즈니스에 가장 중요한 워크로드 흐름이 무엇인지 파악한 후에는 해당 흐름이 의존하는 Azure 서비스에 집중할 수 있습니다. 일부 Azure 서비스는 다른 서비스보다 애플리케이션에 더 중요합니다. 영역 오류가 발생할 경우 애플리케이션이 사용 가능하고 복원력을 유지할 수 있도록 이러한 서비스의 우선 순위를 지정합니다.
다음 지침을 사용하여 워크로드에 대한 중요도에 따라 Azure 서비스 그룹의 우선 순위를 지정합니다. 영역 복원력에 대한 서비스의 우선 순위를 결정할 때 특정 애플리케이션 아키텍처 및 비즈니스 요구 사항을 고려합니다.
네트워킹 서비스로 시작합니다. 워크로드는 네트워킹 서비스를 공유하는 경향이 있으므로 이러한 서비스의 복원력이 증가하면 한 번에 여러 워크로드의 복원력을 향상시킬 수 있습니다.
많은 핵심 네트워킹 서비스는 자동으로 영역 중복되지만 Azure ExpressRoute 게이트웨이, Azure VPN Gateway, Azure Application Gateway, Azure Load Balancer 및 Azure Firewall과 같은 구성 요소에 집중해야 합니다.
운영 데이터 스토리지 복원력을 향상시킵니다. 운영 데이터 저장소에는 여러 워크로드에서 자주 사용하는 중요한 데이터가 포함되어 있으므로 이러한 데이터 저장소의 가용성을 향상하면 많은 워크로드에 도움이 될 수 있습니다.
작동 데이터 스토리지 복원력을 위해 Azure SQL Database, Azure SQL Managed Instance, Azure Storage, Azure Data Lake Storage, Azure Cosmos DB, Azure PostgreSQL 유연한 서버, Azure MySQL 유연한 서버, Azure Cache for Redis와 같은 서비스에 집중합니다.
컴퓨팅 서비스의 우선 순위를 지정합니다. 이러한 서비스는 무상태이기 때문에 영역 간에 쉽게 복제하고 배포할 수 있습니다.
컴퓨팅 서비스에는 Azure Virtual Machines, Azure Virtual Machine Scale Sets, AKS(Azure Kubernetes Service), Azure App Service, App Service Environment, Azure Functions, Azure Service Fabric 및 Azure Container Apps가 포함됩니다.
중요한 흐름에서 사용하는 나머지 중요 비즈니스용 리소스를 검토합니다. 이러한 리소스는 이전에 나열된 리소스만큼 중요하지 않을 수도 있지만 여전히 애플리케이션의 기능에서 역할을 하므로 영역 복원력을 고려해야 합니다.
나머지 비즈니스 운영 리소스를 검토합니다. 영역 복원력을 부여할지 여부에 대해 정보에 입각한 결정을 내립니다. 이 검토에는 중요한 워크로드와 직접적인 관련이 없지만 전반적인 애플리케이션 성능 및 안정성에 여전히 기여하는 서비스가 포함됩니다.
2단계: 영역 구성 방식 평가
워크로드 및 Azure 서비스의 우선 순위를 지정한 후 각 서비스에 대해 가용성 영역 지원을 사용하도록 설정하는 데 필요한 접근 방식을 식별하고 영역 복원력을 구성하기 위해 수행해야 하는 작업을 이해합니다.
각 Azure 안정성 서비스 가이드에는 해당 서비스에 대한 영역 복원력을 사용하도록 설정하는 방법을 설명하는 섹션이 있습니다. 이 섹션에서는 전략을 적절하게 계획할 수 있도록 각 서비스 영역을 복원력 있게 만드는 데 필요한 노력을 이해하는 데 도움이 됩니다. 특정 서비스에 대한 자세한 내용은 Azure 안정성 서비스 가이드를 참조하세요.
영역 구성 테이블을 사용하여 일반적인 Azure 서비스에 대한 접근 방식을 빠르게 이해할 수 있습니다.
중요합니다
워크로드에 영역(또는 단일 영역) 구성에 배포된 구성 요소가 포함된 경우 이러한 구성 요소를 영역 중단에 대한 복원력 있게 만들 계획입니다. 일반적인 방법은 별도의 인스턴스를 다른 가용성 영역에 배포하고 필요한 경우 인스턴스 간에 전환하는 것입니다.
3단계: 대기 시간 테스트
워크로드가 영역 복원성을 갖도록 만들 때 가용성 영역 간의 대기 시간을 고려하세요. 경우에 따라 일부 레거시 시스템은 특히 데이터 계층 내에서 동기 복제를 사용하도록 설정하는 경우 영역 간 트래픽이 발생하는 약간의 추가 대기 시간을 허용할 수 없습니다. 영역 간 대기 시간이 워크로드에 영향을 줄 수 있다고 의심되는 경우 영역 복원력을 사용하도록 설정하기 전과 후에 테스트를 실행합니다. 영역 간 대기 시간이 애플리케이션에 미치는 영향 및 영역 간 대기 시간 문제를 완화하는 방법에 대한 자세한 내용은 영역 리소스 및 영역 복원력을 참조하세요.
Azure 서비스에 대한 영역 구성 방식
각 Azure 서비스는 해당 서비스의 용도와 내부 아키텍처에 따라 특정 형식의 가용성 영역 지원을 지원합니다. 가용성 영역(또는 비영역 리소스)을 사용하도록 구성되지 않은 리소스가 있는 경우 가용성 영역 지원을 사용하여 다시 구성할 수 있습니다. 해당 서비스의 안정성 안내는 가용성 영역 구성 지침에 대한 지침이나 링크를 제공합니다.
이 섹션에서는 다양한 유형의 영역 구성 방법 및 각 서비스가 지원하는 접근 방식에 대한 개요를 제공합니다.
중요합니다
리소스에서 영역 중복을 사용하도록 설정하면 해당 리소스가 영역 오류에 자동으로 복원됩니다. 영역 구성을 사용하여 리소스를 특정 가용성 영역에 고정하는 경우 리소스는 자동으로 영역 중복되지 않습니다. 시스템을 장애 영역에서도 복원력 있게 만들어야 합니다. 영역 서비스의 경우 이 문서에서는 영역에 고정하는 복잡성과 비용을 반영합니다. 영역 복원력을 달성하기 위한 추가 단계에 대한 자세한 내용은 서비스의 안정성 가이드를 참조하세요.
영역 구성 표에는 여러 Azure 서비스에 지원되는 영역 구성 방식이 나열되어 있으며 해당 서비스에 대한 각 안정성 가이드에 대한 링크가 포함되어 있습니다. 안정성 가이드는 가용성 영역 지원을 사용하도록 비 영역 서비스 리소스를 구성하는 방법에 대한 정보를 제공합니다.
다음 표에서는 가용성 영역을 사용하도록 설정하는 데 필요한 작업 수준 및 가동 중지 시간을 포함하여 각 영역 구성 방법을 설명합니다.
| 접근법 | Description | 일반적인 활동 수준 | 가동 중지 시간이 필요할 수 있음 |
|---|---|---|---|
| 항상 영역 복원성이 보장됨 | 서비스는 가용성 영역을 지원하는 지역에서 기본적으로 영역 복원력이 있습니다. 아무 작업도 필요하지 않습니다. | None | 아니오 |
| 사용 여부 | 설정에서 영역 중복을 사용하도록 설정하는 등 최소 구성 변경만 필요합니다. 이 프로세스는 가용성에 영향을 주지 않지만 비용 또는 성능에 미치는 영향을 고려합니다. | Low | 아니오 |
| 수정 | 종속 리소스를 다시 배포하거나 네트워크 설정을 수정하는 등 일부 구성 변경이 필요할 수 있습니다. | 미디엄 | Yes |
| 다시 배포 | 전체 리소스, 애플리케이션 또는 서비스를 다시 배포하거나 데이터를 새 서비스로 마이그레이션하는 등 중요한 변경이 필요합니다. | High | Yes |
서비스에 대한 가용성 영역 지원을 사용하도록 설정하는 비용을 이해합니다. 많은 서비스의 경우 가용성 영역을 사용하도록 설정해도 비용이 추가되지 않습니다. 그러나 일부 서비스에는 특정 계층, 특정 수의 용량 단위 또는 둘 다 필요합니다. 다른 서비스는 가용성 영역을 사용할 때 다른 요금을 청구합니다. 다음 섹션의 표에는 각 서비스에 대한 일반적인 비용 영향이 나와 있습니다.
비고
이 문서의 정보는 가용성 영역 지원을 사용하도록 설정하는 일반적인 방법을 요약하고 일반적인 비용 영향을 간략하게 설명합니다. 그러나 일부 요인은 특정 솔루션의 작동 방식에 영향을 줄 수 있습니다. 예를 들어 일부 서비스는 항상 영역 복원력으로 나열되지만 이 지정은 특정 지역 또는 서비스의 특정 계층에만 적용됩니다. 이러한 테이블을 시작점으로 사용하지만 언급된 다른 리소스를 검토하여 특정 세부 정보를 이해합니다.
영역 구성 방식에 따른 Azure 서비스
다음 표에서는 많은 Azure 서비스에 대한 가용성 영역 지원을 요약하고 각 서비스에 대한 가용성 영역 지원을 사용하도록 설정하는 비용 영향을 비롯한 접근 방식을 제공합니다.
| 서비스 | 영역 중복일 수 있음 | 영역일 수 있음 | 일반적인 영역 구성 방식 | 일반적인 비용 영향 |
|---|---|---|---|---|
| Azure AI 검색 |
|
항상 영역 복원성이 보장됨 | N/A | |
| Azure API Management |
|
|
수정 | 필요한 최소 계층 |
| Azure 앱 구성 |
|
항상 영역 복원성이 보장됨 | N/A | |
| Azure 앱 서비스 |
|
사용 여부 | 필요한 최소 계층 및 인스턴스 수 | |
| Azure App Service - App Service Environment |
|
사용 여부 | 필요한 최소 인스턴스 수 | |
| Azure Application Gateway |
|
|
항상 영역 복원성이 보장됨 | N/A |
| Azure Backup |
|
다시 배포 | 적당한 비용 증가 | |
| Azure Bastion |
|
|
다시 배포 | 비용에 영향을 주지 않음 |
| Azure Batch |
|
다시 배포 | 동일한 수의 VM(가상 머신)에 대한 비용 영향 없음 | |
| Azure Blob Storage |
|
사용 여부 | 적당한 비용 증가 | |
| Azure Cache for Redis - Enterprise |
|
다시 배포 | 비용에 영향을 주지 않음 | |
| Azure Cache for Redis - 표준 및 프리미엄 |
|
사용 여부 | 필요한 최소 계층 | |
| Azure Container Apps |
|
다시 배포 | 필요한 최소 복제본 수 | |
| Azure Container Instances |
|
다시 배포 | 비용에 영향을 주지 않음 | |
| Azure Container Registry |
|
항상 영역 복원성이 보장됨 | N/A | |
| NoSQL용 Azure Cosmos DB |
|
수정 | 자동 크기 조정 또는 다중 지역 쓰기를 사용하는 경우 없음 | |
| Azure Data Factory |
|
항상 영역 복원성이 보장됨 | N/A | |
| Azure Data Lake Storage |
|
사용 여부 | 적당한 비용 증가 | |
| Azure Database for MySQL - 유연한 서버 |
|
다시 배포 | HA(기본 및 고가용성) 인스턴스 필요 | |
| Azure Database for PostgreSQL – 유연한 서버 |
|
사용 여부 | 기본 및 HA 인스턴스 필요 | |
| Azure Databricks |
|
사용 여부 | 동일한 수의 VM에 대한 비용 영향이 없습니다. 스토리지에 대한 적당한 비용 증가 | |
| Azure Disk Storage(관리 디스크) |
|
|
사용 여부 | 적당한 비용 증가 |
| Azure Elastic SAN |
|
다시 배포 | 적당한 비용 증가 | |
| Azure Event Hubs: 전용 계층 |
|
항상 영역 복원성이 보장됨 | 최소 용량 단위(CUs) 필요 | |
| Azure Event Hubs: 다른 모든 계층 |
|
항상 영역 복원성이 보장됨 | N/A | |
| Azure ExpressRoute 게이트웨이 |
|
|
수정 | 계층에 따라 다름 |
| Azure 파일 |
|
사용 여부 | 적당한 비용 증가 | |
| Azure 방화벽 |
|
|
수정 | 비용에 영향을 주지 않음 |
| Azure Functions |
|
다시 배포 | 필요한 최소 계층 및 인스턴스 수 | |
| Azure HDInsight |
|
다시 배포 | 동일한 수의 노드에 대한 비용 영향 없음 | |
| Azure IoT Hub |
|
항상 영역 복원성이 보장됨 | N/A | |
| Azure Key Vault |
|
항상 영역 복원성이 보장됨 | N/A | |
| AKS(Azure Kubernetes Service) |
|
다시 배포 | 비용에 영향을 주지 않음 | |
| Azure Load Balancer |
|
|
수정 | 비용에 영향을 주지 않음 |
| Azure Logic Apps - 소비 계층 |
|
항상 영역 복원성이 보장됨 | N/A | |
| Azure Logic Apps - 표준 계층 |
|
다시 배포 | 필요한 최소 계층 및 인스턴스 수 | |
| Azure Managed Grafana |
|
재배포 | 적당한 비용 증가 | |
| Azure Monitor: Log Analytics |
|
항상 영역 복원성이 보장됨 | ||
| Azure NetApp Files |
|
다시 배포 | 복제 구성에 따라 다름 | |
| Azure Queue Storage |
|
사용 여부 | 적당한 비용 증가 | |
| Azure Service Bus |
|
항상 영역 복원력 있음 | N/A | |
| Azure Service Fabric |
|
|
다시 배포 | 동일한 수의 VM에 대한 비용 영향 없음 |
| Azure Site Recovery |
|
다시 배포 | Site Recovery에 대한 비용 영향 없음, 복제본 스토리지에 대한 중간 비용 증가 | |
| Azure SQL Database: 중요 비즈니스용 계층 |
|
사용 여부 | 비용에 영향을 주지 않음 | |
| Azure SQL 데이터베이스: 범용 계층 |
|
사용 여부 | 적당한 비용 증가 | |
| Azure SQL Database: 하이퍼스케일 계층 |
|
다시 배포 | 필요한 최소 복제본 수 | |
| Azure SQL Database: 프리미엄 계층 |
|
사용 여부 | 비용에 영향을 주지 않음 | |
| Azure SQL Managed Instance |
|
사용 여부 | 적당한 비용 증가 | |
| Azure Table Storage |
|
사용 여부 | 적당한 비용 증가 | |
| Azure Virtual Machine Scale Sets |
|
|
다시 배포 | 동일한 수의 VM에 대한 비용 영향 없음 |
| Azure Virtual Machines |
|
다시 배포 | 동일한 수의 VM에 대한 비용 영향 없음 | |
| Azure Virtual Network |
|
항상 영역 복원성이 보장됨 | N/A | |
| 공용 IP 주소 |
|
|
항상 영역 복원성이 보장됨 | N/A |