중요 업무용 워크로드에 대한 애플리케이션 플랫폼 고려 사항

중요 업무용 아키텍처의 주요 설계 영역은 애플리케이션 플랫폼입니다. 플랫폼은 애플리케이션을 지원하기 위해 프로비저닝해야 하는 인프라 구성 요소와 Azure 서비스를 나타냅니다. 다음은 몇 가지 중요한 권장 사항입니다.

• 계층으로 설계합니다. 올바른 서비스 집합, 구성, 애플리케이션별 종속성을 선택합니다. 이 계층화된 접근 방식은 논리적 및 물리적 구분을 만드는 데 도움이 됩니다. 역할과 함수를 정의하고 적절한 권한과 배포 전략을 할당하는 데 유용합니다. 이 접근 방식은 궁극적으로 시스템의 안정성을 높입니다.

• 중요 업무용 애플리케이션은 매우 안정적이고 데이터 센터 및 지역 실패에 대해 강해야 합니다. 활성-활성 구성에서 영역 및 지역 중복성을 구축하는 것이 주요 전략입니다. 애플리케이션 플랫폼에 대한 Azure 서비스를 선택할 때 여러 Azure 지역을 사용하도록 가용성 영역 지원과 배포 및 운영 패턴을 고려하세요.

• 배율 단위 기반 아키텍처를 사용하여 증가된 부하를 처리합니다. 배율 단위를 사용하면 리소스를 논리적으로 그룹화할 수 있으며 단위는 아키텍처의 다른 단위 또는 서비스와 독립적으로 스케일링될 수 있습니다. 용량 모델과 예상 성능을 사용하여 각 단위의 경계, 수, 기준 규모를 정의합니다.

이 아키텍처에서 애플리케이션 플랫폼은 전역, 배포 스탬프, 지역 리소스로 구성됩니다. 지역 리소스는 배포 스탬프의 일부로 프로비저닝됩니다. 각 스탬프는 배율 단위와 동일하며 비정상 상태가 될 경우 완전히 바꿀 수 있습니다.

각 계층의 리소스에는 고유한 특성이 있습니다. 자세한 내용은 일반적인 중요 업무용 워크로드의 아키텍처 패턴을 참조 하세요.

특징	고려 사항
수명	솔루션의 다른 리소스와 비교하여 예상되는 리소스 수명은 어떻게 되나요? 리소스가 전체 시스템 또는 지역의 수명을 초과하거나 수명을 공유해야 하나요? 아니면 일시적이어야 하나요?
시스템 상태	이 계층의 지속형 상태는 안정성 또는 관리 효율성에 어떤 영향을 미치나요?
도달률	리소스를 전역으로 배포해야 하나요? 리소스가 전역으로 또는 지역에서 다른 리소스와 통신할 수 있나요?
종속성	전역으로 또는 다른 지역의 다른 리소스에 대한 종속성은 무엇인가요?
확장 한도	해당 계층에서 해당 리소스에 대해 예상되는 처리량은 무엇인가요? 해당 수요에 맞게 리소스에서 얼마나 큰 스케일을 제공하나요?
가용성/재해 복구	이 계층에서 가용성 또는 재해에 미치는 영향은 무엇인가요? 시스템 중단이 발생하나요? 아니면 지역화된 용량 또는 가용성 문제만 발생하나요?

전역 리소스

이 아키텍처의 특정 리소스는 지역에 배포된 리소스에서 공유됩니다. 이 아키텍처에서는 여러 지역에 트래픽을 분산하고, 전체 애플리케이션에 대한 영구 상태를 저장하고, 전역 정적 데이터를 캐시하는 데 사용됩니다.

