고가용성 다중 영역 웹 애플리케이션

이 예제 아키텍처는 기본 웹 애플리케이션 예제 아키텍처를 기반으로 하며 다음을 표시하도록 확장합니다.

• Azure 앱 Service 웹 애플리케이션의 확장성 및 성능을 개선하기 위한 검증된 사례
• 여러 지역에서 Azure 앱 Service 애플리케이션을 실행하여 고가용성을 달성하는 방법

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

이 워크플로는 아키텍처의 다중 지역 측면을 해결하고 기본 웹 애플리케이션을 기반으로 빌드합니다.

• 주 지역 및 보조 지역. 이 아키텍처는 더 높은 가용성을 달성하기 위해 두 지역을 사용합니다. 애플리케이션이 각 지역에 배포됩니다. 정상적으로 작동하는 동안에는 네트워크 트래픽이 주 지역으로 라우팅됩니다. 주 지역을 사용할 수 없는 경우에는 트래픽이 보조 지역으로 라우팅됩니다.
• Front Door. Azure Front Door는 다중 지역 구현에 권장되는 부하 분산 장치입니다. 일반적인 악용으로부터 보호하기 위해 WAF(웹 애플리케이션 방화벽)와 통합되며 Front Door의 네이티브 콘텐츠 캐싱 기능을 사용합니다. 이 아키텍처에서 Front Door는 우선 순위 라우팅을 위해 구성되며, 이 라우팅은 사용할 수 없게 되지 않는 한 모든 트래픽을 주 지역으로 보냅니다. 주 지역을 사용할 수 없는 경우에는 트래픽이 보조 지역으로 라우팅됩니다.
• 스토리지 계정, SQL 데이터베이스 및/또는 Azure Cosmos DB의 지역 복제.

구성 요소

이 아키텍처를 구현하는 데 사용되는 주요 기술:

• Microsoft Entra ID 는 직원이 조직을 위해 개발된 클라우드 앱에 액세스할 수 있도록 하는 클라우드 기반 ID 및 액세스 관리 서비스입니다.
• Azure DNS는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공하는 DNS 도메인에 대한 호스팅 서비스입니다. Azure에 도메인을 호스트하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다. 사용자 지정 도메인 이름(예: contoso.com)을 사용하려면 사용자 지정 도메인 이름을 IP 주소에 매핑하는 DNS 레코드를 만듭니다. 자세한 내용은 Azure App Service에서 사용자 지정 도메인 이름 구성을 참조하세요.
• Azure Content Delivery Network 는 전 세계에 전략적으로 배치된 물리적 노드에서 캐싱하여 대역폭이 높은 콘텐츠를 제공하기 위한 글로벌 솔루션입니다.
• Azure Front Door 는 계층 7 부하 분산 장치입니다. 이 아키텍처에서 HTTP 요청을 웹 프런트 엔드로 라우팅합니다. 또한 Front Door는 일반적인 악용 및 취약점으로부터 애플리케이션을 보호하는 WAF(웹 애플리케이션 방화벽)를 제공합니다. Front Door는 이 디자인의 CDN(Content Delivery Network) 솔루션에도 사용됩니다.
• Azure 앱Service는 클라우드 애플리케이션을 만들고 배포하기 위한 완전 관리형 플랫폼입니다. 이를 통해 웹앱이 실행할 컴퓨팅 리소스 집합을 정의하고, 웹앱을 배포하고, 배포 슬롯을 구성할 수 있습니다.
• Azure Function Apps 를 사용하여 백그라운드 작업을 실행할 수 있습니다. 함수는 큐에 배치되는 타이머 이벤트 또는 메시지와 같은 트리거에 의해 호출됩니다. 장기 실행 상태 저장 작업의 경우 Durable Functions를 사용합니다.
• Azure Storage 는 최신 데이터 스토리지 시나리오를 위한 클라우드 스토리지 솔루션으로, 클라우드의 다양한 데이터 개체에 대해 고가용성, 대규모 확장성, 내구성 및 보안 스토리지를 제공합니다.
• Azure Redis Cache 는 오픈 소스 구현 Redis 캐시를 기반으로 데이터를 더 빠르게 검색할 수 있도록 메모리 내 데이터 저장소를 제공하는 고성능 캐싱 서비스입니다.
• Azure SQL Database는 클라우드의 관계형 DaaS(Database-as-a-Service)입니다. SQL Database는 해당 코드 베이스를 Microsoft SQL Server 데이터베이스 엔진과 공유합니다.
• Azure Cosmos DB 는 대규모로 데이터를 관리하기 위해 전역적으로 분산되고, 완전히 관리되고, 대기 시간이 짧고, 다중 모델, 다중 쿼리 API 데이터베이스입니다.
• Azure Cognitive Search 를 사용하여 검색 제안, 유사 항목 검색 및 언어별 검색과 같은 검색 기능을 추가할 수 있습니다. Azure Search는 일반적으로 다른 데이터 저장소와 함께 사용되는데, 특히 기본 데이터 저장소에 엄격한 일관성이 필요한 경우 그렇습니다. 이러한 접근 방식에서는 신뢰할 수 있는 데이터를 다른 데이터 저장소에 저장하고 검색 인덱스를 Azure Search에 저장합니다. 또한 Azure Search는 여러 데이터 저장소의 단일 검색 인덱스를 통합하는 데 사용할 수 있습니다.

