다음을 통해 공유

다중 테넌트 솔루션에서 Azure Front Door 사용

  • 아티클

Azure Front Door는 전 세계 사용자와 애플리케이션의 정적 및 동적 웹 콘텐츠 간에 빠르고 안정적이며 안전한 액세스를 제공하는 Microsoft의 최신 클라우드 CDN(Content Delivery Network)입니다. 이 문서에서는 다중 테넌트 시스템에서 작업할 때 유용한 Azure Front Door의 몇 가지 기능에 대해 설명합니다. 또한 추가 지침 및 예제에 대한 링크를 제공합니다.

다중 테넌트 솔루션의 일부로 Azure Front Door를 사용하는 경우 솔루션의 디자인 및 요구 사항에 따라 몇 가지 결정을 내려야 합니다. 다음 요소를 고려해야 합니다.

  • 현재의 테넌트 수와 향후 예상되는 테넌트 수는 어떻게 됩니까?
  • 여러 테넌트 간에 애플리케이션 계층을 공유하거나, 여러 단일 테넌트 애플리케이션 인스턴스를 배포하거나, 여러 테넌트에서 공유하는 별도의 배포 스탬프를 배포합니까?
  • 테넌트가 자신의 도메인 이름을 가져오려고 합니까?
  • 와일드카드 도메인을 사용하시겠습니까?
  • 사용자 고유의 TLS 인증서를 사용해야 합니까, 아니면 Microsoft에서 TLS 인증서를 관리합니까?
  • Azure Front Door에 적용되는 할당량 및 한도를 고려했습니까? 성장함에 따라 어떤 한도에 가까워질지 알고 있습니까? 이러한 한도에 가까워질 것 같은 경우 여러 Azure Front Door 프로필을 사용하는 것이 좋습니다. 또는 한도를 피하기 위해 Azure Front Door를 사용하는 방법을 변경할 수 있는지 여부를 고려합니다. 프리미엄 SKU는 표준 SKU보다 한도가 높습니다.
  • 사용자 또는 테넌트에게 IP 주소 필터링, 지역 차단 또는 WAF 규칙 사용자 지정 요구 사항이 있습니까?
  • 테넌트의 애플리케이션 서버가 모두 인터넷에 연결되어 있습니까?

다중 테넌트를 지원하는 Azure Front Door의 기능

이 섹션에서는 다중 테넌트 솔루션에 유용한 Azure Front Door의 몇 가지 주요 기능에 대해 설명합니다. Azure Front Door가 와일드카드 도메인 및 TLS 인증서에 대한 정보를 포함하여 사용자 지정 도메인을 구성하는 데 어떻게 도움이 되는지 설명합니다. 또한 Azure Front Door 라우팅 기능을 사용하여 다중 테넌트를 지원하는 방법을 요약합니다.

사용자 지정 도메인

Azure Front Door는 만드는 각 엔드포인트에 대한 기본 호스트 이름(예: contoso.z01.azurefd.net)을 제공합니다. 대부분의 솔루션에서는 사용자 고유의 도메인 이름을 Azure Front Door 엔드포인트와 연결합니다. 사용자 지정 도메인 이름을 사용하면 클라이언트의 요청에 제공된 호스트 이름에 따라 고유한 브랜딩을 사용하고 라우팅을 구성할 수 있습니다.

다중 테넌트 솔루션에서는 테넌트별 도메인 이름 또는 하위 도메인을 사용하고, 테넌트의 트래픽을 해당 테넌트의 워크로드에 대한 올바른 원본 그룹으로 라우팅하도록 Azure Front Door를 구성할 수 있습니다. 예를 들어 tenant1.app.contoso.com과 같은 사용자 지정 도메인 이름을 구성할 수 있습니다. Azure Front Door를 사용하면 단일 Azure Front Door 프로필에서 여러 사용자 지정 도메인을 구성할 수 있습니다.

자세한 내용은 Front Door에 사용자 지정 도메인 추가를 참조하세요.