특징	계층 고려 사항
수명	이러한 자원은 오래 지속될 것으로 예상됩니다. 그들의 수명은 시스템의 수명이거나 그 이상입니다. 리소스는 가동 중지 시간이 없는 업데이트 작업을 지원한다고 가정할 때 현재 위치 데이터 및 컨트롤 플레인 업데이트로 관리되는 경우가 많습니다.
시스템 상태	이러한 리소스는 적어도 시스템의 수명 동안 존재므로 이 계층은 종종 전역, 지역 복제 상태를 저장해야 합니다.
도달률	리소스는 전역으로 분산되어야 합니다. 이러한 리소스는 대기 시간이 짧고 원하는 일관성으로 지역 또는 기타 리소스와 통신하는 것이 좋습니다.
종속성	리소스를 사용할 수 없으면 전역 실패의 원인이 될 수 있으므로 리소스는 지역 리소스에 대한 종속성을 피해야 합니다. 예를 들어 단일 자격 증명 모음에 보관된 인증서 또는 비밀은 자격 증명 모음이 있는 지역에 실패가 있는 경우 전역에 영향을 미칠 수 있습니다.
확장 한도	종종 이러한 리소스는 시스템의 싱글톤 인스턴스이므로 시스템 전체의 처리량을 처리할 수 있도록 스케일링할 수 있어야 합니다.
가용성/재해 복구	지역 및 스탬프 리소스는 전역 리소스를 사용하거나 전면에 배치될 수 있으므로 전체 시스템의 상태를 위해 전역 리소스를 고가용성 및 재해 복구를 사용하여 구성하는 것이 중요합니다.

이 아키텍처에서 전역 계층 리소스는 다른 전역 계층 리소스의 로그와 메트릭 저장을 위한 Azure Front Door, Azure Cosmos DB, Azure Container Registry, Azure Log Analytics입니다.

이 디자인에는 Microsoft Entra ID 및 Azure DNS와 같은 다른 기본 리소스가 있습니다. 간결함을 위해 이 이미지에서는 생략되었습니다.

글로벌 부하 분산 장치

Azure Front Door는 사용자 트래픽의 유일한 진입점으로 사용됩니다. Azure는 Azure Front Door가 99.99%의 시간 동안 오류 없이 요청된 콘텐츠를 배달할 수 있도록 보장합니다. 자세한 내용은 Front Door 서비스 제한을 참조하세요. Front Door를 사용할 수 없게 되면 최종 사용자에게 시스템이 다운된 것으로 표시됩니다.

Front Door 인스턴스는 API 및 프런트 엔드 SPA를 호스트하는 컴퓨팅 클러스터와 같이 구성된 백 엔드 서비스로 트래픽을 보냅니다. Front Door의 백 엔드 구성 오류로 인해 중단이 발생할 수 있습니다. 잘못된 구성으로 인한 중단을 방지하려면 Front Door 설정을 광범위하게 테스트해야 합니다.

또 다른 일반적인 오류는 TLS 인증서가 잘못 구성되었거나 누락되어 사용자가 프런트 엔드 또는 Front Door를 사용하여 백 엔드와 통신하지 못하도록 할 수 있습니다. 완화에는 수동 개입이 필요할 수 있습니다. 예를 들어 가능하면 이전 구성으로 롤백하고 인증서를 다시 발급하도록 선택할 수 있습니다. 그럼에도 불구하고 변경 내용이 적용되는 동안에는 사용할 수 없습니다. 만료 처리와 같은 운영 오버헤드를 줄이려면 Front Door에서 제공하는 관리형 인증서를 사용하는 것이 좋습니다.

Front Door는 전역 트래픽 라우팅 외에 많은 추가 기능을 제공합니다. Front Door는 통과하는 트래픽을 검사할 수 있으므로 중요한 기능은 WAF(Web Application Firewall)입니다. 방지 모드로 구성된 경우 백 엔드에 도달하기 전에 의심스러운 트래픽을 차단합니다.

Front Door 기능에 대한 자세한 내용은 Azure Front Door에 대한 FAQ를 참조하세요.

트래픽의 글로벌 배포에 대한 다른 고려 사항은 잘 설계된 프레임워크: 전역 라우팅의 중요 업무용 지침을 참조하세요.

Container Registry

Azure Container Registry OCI(Open Container Initiative) 아티팩트, 특히 helm 차트와 컨테이너 이미지를 저장하는 데 사용됩니다. 요청 흐름에 참여하지 않으며 주기적으로만 액세스됩니다. 스탬프 리소스를 배포하기 전에 컨테이너 레지스트리가 있어야 하며 지역 계층 리소스에 대한 종속성이 없어야 합니다.

