원본으로의 트래픽 라우팅 메서드

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(클래식) 구성의 백 엔드 및 백 엔드 풀을 나타냅니다.

네 가지 트래픽 라우팅 메서드는 다음과 같습니다.

• 대기 시간: 대기 시간 기반 라우팅은 요청이 민감도 범위 내에서 허용 가능한 최저 대기 시간 원본으로 전송되도록 해줍니다. 즉, 요청은 네트워크 대기 시간과 관련하여 가장 가까운 원본 집합으로 전송됩니다.

• 우선 순위: 모든 트래픽에 서비스를 제공하도록 기본 원본을 구성하려는 경우 원본에 우선 순위를 설정할 수 있습니다. 2차 원본은 1차 원본을 사용할 수 없는 경우 백업이 될 수 있습니다.

• 가중치 적용: 트래픽을 원본 집합에 균등하게 또는 가중치 계수에 따라 분산하려는 경우 원본에 가중치를 할당할 수 있습니다. 원본의 대기 시간이 원본 그룹의 허용 가능한 대기 시간 민감도 범위 내에 있는 경우 트래픽은 가중치 값으로 분산됩니다.

• 세션 선호도: 프런트 엔드 호스트 또는 도메인에 대해 세션 선호도를 구성하여 동일한 최종 사용자의 요청이 동일한 원본으로 전송되도록 할 수 있습니다.

참고 항목

Azure Front Door 표준 및 프리미엄 계층의 엔드포인트 이름은 Azure Front Door(클래식)에서 프런트 엔드 호스트라고 합니다.

모든 Front Door 구성에는 백 엔드 상태 모니터링 및 자동화된 즉각적인 글로벌 장애 조치(failover)가 있습니다. 자세한 내용은 Front Door 백 엔드 모니터링을 참조하세요. Azure Front Door는 단일 라우팅 메서드로 사용할 수 있습니다. 애플리케이션 요구 사항에 따라 여러 라우팅 메서드를 결합하여 최적의 라우팅 토폴로지를 빌드할 수 있습니다.

참고 항목

Front Door 규칙 엔진을 사용할 때 Azure Front Door 표준 및 프리미엄 계층에서 경로 구성을 재정의하거나 요청에 대해 Azure Front Door(클래식)에서 백 엔드 풀을 재정의하도록 규칙을 구성할 수 있습니다. 규칙 엔진에서 설정한 원본 그룹 또는 백 엔드 풀은 이 문서에서 설명하는 라우팅 프로세스를 재정의합니다.

전반적인 의사 결정 흐름

다음 다이어그램은 전반적인 의사 결정 흐름을 보여 줍니다.

의사 결정 단계는 다음과 같습니다.

1. 사용 가능한 원본: 상태 프로브에 대해 사용하도록 설정되고 정상(200 OK)으로 반환된 모든 원본을 선택합니다.
   • 예제: A, B, C, D, E, F의 6개 원본이 있으며 이 중에서 C는 비정상 상태이고 E는 사용하지 않도록 설정되었다고 가정합니다. 사용 가능한 원본 목록은 A, B, D 및 F입니다.
2. 우선 순위: 사용 가능한 원본 중 가장 우선 순위가 높은 원본이 선택됩니다.
   • 예제: 원본 A, B, D의 우선 순위가 1이고 원본 F의 우선 순위가 2라고 가정합니다. 그런 다음, 선택한 원본은 A, B, D입니다.
3. 대기 시간 신호(상태 프로브 기반): 요청이 도착한 Front Door 환경에서 허용되는 대기 시간 범위 내의 원본을 선택합니다. 이 신호는 원본 그룹의 대기 시간 민감도 설정과 더 가까운 원본의 대기 시간을 기준으로 합니다.
   • 예제: Front Door는 요청이 원본 A에 도착하게 되는 환경의 대기 시간을 15ms로 측정하지만, B에 대한 대기 시간은 30ms이고 D에 대한 대기 시간은 60ms를 벗어난다고 가정합니다. 원본 그룹의 대기 시간 민감도를 30ms로 설정하면 D가 가장 가까운 원본(A)에서 30ms 넘게 떨어져 있으므로 가장 낮은 대기 시간 풀은 원본 A 및 B로 구성됩니다.
4. 가중치: 마지막으로 Azure Front Door는 지정된 가중치 비율로 최종 선택된 원본 그룹 간에 트래픽을 라운드 로빈합니다.
   • 예제: 원본 A의 가중치가 3이고 원본 B의 가중치가 7인 경우 트래픽은 원본 A에 3/10 B에 7/10로 분산됩니다.

