지리적으로 분산된 아키텍처 디자인

Azure는 전역 시스템입니다. 둘 이상의 Azure 지역에 있는 아키텍처를 디자인하여 지역 전체 재해에도 탄력적으로 대처할 수 있는 애플리케이션을 빌드할 수 있습니다.

배송 추적 포털은 다양한 Azure 리소스를 사용하여 빌드되기 때문에 확장성이 있습니다. 구성 요소에 여러 인스턴스가 포함될 수 있으므로 많은 오류에 대처할 수도 있습니다. 그러나 포털이 완전히 미국 동부 Azure 지역에 포함되어 있기 때문에 이사회는 대규모 재해로 인해 중단이 발생할 가능성을 걱정하게 되었습니다. 미국 동부에서 장애가 발생하는 경우 두 번째 지역으로 장애 조치할 수 있는 수정된 아키텍처를 제안하려고 합니다.

여기서는 지리적으로 분산된 애플리케이션을 지원하도록 애플리케이션 아키텍처를 조정하는 방법을 알아봅니다. 또한 해당 아키텍처가 중요 비즈니스용 애플리케이션에 유용한 이유를 알아봅니다.

원본 웹앱 아키텍처

추적 포털의 아키텍처 디자인 및 솔루션에서 사용된 구성 요소에 대해 살펴보겠습니다. 모든 부분을 사용하는 방법을 이해하면 지역 중복 시나리오에서 각 구성 요소를 지원하는 방법을 조사할 수 있습니다.

추적 포털 디자인은 다음 다이어그램에 표시된 참조 아키텍처를 기반으로 합니다.

애플리케이션에서 단일 Azure 리소스 그룹을 사용하는 방법을 확인합니다. 이 리소스 그룹을 사용하여 모든 리소스를 논리적으로 그룹화하고 관리하며 관리를 간소화할 수 있습니다. 미국 동부 지역에 이 리소스 그룹을 배포하도록 선택했습니다. 리소스 그룹은 포함된 리소스에 동일한 Azure 지역을 사용하도록 제한하지 않지만, 애플리케이션에 배포된 모든 리소스에 미국 동부 지역을 사용하도록 결정했습니다.

애플리케이션은 세 가지 범주의 Azure 리소스를 사용합니다. 각 범주를 살펴보고 사용 중인 리소스를 확인하겠습니다.

네트워크 구성 요소

추적 포털은 다음 네트워킹 서비스를 사용합니다.

애플리케이션 구성 요소

추적 포털은 다음 서비스를 사용하여 코드, 캐시 및 중간 스토리지 요구 사항을 지원합니다.

데이터 스토리지 구성 요소

추적 포털은 다음과 같은 지속형 스토리지 서비스를 사용합니다.

원래 아키텍처 관련 문제

추적 포털의 기존 아키텍처는 확장성과 가용성을 허용하도록 디자인되었습니다.

예를 들어 요청이 많고 사용자 웹 요청에 대한 응답이 느린 경우 App Service에서 프런트 엔드 웹앱의 인스턴스를 더 추가하는 것을 고려할 수 있습니다. Application Gateway는 새로 만들어진 이 인스턴스에 요청을 라우팅할 수 있습니다.

그러나 아키텍처 디자인에 극복할 과제가 있거나 실패하기도 하는 시나리오가 있습니다. 추적 포털에 미치는 영향을 보다 잘 이해할 수 있도록 각 시나리오를 살펴보겠습니다.

지역 장애

일부 중대한 이벤트로 인해 전체 Azure 지역이 중단될 수 있습니다. Azure 데이터 센터는 복원력이 높게 디자인되지만, 허리케인이나 홍수와 같은 심각한 날씨 이벤트는 해당 지역의 서비스를 방해할 수 있습니다.

이 이벤트는 비정상적인 상황이며 많은 회사에서는 해당 위험을 감당할 수 있다고 생각합니다. 그러나 추적 포털을 사용하지 않는 상태에서 발생하는 지역 장애의 결과는 회사의 실무진 팀이 위험을 제거하기로 결정한 정도의 심각한 위험입니다.

서비스 수준 약정

대부분의 Azure 서비스는 Service Level Agreement(서비스 수준 약정) 또는 작동 시간 보장을 제공합니다. 여러 Azure 서비스로 구성된 애플리케이션 아키텍처를 디자인할 때 모든 다른 서비스 SLA의 복합으로 앱의 전체 SLA를 계산합니다.