시나리오 정보

지역에서 고가용성을 달성하는 데 몇 가지 일반적인 접근 방식이 있습니다.

• 상시 대기의 능동/수동: 트래픽이 한 지역으로 이동하면 다른 하나가 상시 대기 상태에서 기다립니다. 활성 대기 는 보조 지역의 App Service가 할당되고 항상 실행 중임을 의미합니다.

• 수동 대기의 능동/수동: 트래픽이 한 지역으로 이동하면 다른 하나가 수동 대기 상태에서 기다립니다. 콜드 대기는 장애 조치(failover)가 필요할 때까지 보조 지역의 App Service가 할당되지 않음을 의미합니다. 이 방법은 실행하는 데 비용이 덜 들지만, 일반적으로 실패 상태에 있을 때 온라인 상태가 되는 데 더 오래 시간이 걸립니다.

• 능동/수동: 두 지역 모두 활성화되어 있으며, 요청이 두 지역 사이에서 부하 분산됩니다. 한 지역을 사용할 수 없게 해당 지역은 순환에서 제외됩니다.

이 참조는 상시 대기의 능동/수동에 초점을 맞춥니다.

잠재적인 사용 사례

이러한 사용 사례는 다중 지역 배포의 이점을 누릴 수 있습니다.

• LoB 애플리케이션을 위한 비즈니스 연속성 및 재해 복구 계획 설계

• Windows 또는 Linux에서 실행되는 중요 업무용 애플리케이션을 배포합니다.

• 애플리케이션 가용성을 유지하여 사용자 환경을 개선합니다.

권장 사항

개발자의 요구 사항이 여기에 설명된 아키텍처와 다를 수 있습니다. 이 섹션의 권장 사항을 시작점으로 사용합니다.

지역을 쌍으로 연결

Azure 지역은 동일한 지역 내에서 다른 지역과 쌍을 이룹니다. 일반적으로 같은 지역 쌍에서 지역을 선택합니다. 예를 들어 미국 동부 2와 미국 중부입니다. 이에 따른 장점은 다음과 같습니다.

• 광범위한 가동 중단이 발생한 경우 모든 쌍 중에서 하나 이상의 지역에 대한 복구에 우선 순위가 지정됩니다.
• 계획된 Azure 시스템 업데이트는 순차적으로 쌍을 이루는 지역으로 출시되어 가동 중지 시간을 최소화할 수 있습니다.
• 대부분의 경우 지역 쌍은 데이터 상주 요구 사항을 충족하기 위해 동일한 지리 내에 상주합니다.

그러나 두 지역 모두 애플리케이션에 필요한 모든 Azure 서비스를 지원하는지 확인합니다. 지역별 서비스를 참조하세요. 지역 쌍에 대한 자세한 내용은 BCDR(무중단 업무 방식 및 재해 복구): Azure 쌍을 이루는 지역을 참조하세요.

리소스 그룹

주 지역, 보조 지역과 Front Door를 별도의 리소스 그룹에 배치하는 것이 좋습니다. 이 할당을 통해 각 지역에 배포된 리소스를 단일 컬렉션으로 관리할 수 있습니다.

App Service 앱

웹 애플리케이션과 웹 API를 별도의 App Service 앱으로 만드는 것이 좋습니다. 이렇게 디자인하면 이들을 별도의 App Service 계획에서 실행할 수 있으므로 독립적으로 확장할 수 있습니다. 처음에 이러한 수준의 확장성이 필요하지 않은 경우 앱을 동일한 계획에 배포하고 필요한 경우 나중에 별도의 계획으로 이동할 수 있습니다.