이미지에 대한 런타임 액세스가 빠르고 실패에 탄력적이 되도록 레지스트리의 영역 중복성 및 지역 복제를 사용하도록 설정합니다. 사용할 수 없는 경우 인스턴스는 복제본 지역으로 장애 조치(failover)할 수 있으며 요청은 자동으로 다른 지역으로 다시 라우팅됩니다. 장애 조치가 완료될 때까지 이미지 끌어오기 시 일시적인 오류가 발생할 수 있습니다.

이미지가 실수로 삭제되고 새 컴퓨팅 노드가 이미지를 끌어올 수 없지만 기존 노드는 캐시된 이미지를 계속 사용할 수 있는 경우에도 실패가 발생할 수 있습니다. 재해 복구의 기본 전략은 재배포입니다. 컨테이너 레지스트리의 아티팩트가 파이프라인에서 다시 생성될 수 있습니다. 컨테이너 레지스트리는 모든 배포를 지원하기 위해 많은 동시 연결을 견딜 수 있어야 합니다.

프리미엄 SKU를 사용하여 지역 복제를 사용하도록 설정하는 것이 좋습니다. 영역 중복 기능은 특정 지역 내에서 복원력과 고가용성을 보장합니다. 지역 가동 중단의 경우 다른 지역의 복제본은 여전히 데이터 평면 작업에 사용할 수 있습니다. 이 SKU를 사용하면 프라이빗 엔드포인트를 통해 이미지에 대한 액세스를 제한할 수 있습니다.

자세한 내용은 Azure Container Registry 대한 모범 사례를 참조하세요.

데이터베이스

모든 상태는 지역 스탬프와 분리된 데이터베이스에 전역적으로 저장되는 것이 좋습니다. 여러 지역에 데이터베이스를 배포하여 중복성을 구축합니다. 중요 업무용 워크로드의 경우 지역 간 데이터 동기화가 주요 관심사여야 합니다. 또한 실패가 발생한 경우에도 데이터베이스에 대한 쓰기 요청이 계속 작동해야 합니다.

활성-활성 구성의 데이터 복제를 사용하는 것이 좋습니다. 애플리케이션은 다른 지역과 즉시 연결할 수 있어야 합니다. 모든 인스턴스는 읽기 및 쓰기 요청을 처리할 수 있어야 합니다.

자세한 내용은 중요 업무용 워크로드를 위한 데이터 플랫폼을 참조하세요.

전역 모니터링

Azure Log Analytics는 모든 전역 리소스의 진단 로그를 저장하는 데 사용됩니다. 특히 부하 테스트에 사용되는 환경에서는 스토리지의 일일 할당량을 제한하는 것이 좋습니다. 또한 보존 정책을 설정하세요. 이러한 제한은 한도를 초과하여 필요하지 않은 데이터를 저장함으로써 발생하는 초과 지출을 방지합니다.

기본 서비스에 대한 고려 사항

시스템은 Azure DNS 및 Microsoft Entra ID와 같이 전체 시스템이 위험에 노출될 수 있는 다른 중요한 플랫폼 서비스를 사용할 가능성이 높습니다. Azure DNS는 유효한 DNS 요청에 대해 100% 가용성 SLA를 보장합니다. Microsoft Entra는 최소 99.99% 가동 시간을 보장합니다. 그래도 실패가 발생할 경우의 영향을 알고 있어야 합니다.

많은 Azure 서비스가 기본 서비스에 의존하므로 기본 서비스에 대한 강한 종속성을 취하는 것은 불가피합니다. 이를 사용할 수 없는 경우 시스템 중단이 발생할 수 있습니다. 예를 들면 다음과 같습니다.

• Azure Front Door는 Azure DNS를 사용하여 백 엔드 및 기타 전역 서비스에 도달합니다.
• Azure Container Registry Azure DNS를 사용하여 요청을 다른 지역으로 장애 조치(failover)합니다.