세션 선호도를 사용하는 경우 세션의 첫 번째 요청은 위에 나열된 흐름을 따릅니다. 후속 요청은 첫 번째 요청에서 선택한 원본으로 전송됩니다.

최저 대기 시간 기반 트래픽 라우팅

전 세계적으로 둘 이상의 위치에 원본을 배포하면 트래픽을 최종 사용자에게 ‘가장 가까운’ 위치로 라우팅하여 많은 애플리케이션의 응답성을 향상시킬 수 있습니다. 대기 시간은 Front Door 구성의 기본 트래픽 라우팅 메서드입니다. 이 라우팅 메서드는 최종 사용자의 요청을 Azure Front Door 뒤에 있는 가장 가까운 원본으로 전달합니다. Azure Front Door의 애니캐스트 아키텍처와 결합된 이 라우팅 메커니즘은 각 최종 사용자가 위치에 따라 최상의 성능을 얻을 수 있도록 합니다.

'가장 가까운' 원본이 지리적 거리로 측정할 때 반드시 가장 가까운 것은 아닙니다. 대신 Azure Front Door는 네트워크 대기 시간을 측정하여 가장 가까운 원본을 결정합니다. Azure Front Door 라우팅 아키텍처에 대해 자세히 알아봅니다.

각 Front Door 환경은 원본 대기 시간을 개별적으로 측정합니다. 즉, 서로 다른 위치에 있는 다른 사용자가 해당 환경에 가장 적합한 성능으로 원본으로 라우팅됩니다.

참고 항목

기본적으로 대기 시간 민감도 속성은 0ms로 설정됩니다. 이 설정을 사용하면 요청이 항상 사용 가능한 가장 빠른 원본으로 전달되며 두 원본의 네트워크 대기 시간이 동일하지 않으면 원본의 가중치가 적용되지 않습니다.

우선 순위 기반 트래픽 라우팅

기본 백 엔드가 중단되는 경우를 위해 조직은 일반적으로 둘 이상의 백업 서비스를 배포하여 서비스에 고가용성을 제공하려고 합니다. 업계 전반에 걸쳐 이러한 형식의 토폴로지를 활성/대기 또는 활성/수동 배포라고도 합니다. 우선 순위 트래픽 라우팅 메서드를 사용하면 이 장애 조치(failover) 패턴을 쉽게 구현할 수 있습니다.

기본 Azure Front Door에는 동일한 우선 순위의 원본 목록이 포함되어 있습니다. 기본적으로 Azure Front Door는 기본 원본 집합으로 우선 순위가 가장 높은 원본(우선 순위가 가장 낮은 값)으로만 트래픽을 보냅니다. 기본 원본을 사용할 수 없는 경우 Azure Front Door는 트래픽을 두 번째 원본 집합(우선 순위에서 두 번째로 낮은 값)으로 라우팅합니다. 기본 및 보조 원본을 모두 사용할 수 없는 경우 트래픽은 세 번째 백 엔드 등으로 전송됩니다. 원본의 가용성은 구성된 상태와 상태 프로브에 의해 결정된 진행 중인 원본 상태를 기반으로 합니다.

원본에 대한 우선 순위 구성

Azure Front Door 구성의 원본 그룹에 있는 각 원본에는 1에서 5 사이의 숫자가 될 수 있는 우선 순위라는 속성이 있습니다. Azure Front Door를 사용하면 각 원본에 대해 이 속성을 사용하여 명시적으로 원본 우선 순위를 구성할 수 있습니다. 이 속성은 1에서 5 사이의 값입니다. 값이 낮을수록 우선 순위가 높아집니다. 원본은 동일한 우선 순위 값을 공유할 수 있습니다.

가중 트래픽 라우팅 메서드

가중 트래픽 라우팅 메서드를 사용하면 균등하게 트래픽을 분산하거나 미리 정의된 가중치를 사용할 수 있습니다.

가중치 기반 트래픽 라우팅 메서드에서는 원본 그룹의 Azure Front Door 구성에서 각 원본에 가중치를 할당합니다. 가중치는 1에서 1000 사이의 정수입니다. 이 매개 변수는 기본 가중치인 50을 사용합니다.

허용되는 대기 시간 민감도를 가진 사용 가능한 원본 목록과 함께 지정된 가중치 비율을 사용하여 트래픽이 라운드 로빈 메커니즘으로 분산됩니다. 대기 시간 민감도를 0밀리초로 설정하면 이 속성은 네트워크 대기 시간이 동일한 두 개의 원본이 있는 경우에만 적용됩니다.