Front Door 구성

라우팅. Front Door는 여러 라우팅 메커니즘을 지원합니다. 이 문서에 설명된 시나리오는 우선 순위 라우팅을 사용합니다. 이 설정을 사용하면 Front Door가 해당 지역의 엔드포인트에 연결할 수 없는 경우가 아닌 한 모든 요청을 주 지역으로 보냅니다. 이때 자동으로 보조 지역으로 장애 조치(failover)됩니다. 원본 풀을 각기 다른 우선 순위 값으로 설정합니다. 활성 영역에 대해서는 1을, 대기 영역 또는 수동 영역에 대해서는 2를 설정합니다.

상태 프로브. Front Door는 HTTP 프로브를 사용하여 각 백 엔드의 가용성을 모니터링합니다. 프로브는 Front Door에 보조 지역에서의 실패에 대한 합격/실패 테스트를 제공합니다. 지정된 URL 경로 요청을 전송하여 작동됩니다. 제한 시간 내에 200개의 비응답을 받으면 프로브가 실패합니다. 상태 프로브 빈도, 평가에 필요한 샘플 수 및 원본이 정상으로 표시되는 데 필요한 성공적인 샘플 수를 구성할 수 있습니다. Front Door가 원본을 성능 저하로 표시하면 다른 원본으로 장애 조치(fails over)됩니다. 자세한 내용은 상태 프로브를 참조하세요.

모범 사례는 애플리케이션의 전반적인 상태를 보고하는 상태 프로브 경로를 애플리케이션 원본에 만드는 것입니다. 이 상태 프로브는 App Service 앱, 스토리지 큐, SQL Database와 같은 중요 종속성을 확인해야 합니다. 그렇지 않으면 애플리케이션의 중요한 부분이 실제로 실패할 때 프로브에서 정상 원본을 보고할 수 있습니다. 반면에 하위 우선 순위 서비스를 확인하는 데 상태 프로브를 사용하지 않습니다. 예를 들어 메일 서비스가 중단되면 애플리케이션이 두 번째 공급자로 전환하거나 나중에 메일을 보낼 수 있습니다. 이 디자인 패턴에 대한 자세한 내용은 상태 엔드포인트 모니터링 패턴을 참조하세요.

인터넷에서 원본을 보호하는 것은 공개적으로 액세스할 수 있는 앱을 구현하는 데 중요한 부분입니다. Front Door와 앱의 수신 통신을 보호하기 위한 Microsoft의 권장 설계 및 구현 패턴에 대해 알아보려면 네트워크 보안 수신 구현을 참조하세요.

CDN. Front Door의 기본 CDN 기능을 사용하여 정적 콘텐츠를 캐시합니다. CDN의 주요 이점은 사용자의 대기 시간이 줄어드는 것인데 그 이유는 콘텐츠가 사용자와 지리적으로 가까운 에지 서버에 캐시되기 때문입니다. 또한 애플리케이션에 의해 트래픽이 처리되지 않기 때문에 CDN은 애플리케이션의 부하를 줄일 수 있습니다. 또한 Front Door는 동적 사이트 가속을 제공하여 정적 콘텐츠 캐싱에서만 사용할 수 있는 것보다 웹앱에 더 나은 전반적인 사용자 환경을 제공할 수 있습니다.

SQL Database

활성 지역 복제와 자동 장애 조치(failover) 그룹을 사용하여 데이터베이스의 탄력성을 높이세요. 활성 지역 복제를 사용하면 주 지역에서 하나 이상(최대 4개)의 다른 지역으로 데이터베이스를 복제할 수 있습니다. 자동 장애 조치 그룹은 앱에 대한 코드 변경 없이 보조 데이터베이스로 장애 조치할 수 있도록 하여 활성 지역 복제를 기반으로 구축됩니다. 장애 조치는 사용자가 만든 정책 정의에 따라 수동으로 또는 자동으로 수행할 수 있습니다. 자동 장애 조치 그룹을 사용하려면 개별 데이터베이스의 연결 문자열이 아니라 장애 조치 그룹에 대해 자동으로 생성된 장애 조치 연결 문자열을 사용하여 연결 문자열을 구성해야 합니다.

Azure Cosmos DB