두 경우 모두 Azure DNS를 사용할 수 없는 경우 두 Azure 서비스가 모두 영향을 받게 됩니다. Front Door의 사용자 요청에 대한 이름 확인이 실패합니다. Docker 이미지는 레지스트리에서 풀(pull)하지 않습니다. 많은 Azure 서비스에서 이러한 구성을 허용하지 않고 내부 DNS를 사용하기 때문에 외부 DNS 서비스를 백업으로 사용하면 위험이 완화되지 않습니다. 전체 가동 중단을 예상하세요.

마찬가지로 Microsoft Entra ID는 새 AKS 노드 만들기, Container Registry에서 이미지 가져오기 또는 Pod 시작 시 Key Vault 액세스와 같은 컨트롤 플레인 작업에 사용됩니다. Microsoft Entra ID를 사용할 수 없는 경우 기존 구성 요소는 영향을 받지 않지만 전반적인 성능이 저하될 수 있습니다. 새 Pod 또는 AKS 노드가 작동하지 않습니다. 따라서 이 시간 동안 스케일 아웃 작업이 필요한 경우 사용자 환경이 저하될 수 있습니다.

지역 배포 스탬프 리소스

이 아키텍처에서 배포 스탬프는 워크로드를 배포하고 비즈니스 트랜잭션 완료에 참여하는 리소스를 프로비저닝합니다. 스탬프는 일반적으로 Azure 지역에 대한 배포에 해당합니다. 지역에는 두 개 이상의 스탬프가 있을 수 있습니다.

특징	고려 사항
수명	리소스는 스탬프 외부의 지역 리소스가 계속 지속되는 동안 동적으로 추가하고 제거될 수 있도록 수명이 짧을 것(임시)으로 예상됩니다. 사용자에게 더 많은 복원력, 규모, 근접성을 제공하기 위해서는 임시 특성이 필요합니다.
시스템 상태	스탬프는 임시이며 언제든지 파괴될 수 있으므로 스탬프는 가능한 한 상태 비저장이어야 합니다.
도달률	지역 및 전역 리소스와 통신할 수 있습니다. 그러나 다른 지역 또는 다른 스탬프와의 통신은 피해야 합니다. 이 아키텍처에서는 이러한 리소스를 전역으로 배포할 필요가 없습니다.
종속성	스탬프 리소스는 독립적이어야 합니다. 즉, 다른 지역의 다른 스탬프 또는 구성 요소에 의존해서는 안 됩니다. 지역 및 전역 종속성이 있어야 합니다. 주요 공유 구성 요소는 데이터베이스 계층과 컨테이너 레지스트리입니다. 이 구성 요소에는 런타임 시 동기화가 필요합니다.
확장 한도	처리량은 테스트를 통해 설정됩니다. 전체 스탬프의 처리량은 성능이 가장 낮은 리소스로 제한됩니다. 스탬프 처리량은 예상되는 높은 수준의 수요와 해당 지역의 다른 스탬프를 사용할 수 없게 된 결과로 인한 장애 조치를 고려해야 합니다.
가용성/재해 복구	스탬프의 일시적인 특성으로 인해 스탬프를 다시 배포하여 재해 복구를 수행합니다. 리소스가 비정상 상태인 경우 스탬프를 전체적으로 제거하고 다시 배포할 수 있습니다.

이 아키텍처에서 스탬프 리소스는 Azure Kubernetes Service, Azure Event Hubs, Azure Key Vault, Azure Blob Storage입니다.

배율 단위

스탬프는 SU(배율 단위)로 간주될 수도 있습니다. 지정된 스탬프 내의 모든 구성 요소와 서비스는 지정된 범위에서 요청을 처리하도록 구성되고 테스트됩니다. 다음은 구현에 사용된 배율 단위의 예입니다.

각 배율 단위는 Azure 지역에 배포되므로 주로 주어진 영역의 트래픽을 처리합니다(필요한 경우 다른 지역의 트래픽을 인계받을 수 있음). 이러한 지리적 분산으로 인해 지역마다 다를 수 있는 부하 패턴 및 업무 시간이 발생할 수 있으며, 따라서 모든 SU는 유휴 상태일 때 스케일 인/다운되도록 설계되었습니다.