구성 요소 서비스의 SLA를 곱하여 이 SLA를 계산합니다. 예를 들어 앱이 Azure App Service(99.95% SLA)와 Microsoft Entra ID(99.9% SLA)로 구성된다고 가정합니다. 최종 계산된 SLA는 99.85%입니다.

이 작동 시간 비율이 애플리케이션에 충분하지 않은 경우 애플리케이션을 다른 지역으로 장애 조치하도록 계획할 수 있습니다.

전역, 지역 및 구성 가능한 구성 요소

이 디자인에서 일부 구성 요소는 기본적으로 전역이며 지역 장애에 취약하지 않습니다.

일부 구성 요소는 단일 지역(예: Application Gateway)으로 한정됩니다. 이 구성 요소 유형에 대한 대체 서비스를 선택해야 합니다.

일부 구성 요소는 여러 지역을 지원하도록 구성할 수 있습니다. 예를 들어 정적 콘텐츠를 저장하는 Azure Storage 계정에서 GRS(지역 중복 스토리지) 옵션을 사용할 수 있습니다. GRS는 Blob을 다른 지역에 복제합니다.

다음 표에서는 전역, 지역 및 구성 가능한 구성 요소를 보여 줍니다.

제안된 분산 아키텍처

몇 가지 조사 후 다음 다이어그램에 나온 아키텍처를 제안합니다.

이 디자인에는 활성 지역(미국 동부) 및 대기 지역(미국 서부)이 있습니다. 미국 동부 지역은 일반적인 상황에서 구성 요소를 통해 모든 요청을 처리합니다. 재해로 인해 지역 장애가 발생하면 애플리케이션은 미국 서부 지역으로 장애 조치됩니다.

원래 아키텍처를 수정한 방법을 간단히 살펴보겠습니다. 이 변경 내용은 이후 단원에서 자세히 살펴보겠습니다.

네트워킹

Azure DNS 및 Azure CDN은 기본적으로 전역 시스템이며 이미 지역 장애에 탄력적으로 대처합니다. 이 서비스는 그대로 유지합니다.

Azure Application Gateway를 만들 때 서비스를 단일 지역에 할당합니다. 이 서비스를 Azure Front Door로 바꿔서 이 취약성을 제거합니다. Front Door는 여러 App Services를 폴링할 수 있으며 미국 동부 지역에서 미국 서부 지역으로 App Service 장애 조치를 처리합니다.

애플리케이션 서비스

Microsoft Entra ID는 전역 시스템이며 수정이 필요하지 않습니다.

Azure Storage 계정은 콘텐츠를 여러 지역에 복제하도록 구성할 수 있습니다. 지역 중복 스토리지 옵션 중 하나를 사용하여 구성을 변경합니다.

App Service, 함수 앱, Redis cache 및 Azure Search를 포함한 다른 구성 요소는 지역 구성 요소입니다. 새 아키텍처 디자인에서 미국 서부 지역에 이 구성 요소의 중복 인스턴스를 만듭니다. 이 디자인에서 장애 조치가 발생하면 새 지역이 대신 사용될 수 있습니다.

데이터 스토리지

Azure SQL Database 및 Azure Cosmos DB는 둘 다 다른 지역에 대한 데이터 지역 복제를 지원합니다. 미국 서부의 해당 서비스에 미국 동부 데이터를 복제하도록 이 서비스를 구성합니다.

지역 쌍

Azure 지역은 하나 이상의 Azure 데이터 센터를 포함하는 단일 지리적 위치를 포함하는 영역입니다. 모든 지역이 동일한 지리적 위치에 있는 다른 지역과 쌍으로 연결됩니다. 쌍 내에서 업데이트 및 계획된 유지 관리는 한 번에 한 지역에서만 수행됩니다. 여러 지역에 영향을 주는 장애가 발생한 경우 빠른 복구를 위해 각 쌍에서 하나 이상의 지역에 복구 우선 순위가 지정됩니다.

모범 사례는 지역 쌍의 두 지역에 앱에 대한 2개 지역 아키텍처를 배치하는 것입니다. 예를 들어 미국 동부는 미국 서부와 쌍으로 연결됩니다. 제안된 디자인은 활성 지역에 미국 동부를 사용하고 대기 지역에 미국 서부를 사용합니다.