지리적으로 분산된 애플리케이션 아키텍처 디자인

네트워킹 구성 요소가 지역 중단의 영향을 완화하기 위해 요청을 여러 지역으로 라우팅하는 경우 기본 및 대기 지역 모두에서 이러한 요청에 응답할 수 있는 애플리케이션 서비스를 디자인해야 합니다.

이전에 우선 순위 백엔드 할당으로 Azure Front Door를 구성할 계획임을 기억하세요. 미국 동부 지역을 주 지역으로, 미국 서부 지역을 대기 지역으로 할당합니다. 지역 오류가 발생하면 요청은 정상 작동 중인 지역의 App Service로 보내집니다. 사용자 액세스, 복제된 스토리지 및 애플리케이션 코드에 대해 이러한 장애 조치(failover)를 지원하도록 각 지역의 리소스를 구성해야 합니다.

여기서는 솔루션의 애플리케이션 서비스를 검사하고 다중 지역 아키텍처에서 작동하도록 수정해야 하는지 여부를 확인합니다. 특히 Active Directory, 정적 콘텐츠 스토리지, 웹앱, 웹 API, 큐, Azure 함수 및 데이터 캐시를 살펴봅니다.

Microsoft Entra ID

배송 추적 포털에서 사용자는 추적 번호를 입력하여 구매 배달을 추적할 수 있습니다. 그러나 일반 사용자는 배달 프롬프트 및 기타 통계와 같은 고급 기능에 액세스하기 위해 멤버 자격에 등록할 수 있습니다. Microsoft Entra ID에 사용자 계정을 저장하는 추적 포털을 개발했습니다.

Microsoft Entra ID는 기본적으로 전역 시스템으로 설계되었습니다. 따라서 지역 오류에 취약하지 않으며 시스템의 이 구성 요소를 수정할 필요가 없습니다.

Azure Blob Storage (애저 블롭 스토리지)

이미지 및 비디오와 같은 정적 콘텐츠는 Azure Storage 계정에 Blob(Binary Large Objects)로 저장되고 Azure CDN을 통해 사용자에게 제공됩니다.

원래 디자인에서는 LRS(로컬 중복 스토리지)를 사용하도록 선택했기 때문에 스토리지 계정이 단일 지역에 포함됩니다. 데이터는 LRS를 사용하는 단일 데이터 센터 내에서만 복제됩니다. 따라서 이 구성에 지역 가동 중단이 있는 경우 스토리지 계정을 사용할 수 없습니다. CDN에서 이미 캐시한 정적 콘텐츠는 사용자가 계속 사용할 수 있습니다.

ZRS(영역 중복 스토리지)에서도 마찬가지입니다. 이 구성에서 데이터가 다른 데이터 센터에 복제되더라도 이러한 모든 데이터 센터는 여전히 동일한 지역에 있습니다. 지역 가동 중단은 이 구성의 스토리지 계정에도 영향을 줍니다.

디자인에서는 정적 콘텐츠를 캐시하기 위해 CDN 구성을 많이 사용합니다. 가동 중단 중에 사용자가 CDN 캐시에 아직 없는 정적 파일을 요청할 수 있습니다. 이 요청으로 인해 표시할 수 없는 그래픽 또는 비디오가 생성됩니다.

지역 중복 스토리지 옵션을 선택할 때 스토리지 계정을 여러 지역에 복제하여 이러한 가능성을 제거할 수 있습니다. 지역 가동 중단 중에 정적 콘텐츠를 추가하지 못하도록 읽기 전용 복제 옵션도 사용할 수 있습니다.

지역 중복을 사용하도록 설정해야 하는 경우 선택할 수 있는 두 가지 옵션이 있습니다. 이 옵션은 RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)입니다. 우리가 선택하는 것은 예산과 필요한 최대 시간의 비율에 따라 달라집니다.

Azure App Service 및 Azure Function Apps

배송 추적 포털은 두 개의 Azure App Services를 구현합니다. 첫 번째 App Service는 사용자 연결 웹 인터페이스를 구현하는 웹앱을 호스트하고, 두 번째 App Service는 모바일 앱에서 배송 데이터를 추적하는 데 사용하는 웹 API를 호스트합니다. 모든 백그라운드 작업은 Azure Function 앱으로 실행됩니다.