Azure Cosmos DB는 여러 쓰기 지역을 포함한 활성-활성 패턴에서 지역 간에 지역 복제를 지원합니다. 또는 한 지역을 쓰기 가능 지역으로 지정하고 기타 지역을 읽기 전용 복제본으로 지정할 수 있습니다. 지역 가동 중단이 발생하면 다른 지역을 쓰기 지역으로 선택하여 장애 조치할 수 있습니다. 클라이언트 SDK에서는 현재 쓰기 지역에 쓰기 요청을 자동으로 보내므로 장애 조치(failover) 후에 클라이언트 구성을 업데이트할 필요가 없습니다. 자세한 내용은 Azure Cosmos DB를 사용한 글로벌 데이터 분산을 참조하세요.

스토리지

Azure Storage의 경우 RA-GRS(읽기 액세스 지역 중복 스토리지)를 사용합니다. RA-GRS 스토리지를 사용하면 데이터가 보조 지역에 복제됩니다. 별도의 엔드포인트를 통해 보조 지역의 데이터에 읽기 전용으로 액세스할 수 있습니다. 보조 지역에 대한 사용자 시작 장애 조치는 지역에서 복제된 스토리지 계정에 대해 지원됩니다. 스토리지 계정 장애 조치를 시작하면 DNS 레코드가 자동으로 업데이트되어 보조 스토리지 계정이 새로운 기본 스토리지 계정이 됩니다. 장애 조치는 필요하다고 판단되는 경우에만 수행해야 합니다. 이 요구 사항은 조직의 재해 복구 계획에 의해 정의되며 아래 고려 사항 섹션에 설명된 대로 영향을 고려해야 합니다.

지역 가동 중단이나 재해가 발생할 경우 Azure Storage 팀이 보조 지역에 대해 지역 장애 조치를 수행하기로 결정할 수 있습니다. 이러한 유형의 장애 조치의 경우 고객 작업이 필요하지 않습니다. 이러한 경우 기본 지역으로 장애 복구도 Azure 스토리지 팀에서 관리합니다.

경우에 따라 블록 Blob에 대한 개체 복제가 작업 부하에 대한 충분한 복제 솔루션이 될 수 있습니다. 이 복제 기능을 사용하면 기본 스토리지 계정에서 보조 지역의 스토리지 계정으로 개별 블록 Blob을 복사할 수 있습니다. 이 접근 방식의 이점은 복제되는 데이터를 세분화하여 제어할 수 있다는 것입니다. 복제되는 블록 Blob 유형을 보다 세분화하여 제어하기 위해 복제 정책을 정의할 수 있습니다. 정책 정의의 예로는 다음이 포함되지만 이에 국한되지 않습니다.

• 정책을 만든 후에 추가된 블록 Blob만 복제됩니다.
• 지정된 날짜 및 시간 후에 추가된 블록 Blob만 복제됩니다.
• 지정된 접두사와 일치하는 블록 Blob만 복제됩니다.

Queue Storage는 이 시나리오에서 Azure Service Bus에 대한 대체 메시징 옵션으로 참조됩니다. 그러나 메시징 솔루션에 대해 큐 스토리지를 사용하는 경우 큐 스토리지가 스토리지 계정에 상주하므로 지역 복제와 관련하여 위에 제공된 지침이 여기에 적용됩니다. 그러나 메시지는 보조 지역에 복제되지 않으며 해당 상태는 지역과 불가분의 관계라는 점을 이해하는 것이 중요합니다.

Azure Service Bus

Azure Service Bus에 제공되는 최고의 복원력을 활용하려면 네임스페이스에 프리미엄 계층을 사용하세요. 프리미엄 계층은 가용성 영역을 활용하여 데이터 센터 중단에 대한 네임스페이스의 탄력성을 높입니다. 여러 데이터 센터에 영향을 미치는 광범위한 재해가 발생한 경우 프리미엄 계층에 포함된 지리적 재해 복구 기능이 복구에 도움이 될 수 있습니다. 지리적 재해 복구 기능은 네임스페이스의 전체 구성(큐, 토픽, 구독, 필터)이 페어링될 때 기본 네임스페이스에서 보조 네임스페이스로 지속적으로 복제되도록 합니다. 이를 통해 언제든지 기본에서 보조로 한 번만 장애 조치 이동을 시작할 수 있습니다. 장애 조치 이동은 네임스페이스에 대해 선택한 별칭 이름을 보조 네임스페이스로 다시 가리킨 다음 페어링을 끊습니다. 장애 조치가 시작된 후에는 거의 즉시 이루어집니다.