스케일링할 새 스탬프를 배포할 수 있습니다. 스탬프 내에서 개별 리소스는 배율 단위일 수도 있습니다.

한 단위로 Azure 서비스를 선택할 때의 몇 가지 스케일링 및 가용성 고려 사항은 다음과 같습니다.

• 배율 단위의 모든 리소스 간의 용량 관계를 평가합니다. 예를 들어 100개의 들어오는 요청을 처리하려면 Azure Cosmos DB에서 수신 컨트롤러 Pod 5개와 카탈로그 서비스 Pod 3개, 1000RU가 필요합니다. 따라서 수신 Pod를 자동 스케일링하는 경우 카탈로그 서비스와 Azure Cosmos DB RU의 스케일링이 해당 범위를 고려할 수 있습니다.

• 서비스를 부하 테스트하여 요청이 처리될 범위를 결정합니다. 결과에 따라 최소 및 최대 인스턴스와 대상 메트릭을 구성합니다. 대상에 도달하면 전체 단위의 스케일링을 자동화하도록 선택할 수 있습니다.

• Azure 구독 규모 제한 및 할당량을 검토하여 비즈니스 요구 사항에 따라 설정된 용량과 비용 모델을 지원합니다. 또한 고려 중인 개별 서비스의 제한을 확인합니다. 단위는 일반적으로 함께 배포되므로 카나리아 배포에 필요한 구독 리소스 제한을 고려합니다. 자세한 내용은 Azure 서비스 제한을 참조하세요.

• 가용성 영역을 지원하는 서비스를 선택하여 중복성을 구축합니다. 이렇게 하면 기술 선택 항목이 제한될 수 있습니다. 자세한 내용은 가용성 영역을 참조하세요.

단위 크기와 리소스 조합에 대한 다른 고려 사항은 잘 설계된 프레임워크의 중요 업무용 지침: 배율 단위 아키텍처를 참조하세요.

컴퓨팅 클러스터

워크로드를 컨테이너화하려면 각 스탬프가 컴퓨팅 클러스터를 실행해야 합니다. 이 아키텍처에서 AKS(Azure Kubernetes Service)는 Kubernetes가 최신 컨테이너화된 애플리케이션을 위한 가장 인기 있는 컴퓨팅 플랫폼이기 때문에 선택되었습니다.

AKS 클러스터의 수명은 스탬프의 임시 특성에 바인딩됩니다. 클러스터는 상태 비저장이며 영구 볼륨이 없습니다. 애플리케이션 또는 시스템 수준 유지 관리를 받을 것으로 예상되지 않으므로 관리형 디스크 대신 임시 OS 디스크를 사용합니다.

안정성을 높이기 위해 클러스터는 주어진 지역의 세 가지 가용성 영역을 모두 사용하도록 구성됩니다. 이를 통해 클러스터는 AKS 제어 영역의 99.95% SLA 가용성을 보장하는 AKS 작동 시간 SLA를 사용할 수 있습니다.

스케일링 제한, 컴퓨팅 용량, 구독 할당량과 같은 다른 요소도 안정성에 영향을 미칠 수 있습니다. 용량이 부족하거나 한도에 도달하면 스케일 아웃 및 스케일 업 작업이 실패하지만 기존 컴퓨팅은 작동할 것으로 예상됩니다.

클러스터에는 노드 풀이 필요한 경우 자동으로 스케일링할 수 있도록 자동 스케일링이 사용 설정되어 있어 안정성이 향상됩니다. 여러 노드 풀을 사용하는 경우 모든 노드 풀을 자동 스케일링해야 합니다.

Pod 수준에서 HPA(Horizontal Pod Autoscaler)는 구성된 CPU, 메모리 또는 사용자 지정 메트릭에 따라 Pod를 스케일링합니다. 부하 테스트는 워크로드의 구성 요소를 테스트하여 자동 스케일러 및 HPA 값에 대한 기준을 설정합니다.