와일드카드 도메인

와일드카드 도메인은 공유 스템 도메인 및 테넌트별 하위 도메인을 사용하는 경우 DNS 레코드 및 Azure Front Door 트래픽 라우팅 구성의 구성을 간소화합니다. 예를 들어 테넌트가 tenant1.app.contoso.com 및 tenant2.app.contoso.com과 같은 하위 도메인을 사용하여 애플리케이션에 액세스한다고 가정합니다. 각 테넌트별 도메인을 개별적으로 구성하는 대신 와일드카드 도메인 *.app.contoso.com을 구성할 수 있습니다.

Azure Front Door는 와일드카드를 사용하는 사용자 지정 도메인 만들기를 지원합니다. 그런 다음 와일드카드 도메인에 도착하는 요청에 대한 경로를 구성할 수 있습니다. 새 테넌트 온보딩 시 DNS 서버를 다시 구성하거나, 새 TLS 인증서를 발급하거나, Azure Front Door 프로필의 구성을 업데이트할 필요가 없습니다.

모든 트래픽을 단일 원본 그룹으로 보내는 경우 와일드카드 도메인이 제대로 작동합니다. 그러나 솔루션의 별도 스탬프가 있는 경우 단일 수준 와일드카드 도메인만으로는 충분하지 않습니다. 예를 들어 각 테넌트의 하위 도메인에 사용할 경로를 재정의하여 다중 수준 스템 도메인을 사용하거나 추가 구성을 제공해야 합니다. 자세한 내용은 다중 테넌트 솔루션에서 도메인 이름을 사용하는 경우의 고려 사항을 참조하세요.

Azure Front Door는 와일드카드 도메인에 대해 관리되는 TLS 인증서를 발급하지 않으므로 사용자 고유의 인증서를 구매하고 제공해야 합니다.

자세한 내용은 와일드카드 도메인을 참조하세요.

관리되는 TLS 인증서

TLS 인증서를 획득하고 설치하는 것은 복잡하고 오류가 발생하기 쉬울 수 있습니다. 또한 TLS 인증서는 일반적으로 1년 기간 후에 만료되며 애플리케이션 트래픽 중단을 방지하기 위해 다시 발급하고 다시 설치해야 합니다. Azure Front Door 관리형 TLS 인증서를 사용하는 경우 Microsoft는 사용자 지정 도메인에 대한 인증서 발급, 설치 및 갱신을 담당합니다.

원본 애플리케이션은 Azure App Service와 같은 관리형 TLS 인증서를 제공하는 다른 Azure 서비스에서 호스트될 수 있습니다. Azure Front Door는 TLS 인증서를 동기화하기 위해 다른 서비스와 함께 투명하게 작동합니다.

테넌트가 자체 사용자 지정 도메인을 제공하도록 허용하고 Azure Front Door가 이러한 도메인 이름에 대한 인증서를 발급하도록 하려는 경우 테넌트는 AZURE Front Door에서 이들을 대신하여 인증서를 발급하지 못하도록 막을 수 있는 DNS 서버에서 CAA 레코드를 구성해서는 안 됩니다. 자세한 내용은 TLS/SSL 인증서를 참조하세요.

자세한 내용은 Azure Front Door를 사용한 엔드투엔드 TLS를 참조하세요.

라우팅

다중 테넌트 애플리케이션에는 테넌트에 서비스를 제공하는 애플리케이션 스탬프가 하나 이상 있을 수 있습니다. 스탬프는 다중 지역 배포를 사용하도록 설정하고 솔루션을 많은 수의 테넌트로 스케일링을 지원하는 데 자주 사용됩니다.

Azure Front Door에는 여러 다중 테넌트 아키텍처를 지원할 수 있는 강력한 라우팅 기능 집합이 있습니다. 라우팅을 사용하여 스탬프 내의 원본 간에 트래픽을 분산하거나 특정 테넌트에 대한 올바른 스탬프로 트래픽을 보낼 수 있습니다. 개별 도메인 이름, 와일드카드 도메인 이름 및 URL 경로에 따라 라우팅을 구성할 수 있습니다. 또한 규칙 엔진을 사용하여 라우팅 동작을 추가로 사용자 지정할 수 있습니다.