Azure Cognitive Search

Cognitive Search에서 여러 개의 복제본을 통해 가용성을 달성하는 반면 BCDR(비즈니스 연속성 및 재해 복구)는 여러 검색 서비스를 통해 달성됩니다.

Cognitive Search 복제본은 인덱스의 복제본입니다. 복제본이 여러 개인 경우 Azure Cognitive Search는 한 복제본에 대해 컴퓨터 다시 부팅 및 유지 관리를 수행할 수 있습니다. 반면 쿼리 실행은 다른 복제본에서 계속됩니다. 복제본 추가에 대한 자세한 내용은 복제본 및 파티션 추가 또는 축소를 참조하세요.

검색 서비스에 두 개 이상의 복제본을 추가하여 Azure Cognitive Search에서 가용성 영역을 활용할 수 있습니다. 각 복제본은 지역 내의 다른 가용성 영역에 배치됩니다.

BCDR 고려 사항은 별도의 지역에 있는 여러 서비스 문서를 참조하세요.

Azure Cache for Redis

Azure Cache for Redis의 모든 계층은 고가용성을 위한 표준 복제를 제공하지만 더 높은 수준의 복원력과 복구 가능성을 제공하려면 프리미엄 또는 엔터프라이즈 계층을 권장합니다. 이러한 계층에 대한 복원력 및 복구 가능성 기능과 옵션의 전체 목록은 고가용성 및 재해 복구를 검토하세요. 비즈니스 요구 사항에 따라 인프라에 가장 적합한 계층이 결정됩니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요. 지역 간 고가용성을 위해 디자인할 때 이러한 점을 고려합니다.

Azure Front Door

주 지역을 사용할 수 없게 되면 Azure Front Door가 자동으로 장애 조치(failover)합니다. Front Door가 장애 조치를 하면 일정 시간(일반적으로 약 20~60초) 동안 클라이언트가 애플리케이션에 접근할 수 없습니다. 그 기간은 다음과 같은 요인에 의해 영향을 받습니다.

• 상태 프로브의 빈도. 상태 프로브가 전송되는 빈도가 높을수록 Front Door가 가동 중지 시간을 감지하거나 원본이 정상 상태로 돌아오는 속도가 빨라집니다.
• 샘플 크기 구성. 이 구성은 기본 원본에 접근할 수 없게 되었음을 감지하기 위해 상태 프로브에 필요한 샘플 수를 제어합니다. 이 값이 너무 낮으면 일시적인 문제에서 가양성이 나올 수 있습니다.

Front Door는 시스템에서 오류가 발생할 수 있는 지점입니다. 서비스가 실패하면 클라이언트가 가동 중지 시간 동안 애플리케이션에 액세스할 수 없습니다. Front Door SLA(서비스 수준 계약)를 검토하고 Front Doorr만 사용하여 고가용성을 위한 비즈니스 요구 사항을 충족하는지 여부를 확인합니다. 그렇지 않은 경우 다른 트래픽 관리 솔루션을 장애 복구(Failback)로 추가합니다. Front Door 서비스가 실패하면 다른 트래픽 관리 서비스를 가리키도록 DNS의 CNAME(정식 이름) 레코드를 변경합니다. 이 단계는 수동으로 수행해야 하며 DNS 변경 사항이 전파될 때까지 애플리케이션을 사용할 수 없습니다.

Azure Front Door 표준 및 프리미엄 계층은 Azure Front Door(클래식), Microsoft의 Azure CDN 표준(클래식), Azure WAF의 기능을 단일 플랫폼으로 결합합니다. Azure Front Door 표준 또는 프리미엄을 사용하면 실패 지점이 줄어들고 향상된 제어, 모니터링, 보안을 사용할 수 있습니다. 자세한 내용은 Azure Front Door 계층 개요를 참조하세요.

SQL Database

SQL 데이터베이스의 RPO(복구 지점 목표) 및 예상 RTO(복구 시간 목표)는 Azure SQL Database를 사용한 비즈니스 연속성 개요에 설명되어 있습니다.

활성 지역 복제는 복제된 각 데이터베이스의 비용을 효과적으로 두 배로 늘릴 수 있습니다. 샌드박스, 테스트, 개발 데이터베이스는 일반적으로 복제에 권장되지 않습니다.

