고가용성 및 내결함성은 잘 설계된 솔루션의 핵심 구성 요소입니다. 강력한 구성에는 가동 중지 시간을 줄이고 시스템을 자동으로 실행하기 위한 예기치 않은 오류에 대한 긴급 계획이 포함됩니다.
클라우드에 앱을 배포하는 경우 앱 인프라 기반에 대한 해당 클라우드의 지역을 선택합니다. 단일 지역에만 앱을 배포하고 해당 지역을 사용할 수 없게 되면 앱도 사용할 수 없습니다. 가용성 부족은 앱의 SLA(서비스 수준 계약)의 조건에 따라 허용되지 않을 수 있습니다. 가용성을 보장하려면 클라우드의 여러 지역에 앱 및 해당 서비스를 배포합니다.
이 자습서에서는 고가용성 다중 지역 웹앱을 배포하는 방법을 설명합니다. 이 절차는 웹앱과 Azure Front Door 구성된 간단한 시나리오를 구현합니다. 개념을 확장하여 다른 인프라 패턴을 지원할 수 있습니다. 예를 들어 앱이 Azure 데이터베이스 제품 또는 스토리지 계정에 연결하는 경우 SQL 데이터베이스에 대한 활성 지역 복제 및 Azure Storage 중복성 참조하세요. 자세한 시나리오에 대한 참조 아키텍처는 .NET 대한 신뢰할 수 있는 웹앱 패턴을 참조하세요.
이 자습서에서는 다음을 수행합니다.
- 별도의 지역에서 동일한 App Service 앱 만들기
- App Service에 대한 공용 액세스를 차단하는 액세스 제한이 있는 Azure Front Door 만들기
필수 구성 요소
Azure 계정이 없는 경우 시작하기 전에 free 계정을 만듭니다.
이 자습서를 완료하려면 다음이 필요합니다.
Azure Cloud Shell Bash 환경을 사용합니다. 자세한 내용은 Azure Cloud Shell 시작하기를 참조하세요.
CLI 참조 명령을 로컬로 실행하려면 Azure CLI를 설치하세요. Windows 또는 macOS에서 실행하는 경우 Docker 컨테이너에서 Azure CLI 실행하는 것이 좋습니다. 자세한 내용은 Docker 컨테이너에서 Azure CLI 실행하는 방법 참조하세요.
로컬 설치를 사용하는 경우 az login 명령을 사용하여 Azure CLI 로그인합니다. 인증 프로세스를 완료하려면 터미널에 표시되는 단계를 수행합니다. 다른 로그인 옵션은 Azure CLI 사용하여 Azure 인증을 참조하세요.
메시지가 표시되면 처음 사용할 때 Azure CLI 확장을 설치합니다. 확장에 대한 자세한 내용은
Azure CLI 참조하세요. az version을 실행하여 설치된 버전과 종속 라이브러리를 찾습니다. 최신 버전으로 업그레이드하려면 az upgrade를 실행합니다.
시나리오 아키텍처 검토
다음 아키텍처 다이어그램에서는 이 자습서에서 만드는 인프라를 보여줍니다. 별도의 지역에서 두 개의 동일한 App Service 앱으로 구성됩니다. 첫 번째 웹앱은 활성 지역에 있습니다. 들어오는 트래픽 처리를 담당하는 기본 앱입니다. 두 번째 앱은 대기 지역에 있으며 기본 앱의 가용성을 기다립니다. Azure Front Door 트래픽을 기본 웹앱으로 라우팅하려고 시도합니다. 주 지역을 사용할 수 없는 경우 트래픽은 대기 웹으로 라우팅됩니다. 다이어그램에서 점선은 지역 상태에 따라 트래픽 라우팅을 나타냅니다. 액세스 제한은 인터넷에서 앱에 대한 직접 액세스를 차단하도록 구성됩니다.
Azure 부하 분산 및 트래픽 라우팅을 위한 다양한 옵션을 제공합니다. Azure Front Door 여러 지역에 배포된 Azure App Service 호스팅되는 인터넷 연결 웹앱을 포함하므로 이 자습서에서 선택됩니다. 구성이 이 자습서의 예제와 다른 경우 시나리오에 대한 부하 분산 솔루션 선택을 참조하세요.
이 자습서의 시나리오에서는 다음과 같은 동작을 제공합니다.
- 동일한 App Service 앱이 별도의 두 지역에 배포됩니다.
- 웹앱으로 직접 전송되는 공용 트래픽이 차단됩니다.
- Azure Front Door 트래픽을 주 지역의 활성 앱으로 라우팅합니다.
- 보조 지역의 대기 앱은 필요에 따라 트래픽을 처리할 수 있습니다.
리소스 그룹 만들기
이 자습서를 위해 서로 다른 Azure 지역에서 실행되는 웹앱의 두 인스턴스가 필요합니다.
사용 가능한 지역 쌍을 검토하고 웹앱에 대해 쌍을 이루는 두 지역을 선택합니다.
이 자습서에서는 두 지역을
<primary-region>(eastus) 및<standby-region>(westus)라고 합니다.이 자습서에서 구성하는 모든 리소스에 대한 리소스 그룹을 만듭니다. 이 자습서에서는
<primary-region>위치에 리소스 그룹을 만듭니다.az group create --name <resource-group> --location <primary-region>다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --name<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--location<primary-region>리소스 그룹의 지역 위치입니다. 이 자습서에서는 리소스 그룹 및 기본 웹앱에 대해 동일한 지역 위치를 사용합니다. eastus실제 구현에서는 각 지역/리소스에 대해 별도의 리소스 그룹을 사용합니다. 분리를 통해 재해 복구 상황에서 리소스를 격리할 수 있습니다.
자세한 내용은 az group create 명령 참조를 참조하세요.
두 개의 App Service 계획 만들기
각 웹앱에 대해 하나씩 두 개의 App Service 계획을 만듭니다. 해당 앱을 만들 것으로 예상되는 지역 위치에 각 계획을 만듭니다.
이 명령의 경우 이전에 선택한 지역 쌍 을 사용합니다. 기본 웹앱의 활성 지역 및 대기 웹앱의 수동 지역을 사용합니다.
다음 명령을 실행하여 기본 웹앱에 대한 App Service 계획을 만들고 명령을 다시 실행하여 대기 앱에 대한 계획을 만듭니다.
az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`
다음 <placeholder> 매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.
| 매개 변수 | 값 | 설명 | 예시 |
|---|---|---|---|
--name |
<app-service-plan> |
웹앱에 대한 App Service 계획의 이름입니다. 각 계획 인스턴스에는 고유한 이름이 있어야 합니다. | zava-primary-planzava-standby-plan |
--resource-group |
<resource-group> |
이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. | zava-resource-group |
--location |
<region> |
웹앱의 지역 위치입니다. | - 기본 웹앱, 활성 지역 eastus - 대기 웹앱, 수동 지역 westus |
자세한 내용은 az appservice plan create 명령 참조를 참조하세요.
두 개의 애플리케이션 만들기
두 개의 App Service 웹앱을 만듭니다. 각 앱을 해당 App Service 계획 및 지역 위치에 배치합니다.
웹앱의
--runtime언어 버전을 식별합니다.사용 가능한 런타임 목록에 대해 다음 명령을 실행할 수 있습니다.
az webapp list-runtimes이 자습서에 설명된 샘플 Node.js 앱을 사용하려는 경우 값을 으로
<language-version>설정합니다NODE:24-lts.두 개의 웹앱을 만듭니다. 다음 명령을 실행하여 기본 웹앱을 만들고 명령을 다시 실행하여 대기 앱을 만듭니다.
az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --name<web-app-name>웹앱의 이름입니다. 각 앱에는 전역적으로 고유한 이름이 있어야 합니다. 유효한 문자는 a-z,0-9및-.zava-primary-appzava-standby-app--resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--name<app-service-plan>웹앱에 대한 App Service 계획의 이름입니다. zava-primary-planzava-standby-plan--runtime<language-version>웹앱의 런타임 언어 버전입니다. NODE:24-lts자세한 내용은 az webapp create 명령 참조를 참조하세요.
각 웹앱의
defaultHostName값을 식별합니다. 호스트 이름 형식은 .입니다<web-app-name>.azurewebsites.net.각 웹앱에 대한 명령 출력을 검색하고 값을 찾거나 각 웹앱에 대해 다음 명령을 실행합니다.
az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --name<web-app-name>웹앱의 이름입니다. zava-primary-appzava-standby-app--resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-groupAzure 포털 각 앱의 호스트 이름이 웹앱 Overview 페이지에 표시됩니다.
나중에 호스트 이름 값을 기록합니다. 호스트 이름을 사용하여 Azure Front Door 배포에 대한 백 엔드 주소를 정의합니다.
새 웹앱에 액세스할 수 있는지 확인합니다.
브라우저에서 기본 웹앱의 호스트 이름(예:
zava-primary-app.azurewebsites.net.)을 입력합니다.연결에 성공하면 다음 메시지가 표시됩니다.
대기 웹앱의 호스트 이름으로 테스트를 반복합니다.
Azure Front Door 구성하기
다중 지역 배포는 활성-활성 또는 활성-수동 구성을 사용할 수 있습니다. 주 지역이 활성화되고 대기 지역이 수동입니다.
- 활성-활성 구성은 여러 활성 지역에 요청을 분산합니다.
- 활성-수동 구성은 대기(수동) 지역에서 인스턴스를 계속 실행하지만 주(활성) 지역이 실패하지 않는 한 트래픽을 전송하지 않습니다.
Azure Front Door 두 구성을 모두 사용하도록 설정할 수 있습니다. 고가용성 및 내결함성을 위한 앱 디자인에 대한 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.
프로필 만들기
웹앱에 트래픽을 라우팅하기 위한 Azure Front Door Premium 인스턴스를 만듭니다.
Azure Front Door 계층 비교 검토하고 배포에 대한 계층을 선택합니다.
이 자습서에서는 Azure Front Door Premium(
Premium_AzureFrontDoor)을 사용합니다.Azure Front Door Standard를 배포하려는 경우 표준 계층은 WAF 정책을 사용하여 관리되는 규칙 배포를 지원하지 않습니다.
다음 명령을 실행하여 프로필을 만듭니다.
az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --profile-name<front-door-profile>Azure Front Door 프로필의 이름입니다. 이름은 각 리소스 그룹 내에서 고유해야 합니다. zava-profile--resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--sku<front-door-tier>배포에 사용되는 Azure Front Door 계층 SKU입니다. Premium_AzureFrontDoor(권장)
Standard_AzureFrontDoor자세한 내용은 az afd profile create 명령 참조를 참조하세요.
엔드포인트 추가
프로필에 엔드포인트를 만듭니다. 첫 번째 엔드포인트를 만든 후 프로필에 여러 엔드포인트를 만들 수 있습니다.
az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled
다음 <placeholder> 매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.
| 매개 변수 | 값 | 설명 | 예시 |
|---|---|---|---|
--resource-group |
<resource-group> |
이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. | zava-resource-group |
--endpoint-name |
<front-door-endpoint> |
Azure Front Door 프로필 아래의 엔드포인트 이름입니다. 이름은 전역적으로 고유해야 합니다. | zava-endpoint |
--profile-name |
<front-door-profile> |
Azure Front Door 프로필의 이름입니다. | zava-profile |
자세한 내용은 az afd endpoint create 명령 참조를 참조하세요.
원본 그룹 만들기
Azure Front Door 배포하는 경우 웹앱 백 엔드의 엔드포인트 역할을 하는 원본이 필요합니다. 자세한 내용은 Azure Front Door의 기원 및 원본 그룹 참조하세요. 원본은 원본 그룹에 저장됩니다.
Azure Front Door 프로필에 원본 그룹을 만들어 두 웹앱의 원본을 포함합니다.
az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
--probe-request-type <probe-request> \
--probe-protocol <probe-protocol> \
--probe-interval-in-seconds <probe-interval> \
--probe-path <probe-path> \
--sample-size <sample-size> \
--successful-samples-required <required-samples> \
--additional-latency-in-milliseconds <extra-latency>
다음 <placeholder> 매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.
| 매개 변수 | 값 | 설명 | 예시 |
|---|---|---|---|
--resource-group |
<resource-group> |
이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. | zava-resource-group |
--origin-group-name |
<front-door-origin-group> |
Azure Front Door 원본 그룹의 이름입니다. 이름은 전역적으로 고유해야 합니다. | zava-origin-group |
--profile-name |
<front-door-profile> |
Azure Front Door 프로필의 이름입니다. | zava-profile |
--probe-request-type |
<probe-request> |
상태 프로브 요청 유형입니다. | GET |
--probe-protocol |
<probe-protocol> |
상태 프로브에 사용할 프로토콜입니다. | Http |
--probe-interval-in-seconds |
<probe-interval> |
상태 프로브 간격(초)입니다. | 60 |
--probe-path |
<probe-path> |
원점의 상태를 확인하는 데 사용되는 원점에 상대적인 경로입니다. |
/ (백슬래시) |
--sample-size |
<sample-size> |
부하 분산을 결정할 때 고려해야 하는 샘플 수입니다. | 4 |
--successful-samples-required |
<required-samples> |
성공해야 하는 샘플 기간 내의 샘플 수입니다. | 3 |
--additional-latency-in-milliseconds |
<extra-latency> |
최저 대기 시간 버킷으로 분류되는 프로브의 추가 대기 시간(밀리초)입니다. | 50 |
자세한 내용은 az afd origin-group create 명령 참조를 참조하세요.
원본 그룹에 원본 추가
각 웹앱의 원본을 Azure Front Door 원본 그룹에 추가합니다.
기본 웹앱에 원본을 추가합니다.
--priority매개 변수를1설정하면 이 앱이 트래픽의 기본 수신자임을 Azure Front Door 알 수 있습니다.az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \ --origin-group-name <front-door-origin-group> \ --origin-name <web-app-origin-name> \ --origin-host-header <web-app-name>.azurewebsites.net \ --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \ --http-port <origin-port> --https-port <origin-secure-port>다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--host-name<web-app-name>.azurewebsites.net기본 웹앱의 호스트 이름 입니다 . 호스트 이름은 호스트 식별자와 같은 zava-primary-app웹앱 이름을 결합합니다azurewebsites.net.zava-primary-app.azurewebsites.net--profile-name<front-door-profile>Azure Front Door 프로필의 이름입니다. zava-profile--origin-group-name<front-door-origin-group>Azure Front Door 원본 그룹의 이름입니다. zava-origin-group--origin-name<web-app-origin-name>기본 웹앱의 원본 이름 입니다 . 이름은 원본 그룹 내에서 고유해야 합니다. primary-origin--origin-host-header<web-app-name>.azurewebsites.net기본 웹앱 원본에 요청을 보낼 호스트 헤더 입니다 . 값을 지정하지 않으면 요청 호스트 이름이 이 값을 결정합니다. Web Apps, Blob Storage 및 Cloud Services와 같은 Azure CDN 원본은 기본적으로 원본 호스트 이름과 일치하도록 이 호스트 헤더 값이 필요합니다. zava-primary-app.azurewebsites.net--priority<origin-priority>원본 그룹 내에서 이 원본의 우선 순위입니다. 기본 웹앱의 경우 우선 순위를 1로 설정합니다. Azure Front Door 원본 및 활성 지역에서 부하 분산에 우선 순위 값을 사용합니다. 값은 1에서 5 사이여야 합니다. 1 --weight<origin-weight>부하 분산을 위한 원본 그룹 내 원본의 가중치입니다. 값은 1에서 1000 사이여야 합니다. 1000 --enabled-state<origin-state>이 원본이 트래픽을 수신하도록 설정할지 여부를 나타냅니다. Enabled--http-port<origin-port>원본에 대한 HTTP 요청에 사용되는 포트입니다. 80 --https-port<origin-secure-port>원본에 대한 보안 HTTPS 요청에 사용되는 포트입니다. 443 자세한 내용은 az afd origin create 명령 참조를 참조하세요.
명령을 다시 실행하고 대기 웹앱의 원본을 추가합니다. 이 명령은 동일한 매개 변수를 사용하지만 다음과 같은 고유한 매개 변수 값을 사용합니다.
매개 변수 값 설명 예시 --host-name<web-app-name>.azurewebsites.net대기 웹앱의 호스트 이름입니다. zava-standby-app.azurewebsites.net--origin-name<web-app-origin-name>스탠바이 웹앱의 원본 이름입니다. standby-origin--origin-host-header<web-app-name>.azurewebsites.net대기 웹앱 원본에 요청을 보낼 호스트 헤더입니다. zava-standby-app.azurewebsites.net--priority<origin-priority>원본 그룹 내에서 이 원본의 우선 순위입니다. 대기 웹앱의 경우 우선 순위를 2로 설정합니다. Azure Front Door 모든 트래픽을 기본 원본으로 전달하려고 시도합니다. 기본 원본을 사용할 수 없는 경우 트래픽은 대기 원본으로 라우팅됩니다. 2
경로 규칙 추가
라우팅 규칙을 추가하여 Azure Front Door 엔드포인트를 원본 그룹에 매핑합니다. 경로는 엔드포인트에서 원본 그룹으로 요청을 전달합니다.
Azure Front Door 엔드포인트를 원본 그룹에 매핑하는 경로 규칙을 만듭니다.
az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> ` --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> ` --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link>다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--profile-name<front-door-profile>Azure Front Door 프로필의 이름입니다. zava-profile--endpoint-name<front-door-endpoint>Azure Front Door 프로필 아래의 엔드포인트 이름입니다. zava-endpoint--forwarding-protocol<protocol-type>백 엔드 앱에 트래픽을 전달할 때 이 경로 규칙에서 사용하는 프로토콜입니다. MatchRequest--route-name<route-rule-name>라우팅 규칙의 이름 Azure Front Door 프로필 내에서 고유해야 합니다. zava-route-rule--https-redirect<secure-redirect>HTTP 트래픽을 HTTPS 트래픽으로 자동으로 리디렉션할지 여부를 나타냅니다. Enabled--origin-group-name<front-door-origin-group>Azure Front Door 원본 그룹의 이름입니다. zava-origin-group--supported-protocols<protocol-list>이 경로 규칙에 대해 지원되는 프로토콜 목록입니다. 공간을 사용하여 프로토콜 형식을 구분합니다. Http Https--link-to-default-domain<domain-link>이 경로가 기본 엔드포인트 도메인에 연결되어 있는지 여부를 나타냅니다. Enabled자세한 내용은 az afd route create 명령 참조를 참조하세요.
배포를 완료하는 데 약 15분이 걸립니다. 변경 내용이 전역적으로 전파되려면 다소 시간이 걸릴 수 있습니다.
Azure Front Door 통해서만 액세스 제한
현재 브라우저에 호스트 이름을 입력하여 웹앱에 직접 액세스할 수 있습니다. 앱에 대한 액세스 제한을 설정하는 경우 트래픽이 Azure Front Door 통해서만 앱에 도달하도록 할 수 있습니다.
Azure Front Door 기능은 트래픽이 서비스를 통해서만 흐르는 경우에 가장 적합합니다. Azure Front Door 통해 전송되지 않는 트래픽을 차단하도록 웹앱 원본을 구성하는 것이 가장 좋습니다. 그렇지 않으면 트래픽이 Azure Front Door 웹 애플리케이션 방화벽, DDoS 보호 및 기타 보안 기능을 우회할 수 있습니다.
Azure Front Door 앱으로의 트래픽은 AzureFrontDoor.Backend 서비스 태그에 정의된 잘 알려진 IP 범위 집합에서 시작됩니다. 서비스 태그 제한 규칙을 사용하면 트래픽이 Azure Front Door에서만 유입되도록 제한할 수 있습니다.
Azure Front Door 프로필의 식별자를 가져옵니다.
트래픽이 특정 Azure Front Door 인스턴스에서만 발생하도록 하려면 프로필 ID가 필요합니다. 액세스 제한은 Azure Front Door 프로필에서 보낸 고유한 HTTP 헤더를 기반으로 들어오는 요청을 추가로 필터링합니다.
az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--profile-name<front-door-profile>Azure Front Door 프로필의 이름입니다. zava-profile명령 출력은 프로필 ID(32자리 영숫자 값)를 표시합니다.
"0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"다음 단계에서는
<profile-identifier>값에 프로필 ID를 사용합니다.다음 명령을 실행하여 기본 웹앱에 대한 액세스 제한을 설정하고 명령을 다시 실행하여 대기 앱에 대한 제한을 설정합니다.
az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> ` --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--name<web-app-name>액세스 제한을 설정하는 웹앱의 이름입니다. zava-primary-appzava-standby-app--priority<access-priority>프로필에 대해 정의된 모든 규칙에서 액세스 제한 규칙의 우선 순위를 지정합니다. 낮은 값은 더 높은 우선 순위와 동일합니다. 100 --service-tag<tag-name>Azure Front Door에서 인식되는 서비스 태그 이름입니다. 액세스 제한은 서비스 태그로 표시된 IP 범위에 적용됩니다. AzureFrontDoor.Backend--http-headerx-azure-fdid=<profile-identifier>들어오는 트래픽의 추가 필터링을 위해 하나 이상의 고유한 HTTP 헤더를 지정합니다. 액세스 제한은 Azure Front Door 프로필에서 보낸 고유한 HTTP 헤더를 기반으로 들어오는 요청을 필터링합니다. 헤더는 Azure Front Door 접두사 및 Azure Front Door 인스턴스의 프로필 식별자를 결합합니다. x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee자세한 내용은 az webapp config access-restriction add 명령 참조를 참조하세요.
액세스 제한 테스트
액세스 제한으로 인해 앱에 직접 액세스할 수 없는지 확인합니다.
브라우저에서 기본 웹앱의 호스트 이름(예:
zava-primary-app.azurewebsites.net.)을 입력합니다.다음 메시지와 함께 연결이 실패합니다.
대기 웹앱의 호스트 이름으로 테스트를 반복합니다(예:
zava-standby-app.azurewebsites.net.).
Azure Front Door 배포 테스트
Azure Front Door Standard 또는 Premium 프로필을 만들 때 구성이 전역적으로 배포되는 데 다소 시간이 걸릴 수 있습니다. 배포가 완료되면 프런트 엔드 호스트에 액세스할 수 있습니다.
Azure Front Door 엔드포인트의 호스트 이름을 가져옵니다.
az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.매개 변수 값 설명 예시 --resource-group<resource-group>이 자습서에서 만든 리소스를 포함하는 리소스 그룹입니다. zava-resource-group--profile-name<front-door-profile>Azure Front Door 프로필의 이름입니다. zava-profile--endpoint-name<front-door-endpoint>Azure Front Door 프로필 아래의 엔드포인트 이름입니다. zava-endpoint명령 출력은 엔드포인트 호스트 이름을 표시합니다.
"zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"호스트 이름은 엔드포인트 이름, 고유한 영숫자 해시, 식별자 및 Azure Front Door 접미사로 구성됩니다. 다음 단계에서는 엔드포인트 호스트 이름을 사용합니다.
자세한 내용은 az afd endpoint show 명령 참조를 참조하세요.
브라우저에서 엔드포인트 호스트 이름(예:
zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.)을 입력합니다.요청은 활성 지역의 기본 앱으로 자동으로 라우팅되어야 합니다.
페어링된 지역의 앱 간 즉각적인 전역 장애 조치를 테스트합니다.
브라우저에서 엔드포인트 호스트 이름(예:
zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.)을 입력합니다.az webapp stop 명령을 실행하여 기본 앱을 중지합니다.
다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.az webapp stop --name <primary-web-app> --resource-group <resource-group>브라우저를 새로 고칩니다.
트래픽이 다른 지역의 대기 앱으로 올바르게 리디렉션되는 경우 동일한 페이지와 메시지가 표시됩니다.
팁
장애 조치(failover)를 완료하려면 페이지를 여러 번 새로 고쳐야 할 수 있습니다.
Azure 포털에서 웹앱의 상태를 확인하여 Azure Front Door 대기 앱으로 리디렉션되고 있는지 확인할 수 있습니다. 기본 웹앱의 개요 페이지에서 시작 옵션을 사용할 수 있어야 합니다(회색이 아님). 대기 웹앱의 개요 페이지에서 시작 옵션을 사용할 수 없습니다(회색).
az webapp stop명령을 다시 실행하고 대기 앱을 중지합니다.다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.az webapp stop --name <standby-web-app> --resource-group <resource-group>브라우저를 다시 새로 고칩니다.
대기 앱도 중지되면 모든 트래픽 라우팅이 중지됩니다. 이번에는 다음과 같은 오류 메시지가 표시됩니다.
az webapp start명령을 실행하고 대기 앱을 다시 시작합니다.다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.az webapp start --name <standby-web-app> --resource-group <resource-group>브라우저를 새로 고치면 성공적인 앱 연결이 표시됩니다.
유효성 검사는 이제 의도한 대로 Azure Front Door 및 장애 조치(failover) 함수를 통해 앱에 액세스할 수 있는지 확인합니다.
장애 조치(failover) 테스트를 완료한 경우 기본 앱을 다시 시작합니다.
리소스 정리
이전 단계에서는 리소스 그룹에 Azure 리소스를 만들었습니다. 나중에 이러한 리소스가 필요하지 않은 경우 Cloud Shell 다음 명령을 실행하여 리소스 그룹을 삭제합니다.
<placeholder> 매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉다.
az group delete --name <resource-group>
이 명령을 실행하는 데 몇 분 정도 걸릴 수 있습니다.
ARM 또는 Bicep에서 배포하기
이 자습서에서 만든 리소스는 ARM 템플릿(Azure Resource Manager 템플릿) 또는 Bicep 템플릿을 사용하여 배포할 수 있습니다. GitHub에서 고가용성 멀티 리전 웹 앱 Bicep 파일로 시작할 수 있습니다. 이 템플릿을 사용하면 Azure Front Door 뒤에 있는 서로 다른 지역에 두 개의 웹앱을 사용하여 안전하고 고가용성 다중 지역 엔드 투 엔드 솔루션을 만들 수 있습니다.
ARM 및 Bicep 템플릿을 배포하는 방법을 알아보려면 Azure CLI 사용하여 Bicep 파일 배포를 참조하세요.
질문과 대답
이 자습서에서는 다중 지역 웹앱을 사용하도록 설정하는 기준 인프라를 배포했습니다. App Service는 보안 모범 사례 및 권장 사항을 따르는 애플리케이션을 실행하는 데 도움이 되는 기능을 제공합니다.
이 섹션에는 앱을 더욱 안전하게 보호하고 모범 사례에 따라 리소스를 배포 및 관리하는 데 도움이 되는 자주 묻는 질문에 대한 답변이 포함되어 있습니다.
인프라 및 Azure 리소스 관리 및 배포
이 자습서에서는 Azure CLI 사용하여 인프라 리소스를 배포했습니다. 지속적인 배포 메커니즘을 구성하여 애플리케이션 인프라를 관리하는 방안을 고려해 보세요. 다른 지역에 리소스를 배포하기 때문에 지역 전체에서 해당 리소스를 독립적으로 관리해야 합니다. 리소스가 각 지역에서 동일한지 확인하려면 ARM 템플릿 또는 Terraform 같은 코드로서의 인프라는 Azure Pipelines 또는 GitHub Actions 같은 배포 파이프라인과 함께 사용해야 합니다. 이 구성을 적절하게 설정하면 리소스를 변경하면 모든 배포 지역에서 업데이트가 트리거됩니다. 자세한 내용은
프로덕션에 안전하게 배포하기 위해 스테이징 슬롯 사용
프로덕션 앱 및 슬롯에 애플리케이션 코드를 직접 배포하는 것은 권장되지 않습니다. 프로덕션으로 푸시하기 전에 앱을 테스트하고 변경 내용의 유효성을 검사할 수 있는 안전한 장소를 마련하는 것이 중요합니다. 스테이징 슬롯과 슬롯 교환의 조합을 사용하여 테스트 환경에서 프로덕션으로 코드를 이동합니다.
이 자습서에서는 스테이징 슬롯 사용을 지원하는 기준 인프라를 만들었습니다. 웹앱의 각 인스턴스에 대한 배포 슬롯을 만들고 GitHub Actions 사용하여 이러한 스테이징 슬롯에 대한 지속적인 배포를 구성할 수 있습니다. 인프라 관리와 마찬가지로 애플리케이션 소스 코드에 대한 지속적인 배포를 구성하여 지역 간 변경 내용이 동기화된 상태로 유지되도록 하는 것이 좋습니다. 지속적인 배포를 구성하지 않으면 코드 변경이 있을 때마다 각 지역의 각 앱을 수동으로 업데이트해야 합니다.
스테이징 슬롯을 사용하려면 다음 절차를 따르세요.
이 절차의 경우 App Service 앱에 배포할 준비가 된 앱이 필요합니다.
자습서를 완료한 경우 기본 웹앱 및 대기 웹앱을 사용할 수 있습니다. 그러나 충분한 배포 슬롯을 지원하는 App Service 계획이 필요합니다. 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건 참조하세요.
앱이 없는 경우 Node.js Hello World 샘플 앱 시작할 수 있습니다. 변경할 고유한 복사본이 있도록 GitHub 리포지토리를 포크합니다.
웹앱에 대한 App Service 스택 설정을 구성합니다.
스택 설정은 앱에 사용되는 언어 버전 또는 런타임을 나타냅니다.
Azure 포털에서 설정을 구성하거나
az webapp config set명령을 사용할 수 있습니다. Node.js 샘플을 사용하는 경우 스택 설정을Node 24 LTS.로 설정합니다.Azure 포털에서 주(primary) 웹앱을 선택합니다.
왼쪽 메뉴에서 설정>구성을 선택합니다.
스택 설정 탭에서 다음 설정을 구성합니다.
노드와 같은 스택 값을 선택합니다.
노드 24 LTS와 같은 버전 값을 선택합니다.
적용을 선택합니다.
이 프로세스를 반복하여 대기 웹앱에 대한 App Service 스택 설정을 구성합니다.
Azure 포털에서 연속 배포를 설정합니다. GitHub Actions 같은 공급자를 사용하여 지속적인 배포를 구성하는 방법에 대한 자세한 지침은
Azure App Service 참조하세요. 다음 명령을 실행하여
stage웹앱의 라는 스테이징 슬롯을 만듭니다.az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>az webapp deployment slot create명령을 다시 실행하고stage웹앱에 대한 스테이징 슬롯을 만듭니다.각 스테이징 슬롯에 대한 GitHub Actions 사용하여 연속 배포를 구성합니다.
Azure 포털에서 주(primary) 웹앱을 선택합니다.
왼쪽 메뉴에서 배포>배포 슬롯을 선택합니다.
목록에서 스테이지 슬롯을 찾고 슬롯을 선택하여 세부 정보 창을 엽니다.
왼쪽 메뉴에서 배포>센터를 선택합니다.
Settings 탭에서 Source 옵션을 GitHub로 설정합니다.
Azure 포털에서 웹앱 스테이징 슬롯의 배포 원본을 선택하는 방법을 보여 주는 스크린샷입니다. GitHub 처음으로 배포하는 경우 Authorize를 선택하고 권한 부여 프롬프트를 따릅니다. 다른 사용자의 리포지토리에서 배포하려면 계정 변경을 선택합니다.
GitHub 사용하여 Azure 계정에 권한을 부여한 후 Organization, Repository 및 Branch를 선택하여 CI/CD를 구성합니다. 조직 또는 리포지토리를 찾을 수 없는 경우 GitHub 대해 더 많은 권한을 사용하도록 설정해야 할 수 있습니다. 자세한 내용은 조직의 리포지토리에 대한 사용자 액세스 관리를 참조하세요.
Node.js 샘플 앱을 사용하는 경우 다음 설정을 사용합니다.
설정 값 조직 <your-GitHub-organization>리포지토리 nodejs-docs-hello-world 브랜치 기본 저장을 선택합니다.
선택한 리포지토리 및 분기의 새 커밋이 이제 App Service 앱에 지속적으로 배포됩니다. 로그 탭에서 커밋 및 배포를 추적할 수 있습니다.
게시 프로필을 사용하여 App Service에 인증하는 기본 워크플로 파일이 GitHub 리포지토리에 추가됩니다.
<repo-name>/.github/workflows/ 디렉터리로 이동하여 이 파일을 볼 수 있습니다.
App Service에서 기본 인증 사용 안 함
FTP 및 SCM 엔드포인트에 대한 액세스를 Microsoft Entra ID로 지원되는 사용자로 제한하려면 기본 인증을 비활성화해야 합니다.
연속 배포 도구를 사용하여 애플리케이션 소스 코드를 배포하는 경우 기본 인증을 사용하지 않도록 설정하려면 지속적인 배포를 구성하기 위한 추가 단계가 필요합니다. 예를 들어 게시 프로필은 Microsoft Entra 자격 증명을 사용하지 않으므로 사용할 수 없습니다. 대신 서비스 주체 또는 OpenID Connect 자격 증명을 사용해야 합니다.
다음 명령은 App Service 기본 웹앱 및 스테이징 슬롯 및 대기 웹앱 및 스테이징 슬롯에 대한 기본 인증을 사용하지 않도록 설정합니다. 다음 <placeholder> 매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.
기본 웹앱에 대한 프로덕션 사이트 및 스테이징 슬롯에 대한 FTP 액세스를 사용하지 않도록 설정합니다.
az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<web-app-name> --set properties.allow=false az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<web-app-name>/slots/stage --set properties.allow=false대기 웹앱에 대해 명령을 다시 실행합니다.
기본 웹앱의 프로덕션 사이트 및 스테이징 슬롯에 대한 WebDeploy 포트 및 SCM 사이트에 대한 기본 인증 액세스를 사용하지 않도록 설정합니다.
az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<primary-web-app> --set properties.allow=false az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<primary-web-app>/slots/stage --set properties.allow=false대기 웹앱에 대해 명령을 다시 실행합니다.
로그인을 테스트하고 모니터링하는 방법을 포함하여 기본 인증을 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 App Service 배포에서 기본 인증 사용 안 함을 참조하세요.
기본 인증을 사용하지 않도록 설정한 경우 연속 배포 사용
App Service 앱에서 기본 인증을 허용하도록 선택한 경우 App Service에서 사용 가능한 배포 방법 중 하나를 사용할 수 있습니다. 예를 들어 스테이징 슬롯 섹션에서 구성한 게시 프로필을 사용할 수 있습니다.
App Service 앱에 대한 기본 인증을 사용하지 않도록 설정하는 경우 지속적인 배포에는 인증을 위해 서비스 주체 또는 OpenID Connect가 필요합니다. GitHub Actions 코드 리포지토리로 사용하는 경우 GitHub Actions 사용하여 Azure App Service 배포를 참조하세요. 이 자습서에서는 GitHub Actions 사용하여 App Service에 배포할 서비스 주체 또는 OpenID Connect를 만드는 단계별 지침을 제공합니다. 다음 섹션의 절차에 따라 프로세스를 완료할 수도 있습니다.
GitHub Actions 사용하여 서비스 주체 및 자격 증명 만들기
GitHub Actions 및 서비스 주체를 사용하여 연속 배포를 구성합니다.
기본 웹앱 및 대기 웹앱에 대한 서비스 주체 를 만듭니다.
다음
<placeholder>매개 변수 값을 사용자 고유의 리소스에 대한 정보로 바꿉니다.az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \ /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \ /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>App Service 앱에 대한 액세스를 제공하는 역할 할당 자격 증명이 있는 JSON 개체가 출력됩니다.
{ "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444", "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888", "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a", "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee", "activeDirectoryEndpointUrl": "https://login.microsoftonline.com", "resourceManagerEndpointUrl": "https://management.azure.com/", "activeDirectoryGraphResourceId": "https://graph.windows.net/", "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/", "galleryEndpointUrl": "https://gallery.azure.com/", "managementEndpointUrl": "https://management.core.windows.net/" }JSON에는 현재만 표시되는 클라이언트 암호가 포함됩니다.
팁
최소 액세스 권한을 부여하는 것이 좋습니다. 이 예제에서 범위는 전체 리소스 그룹이 아닌 앱으로만 제한됩니다.
클라이언트 비밀에 대한 레코드가 있도록 JSON 개체를 복사합니다.
GitHub 작업 워크플로의 일부로 Azure 로그인 작업에 서비스 주체 자격 증명을 제공합니다.
워크플로에서 직접 값을 제공하거나 워크플로에서 참조되는 GitHub 비밀로 저장할 수 있습니다. 값을 GitHub 비밀로 저장하는 것이 더 안전한 옵션입니다.
앱에 대한 GitHub 리포지토리를 엽니다.
설정>보안>비밀 및 변수 작업으로> 이동합니다.
새 리포지토리 비밀을 선택하고 다음 설정 각각에 대한 비밀을 만듭니다. JSON 출력의 값을 사용합니다.
설정 값 예시 AZURE_APP_ID <application/client-id>00001111-aaaa-2222-bbbb-3333cccc4444AZURE_PASSWORD <client-secret>ffffffff-5a5a-6b6b-7c7c-888888888888AZURE_TENANT_ID <tenant-id>aaaabbbb-6666-cccc-7777-dddd8888eeeeAZURE_SUBSCRIPTION_ID <subscription-id>cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a
GitHub Actions 워크플로 만들기
App Service 앱에 액세스할 수 있는 서비스 주체가 있으면 앱의 기본 워크플로를 편집합니다. 이러한 워크플로는 연속 배포를 구성할 때 자동으로 생성됩니다.
게시 프로필 대신 서비스 주체를 사용하여 인증을 수행해야 합니다. 샘플 워크플로를 보려면 서비스 주체 탭을 GitHub 리포지토리에 워크플로 파일 추가에서 참조하십시오. 다음 샘플 워크플로는 Node.js 샘플 앱에 사용할 수 있습니다.
앱에 대한 GitHub 리포지토리를 엽니다.
<repo-name>/.github/workflows/디렉터리로 이동합니다. 자동 생성된 워크플로가 표시되어야 합니다.각 워크플로 파일에 대해 편집 (연필)을 선택합니다.
워크플로 파일의 내용을 다음 콘텐츠로 바꿉니다. 코드는 자격 증명에 대한 GitHub 비밀을 이미 만들었다고 가정합니다.
env섹션에서 다음 설정을 구성합니다.-
AZURE_WEBAPP_NAME:<web-app-name>자리 표시자를 귀하의 웹 앱 이름으로 바꿉니다. -
NODE_VERSION: 사용할 노드 버전을 지정합니다. Node.js 샘플의 경우 값은 .입니다'24.x'. -
AZURE_WEBAPP_PACKAGE_PATH: 웹앱 프로젝트의 경로를 지정합니다. 기본값은 리포지토리 루트입니다'.'. -
AZURE_WEBAPP_SLOT_NAME: 애플리케이션 슬롯 이름을 지정합니다. 일반 이름은 .입니다stage.
name: Build and deploy Node.js app to Azure Web App on: push: branches: - main workflow_dispatch: env: AZURE_WEBAPP_NAME: <web-app-name> # Your application name NODE_VERSION: '24.x' # Node version to use AZURE_WEBAPP_PACKAGE_PATH: '.' # Path to your web app project AZURE_WEBAPP_SLOT_NAME: stage # Application slot name jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Node.js version uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} - name: npm install, build run: | npm install npm run build --if-present - name: Upload artifact for deployment job uses: actions/upload-artifact@v4 with: name: node-app path: . deploy: runs-on: ubuntu-latest needs: build environment: name: 'stage' url: ${{ steps.deploy-to-webapp.outputs.webapp-url }} steps: - name: Download artifact from build job uses: actions/download-artifact@v4 with: name: node-app - uses: azure/login@v2 with: creds: | { "clientId": "${{ secrets.AZURE_APP_ID }}", "clientSecret": "${{ secrets.AZURE_PASSWORD }}", "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}", "tenantId": "${{ secrets.AZURE_TENANT_ID }}" } - name: 'Deploy to Azure Web App' id: deploy-to-webapp uses: azure/webapps-deploy@v3 with: app-name: ${{ env.AZURE_WEBAPP_NAME }} slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }} package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }} - name: logout run: | az logout-
워크플로 파일 변경 내용을 저장하고 리포지토리의 기본 분기에 직접 커밋합니다.
커밋은 GitHub 작업을 트리거하여 다시 실행하고 코드를 배포합니다. 이번에는 서비스 주체를 인증하는 데 사용됩니다.
슬롯 트래픽 라우팅을 사용하여 앱 업데이트 테스트
슬롯을 사용하여 트래픽을 라우팅하면 미리 정의된 사용자 트래픽의 일부가 각 슬롯으로 전송될 수 있습니다. 처음에는 트래픽의 100%가 프로덕션 사이트로 전송됩니다. 그러나 트래픽의 10%를 스테이징 슬롯으로 보낼 수 있습니다. 슬롯 트래픽 라우팅에 대한 이 접근 방식은 액세스를 시도하는 사용자 중 10%를 자동으로 스테이징 슬롯으로 보냅니다. 이 접근 방식을 사용하려면 Azure Front Door 인스턴스를 변경할 필요가 없습니다. App Service의 슬롯 교환 및 스테이징 환경에 대한 자세한 내용은
스테이징 슬롯에서 프로덕션 슬롯으로 코드 이동
스테이징 슬롯에서 테스트 및 유효성 검사를 완료한 후 스테이징 슬롯에서 프로덕션 사이트로 슬롯 교환 을 수행할 수 있습니다. 각 지역에 있는 앱의 모든 인스턴스에 대한 교환을 완료합니다. 슬롯 스왑 중에 App Service 플랫폼은 대상 슬롯이 가동 중지되지 않게 합니다.
기본 웹앱에 대한 교환을 수행합니다.
az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production대기 중인 웹앱의 교환을 수행합니다.
az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production몇 분 후 Azure 포털의 Azure Front Door 엔드포인트 n으로 이동하여 슬롯 교환이 성공했는지 확인합니다.
이 시점에서 앱이 실행되고 있으며 애플리케이션 소스 코드를 변경하면 두 스테이징 슬롯에 대한 업데이트가 자동으로 트리거됩니다. 이후에 해당 코드를 프로덕션으로 이동할 준비가 되면 슬롯 스왑 프로세스를 반복하면 됩니다.
다중 지역 배포를 사용하여 중단 및 연속성 문제 방지
Azure Front Door 원본 그룹에서 슬롯 교환을 진행 중인 사이트를 일시적으로 제거하여 지역 간 연속성 문제를 방지할 수 있습니다. 이 작업을 통해 고객이 다른 버전의 앱을 동시에 볼 수 없습니다. 또한 앱을 크게 변경할 때도 유용합니다. 임시 제거로 인해 모든 트래픽이 다른 원본으로 리디렉션됩니다.
Azure 포털에서 Azure Front Door 인스턴스로 이동합니다.
왼쪽 메뉴에서 원본>설정 그룹을 선택합니다.
원본 그룹 목록에서 일시적으로 제거할 슬롯이 포함된 원본 그룹을 선택합니다.
원본 그룹 업데이트 창에서 원본 호스트 이름 목록에서 제거할 슬롯을 찾습니다.
추가 작업 선택(...) >삭제한 다음 업데이트를 선택합니다.
변경 사항을 적용하는 데 몇 분 정도 걸릴 수 있습니다.
제거된 슬롯에 대한 트래픽을 허용할 준비가 되면 원본 그룹 업데이트 창으로 돌아갑니다.
맨 위에서 원본 추가를 선택하여 원본 슬롯을 원본 그룹에 다시 추가합니다.
Azure Front Door 원점 슬롯을 다시 추가하는 방법을 보여주는 스크린샷입니다.
추가 원본 그룹 만들기 및 경로 연결 변경
원본을 삭제하고 읽지 않으려는 경우 Azure Front Door 인스턴스에 대한 추가 원본 그룹을 만들 수 있습니다. 그런 다음 경로를 의도한 원본을 가리키는 원본 그룹에 연결할 수 있습니다.
예를 들어 기본(활성) 지역과 대기(수동) 지역에 대한 두 개의 추가 원본 그룹을 만들 수 있습니다. 주 지역이 변경되는 경우 경로를 대기 지역과 연결합니다. 대기 지역이 변경되는 경우 경로를 주 지역과 연결합니다. 모든 변경 작업이 완료되면 두 지역이 모두 포함된 원래 원본 그룹에 경로를 연결하면 됩니다. 이 방법이 작동하는 이유는 경로를 한 번에 하나의 원본 그룹에만 연결할 수 있기 때문입니다.
세 개의 원본 그룹이 있는 구성을 고려합니다.
- 그룹에는
Main-Origin각 지역의 기본 웹앱과 대기 웹앱이 모두 포함됩니다. - 그룹에는
Primary-Origin활성 지역의 기본 웹앱만 포함됩니다. - 그룹에는
Standby-Origin수동 지역의 대기 웹앱만 포함됩니다.
기본 웹앱이 변경되고 있다고 가정합니다. 변경이 시작되기 전에, Main-Origin 그룹의 경로 연결이 Secondary-Origin 그룹으로 변경됩니다. 이 작업을 수행하면 해당 지역의 기본 웹앱이 변경되는 동안 해당 지역의 대기 웹앱으로 가는 모든 트래픽 경로가 보장됩니다.
원본 그룹에 대한 경로 연결을 변경하려면 다음 단계를 수행합니다.
Azure 포털에서 Azure Front Door 인스턴스로 이동합니다.
왼쪽 메뉴에서 원본>설정 그룹을 선택합니다.
원본 그룹 목록에서 경로 열에서 연결되지 않은 표시기를 표시하는 원본 그룹을 찾습니다.
추가 작업 선택(...) >엔드포인트 및 경로를 연결합니다.
경로 연결 창에서 원본 그룹과 연결할 경로를 하나 이상 선택한 다음 연결을 선택합니다.
고급 도구 사이트에 대한 액세스 제한
Azure App 서비스를 사용하면 SCM/고급 도구 사이트가 앱을 관리하고 애플리케이션 소스 코드를 배포하는 데 사용됩니다. Front Door를 통해 이 사이트에 연결할 일이 거의 없으므로 SCM/고급 도구 사이트를 잠그는 것이 좋습니다. 예를 들어 원하는 도구로 테스트를 수행하고 지속적인 배포를 사용하도록 설정하는 것만 허용하는 액세스 제한을 설정할 수 있습니다. 배포 슬롯을 사용하는 경우, 특히 프로덕션 슬롯인 경우 테스트와 유효성 검사가 스테이징 슬롯에서 수행되므로 SCM 사이트에 대한 거의 모든 액세스를 거부할 수 있습니다.