또한 클러스터는 자동 노드 이미지 업그레이드를 위해 구성되고 해당 업그레이드 중에 적절하게 스케일링되도록 구성됩니다. 이 스케일링을 사용하면 업그레이드가 수행되는 동안 가동 중지 시간이 발생하지 않습니다. 업그레이드 중에 한 스탬프의 클러스터가 실패하더라도 다른 스탬프의 다른 클러스터는 영향을 받지 않아야 하지만, 스탬프 간 업그레이드는 가용성을 유지하기 위해 서로 다른 시간에 발생해야 합니다. 또한 클러스터 업그레이드는 동시에 사용할 수 없도록 노드 간에 자동으로 롤링됩니다.

cert-manager 및 ingress-nginx와 같은 일부 구성 요소에는 외부 컨테이너 레지스트리의 컨테이너 이미지가 필요합니다. 해당 리포지토리 또는 이미지를 사용할 수 없는 경우 새 노드(이미지가 캐시되지 않음)의 새 인스턴스를 시작하지 못할 수 있습니다. 이 위험은 이러한 이미지를 환경의 Azure Container Registry로 가져와서 완화할 수 있습니다.

스탬프는 임시이므로 이 아키텍처에서는 가시성이 중요합니다. 진단 설정은 모든 로그 및 메트릭 데이터를 지역 Log Analytics 작업 영역에 저장하도록 구성됩니다. 또한 AKS Container Insights는 클러스터 내 OMS 에이전트를 통해 사용하도록 설정됩니다. 이 에이전트를 사용하면 클러스터가 모니터링 데이터를 Log Analytics 작업 영역으로 보낼 수 있습니다.

컴퓨팅 클러스터에 대한 기타 고려 사항은 잘 설계된 프레임워크의 중요 업무용 지침: 컨테이너 오케스트레이션 및 Kubernetes를 참조하세요.

Key Vault

Azure Key Vault는 데이터베이스에 대한 연결 문자열과 같은 전역 비밀과 Event Hubs 연결 문자열과 같은 스탬프 비밀을 저장하는 데 사용됩니다.

이 아키텍처는 컴퓨팅 클러스터에서 비밀 저장소 CSI 드라이버를 사용하여 Key Vault에서 비밀을 가져옵니다. 새 Pod가 생성될 때 비밀이 필요합니다. Key Vault를 사용할 수 없는 경우 새 Pod가 시작되지 않을 수 있습니다. 결과적으로 중단이 있을 수 있습니다. 스케일 아웃 작업에 영향을 미칠 수 있고, 업데이트가 실패할 수 있으며, 새 배포를 실행할 수 없습니다.

Key Vault에는 작업 수에 제한이 있습니다. 비밀의 자동 업데이트로 인해 Pod가 많으면 한도에 도달할 수 있습니다. 이러한 상황을 피하기 위해 업데이트 빈도를 줄이도록 선택할 수 있습니다.

비밀 관리에 대한 기타 고려 사항은 잘 설계된 프레임워크의 중요 업무용 지침: 데이터 무결성 보호를 참조하세요.

Event Hubs

스탬프의 유일한 상태 저장 서비스는 짧은 기간 동안 요청을 저장하는 메시지 브로커인 Azure Event Hubs입니다. 브로커는 버퍼링과 신뢰할 수 있는 메시징에 대한 요구를 충족합니다. 처리된 요청은 글로벌 데이터베이스에 유지됩니다.

이 아키텍처에서는 표준 SKU가 사용되고 고가용성을 위해 영역 중복을 사용하도록 설정됩니다.

Event Hubs 상태는 컴퓨팅 클러스터에서 실행되는 HealthService 구성 요소에 의해 확인됩니다. 다양한 리소스에 대해 주기적인 검사를 수행합니다. 이는 비정상 상태를 검색하는 데 유용합니다. 예를 들어 메시지를 이벤트 허브로 보낼 수 없는 경우 모든 쓰기 작업에 스탬프를 사용할 수 없습니다. HealthService는 이 조건을 자동으로 감지하고 비정상 상태를 Front Door에 보고해야 합니다. 그러면 스탬프가 순환에서 제외됩니다.