Azure Cosmos DB

Azure Cosmos DB에 대한 RPO 및 RTO(복구 시간 목표)는 사용되는 일관성 수준을 통해 구성할 수 있으며, 가용성, 데이터 내구성, 처리량 간에 상충 관계가 생깁니다. Azure Cosmos DB는 다중 마스터와의 완화된 일관성 수준을 위해 최소 RTO 0 또는 단일 마스터와의 강력한 일관성을 위해 RPO 0을 제공합니다. Azure Cosmos DB 일관성 수준에 대한 자세한 내용은 Azure Cosmos DB의 일관성 수준 및 데이터 내구성을 참조하세요.

스토리지

RA-GRS 스토리지는 지속형 스토리지를 제공하지만 장애 조치 수행을 고려할 때 다음 요소를 고려하는 것이 중요합니다.

• 데이터 손실 예상: 보조 지역에 대한 데이터 복제는 비동기적으로 수행됩니다. 따라서 지리적 장애 조치가 수행되는 경우 기본 계정의 변경 사항이 보조 계정과 완전히 동기화되지 않으면 일부 데이터의 손실이 예상됩니다. 보조 스토리지 계정의 마지막 동기화 시간 속성을 확인하여 주 지역의 데이터가 보조 지역에 성공적으로 기록된 마지막 시간을 확인할 수 있습니다.

• 그에 따라 RTO(복구 시간 목표)를 계획합니다. 보조 지역으로의 장애 조치는 일반적으로 약 1시간이 걸리므로 RTO 매개 변수를 계산할 때 DR 계획에서 이 정보를 고려해야 합니다.

• 장애 복구를 신중하게 계획합니다. 스토리지 계정이 장애 조치되면 원래 기본 계정의 데이터가 손실된다는 점을 이해하는 것이 중요합니다. 신중한 계획 없이 주 지역으로 장애 복구를 시도하는 것은 위험합니다. 장애 조치가 완료되면 장애 조치 지역의 새로운 기본 계정이 LRS(로컬 중복 스토리지)에 대해 구성됩니다. 주 지역에 대한 복제를 시작한 다음 계정이 동기화될 수 있도록 충분한 시간을 제공하려면 지역 복제 스토리지로 수동으로 재구성해야 합니다.

• 네트워크 가동 중단 등의 일시적인 실패는 스토리지 장애 조치를 트리거하지 않습니다. 일시적인 장애를 복원할 수 있도록 애플리케이션을 디자인합니다. 완화 옵션은 다음과 같습니다.

  • 보조 지역에서 읽습니다.
  • 새 쓰기 작업(예: 메시지 큐에 넣기)을 위해 다른 스토리지 계정으로 일시적으로 전환합니다.
  • 데이터를 보조 지역에서 다른 스토리지 계정으로 복사합니다.
  • 시스템이 장애 복구(failback)할 때까지 축소된 기능을 제공합니다.

자세한 내용은 Azure Storage 중단이 발생할 경우 수행할 작업을 참조하세요.

블록 Blob에 개체 복제를 사용할 때 고려해야 할 사항은 개체 복제에 대한 전제 조건 및 주의 사항 문서를 참조하세요.

Azure Service Bus

프리미엄 Azure Service Bus 계층에 포함된 지리적 재해 복구 기능을 사용하면 동일한 구성으로 작업의 즉각적인 연속성을 사용할 수 있다는 점을 이해하는 것이 중요합니다. 그러나 큐, 토픽 구독 또는 배달 못 한 편지 큐에 보관된 메시지는 복제하지 않습니다. 따라서 보조 지역으로의 원활한 장애 조치를 보장하려면 완화 전략이 필요합니다. 기타 고려 사항 및 완화 전략에 대한 자세한 설명은 고려해야 할 중요 사항 및 재해 복구 고려 사항 설명서를 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

들어오는 트래픽 제한 Front Door에서만 트래픽을 허용하도록 애플리케이션을 구성합니다. 이렇게 하면 앱에 도달하기 전에 모든 트래픽이 WAF를 통과합니다. 자세한 내용은 내 백 엔드에 Azure Front Door만 액세스하도록 잠그려면 어떻게 해야 할까요?를 참조하세요.

CORS(원본 간 리소스 공유) 웹 사이트 및 웹 API를 별도의 앱으로 만드는 경우 CORS를 사용하도록 설정하지 않으면 웹 사이트에서 API에 대한 클라이언트 쪽 AJAX 호출을 수행할 수 없습니다.

