원본으로의 트래픽 라우팅 메서드
Important
Azure Front Door(클래식)는 2027년 3월 31일에 사용이 중지됩니다. 서비스가 중단되지 않도록 하려면 2027년 3월까지 Azure Front Door(클래식) 프로필을 Azure Front Door 표준 또는 프리미엄 계층으로 마이그레이션하는 것이 중요합니다. 자세한 내용은 Azure Front Door(클래식) 사용 중지를 참조하세요.
Azure Front Door는 HTTP/HTTPS 트래픽이 서로 다른 원본 간에 분산되는 방법을 관리하는 네 가지 트래픽 라우팅 방법을 지원합니다. 사용자 요청이 Front Door 에지 위치에 도달하면 구성된 라우팅 방법을 통해 요청이 최상의 백 엔드 리소스로 전달됩니다.
참고 항목
이 문서에서 원본 은 백 엔드를 참조하고 원본 그룹은 Azure Front Door(클래식) 구성의 백 엔드 풀을 참조합니다.
네 가지 트래픽 라우팅 메서드는 다음과 같습니다.
대기 시간: 허용 가능한 민감도 범위 내에서 대기 시간이 가장 낮은 원본으로 요청을 라우팅하여 네트워크 대기 시간 측면에서 요청이 가장 가까운 원본으로 전송되도록 합니다.
우선 순위: 주 원본을 사용할 수 없게 되면 모든 트래픽을 처리할 기본 원본과 보조 원본을 백업으로 지정하여 원본에 대한 우선 순위를 설정할 수 있습니다.
가중치: 지정된 가중치 계수에 따라 트래픽을 균등하게 또는 분산하는 각 원점의 가중치를 할당합니다. 원본의 대기 시간이 허용 가능한 민감도 범위 내에 있는 경우 트래픽은 가중치 값에 따라 분산됩니다.
세션 선호도: 프런트 엔드 호스트 또는 도메인에 대한 세션 선호도를 구성하여 동일한 최종 사용자의 요청이 동일한 원본으로 전송되도록 합니다.
참고 항목
Azure Front Door 표준 및 프리미엄 계층에서 엔드포인트 이름은 Azure Front Door(클래식)의 프런트 엔드 호스트라고 합니다.
모든 Front Door 구성에는 백 엔드 상태 모니터링 및 자동화된 전역 장애 조치(failover)가 포함됩니다. 자세한 내용은 Front Door 백 엔드 모니터링을 참조하세요. Azure Front Door는 단일 라우팅 방법을 사용하거나 여러 메서드를 결합하여 애플리케이션 요구 사항에 따라 최적의 라우팅 토폴로지 만들기를 수행할 수 있습니다.
참고 항목
Front Door 규칙 엔진을 사용하여 Azure 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의 우선 순위 트래픽 라우팅 방법을 사용하면 이 장애 조치(failover) 패턴을 효과적으로 구현할 수 있습니다.
기본적으로 Azure Front Door는 트래픽을 가장 높은 우선 순위(가장 낮은 우선 순위 값)로 원본으로 라우팅합니다. 이러한 기본 원본을 사용할 수 없게 되면 트래픽을 보조 원본(다음으로 가장 낮은 우선 순위 값)으로 라우팅합니다. 이 프로세스는 기본 원본과 보조 원본을 모두 사용할 수 없는 경우 3차 원본으로 계속됩니다. 상태 프로브는 구성된 상태 및 상태에 따라 원본의 가용성을 모니터링합니다.
원본에 대한 우선 순위 구성
Azure Front Door 원본 그룹의 각 원본에는 1에서 5 사이의 값으로 설정할 수 있는 Priority 속성이 있습니다. 값이 낮을수록 우선 순위가 높습니다. 여러 원본이 동일한 우선 순위 값을 공유할 수 있습니다.
가중 트래픽 라우팅 메서드
가중 트래픽 라우팅 방법을 사용하면 미리 정의된 가중치에 따라 트래픽을 분산할 수 있습니다.
이 메서드에서는 Azure Front Door 원본 그룹의 각 원본에 가중치를 할당합니다. 가중치는 1에서 1000 사이의 정수이며 기본값 은 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없는 헤더가 포함됩니다. - 응답에는 유효한
Authorization헤더가 포함됩니다. - 응답은 HTTP 302 상태 코드입니다.
다음 단계
- Azure Front Door를 만드는 방법을 알아봅니다.
- Azure Front Door의 작동 방식을 알아봅니다.