지리적으로 분산된 애플리케이션 아키텍처 디자인
네트워킹 구성 요소가 요청을 여러 지역으로 라우팅하여 지역 중단의 영향을 완화하는 경우에는 주 및 대기 지역에서 해당 요청에 응답할 수 있는 애플리케이션 서비스를 디자인해야 합니다.
앞에서 설명한 대로 우선순위 백 엔드 할당을 사용하여 Azure Front Door를 구성할 계획입니다. 미국 동부 지역을 주 지역으로 할당하고 미국 서부 지역을 대기 지역으로 할당합니다. 지역 장애가 발생하면 요청은 실패하지 않은 지역의 App Service로 라우팅됩니다. 사용자 액세스, 복제된 스토리지 및 애플리케이션 코드에서 이 장애 조치를 지원하려면 각 지역에서 리소스를 구성해야 합니다.
여기서는 솔루션의 애플리케이션 서비스를 검사하고 다중 지역 아키텍처에서 작동하도록 수정해야 하는지 여부를 확인합니다. 특히 Active Directory, 고정 콘텐츠 스토리지, 웹앱, 웹 API, 큐, Azure 함수, 데이터 캐시를 살펴봅니다.
Microsoft Entra ID
배송 추적 포털에서 사용자는 추적 번호를 입력하여 구매의 배송 상황을 추적할 수 있습니다. 그러나 일반 사용자는 배송 기민성 및 기타 통계와 같은 고급 기능에 액세스하기 위해 멤버 자격을 등록할 수 있습니다. Microsoft Entra ID에 사용자 계정을 저장하기 위한 추적 포털을 개발했습니다.
Microsoft Entra ID는 기본적으로 글로벌 시스템으로 설계되어 있습니다. 따라서 지역 장애에 취약하지 않으며 시스템의 이 구성 요소를 수정할 필요가 없습니다.
Azure Blob Storage
이미지 및 동영상과 같은 정적 콘텐츠는 Azure Storage 계정에 Blob(Binary Large Object)으로 저장되고 Azure CDN을 통해 사용자에게 제공됩니다.
원래 디자인에서 LRS(로컬 중복 스토리지)를 사용하도록 선택했기 때문에 스토리지 계정은 단일 지역에 포함됩니다. 데이터는 LRS을 사용하여 단일 데이터 센터 내에서만 복제됩니다. 따라서 이 구성에서 지역 중단이 발생하면 스토리지 계정을 사용할 수 없습니다. CDN으로 이미 캐시된 고정 콘텐츠는 사용자에게 계속 제공됩니다.
ZRS(영역 중복 스토리지)의 경우에도 마찬가지입니다. 이 구성에서 데이터를 다른 데이터 센터로 복제하더라도 모든 데이터 센터는 계속 동일한 지역에 있습니다. 지역 중단은 이 구성의 스토리지 계정에도 영향을 줍니다.
이 디자인에서는 CDN 구성을 사용하여 정적 콘텐츠를 캐시합니다. 작동 중단 시 사용자가 CDN 캐시에 없는 정적 파일을 요청할 수도 있습니다. 이 요청으로 인해 그래픽 또는 동영상을 표시하지 못할 수 있습니다.
지역 중복 스토리지 옵션을 선택하면 스토리지 계정을 여러 지역에 복제하여 이 가능성을 제거할 수 있습니다. 읽기 전용 복제 옵션을 사용하여 지역 중단 중 정적 콘텐츠를 추가하지 않도록 할 수도 있습니다.
지역 중복을 사용하도록 설정해야 하는 경우 두 가지 옵션을 선택할 수 있습니다. 이 옵션은 RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)입니다. 선택하는 옵션은 예산과 필요한 작동 시간 비율에 따라 결정됩니다.
Azure App Service 및 Azure 함수 앱
배송 추적 포털에서는 두 개의 Azure App Services를 구현합니다. 첫 번째 App Service는 사용자에게 표시되는 웹 인터페이스를 구현하는 웹앱을 호스트하고, 두 번째는 모바일 앱에서 배송 데이터를 추적하는 데 사용되는 웹 API를 호스트합니다. 모든 백그라운드 작업은 Azure 함수 앱으로 실행됩니다.
원래 디자인에서는 각 Azure App Service가 단일 Azure 지역으로 지역화됩니다. 보조 지역(미국 서부)에 두 번째 App Service를 만들고 웹 프로젝트를 배포하여 새로운 다중 지역 아키텍처를 지원합니다. 주 지역을 사용할 수 없는 경우 요청을 보조 지역으로 전송하도록 Azure Front Door 우선 순위 라우팅 모드를 구성합니다.
최대한 원활한 장애 조치를 보장하려면 웹 애플리케이션이 세션 상태 정보를 메모리에 저장하지 않아야 합니다. 데이터 손실이 발생하지 않도록 웹 사이트를 변경합니다. 예를 들어 코드가 사용자의 배송 목록을 메모리에 저장하는 경우에는 장애 조치가 수행되면 이 목록이 손실됩니다.
세션 상태가 저장되지 않은 경우에는 다른 요청에 영향을 주지 않고 각 웹 요청이 처리됩니다. 사용자의 세션 중간에 장애 조치가 발생하는 경우 장애 조치는 사용자에게 투명해야 합니다.
Azure 함수 앱을 비슷하게 변경합니다. 보조 지역에 Azure 함수의 개별 인스턴스를 만들고 주 지역에서 실행되는 것과 동일한 사용자 지정 코드를 배포합니다.
중요
App Service 또는 함수 앱 서비스에서 사용자 지정 코드의 업데이트를 배포하는 경우 App Service의 모든 인스턴스에도 배포해야 합니다. 이 프로세스를 자동화하려는 경우 Azure DevOps에 유용한 도구가 있습니다.
Azure Storage 큐
원래 단일 지역 아키텍처에서는 Azure Storage 계정의 큐를 사용하여 App Service와 함수 앱 간 통신을 관리했습니다. 웹앱 또는 웹 API가 백그라운드 작업을 실행해야 하는 경우 필요한 모든 정보가 포함된 메시지를 큐에 저장합니다. 함수 앱은 큐에서 새 메시지를 모니터링하고 데이터 저장소에서 필요한 쿼리를 실행하여 백그라운드 작업을 실행합니다.
이 방식으로 큐를 사용하면 수요가 높은 웹 요청을 차례대로 관리할 수 있습니다. 실행할 백그라운드 작업이 많을 때 큐가 빌드되지만 작업이 삭제되지는 않습니다. 처리될 때까지 큐에 유지됩니다. 함수 앱은 큐를 통해 작동하며 요청이 감소하면 크기를 줄입니다. 요청이 지속되면 함수 앱의 인스턴스 수를 늘립니다.
다중 지역 버전 배송 추적 포털의 경우 장애 조치가 발생할 때 큐 항목이 손실되지 않는지 확인해야 합니다. 이 큐는 Azure Storage에서 정의되며 지역 복제에 중복 옵션을 사용할 수 있습니다.
큐에서 읽기 및 쓰기 작업을 지원하므로 읽기 액세스 중복 옵션을 사용할 수 없다는 점에 유의하세요. App Service는 큐에 항목을 추가해야 하며 함수 앱은 큐에서 완료된 항목을 제거해야 합니다. 대신, GRS(지역 중복 스토리지) 또는 GZRS(지리적 영역 중복 스토리지)를 사용합니다.
Azure Redis Cache
Azure Redis Cache를 사용하여 데이터 스토리지의 성능을 최대화하고 있습니다. Redis는 데이터베이스의 데이터를 요청할 때 앱에서 생성된 모든 쿼리 결과를 캐시합니다. 유사한 데이터에 대한 모든 추가 쿼리는 데이터베이스 쿼리가 필요하지 않으며 Redis cache에서 가져옵니다.
다중 지역 아키텍처의 경우 기본 및 대기 지역 모두에 Redis Cache 인스턴스를 만듭니다. 장애 조치가 발생하는 경우 대기 지역의 Redis Cache가 비어 있을 수 있습니다. 이 빈 캐시로 인해 오류가 발생하지는 않지만, 데이터가 새 캐시를 채우므로 성능이 일시적으로 저하될 수 있습니다.