App Services에서는 애플리케이션 코드를 작성할 필요 없이 기본적으로 CORS를 지원합니다. CORS를 사용하여 JavaScript에서 API 앱 사용을 참조하세요. API에 대해 허용되는 원본 목록에 웹 사이트를 추가합니다.

SQL Database 암호화 데이터베이스의 미사용 데이터를 암호화해야 하는 경우 투명한 데이터 암호화 사용합니다. 이 기능은 전체 데이터베이스(백업 및 트랜잭션 로그 파일 포함)의 실시간 암호화 및 암호 해독을 수행하며 애플리케이션을 변경할 필요가 없습니다. 암호화를 수행하면 대기 시간이 늘어나므로, 고유한 데이터베이스에 보호해야 하는 데이터를 분리하고 해당 데이터베이스에 대해서만 암호화를 사용하도록 설정하는 것이 좋습니다.

ID 이 아키텍처의 구성 요소에 대한 ID를 정의할 때 가능한 경우 시스템 관리 ID를 사용하여 자격 증명을 관리할 필요와 자격 증명 관리에 내재된 위험을 줄입니다. 시스템 관리 ID를 사용할 수 없는 경우 모든 사용자 관리 ID가 하나의 지역에만 존재하고 지역 경계 간에 공유되지 않도록 해야 합니다.

서비스 방화벽 구성 요소에 대한 서비스 방화벽을 구성할 때 지역-로컬 서비스만 서비스에 액세스할 수 있는지와 서비스에서 아웃바운드 연결만 허용하는지 확인합니다. 이 연결은 복제본(replica) 및 애플리케이션 기능에 명시적으로 필요합니다. 향상된 제어 및 구분을 위해 Azure Private Link를 사용하는 것이 좋습니다. 웹 애플리케이션 보안에 대한 자세한 내용은 고가용성 영역 중복 웹 애플리케이션 기준을 참조 하세요.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

캐싱 캐싱을 사용하여 자주 변경되지 않는 콘텐츠를 제공하는 서버의 부하를 줄입니다. 페이지의 모든 렌더링 주기는 컴퓨팅, 메모리 및 대역폭을 소비하기 때문에 비용에 영향을 미칠 수 있습니다. 특히 JavaScript 단일 페이지 앱 및 미디어 스트리밍 콘텐츠와 같은 정적 콘텐츠 서비스의 경우 캐싱을 사용하여 이러한 비용을 크게 줄일 수 있습니다.

앱에 정적 콘텐츠가 있는 경우 CDN을 사용하여 프런트 엔드 서버의 부하를 줄입니다. 자주 변경되지 않는 데이터의 경우 Azure Cache for Redis를 사용합니다.

자동 크기 조정을 위해 구성된 상태 비정 상 앱은 상태 저장 앱보다 비용 효율적입니다. 세션 상태를 사용하는 ASP.NET 애플리케이션의 경우 Azure Cache for Redis를 사용하여 메모리에 저장합니다. 자세한 내용은 Azure Cache for Redis용 ASP.NET 세션 상태 공급자를 참조하세요. 또 다른 옵션은 세션 상태 공급자를 통해 Azure Cosmos DB를 백 엔드 상태 저장소로 사용하는 것입니다. Azure Cosmos DB를 ASP.NET 세션 상태 및 캐싱 공급자로 사용을 참조하세요.

함수는 HTTP 요청을 처리하는 동일한 인스턴스에서 백그라운드 작업이 실행되지 않도록 전용 App Service 계획에 함수 앱을 배치하는 것이 좋습니다. 백그라운드 작업을 일시적으로 실행하는 경우 사용 플랜을 사용하는 것이 좋습니다. 그러면 매시간이 아닌 실행의 수 및 사용된 리소스를 기준으로 요금이 청구됩니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

가격 책정 계산기를 사용하여 비용을 예측해 보세요. 이 섹션의 권장 사항은 비용을 줄이는 데 도움이 될 수 있습니다.

Azure Front Door

Azure Front Door 청구는 세 가지의 가격 책정 계층, 즉 아웃바운드 데이터 전송, 인바운드 데이터 전송 및 라우팅 규칙이 있습니다. 자세한 내용은 Azure Front Door 가격 책정을 참조하세요. 가격 차트에는 원본 서비스에서 데이터에 액세스하고 Front Door로 전송하는 비용은 포함되지 않습니다. 이러한 비용은 대역폭 가격 정보에 설명된 데이터 전송 요금을 기준으로 청구됩니다.

