Azure Spring Apps의 안정성
이 문서에는 Azure Spring Apps에 대한 가용성 영역 및 지역 간 재해 복구 및 비즈니스 연속성 지원을 사용하는 지역 복원력 에 대한 자세한 정보가 포함되어 있습니다.
가용성 영역 지원
Azure 가용성 영역은 각 Azure 지역 내에서 물리적으로 분리된 세 개 이상의 데이터 센터 그룹입니다. 각 영역 내의 데이터 센터에는 독립적인 전원, 냉각, 네트워킹 인프라가 장착되어 있습니다. 가용성 영역은 로컬 영역이 실패한 경우에 한 영역이 영향을 받는 경우 나머지 두 영역에서 지역 서비스, 용량 및 고가용성을 지원하도록 설계되었습니다.
오류는 소프트웨어 및 하드웨어 오류에서 지진, 홍수 및 화재와 같은 이벤트에 이르기까지 다양합니다. Azure 서비스의 중복성과 논리적 격리로 인해 오류 허용성에 도달합니다. Azure의 가용성 영역에 대한 자세한 내용은 지역 및 가용성 영역을 참조하세요.
Azure 가용성 영역 지원 서비스는 적절한 수준의 복원력과 유연성을 제공하도록 설계되었습니다. 두 가지 방법으로 구성할 수 있습니다. 영역 간 자동 복제를 사용하는 영역 중복 또는 특정 영역에 고정된 인스턴스를 사용하는 영역일 수 있습니다. 이러한 방식을 결합할 수도 있습니다. 영역 및 영역 중복 아키텍처에 대한 자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항을 참조하세요.
Azure Spring Apps는 영역 중복성을 지원합니다. 영역 중복을 사용하도록 설정된 Azure Spring Apps 서비스 인스턴스가 만들어지면 Azure Spring Apps에서 기본 리소스를 기본 Azure 인프라의 논리적 섹션 간에 자동으로 배포합니다. 기본 컴퓨팅 리소스는 컴퓨팅 기능을 보장하기 위해 VM을 모든 가용성 영역에 배포합니다. 기본 스토리지 리소스는 데이터 센터 오류가 있는 경우에도 사용 가능한 상태로 유지하기 위해 데이터를 가용성 영역 간에 복제합니다. 이 배포는 더 높은 수준의 가용성을 제공하고 하드웨어 오류 또는 계획된 유지 관리 이벤트로부터 보호합니다.
필수 조건
영역 중복은 기본 계획에서 사용할 수 없습니다.
Azure Spring Apps는 다음 지역에서 가용성 영역을 지원합니다.
- 오스트레일리아 동부
- 브라질 남부
- 캐나다 중부
- 미국 중부
- 동아시아
- 미국 동부
- 미국 동부 2
- 프랑스 중부
- 독일 중서부
- 북유럽
- 일본 동부
- 한국 중부
- 남아프리카 북부
- 미국 중남부
- 동남아시아
- 영국 남부
- 서유럽
- 미국 서부 2
- 미국 서부 3
가용성 영역이 사용하도록 설정된 Azure Spring Apps 인스턴스 만들기
참고 항목
Azure Spring Apps 서비스 인스턴스를 만들 때만 영역 중복을 사용하도록 설정할 수 있습니다. 만든 후에는 영역 중복 속성을 변경할 수 없습니다.
Azure CLI 또는 Azure Portal을 사용하여 Azure Spring Apps에서 영역 중복을 사용하도록 설정할 수 있습니다.
Azure CLI를 사용하여 Azure Spring Apps에서 영역 중복이 사용하도록 설정된 서비스를 만들려면 다음 예제와 같이 서비스를 만들 때 --zone-redundant 매개 변수를 포함합니다.
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
가용성 영역을 사용하도록 설정된 사용자 고유의 리소스 사용
사용자 고유의 영구 스토리지와 같은 Azure Spring Apps에서 사용자 고유의 리소스를 사용하도록 설정할 수 있습니다. 그러나 리소스에 대해 영역 중복을 사용하도록 설정해야 합니다. 자세한 내용은 Azure Spring Apps에서 사용자 고유의 영구 스토리지를 사용하도록 설정하는 방법을 참조하세요.
영역 다운 환경
앱 인스턴스가 실패한 영역의 VM 노드에 있기 때문에 실패하면 Azure Spring Apps는 다른 가용성 영역의 다른 VM 노드에서 실패한 앱에 대한 새 앱 인스턴스를 만듭니다. 사용자는 이 시간 동안 잠시 중단이 발생할 수 있습니다. 사용자 작업이 필요하지 않으며 영향을 받는 Azure Spring Apps 인스턴스가 서비스에 의해 복원됩니다.
가격 책정
영역 중복을 사용하도록 설정하는 것과 관련된 추가 비용은 없습니다. 영역 중복을 사용하도록 설정하는 데 필요한 표준 또는 엔터프라이즈 계획에 대해서만 비용을 지불하면 됩니다.
지역 간 재해 복구 및 비즈니스 연속성
DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.
DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 공유 책임 모델에서 Microsoft는 기준 인프라 및 플랫폼 서비스를 사용할 수 있도록 합니다. 동시에 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 사용하도록 설정된 다른 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우 자신의 워크로드에 적합한 재해 복구 계획을 설정할 책임이 있습니다. Azure PaaS(Platform as a Service) 제품에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공하며, 서비스별 기능을 사용하여 빠른 복구를 지원하여 DR 계획을 개발하는 데 도움이 될 수 있습니다.
Azure Spring Apps 서비스는 지리적 재해 복구를 제공하지 않지만, 신중한 계획을 통해 가동 중지 시간이 발생하지 않도록 보호할 수 있습니다.
재해로부터 고가용성 및 보호를 보장하려면 Azure Spring Apps에서 호스트되는 애플리케이션을 여러 지역에 배포합니다. Azure는 이에 따라 앱 배포를 계획할 수 있도록 쌍을 이루는 지역 목록을 제공합니다.
아키텍처를 설계할 때 고려해야 하는 주요 요소는 다음과 같습니다.
- 지역 가용성. 네트워크 지연 및 전송 시간을 최소화하려면 Azure Spring Apps 영역 중복을 지원하는 지역 또는 사용자와 가까운 지리적 영역을 선택합니다.
- Azure 쌍을 이루는 지역. 필요한 경우 조정된 플랫폼 업데이트 및 우선 순위가 지정된 복구 작업을 보장하려면 선택한 지리적 영역 내에서 쌍을 이루는 지역을 선택합니다.
- 서비스 가용성. 쌍을 이루는 지역이 핫/핫, 핫/웜 또는 핫/콜드를 실행해야 하는지 여부를 결정합니다.
Azure Traffic Manager를 사용하여 트래픽 라우팅
Azure Traffic Manager는 DNS 기반 트래픽 부하 분산을 제공하고 네트워크 트래픽을 여러 지역에 배포할 수 있습니다. Azure Traffic Manager를 사용하여 고객을 가장 가까운 Azure Spring Apps 서비스 인스턴스로 안내합니다. 최상의 성능과 중복성을 위해 모든 애플리케이션 트래픽을 Azure Spring Apps 서비스 인스턴스로 보내기 전에 Azure Traffic Manager를 통해 전달합니다. 자세한 내용은 Traffic Manager란?을 참조하세요.
여러 지역에서 실행되는 Azure Spring Apps의 애플리케이션이 있는 경우 Azure Traffic Manager는 각 지역의 애플리케이션에 대한 트래픽 흐름을 제어할 수 있습니다. 인스턴스 IP를 사용하여 각 서비스 인스턴스에 대한 Azure Traffic Manager 엔드포인트를 정의합니다. Azure Spring Apps 서비스 인스턴스를 가리키는 Azure Traffic Manager DNS 이름에 연결해야 합니다. Azure Traffic Manager는 정의된 엔드포인트에서 트래픽 부하를 분산합니다. 재해가 데이터 센터에 발생하면 Azure Traffic Manager는 트래픽을 해당 지역에서 해당 쌍으로 전달하여 서비스 연속성을 보장합니다.
다음 단계를 사용하여 Azure Spring Apps 인스턴스에 대한 Azure Traffic Manager 인스턴스를 만듭니다.
Azure Spring Apps 인스턴스를 서로 다른 두 지역에 만듭니다. 예를 들어 서비스 인스턴스를 다음 표와 같이 미국 동부와 서유럽에 만듭니다. 각 인스턴스는 트래픽에 대한 기본 및 장애 조치(failover) 엔드포인트 역할을 수행합니다.
Service name 위치 애플리케이션 service-sample-a 미국 동부 gateway / auth-service / account-service service-sample-b 서유럽 gateway / auth-service / account-service 서비스 인스턴스에 대한 사용자 지정 도메인을 설정합니다. 자세한 내용은 자습서: Azure Spring Apps에 기존 사용자 지정 도메인 매핑을 참조하세요. 성공적으로 설정되면 두 서비스 인스턴스가 동일한 사용자 지정 도메인(예:
bcdr-test.contoso.com)에 바인딩됩니다.Traffic Manager 및 두 개의 엔드포인트를 만듭니다. 지침은 빠른 시작: Azure Portal을 사용하여 Traffic Manager 프로필 만들기를 참조하세요. 여기서는 다음 Traffic Manager 프로필을 생성합니다.
- Traffic Manager DNS 이름:
http://asa-bcdr.trafficmanager.net - 엔드포인트 프로필:
프로필 Type 대상 우선 순위 사용자 지정 헤더 설정 엔드포인트 A 프로필 외부 엔드포인트 service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.com엔드포인트 B 프로필 외부 엔드포인트 service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Traffic Manager DNS 이름:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net예제와 비슷한 CNAME 레코드를 DNS 영역에 만듭니다.
이제 환경이 설정되었습니다. 연결된 문서의 예제 값을 사용한 경우 https://bcdr-test.contoso.com을 사용하여 앱에 액세스할 수 있어야 합니다.
Azure Front Door 및 Azure Application Gateway를 사용하여 트래픽 라우팅
Azure Front Door는 Microsoft 글로벌 경계 네트워크를 사용하여 빠르고, 안전하고, 스케일링 성능이 뛰어난 웹 애플리케이션을 만들기 위한 확장 가능한 글로벌 진입점입니다. Azure Front Door는 Azure Traffic Manager와 동일한 다중 지역 중복 및 가장 가까운 지역으로의 라우팅을 제공합니다. 또한 Azure Front Door는 TLS 프로토콜 종료, 애플리케이션 계층 처리 및 WAF(Web Application Firewall)와 같은 고급 기능을 제공합니다. 자세한 내용은 Azure Front Door란?을 참조하세요.
다음 다이어그램에서는 다중 지역 중복, 가상 네트워크 통합 Azure Spring Apps 서비스 인스턴스의 아키텍처를 보여 줍니다. 이 다이어그램에서는 사용자 지정 도메인이 있는 Application Gateway 및 Front Door에 대한 올바른 역방향 프록시 구성을 보여 줍니다. 이 아키텍처는 가상 네트워크에서 엔드투엔드 TLS를 사용하여 애플리케이션 노출에서 설명하는 시나리오를 기반으로 합니다. 이 방법은 두 개의 Application Gateway 통합 Azure Spring Apps 가상 네트워크 주입 인스턴스를 지역 중복 인스턴스로 결합합니다.
