적용 대상: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door(클래식)
중요합니다
Azure Front Door(클래식)는 프로필 만들기, 새 도메인 온보딩 또는 관리되는 인증서를 지원하지 않으며 March 31, 2027 사용 중지합니다. 서비스 중단을 방지하려면 Azure Front Door Standard 또는 Premium로 마이그레이션합니다. 자세한 내용은 Azure Front Door(클래식) 사용 중지 참조하세요.
Azure Front Door는 HTTP/HTTPS 트래픽을 서로 다른 원본 간에 분산하는 방법을 관리하기 위해 네 가지 트래픽 라우팅 방법을 지원합니다. 사용자 요청이 Front Door 에지 위치에 도달하면 구성된 라우팅 방법을 통해 요청이 최상의 백 엔드 리소스로 전달됩니다.
참고
이 문서에서 원본 은 백 엔드를 참조하고 원본 그룹은 Azure Front Door(클래식) 구성의 백 엔드 풀을 참조합니다.
네 가지 트래픽 라우팅 메서드는 다음과 같습니다.
대기 시간: 허용 가능한 민감도 범위 내에서 대기 시간이 가장 낮은 원본으로 요청을 라우팅하여 네트워크 대기 시간 측면에서 요청이 가장 가까운 원본으로 전송되도록 합니다.
우선 순위: 주 원본을 사용할 수 없게 되면 모든 트래픽을 처리할 기본 원본과 보조 원본을 백업으로 지정하여 원본에 대한 우선 순위를 설정할 수 있습니다.
가중치: 지정된 가중치 계수에 따라 트래픽을 균등하게 또는 분산하는 각 원점의 가중치를 할당합니다. 원본의 대기 시간이 허용 가능한 민감도 범위 내에 있는 경우 트래픽은 가중치 값에 따라 분산됩니다.
세션 선호도: 프런트 엔드 호스트 또는 도메인에 대한 세션 선호도를 구성하여 동일한 최종 사용자의 요청이 동일한 원본으로 전송되도록 합니다.
참고
Azure Front Door 표준 및 프리미엄 계층에서, 엔드포인트 이름은 Azure Front Door(클래식)에서 프런트 엔드 호스트로 지칭됩니다.
모든 Front Door 구성에는 백엔드 상태 모니터링과 자동 전역 장애 조치가 포함됩니다. 자세한 내용은 Front Door 백엔드 모니터링을 참조하세요. Azure Front Door는 단일 라우팅 방법을 사용하거나 여러 메서드를 결합하여 애플리케이션 요구 사항에 따라 최적의 라우팅 토폴로지 만들기를 수행할 수 있습니다.
참고
전반적인 의사 결정 흐름
다음 다이어그램은 전반적인 의사 결정 흐름을 보여 줍니다.
의사 결정 단계는 다음과 같습니다.
-
사용 가능한 원본: 상태 프로브에 따라 활성화되고 정상(200 OK)인 모든 원본을 선택합니다.
- 예: 6개의 원본 A, B, C, D, E 및 F 및 C가 비정상이고 E가 비활성화된 경우 사용 가능한 원본은 A, B, D 및 F입니다.
-
우선 순위: 사용 가능한 원본 중에서 우선 순위가 가장 큰 원본을 선택합니다.
- 예: 원본 A, B 및 D의 우선 순위가 1이고 원본 F의 우선 순위가 2인 경우 선택한 원본은 A, B 및 D입니다.
-
대기 시간 신호(상태 프로브 기반): 요청이 도착한 Front Door 환경에서 허용되는 대기 시간 범위 내의 원본을 선택합니다. 이 범위는 원본 그룹의 대기 시간 민감도 설정과 가장 가까운 원본의 대기 시간을 기반으로 합니다.
- 예: 원본 A에 대한 대기 시간이 15ms이고 B가 30ms이고 D가 60ms이고 대기 시간 민감도가 30ms로 설정된 경우 D가 30ms 범위를 초과하므로 선택한 원본은 A 및 B입니다.
-
가중치: 지정된 가중치 비율에 따라 선택한 최종 원본 간에 트래픽을 분산합니다.
- 예: 원본 A의 가중치가 3이고 원본 B의 가중치가 7인 경우 트래픽은 3/10에서 A로, 7/10은 B로 분산됩니다.
세션 선호도를 사용하도록 설정하면 세션의 첫 번째 요청은 이전에 설명한 흐름을 따릅니다. 후속 요청은 첫 번째 요청에서 선택한 원본으로 이동합니다.
최저 대기 시간 기반 트래픽 라우팅
여러 글로벌 위치에 원본을 배포하면 최종 사용자에게 "가장 가까운" 원본으로 트래픽을 라우팅하여 애플리케이션의 응답성을 향상시킬 수 있습니다. 대기 시간 라우팅 방법은 Azure Front Door 구성의 기본값입니다. 이 메서드는 가장 가까운 지리적 위치가 아닌 네트워크 대기 시간이 가장 낮은 원본으로 사용자 요청을 전달하여 최적의 성능을 보장합니다.
대기 시간 라우팅 방법과 결합된 Azure Front Door의 애니캐스트 아키텍처는 각 사용자가 자신의 위치에 따라 최상의 성능을 경험할 수 있도록 합니다. 각 Front Door 환경은 원본에 대한 대기 시간을 독립적으로 측정합니다. 즉, 서로 다른 위치에 있는 사용자가 특정 환경에 가장 적합한 성능을 제공하는 원본으로 라우팅됩니다.
참고
기본적으로 대기 시간 민감도 속성은 0ms로 설정됩니다. 이 설정을 사용하면 요청이 항상 사용 가능한 가장 빠른 원본으로 전달됩니다. 원본에 대한 가중치는 두 원본의 네트워크 대기 시간이 동일한 경우에만 적용됩니다.
자세한 내용은 Azure Front Door 라우팅 아키텍처를 참조 하세요.
우선 순위 기반 트래픽 라우팅
고가용성을 보장하려면 주 서비스가 실패할 경우 백업 서비스를 배포하여 인수합니다. 이 설정은 활성/대기 또는 활성/수동 배포로 알려져 있습니다. Azure Front Door Priority 트래픽 라우팅 방법을 사용하면 이 장애 조치 패턴을 구현할 수 있습니다.
기본적으로 Azure Front Door는 트래픽을 가장 높은 우선 순위(가장 낮은 우선 순위 값)로 원본으로 라우팅합니다. 이러한 기본 원본을 사용할 수 없게 되면 트래픽을 보조 원본(다음으로 가장 낮은 우선 순위 값)으로 라우팅합니다. 이 프로세스는 기본 원본과 보조 원본을 모두 사용할 수 없는 경우 3차 원본으로 계속됩니다. 헬스 프로브는 구성된 상태 및 건강도에 따라 원본의 가용성을 모니터링합니다.
원본에 대한 우선 순위 구성
Azure Front Door 원본 그룹의 각 원본에는 1에서 5 사이의 값으로 설정할 수 있는 Priority 속성이 있습니다. 값이 낮을수록 우선 순위가 높습니다. 여러 원본이 동일한 우선 순위 값을 공유할 수 있습니다.
가중 트래픽 라우팅 메서드
참고
분산된 AFD POP 및 기계의 특성으로 인해 초당 요청 수(RPS)가 매우 낮은 고객의 경우, Azure Front Door는 설정한 가중치가 엄격하게 준수되지 않거나 부하 분산이 왜곡된 것으로 보일 수 있음을 보장할 수 없습니다.
가중 트래픽 라우팅 방법은 미리 정의된 가중치에 따라 트래픽을 분산합니다.
이 메서드에서는 Azure Front Door 원본 그룹의 각 원본에 가중치를 할당합니다. 가중치는 1에서 1,000 사이의 정수이며 기본값은 50입니다.
원본이 허용 가능한 대기 시간 민감도를 충족하는 경우 지정된 가중치 비율에 따라 라운드 로빈 메커니즘을 사용하여 사용 가능한 원본 간에 트래픽을 분산합니다. 대기 시간 민감도를 0 밀리초로 설정하면 두 원본의 네트워크 대기 시간이 동일한 경우에만 가중치가 적용됩니다.
가중 메서드는 다음과 같은 몇 가지 시나리오를 지원합니다.
- 점진적 애플리케이션 업그레이드: 트래픽의 백분율을 새 원본으로 라우팅하고 시간이 지남에 따라 점진적으로 증가합니다.
- Azure로 애플리케이션 마이그레이션: Azure 및 외부 원본이 있는 원본 그룹을 만듭니다. 새 원본을 선호하도록 가중치를 조정하고, 대부분의 트래픽을 처리할 때까지 트래픽 공유를 점진적으로 늘인 다음, 선호도가 낮은 원본을 사용하지 않도록 설정하고 제거합니다.
- 추가 용량에 대한 클라우드 버스팅: 더 많은 원본을 추가하거나 사용하도록 설정하고 트래픽 배포를 지정하여 온-프레미스 배포를 클라우드로 확장합니다.
세션 선호도
기본적으로 Azure Front Door는 동일한 클라이언트의 요청을 다른 원본으로 전달합니다. 그러나 세션 선호도는 상태 저장 애플리케이션 또는 동일한 사용자의 후속 요청을 동일한 원본에서 처리해야 하는 시나리오에 유용합니다. 이 기능은 동일한 원본이 사용자의 세션을 처리하도록 보장하며, 클라이언트 인증과 같은 시나리오에서 유용합니다.
Azure Front Door는 원본 URL의 SHA256을 식별자로 사용하는 관리되는 쿠키를 사용하는 쿠키 기반 세션 선호도를 사용합니다. 이 메서드는 사용자 세션에서 동일한 원본으로 후속 트래픽을 전달합니다.
Azure Front Door 표준 및 프리미엄 계층의 원본 그룹 수준과 구성된 각 도메인 또는 하위 도메인에 대한 Azure Front Door(클래식)의 프런트 엔드 호스트 수준에서 세션 선호도를 사용하도록 설정할 수 있습니다. 이 기능을 사용하도록 설정하면 Azure Front Door ASLBSA 및 ASLBSACORS라는 쿠키를 사용자의 세션에 추가합니다. 이러한 쿠키는 동일한 IP 주소를 공유하는 경우에도 다른 사용자를 식별하는 데 도움이 되므로 원본 간에 트래픽을 더 균등하게 분산할 수 있습니다.
Front Door는 현재 세션 쿠키만 지원하므로 쿠키의 수명은 사용자의 세션과 일치합니다.
참고
브라우저 세션 쿠키는 도메인 수준에서 세션 선호도를 유지합니다. 동일한 와일드카드 도메인 아래의 하위 도메인은 사용자의 브라우저가 동일한 원본 리소스에 대한 요청을 보내는 한 세션 선호도를 공유할 수 있습니다.
세션을 설정하려면 Front Door가 응답에 세션 선호도 쿠키를 추가해야 하기 때문에 공용 프록시가 세션 선호도를 방해할 수 있습니다. 응답이 캐시 가능한 경우 동일한 리소스를 요청하는 다른 클라이언트의 쿠키가 중단되므로 이 작업을 수행할 수 없습니다. 이 문제를 방지하기 위해 원본이 캐시 가능한 응답을 보내는 경우 세션 선호도가 설정 되지 않습니다 . 세션이 이미 설정된 경우 응답의 캐시 가능성은 중요하지 않습니다.
세션 선호도는 다음과 같은 경우에 표준 캐시할 수 없는 시나리오를 넘어서 설정됩니다.
- 응답에는
Cache-Control헤더가 no-store를 포함합니다. - 응답에는 유효한
Authorization헤더가 포함됩니다. - 응답은 HTTP 302 상태 코드입니다.
다음 단계
- Azure Front Door를 만드는 방법을 알아봅니다.
- Azure Front Door의 작동 방식을 알아봅니다.