Azure Cosmos DB

Azure Cosmos DB 가격 책정을 결정하는 두 가지 요인이 있습니다.

• 프로비전된 처리량 또는 초당 요청 단위(RU/s)입니다.

  Azure Cosmos DB, 표준 및 자동 스케일링에서 프로비저닝할 수 있는 처리량에는 두 가지 유형이 있습니다. 표준 처리량은 지정한 RU/s를 보장하는 데 필요한 리소스를 할당합니다. 자동 스케일링의 경우 사용자가 최대 처리량을 프로비저닝하고 Azure Cosmos DB는 최대 자동 스케일링 처리량의 최소 10%를 사용하여 로드에 따라 즉시 스케일링 업 또는 다운을 합니다. 표준 처리량은 시간당 프로비전된 처리량에 대해 청구됩니다. 자동 스케일링 처리량은 시간당 사용되는 최대 처리량에 대해 청구됩니다.

• 사용된 스토리지. 지정된 1시간 동안 데이터 및 인덱스에 사용된 총 스토리지 양(GB)에 대해 정액 요금이 부과됩니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

성능 효율성

Azure App Service의 주요 이점은 부하에 따라 애플리케이션을 확장할 수 있다는 점입니다. 다음은 애플리케이션 확장을 계획할 때 염두에 둘 몇 가지 고려 사항입니다.

App Service 앱

솔루션에 여러 App Service 앱이 포함되어 있는 경우 App Service 계획이 분리되도록 배포하는 것을 고려합니다. 이러한 방식을 사용하면 개별 인스턴스에서 실행되므로 개별적으로 확장할 수 있습니다.

SQL Database

데이터베이스를 분할하여 SQL데이터베이스의 확장성을 높입니다. 분할은 데이터베이스를 가로로 분할합니다. 분할을 사용하면 Elastic Database 도구로 데이터베이스를 가로로 확장할 수 있습니다. 분할의 잠재적 이점은 다음과 같습니다.

• 트랜잭션 처리량이 늘어납니다.
• 쿼리가 데이터의 하위 집합에서 더 빨리 실행될 수 있습니다.

Azure Front Door

Front Door는 SSL 오프로드를 수행할 수 있으며 백 엔드 웹앱과의 총 TCP 연결 수를 줄일 수도 있습니다. 이는 웹앱이 SSL 핸드셰이크 및 TCP 연결의 작은 볼륨을 관리하기 때문에 확장성을 향상시킵니다. 이러한 성능 향상은 높은 수준의 연결 재사용으로 인해 웹앱에 요청을 HTTPS로 전달하는 경우에도 적용됩니다.

Azure Search

Azure Search는 주요 데이터 저장소에서 복잡한 데이터 검색을 수행하는 데 따른 오버헤드를 제거하므로 부하를 처리하도록 확장할 수 있습니다. Azure Search의 쿼리 및 인덱싱 작업을 위한 리소스 수준 확장을 참조하세요.

운영 우수성

운영 우수성 은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행되는 운영 프로세스를 의미하며 잘 설계된 프레임워크 안정성 지침의 확장입니다. 이 지침은 워크로드를 사용할 수 있고 모든 규모의 실패에서 복구할 수 있도록 애플리케이션 프레임워크에 복원력을 설계하는 방법에 대한 자세한 개요를 제공합니다. 이 접근 방식의 핵심 원칙은 이 설계에서 알 수 있듯이 애플리케이션 인프라를 고가용성으로 여러 지역에 걸쳐 최적으로 설계하는 것입니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Arvind Boggaram Pandurangaiah Setty | 선임 컨설턴트

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

• Azure Front Door - 트래픽 라우팅 방법에 대한 심층 분석

• 엔드포인트 모니터링 패턴을 기반으로 애플리케이션의 전반적인 상태를 보고하는 상태 프로브 만들기

• Azure SQL 자동 장애 조치(failover) 그룹 사용

• Azure 쌍을 이루는 지역을 사용하여 비즈니스 연속성 및 재해 복구 보장

관련 리소스

• 다중 지역 N 계층 애플리케이션도 비슷한 시나리오입니다. 여러 Azure 지역에서 실행되는 N 계층 애플리케이션을 보여 줍니다.

• Azure 애플리케이션 디자인 원칙