원래 디자인에서 각 Azure App Service는 단일 Azure 지역으로 지역화됩니다. 보조 지역(미국 서부)에 두 번째 App Service를 만들고 새 다중 지역 아키텍처를 지원하기 위해 웹 프로젝트를 배포합니다. 주 지역을 사용할 수 없는 경우 보조 지역으로 요청을 보내도록 Azure Front Door 우선 순위 라우팅 모드를 구성합니다.

장애 조치(failover)가 최대한 원활하도록 하려면 웹 애플리케이션이 메모리에 세션 상태 정보를 저장하지 않는지 확인합니다. 데이터 손실로 끝나지 않도록 웹 사이트를 변경합니다. 예를 들어 코드에서 사용자의 배송 목록을 메모리에 저장하는 경우 장애 조치(failover)가 발생하면 이 목록이 손실됩니다.

각 웹 요청은 세션 상태가 저장되지 않은 경우 다른 웹 요청에 영향을 주지 않고 처리됩니다. 사용자 세션 중간에 장애 조치(failover)가 발생하는 경우 장애 조치(failover)는 사용자에게 투명해야 합니다.

Azure Function 앱과 비슷한 변경을 합니다. 보조 지역에 별도의 Azure Function 인스턴스를 만들고 주 지역에서 실행되는 것과 동일한 사용자 지정 코드를 배포합니다.

Azure Storage 큐

원래 단일 지역 아키텍처에서는 Azure Storage 계정의 큐를 사용하여 App Service와 함수 앱 간의 통신을 관리했습니다. 웹앱 또는 웹 API가 백그라운드 작업을 실행해야 하는 경우 큐에 필요한 모든 정보가 포함된 메시지를 배치합니다. 함수 앱은 큐에서 새 메시지를 모니터링하고 데이터 저장소에 대해 필요한 쿼리를 실행하여 백그라운드 작업을 실행합니다.

이러한 방식으로 큐를 사용하는 경우 순서대로 웹 요청에서 높은 수요를 관리할 수 있습니다. 실행할 백그라운드 작업이 많으면 큐가 쌓일 수 있지만 작업은 삭제되지 않습니다. 처리될 때까지 큐에 유지됩니다. 함수 앱은 큐를 통해 작동하며 요청이 감소하면 크기를 줄입니다. 수요가 지속되면 함수 앱의 인스턴스 수가 증가합니다.

배송 추적 포털의 다중 지역 버전의 경우 장애 조치(failover)가 발생할 때 큐 항목이 손실되지 않도록 해야 합니다. 큐는 Azure Storage에 정의되어 있으며 지역 복제에 중복 옵션을 사용할 수 있습니다.

저희 큐가 읽기 및 쓰기 작업을 지원하므로 읽기 액세스 중복 옵션을 사용할 수 없다는 점을 명심하세요. App Service는 큐에 항목을 추가해야 하며 함수 앱은 큐에서 완료된 항목을 제거해야 합니다. 대신, GRS(지역 중복 스토리지) 또는 GZRS(지리적 영역 중복 스토리지)를 사용합니다.

Azure Redis 캐시

Azure Redis Cache를 사용하여 데이터 스토리지의 성능을 최대화합니다. Redis는 데이터베이스에서 데이터를 요청할 때 앱에서 생성된 모든 쿼리 결과를 캐시합니다. 유사한 데이터에 대한 추가 쿼리는 데이터베이스 쿼리가 필요하지 않으며 Redis 캐시에서 가져옵니다.

다중 지역 아키텍처의 경우 기본 및 대기 지역 모두에서 Redis Cache 인스턴스를 만듭니다. 장애 조치가 발생했을 때, 대기 지역의 Redis 캐시는 비어 있을 가능성이 높습니다. 빈 캐시로 인해 오류가 발생하지는 않지만 데이터가 새 캐시를 채우면 성능이 일시적으로 떨어질 수 있습니다.