자세한 내용은 라우팅 아키텍처 개요를 참조하세요.

규칙 엔진

Azure Front Door 규칙 엔진을 사용하여 Azure Front Door가 네트워크 에지에서 요청을 처리하는 방법을 사용자 지정할 수 있습니다. 규칙 엔진을 사용하면 Azure Front Door 요청 처리 파이프라인 내에서 작은 논리 블록을 실행할 수 있습니다. 다음을 포함하여 다양한 작업에 규칙 엔진을 사용할 수 있습니다.

  • URL 및 경로의 세그먼트를 포함하여 HTTP 요청에 대한 정보를 검색하고 요청의 다른 부분에 정보를 전파합니다.
  • 원본으로 전송되기 전에 HTTP 요청의 요소를 수정합니다.
  • 클라이언트에 반환되기 전에 HTTP 응답의 일부를 수정합니다.
  • 요청을 보내야 하는 원본 그룹을 변경하는 등 요청에 대한 라우팅 구성을 재정의합니다.

다음은 다중 테넌트 솔루션에서 Azure Front Door 규칙 엔진을 사용하는 몇 가지 예제 접근 방식입니다.

  • 다음 예제 시나리오에 설명된 대로 테넌트별 와일드카드 하위 도메인도 사용하는 다중 테넌트 애플리케이션 계층을 배포한다고 가정합니다. 규칙 엔진을 사용하여 요청 하위 도메인에서 테넌트 식별자를 추출하고 요청 헤더에 추가할 수 있습니다. 이 규칙은 애플리케이션 계층이 어떤 테넌트에서 요청이 왔는지 확인하는 데 도움이 될 수 있습니다.
  • 다중 테넌트 애플리케이션 계층을 배포하고 경로 기반 라우팅(예 https://application.contoso.com/tenant1/welcome : 테넌트 1과 https://application.contoso.com/tenant2/welcome 2 각각)을 사용한다고 가정합니다. 규칙 엔진을 사용하여 URL 경로 세그먼트에서 테넌트 식별자 세그먼트를 추출하고 URL을 다시 작성하여 애플리케이션에서 사용할 쿼리 문자열 매개 변수 또는 요청 헤더에 테넌트 식별자를 포함할 수 있습니다.

자세한 내용은 Azure Front Door 규칙 엔진이란?을 참조하세요.

예제 시나리오

다음 예제 시나리오에서는 Azure Front Door에서 다양한 다중 테넌트 아키텍처를 구성하는 방법과 결정 사항이 DNS 및 TLS 구성에 미치는 영향을 보여 줍니다.

많은 다중 테넌트 솔루션은 배포 스탬프 패턴을 구현합니다. 이 배포 방법을 사용하는 경우 일반적으로 단일 공유 Azure Front Door 프로필을 배포하고 Azure Front Door를 사용하여 들어오는 트래픽을 적절한 스탬프로 라우팅합니다. 이 배포 모델은 가장 일반적인 모델이며 이 문서의 시나리오 1~4에서는 다양한 요구 사항을 충족하는 데 사용할 수 있는 방법을 보여 줍니다.

그러나 경우에 따라 솔루션의 각 스탬프에 Azure Front Door 프로필을 배포할 수 있습니다. 시나리오 5에서는 이 배포 모델을 설명합니다.

시나리오 1: 공급자 관리 와일드카드 도메인, 단일 스탬프

Contoso는 작은 다중 테넌트 솔루션을 빌드하고 있습니다. 이 회사는 단일 지역에 단일 스탬프를 배포하고 해당 스탬프는 모든 테넌트에서 서비스를 제공합니다. 모든 요청은 동일한 애플리케이션 서버로 라우팅됩니다. Contoso는 tenant1.contoso.com 및 tenant2.contoso.com과 같은 모든 테넌트에 와일드카드 도메인을 사용하기로 결정했습니다.

Contoso는 다음 구성을 사용하여 Azure Front Door를 배포합니다.

단일 사용자 지정 도메인, 경로 및 원본 그룹과 Azure Key Vault 와일드카드 TLS 인증서가 있는 Azure Front Door 구성을 보여 주는 다이어그램.

DNS 구성

일회성 구성: Contoso는 두 개의 DNS 항목을 구성합니다.

  • *.contoso.com에 대한 와일드카드 TXT 레코드입니다. 사용자 지정 도메인 온보딩 프로세스 중에 Azure Front Door에서 지정한 값으로 설정됩니다.
  • 와일드카드 CNAME 레코드인 *.contoso.com. Contoso의 Azure Front Door 엔드포인트 contoso.z01.azurefd.net에 대한 별칭입니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

TLS 구성

일회성 구성: Contoso는 와일드카드 TLS 인증서를 구입하고, 키 자격 증명 모음에 추가하고, Azure Front Door에 자격 증명 모음에 대한 액세스 권한을 부여합니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

Azure Front Door 구성

일회성 구성: Contoso는 Azure Front Door 프로필 및 단일 엔드포인트를 만듭니다. *.contoso.com이라는 이름을 가진 하나의 사용자 지정 도메인을 추가하고 와일드카드 TLS 인증서를 사용자 지정 도메인 리소스와 연결합니다. 그런 다음 애플리케이션 서버에 대한 단일 원본을 포함하는 단일 원본 그룹을 구성합니다. 마지막으로, 사용자 지정 도메인을 원본 그룹에 연결하도록 경로를 구성합니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

이점

  • 이 구성은 비교적 쉽게 구성할 수 있으며 고객에게 Contoso 브랜드 URL을 제공합니다.
  • 이 방법은 많은 수의 테넌트에서 지원합니다.
  • 새 테넌트가 온보딩되면 Contoso는 Azure Front Door, DNS 또는 TLS 인증서를 변경할 필요가 없습니다.

단점

  • 이 방법은 단일 애플리케이션 스탬프 또는 지역 이상으로 쉽게 확장되지 않습니다.
  • Contoso는 와일드카드 TLS 인증서를 구입하고 만료되면 인증서를 갱신하고 설치해야 합니다.

시나리오 2: 공급자 관리 와일드카드 도메인, 여러 스탬프

Proseware는 호주와 유럽 모두에 배포되는 여러 스탬프에 걸쳐 다중 테넌트 솔루션을 빌드하고 있습니다. 단일 지역 내의 모든 요청은 해당 지역의 스탬프에 의해 제공됩니다. Contoso와 마찬가지로 Proseware는 tenant1.proseware.com 및 tenant2.proseware.com과 같은 모든 테넌트에 와일드카드 도메인을 사용하기로 결정했습니다.

Proseware는 다음 구성을 사용하여 Azure Front Door를 배포합니다.

여러 사용자 지정 도메인, 경로 및 원본 그룹과 Azure Key Vault 와일드카드 TLS 인증서가 있는 Front Door 구성을 보여 주는 다이어그램.

DNS 구성

일회성 구성: Proseware는 두 개의 DNS 항목을 구성합니다.

  • *.proseware.com에 대한 와일드카드 TXT 레코드입니다. 사용자 지정 도메인 온보딩 프로세스 중에 Azure Front Door에서 지정한 값으로 설정됩니다.
  • 와일드카드 CNAME 레코드인 *.proseware.com. Proseware의 Azure Front Door 엔드포인트 proseware.z01.azurefd.net에 대한 별칭입니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

TLS 구성

일회성 구성: Proseware는 와일드카드 TLS 인증서를 구입하고, 키 자격 증명 모음에 추가하고, Azure Front Door에 자격 증명 모음에 대한 액세스 권한을 부여합니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

Azure Front Door 구성

일회성 구성: Proseware는 Azure Front Door 프로필 및 단일 엔드포인트를 만듭니다. 이 회사는 각 지역의 애플리케이션 스탬프/서버당 하나씩 여러 원본 그룹을 구성합니다.

새 테넌트가 온보딩된 경우: Proseware는 Azure Front Door에 사용자 지정 도메인 리소스를 추가합니다. *.proseware.com이라는 이름을 사용하고 와일드카드 TLS 인증서를 사용자 지정 도메인 리소스와 연결합니다. 그런 다음, 테넌트의 요청을 전달해야 하는 원본 그룹(스탬프)을 지정하는 경로를 만듭니다. 앞의 다이어그램에서 tenant1.proseware.com은 오스트레일리아 지역의 원본 그룹으로 라우팅하고 tenant2.proseware.com은 유럽 지역의 원본 그룹으로 라우팅합니다.

이점

  • 새 테넌트가 온보딩되면 DNS 또는 TLS 구성 변경이 필요하지 않습니다.
  • Proseware는 Azure Front Door의 단일 인스턴스를 유지 관리하여 트래픽을 여러 지역의 여러 스탬프로 라우팅합니다.

단점

  • Proseware는 새 테넌트가 온보딩될 때마다 Azure Front Door를 다시 구성해야 합니다.
  • Proseware는 Azure Front Door 할당량 및 한도, 특히 경로 및 사용자 지정 도메인의 수 및 복합 라우팅 한도에 주의해야 합니다.
  • Proseware는 와일드카드 TLS 인증서를 구입해야 합니다.
  • Proseware는 인증서가 만료되면 갱신 및 설치를 담당합니다.

시나리오 3: 공급자 관리 스탬프 기반 와일드카드 하위 도메인

Fabrikam은 다중 테넌트 솔루션을 빌드하고 있습니다. 이 회사는 호주와 미국 스탬프를 배포합니다. 단일 지역 내의 모든 요청은 해당 지역의 스탬프에서 처리됩니다. Fabrikam은 tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.com, tenant3.us.fabrikam.com과 같은 스탬프 기반 스템 도메인을 사용합니다.

이 회사는 다음 구성을 사용하여 Azure Front Door를 배포합니다.

여러 사용자 지정 스탬프 기반 스템 도메인, 경로 및 원본 그룹과 Azure Key Vault 와일드카드 TLS 인증서가 있는 Front Door 구성을 보여 주는 다이어그램.

DNS 구성

일회성 구성: Fabrikam은 각 스탬프에 대해 다음 두 개의 와일드카드 DNS 항목을 구성합니다.

  • 각 스탬프에 대한 와일드카드 TXT 레코드입니다(*.australia.fabrikam.com 및 *.us.fabrikam.com). 사용자 지정 도메인 온보딩 프로세스 중에 Azure Front Door에서 지정한 값으로 설정됩니다.
  • 각 스탬프에 대한 와일드카드 CNAME 레코드 *.australia.fabrikam.com 및 *.us.fabrikam.com. Azure Front Door 엔드포인트 fabrikam.z01.azurefd.net의 별칭입니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

TLS 구성

일회성 구성: Fabrikam은 각 스탬프에 대해 와일드카드 TLS 인증서를 구입하고, 키 자격 증명 모음에 추가하고, Azure Front Door에 자격 증명 모음에 대한 액세스 권한을 부여합니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

Azure Front Door 구성

일회성 구성: Fabrikam은 Azure Front Door 프로필 및 단일 엔드포인트를 만듭니다. 각 스탬프에 대한 원본 그룹을 구성합니다. 각 스탬프 기반 하위 도메인 *.australia.fabrikam.com 및 *.us.fabrikam.com에 대해 와일드카드를 사용하여 사용자 지정 도메인을 만듭니다. 각 스탬프의 사용자 지정 도메인에 대한 경로를 만들어 적절한 원본 그룹에 트래픽을 보냅니다.

새 테넌트가 온보딩된 경우: 추가 구성이 필요하지 않습니다.

이점

  • 이 방법을 사용하면 Fabrikam이 여러 스탬프에서 많은 수의 테넌트로 확장할 수 있습니다.
  • 새 테넌트가 온보딩되면 DNS 또는 TLS 구성 변경이 필요하지 않습니다.
  • Fabrikam은 Azure Front Door의 단일 인스턴스를 유지 관리하여 트래픽을 여러 지역의 여러 스탬프로 라우팅합니다.

단점

  • URL은 다중 파트 스템 도메인 구조를 사용하므로 URL은 사용자가 다루기 더 복잡할 수 있습니다.
  • Fabrikam은 여러 와일드카드 TLS 인증서를 구입해야 합니다.
  • Fabrikam은 TLS 인증서가 만료되면 갱신 및 설치를 담당합니다.

시나리오 4: 베니티 도메인

Adventure Works Cycles는 다중 테넌트 솔루션을 빌드하고 있습니다. 이 회사는 호주 및 미국 등의 여러 지역에 스탬프를 배포합니다. 단일 지역 내의 모든 요청은 해당 지역의 스탬프에서 처리됩니다. Adventure Works를 사용하면 테넌트가 자신의 도메인 이름을 가져올 수 있습니다. 예를 들어 테넌트 1은 tenant1app.tenant1.com과 같은 사용자 지정 도메인 이름을 구성할 수 있습니다.

이 회사는 다음 구성을 사용하여 Azure Front Door를 배포합니다.

여러 사용자 지정 베니티 도메인, 경로 및 원본 그룹이 있는 Azure Front Door 구성과 Key Vault의 TLS 인증서 및 Azure Front Door에서 관리하는 TLS 인증서의 조합을 보여 주는 다이어그램.

DNS 구성

일회성 구성: 없음.

새 테넌트가 온보딩된 경우: 테넌트는 자체 DNS 서버에 두 개의 레코드를 만들어야 합니다.

  • 도메인 유효성 검사를 위한 TXT 레코드. 예를 들어 테넌트 1은 tenant1app.tenant1.com이라는 이름의 TXT 레코드를 구성하고 사용자 지정 도메인 온보딩 프로세스 중에 Azure Front Door에서 지정한 값으로 설정해야 합니다.
  • Adventure Works Azure Front Door 엔드포인트에 별칭이 지정된 CNAME 레코드. 예를 들어 테넌트 1은 tenant1app.tenant1.com이라는 이름의 CNAME 레코드를 구성하고 adventureworks.z01.azurefd.net에 매핑해야 합니다.

TLS 구성

Adventure Works 및 해당 테넌트는 누가 TLS 인증서를 발급할지 결정해야 합니다.

  • 가장 쉬운 옵션은 Azure Front Door를 사용하여 인증서를 발급하고 관리하는 것이지만 테넌트는 DNS 서버에서 CCA 레코드를 구성해서는 안 됩니다. 그렇게 하는 경우 레코드가 Azure Front Door 인증 기관에서 인증서를 발급하지 못하도록 막을 수 있습니다.
  • 또는 테넌트가 자체 인증서를 제공할 수 있습니다. Adventure Works와 협력하여 인증서를 키 자격 증명 모음에 업로드하고 Azure Front Door에 대한 액세스를 제공해야 합니다.

Azure Front Door 구성

일회성 구성: Adventure Works는 Azure Front Door 프로필 및 단일 엔드포인트를 만듭니다. 각 스탬프에 대한 원본 그룹을 구성합니다. 사용자 지정 도메인 리소스 또는 경로를 만들지 않습니다.

새 테넌트가 온보딩된 경우: Adventure Works는 Azure Front Door에 사용자 지정 도메인 리소스를 추가합니다. 테넌트 제공 도메인 이름을 사용하고 적절한 TLS 인증서를 사용자 지정 도메인 리소스와 연결합니다. 그런 다음, 테넌트의 요청을 전달해야 하는 원본 그룹(스탬프)을 지정하는 경로를 만듭니다. 앞의 다이어그램에서 tenant1app.tenant1.com은 오스트레일리아 지역의 원본 그룹으로 라우팅하고 tenant2app.tenant3.com은 미국 지역의 원본 그룹으로 라우팅합니다.

이점

  • 고객은 자신의 도메인 이름을 제공할 수 있습니다. Azure Front Door는 요청을 다중 테넌트 솔루션으로 투명하게 라우팅합니다.
  • Adventure Works는 Azure Front Door의 단일 인스턴스를 유지 관리하여 트래픽을 여러 지역의 여러 스탬프로 라우팅합니다.

단점

  • Adventure Works는 새 테넌트가 온보딩될 때마다 Azure Front Door를 다시 구성해야 합니다.
  • 테넌트가 온보딩 프로세스에 참여해야 합니다. DNS를 변경하고 TLS 인증서를 발급해야 합니다.
  • 테넌트가 DNS 레코드를 제어합니다. DNS 레코드를 변경하면 Adventure Works 솔루션에 액세스하는 기능에 영향을 줄 수 있습니다.
  • Adventure Works는 Azure Front Door 할당량 및 한도, 특히 경로 및 사용자 지정 도메인 수와 복합 라우팅 한도에 주의해야 합니다.

시나리오 5: 스탬프당 Azure Front Door 프로필

각 스탬프에 대해 Azure Front Door 프로필을 배포할 수 있습니다. 스탬프가 10개인 경우 10개의 Azure Front Door 인스턴스를 배포합니다. 이 방법은 각 스탬프의 Azure Front Door 구성에 대한 관리 액세스를 제한해야 하는 경우에 유용할 수 있습니다. 리소스 할당량 또는 한도를 초과하지 않도록 여러 Azure Front Door 프로필을 사용해야 하는 경우에도 유용할 수 있습니다.

팁

Azure Front Door는 글로벌 리소스입니다. 지역 범위 스탬프를 배포하더라도 각 Azure Front Door 프로필은 전역적으로 배포됩니다. 여러 Azure Front Door 프로필을 실제로 배포해야 하는지 여부와 이를 통해 얻을 수 있는 이점을 고려해야 합니다.

여러 테넌트에서 제공하는 스탬프가 있는 경우 트래픽을 각 테넌트로 라우팅하는 방법을 고려해야 합니다. 이전 시나리오에서 설명한 접근 방식을 검토하고 요구 사항에 맞게 접근 방식을 결합하는 것이 좋습니다.

이점

  • 여러 프로필에서 구성을 확장하면 Azure Front Door 리소스 한도에 도달할 가능성이 줄어듭니다. 예를 들어 많은 수의 사용자 지정 도메인을 지원해야 하는 경우 도메인을 여러 Azure Front Door 프로필로 나누고 각 프로필의 한도 내에서 유지할 수 있습니다.
  • 이 방법을 사용하면 Azure Front Door 리소스 관리 권한의 범위를 지정할 수 있습니다. Azure RBAC(역할 기반 액세스 제어)를 사용하여 관리자에게 단일 스탬프의 프로필에 대한 액세스 권한을 부여할 수 있습니다.

단점

  • 이 방법은 일반적으로 더 많은 프로필을 배포하기 때문에 비용이 많이 듭니다. 자세한 내용은 Front Door 청구 이해를 참조하세요.
  • 단일 Azure 구독에 배포할 수 있는 Azure Front Door 프로필의 수에는 한도가 있습니다. 자세한 내용은 Front Door 할당량 및 한도를 참조하세요.
  • 각 스탬프의 Azure Front Door 프로필을 별도로 구성해야 하며 각 스탬프에 대한 DNS 구성, TLS 인증서 및 TLS 구성을 관리해야 합니다.

참가자

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

주요 작성자:

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계