스케일링 성능을 위해 자동 확장을 사용하도록 설정하는 것이 좋습니다.

자세한 내용은 중요 업무용 워크로드에 대한 메시징 서비스를 참조하세요.

메시징에 대한 기타 고려 사항은 잘 설계된 프레임워크의 중요 업무용 지침: 비동기 메시징.을 참조하세요.

Storage 계정

이 아키텍처에서는 두 개의 스토리지 계정이 프로비저닝됩니다. 두 계정 모두 ZRS(영역 중복 모드)로 배포됩니다.

Event Hubs 검사점 지정에 하나의 계정이 사용됩니다. 이 계정이 응답하지 않는 경우 스탬프는 Event Hubs의 메시지를 처리할 수 없으며 스탬프의 다른 서비스에도 영향을 미칠 수 있습니다. 이 조건은 컴퓨팅 클러스터에서 실행되는 애플리케이션 구성 요소 중 하나인 HealthService에서 주기적으로 검사합니다.

다른 하나는 UI 단일 페이지 애플리케이션을 호스트하는 데 사용됩니다. 정적 웹 사이트의 서비스 서비스에 문제가 있는 경우 Front Door는 문제를 검색하고 이 스토리지 계정에 트래픽을 보내지 않습니다. 이 시간 동안 Front Door는 캐시된 콘텐츠를 사용할 수 있습니다.

복구에 대한 자세한 내용은 재해 복구 및 스토리지 계정 장애 조치(failover)를 참조하세요.

지역 리소스

시스템에는 지역에 배포되지만 스탬프 리소스보다 오래 지속되는 리소스가 있을 수 있습니다. 이 아키텍처에서는 스탬프 리소스에 대한 가시성 데이터가 지역 데이터 저장소에 저장됩니다.

특징	고려 사항
수명	리소스는 지역의 수명을 공유하고 스탬프 리소스를 라이브로 실행합니다.
시스템 상태	지역에 저장된 상태는 지역의 수명을 초과하여 존재할 수 없습니다. 지역 간에 상태를 공유해야 하는 경우 전역 데이터 저장소를 사용하는 것이 좋습니다.
도달률	리소스를 전역적으로 배포할 필요가 없습니다. 다른 지역과의 직접 통신은 가능한 한 피해야 합니다.
종속성	리소스는 전역 리소스에 종속될 수 있지만 스탬프는 수명이 짧으므로 스탬프 리소스에는 종속될 수 없습니다.
확장 한도	지역 내의 모든 스탬프를 결합하여 지역 리소스의 스케일 제한을 결정합니다.

스탬프 리소스에 대한 데이터 모니터링

모니터링 리소스 배포는 지역 리소스의 일반적인 예입니다. 이 아키텍처에서 각 지역에는 스탬프 리소스에서 내보낸 모든 로그 및 메트릭 데이터를 저장하도록 구성된 개별 Log Analytics 작업 영역이 있습니다. 지역 리소스는 스탬프 리소스보다 오래 지속되므로 스탬프가 삭제된 경우에도 데이터를 사용할 수 있습니다.

Azure Log Analytics 및 Azure Application Insights는 플랫폼의 로그와 메트릭을 저장하는 데 사용됩니다. 특히 부하 테스트에 사용되는 환경에서는 스토리지의 일일 할당량을 제한하는 것이 좋습니다. 또한 모든 데이터를 저장하도록 보존 정책을 설정합니다. 이러한 제한은 한도를 초과하여 필요하지 않은 데이터를 저장함으로써 발생하는 초과 지출을 방지합니다.

마찬가지로 Application Insights는 모든 애플리케이션 모니터링 데이터를 수집하기 위해 지역 리소스로 배포됩니다.

모니터링에 대한 설계 권장 사항은 잘 설계된 프레임워크의 중요 업무용 지침: 상태 모델링을 참조하세요.

다음 단계

참조 구현을 배포하여 이 아키텍처에 사용되는 리소스와 해당 구성을 완전히 이해하세요.

구현: 중요 업무용 온라인