가중 메서드를 사용하면 다음과 같은 몇 가지 유용한 시나리오를 사용할 수 있습니다.

• 점진적 애플리케이션 업그레이드: 트래픽의 일정 비율을 제공하여 새 원본으로 라우팅하고 시간이 지남에 따라 트래픽을 점차 늘려 다른 원본과 동등하게 만듭니다.
• Azure로 애플리케이션 마이그레이션: Azure 및 외부 원본이 있는 원본 그룹을 만듭니다. 새 원본을 기본 설정하도록 원본의 가중치를 조정합니다. 새 원본을 비활성화하는 것으로 시작하여 최저 가중치를 할당하고 대부분 트래픽을 처리하는 수준까지 서서히 늘려 점진적으로 설정할 수 있습니다. 그런 다음 마지막으로 덜 기본 설정하는 원본을 사용하지 않도록 설정하고 그룹에서 제거합니다.
• 추가 용량을 위한 클라우드 버스트: Front Door 뒤에 두어 온-프레미스 배포를 클라우드로 신속하게 확장합니다. 클라우드에서 추가 용량이 필요한 경우 더 많은 원본을 추가하거나 사용하도록 설정하고 각 원본으로 가는 트래픽 부분을 지정할 수 있습니다.

세션 선호도

기본적으로 세션 선호도가 없으면 Azure Front Door는 동일한 클라이언트에서 시작되는 요청을 다른 원본으로 전달합니다. 특정 상태 저장 애플리케이션 또는 특정 시나리오에서 동일한 사용자의 요청이 이어지는 경우 초기 요청을 처리하기 위해 동일한 원본을 기본 설정합니다. 쿠키 기반 세션 선호도 기능은 클라이언트가 원본에 인증하는 시나리오와 같이 동일한 원본에서 사용자 세션을 유지하려는 경우 유용합니다. 원본 URL의 SHA256과 함께 관리되는 쿠키를 쿠키의 식별자로 사용하는 경우 Azure Front Door는 처리를 위해 사용자 세션의 후속 트래픽을 동일한 원본으로 보낼 수 있습니다.

세션 선호도는 구성된 각 도메인(또는 하위 도메인)에 대해 Azure Front Door 표준 및 프리미엄 계층의 원본 그룹 수준과 Azure Front Door(클래식)의 프런트 엔드 호스트 수준에서 사용하도록 설정할 수 있습니다. 사용하도록 설정되면 Azure Front Door는 사용자 세션에 쿠키를 추가합니다. 쿠키는 ASLBSA 및 ASLBSACORS라고 합니다. 쿠키 기반 세션 선호도를 통해 Front Door는 동일한 IP 주소를 사용하고 있더라도 다른 사용자를 식별할 수 있어 다른 원본 간에 트래픽을 더 고르게 분산시킬 수 있습니다.

Front Door가 현재 세션 쿠키만을 지원하고 있으므로, 쿠키 수명은 사용자의 세션과 동일합니다.

참고 항목

구성 위치에 관계없이 세션 선호도는 도메인 수준에서 브라우저 세션 쿠키를 통해 기억됩니다. 동일한 와일드카드 도메인 아래의 하위 도메인은 동일한 사용자 브라우저가 동일한 원본 리소스에 대한 요청을 보내는 한 세션 선호도를 공유할 수 있습니다.

공용 프록시는 세션 선호도를 방해할 수 있습니다. 이는 세션을 구축하려면 Front Door가 세션 선호도 쿠키를 응답에 추가해야 하기 때문입니다. 즉, 동일한 리소스를 요청하는 다른 클라이언트의 쿠키를 방해하므로 응답이 캐싱 가능한 경우 실행할 수 없습니다. 이로부터 보호하기 위해 시도될 때 원본이 캐싱 가능한 응답을 전송하면 세션 선호도는 설정되지 않습니다. 세션이 이미 설정된 경우 원본의 응답이 캐시 가능한지 여부는 중요하지 않습니다.

세션 선호도는 캐시할 수 없는 표준 시나리오 이외의 다음과 같은 상황에서 설정됩니다.

• 응답에는 no-store의 Cache-Control 헤더가 포함되어야 합니다.
• 응답에 Authorization 헤더가 포함된 경우 만료되지 않아야 합니다.
• 응답은 HTTP 302 상태 코드입니다.

다음 단계

• Azure Front Door를 만드는 방법을 알아봅니다.
• Azure Front Door의 작동 방식을 알아봅니다.