Azure Front Door의 일반적인 성능 문제 해결

2025-09-28

성능 문제는 Azure Front Door 서비스, 원본, 요청한 클라이언트 또는 이러한 홉 사이의 경로 등 여러 잠재적 영역에서 발생할 수 있습니다. 이 문제 해결 가이드는 데이터 경로에서 문제의 근본 원인일 가능성이 가장 높은 홉을 식별하고 문제를 해결하는 방법을 안내합니다.

알려진 문제 확인

시작하기 전에 다음과 같은 알려진 문제가 있는지 확인합니다.

Azure Front Door 플랫폼
경로의 ISP(인터넷 서비스 공급자)
데이터를 연결하고 검색하는 요청한 클라이언트의 기능

시나리오 1: 원본 조사

원본 서버 중 하나가 느리면 Azure Front Door를 통한 개체에 대한 첫 번째 요청이 느려집니다. 또한 콘텐츠가 Azure Front Door POP(현재 상태 지점)에 캐시되지 않으면 요청이 원본으로 전달됩니다. 원본에서 서비스를 제공하면 요청한 클라이언트에 대한 POP의 근접성 및 로컬 전달의 이점이 없어지며, 대신 원본의 성능에 의존하게 됩니다.

시나리오 1: 필요한 환경 정보

Azure Front Door: 엔드포인트 이름
- 엔드포인트 호스트 이름
- 엔드포인트 사용자 지정 도메인(해당하는 경우)
- 원본 호스트 이름
영향을 받는 파일의 전체 URL

시나리오 1: 문제 해결 단계

영향을 받는 요청에서 응답 헤더를 확인합니다.

응답 헤더를 확인하려면 Bash에서 다음 curl 예제를 사용합니다. F12 키를 선택하여 브라우저의 개발자 도구를 사용할 수도 있습니다. 네트워킹 탭을 선택하고 조사할 관련 파일을 선택한 다음, 헤더 탭을 선택합니다. 파일이 없으면 개발자 도구가 열려 있는 페이지를 다시 로드합니다.

초기 응답에는 TCP_MISS 또는 CONFIG_NOCACHE 값이 있는 x-cache 헤더가 있어야 합니다. Azure Front Door POP는 이 값이 있는 요청을 원본으로 전달합니다. 원본은 동일한 경로의 반환 트래픽을 요청한 클라이언트로 보냅니다.

다음은 TCP_MISS를 보여 주는 예제입니다.
```
$ curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:02:09 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170209Z-AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
x-fd-int-roxy-purgeid: 0
x-cache: TCP_MISS
accept-ranges: bytes
```
다음은 TCP_HIT를 보여 주는 예제입니다.
```
curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:04:38 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170438Z-BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
x-fd-int-roxy-purgeid: 0
x-cache: TCP_HIT
x-cache-info: L1_T2
accept-ranges: bytes
```
x-cache 헤더에 TCP_HIT 값이 있을 때까지 엔드포인트에 대해 계속 요청합니다.

처음에 본 CONFIG_NOCACHE경우 경로 구성에서 캐싱을 사용하도록 설정되지 않습니다. 이 경우, TCP_HIT가 시되지 않습니다.
성능 문제가 해결되면 문제의 원인은 Azure Front Door의 성능이 아니라 원본의 속도 때문이었습니다. 소유자는 성능을 향상하기 위해 Azure Front Door 캐시 설정 또는 원본을 해결해야 합니다.

문제가 지속되면 원본은 콘텐츠 또는 Azure Front Door 서비스를 요청하는 클라이언트일 수 있습니다. 시나리오 2로 이동하여 원본을 식별합니다.

시나리오 2: 단일 클라이언트 또는 위치(예: ISP)가 느림

요청한 클라이언트와 Azure Front Door POP 사이에 잘못된 네트워크 경로가 있는 경우 단일 클라이언트 또는 위치가 느려질 수 있습니다. 잘못된 경로를 지정하면 POP까지의 거리에 영향을 주게 되어 Azure Front Door POP의 근접성 이점이 없어지므로 이러한 경로는 제거해야 합니다.

VPN(가상 사설망)을 사용하거나 분산된 회사 네트워크의 일부인 경우 긴 대기 시간 또는 낮은 대역폭은 ISP 문제의 결과일 수 있습니다. 회사 네트워크는 중앙 원격 지점을 통해 모든 트래픽을 라우팅할 수 있습니다.

시나리오 2: 필요한 환경 정보

Azure Front Door: 엔드포인트 이름
- 엔드포인트 호스트 이름
- 엔드포인트 사용자 지정 도메인(해당하는 경우)
- 원본 호스트 이름
영향을 받는 파일의 전체 URL
요청한 클라이언트 정보
- 요청한 클라이언트 IP
- 요청한 클라이언트 위치
- Azure 환경에 대한 요청한 클라이언트 경로(일반적으로 tracert, pathping 또는 유사한 도구로 식별됨)

시나리오 2: 문제 해결 단계

POP에 대한 경로를 확인하려면 500개 패킷에 대해 pathping 또는 유사한 도구를 사용하여 네트워크 경로를 확인합니다.

Pathping에는 최대 250개의 쿼리가 있습니다. 500까지 테스트하려면 다음 쿼리를 두 번 실행합니다.
```
pathping /q 250 <Full URL of Affected File>
```
트래픽이 시간을 늘리거나 먼 지역으로 이동하는 경로를 취하는지 확인합니다.

지리에 따라 적절한 경로를 사용하지 않거나(예: 유럽의 트래픽이 미국으로 라우팅됨) 또는 홉 수가 너무 많은 IP, 도시 또는 지역 코드를 찾습니다.
요청한 클라이언트 설정을 배제하려면 동일한 지역의 다른 요청한 클라이언트에서 테스트합니다.
추가 홉 또는 원격 지역을 식별하는 경우 Azure Front Door 서비스 자체가 아닌 Azure Front Door POP에 액세스하는 클라이언트에 문제가 있는 것입니다. 연결 또는 VPN 공급자는 엔드포인트 간의 홉을 처리해야 합니다.

추가 홉 또는 원격 지역을 식별하지 않고 콘텐츠가 캐시(x-cache: TCP_HIT)에서 제공되는 경우 Azure Front Door 서비스에 문제가 있습니다. 지원 요청을 만들어야 할 수도 있습니다. 이 문제 해결 문서 및 수행한 단계에 대한 참조를 포함합니다.

참고

콘텐츠가 원본(x-cache: TCP_MISS)에서 제공되는 경우 이 문서의 앞부분에 있는 시나리오 1을 참조하세요.

시나리오 3: 웹 사이트가 느리게 로드됨

일부 시나리오에서는 단일 파일에 문제가 없지만 전체(Azure Front Door에서 프록시) 웹 페이지의 성능은 만족스럽지 않습니다. 웹 페이지 성능 도구는 Azure Front Door 외부의 웹 페이지에 비해 사이트 성능이 저하되었음을 보여 줍니다.

웹 페이지는 종종 많은 파일로 구성됩니다. 웹 사이트는 Azure Front Door가 웹 페이지에서 각 파일을 제공하는 경우에만 Azure Front Door의 이점을 누릴 수 있습니다. 이점을 최대화하도록 Azure Front Door를 구성해야 합니다.

다음과 같은 예제를 참조하세요.

원본: origin.contoso.com
Azure Front Door 사용자 지정 도메인: contoso.com
로드하려는 페이지: https://contoso.com

페이지가 로드되면 "/" 디렉터리의 초기 파일은 페이지를 빌드하는 다른 파일을 호출합니다. 이러한 파일은 이미지, JavaScript, 텍스트 파일 등입니다. 해당 파일이 Azure Front Door 호스트 이름()contoso.com을 통해 호출되지 않는 경우 페이지는 Azure Front Door를 사용하지 않습니다. 웹사이트에서 요청하는 파일 가운데 하나가 http://www.images.fabrikam.com/businessimage.jpg이라면, 그 파일은 Azure Front Door의 사용으로부터 이점이 없습니다. 대신 요청한 클라이언트의 브라우저가 images.fabrikam.com 서버에서 직접 파일을 요청합니다.

단일 웹 사이트에 대해 서로 다른 원본이 있는 여러 파일과 해당 구성이 Azure Front Door 성능에 미치는 영향을 보여 주는 다이어그램

시나리오 3: 필요한 환경 정보

Azure Front Door: 엔드포인트 이름
- 엔드포인트 호스트 이름
- 엔드포인트 사용자 지정 도메인(해당하는 경우)
- 원본 호스트 이름
- 원본의 지리적 위치
영향을 받는 웹 페이지의 전체 URL
성능을 측정하는 도구 및 메트릭

시나리오 3: 문제 해결

성능 저하를 보여 주는 메트릭을 검토합니다.

중요합니다

Microsoft는 소유하지 않는 도구로 측정되는 사항을 파악할 수 없습니다.
브라우저에서 Azure Front Door 웹 페이지를 열고 F12 키를 선택하여 개발자 도구를 엽니다.

브라우저에서 개발자 도구를 사용하여 제공되는 파일의 원본을 확인할 수 있습니다. 개발자 도구에서 요청 URL을 보려면 네트워킹 탭을 선택하고 조사 중인 파일을 선택한 다음, 일반을 선택합니다. 파일이 없으면 개발자 도구가 열려 있는 페이지를 다시 로드합니다.
파일의 원본 또는 요청 URL을 확인합니다.
Azure Front Door 호스트 이름을 사용하는 파일과 그렇지 않은 파일을 식별합니다.

앞의 예제에서 Azure Front Door에서 호스트되는 이미지는 https://www.contoso.com/productimage1.jpg입니다. Azure Front Door에서 호스트되지 않는 이미지는 http://www.images.fabrikam.com/businessimage.jpg입니다.
Azure Front Door에서 제공하는 파일의 성능, 원본 및(해당하는 경우) 테스트 웹 페이지를 테스트합니다.

원본 또는 테스트 웹 페이지가 성능을 테스트하는 도구와 가까운 지리적 지역에서 제공되는 경우 도구를 사용하거나 다른 지역의 클라이언트를 요청하여 Azure Front Door POP의 근접성 이점을 검사해야 할 수 있습니다.

중요합니다

Azure Front Door 호스트 이름 외부에서 제공되는 파일은 이를 통해 이점을 얻지 못합니다. 이렇게 하려면 웹 페이지를 다시 디자인해야 할 수 있습니다.

파일이 캐시되는 경우 응답 헤더 x-cache: TCP_HIT가 있는 파일을 테스트해야 합니다.
수집된 데이터에 따라 작업을 수행합니다.
- 수집된 데이터에 Azure Front Door 호스트 이름 외부의 서버에서 파일이 실행되고 있음을 보여 주는 경우 Azure Front Door가 예상대로 작동되는 것입니다.
  
  웹 사이트를 천천히 로드하려면 웹 페이지 디자인을 변경해야 할 수 있습니다. Azure Front Door를 사용하도록 웹 사이트를 최적화하는 데 도움이 필요하면 웹 사이트 디자인 팀 또는 Microsoft 솔루션 공급자와 연결하세요.
  
  참고
  
  웹 사이트 디자인의 복잡성과 파일 호출 지침에 따라 웹 사이트를 느리게 로드하는 문제를 검토하는 데 시간이 걸릴 수 있습니다.
- 수집된 데이터에 원본 또는 테스트 사이트에 비해 Azure Front Door의 파일 로드 성능이 더 나은 것으로 나타나면 Azure Front Door가 예상대로 작동되는 것입니다. 문제의 원인은 개별 클라이언트 요청일 수 있습니다. 이 경우 이 문서의 앞부부분에 있는 시나리오 1을 참조하세요.
- 수집된 데이터가 Azure Front Door에서 성능이 더 좋지 않다는 것을 보여 주는 경우 추가 조사를 위해 지원 요청을 제출해야 할 수 있습니다. 이 문제 해결 문서 및 수행한 단계에 대한 참조를 포함합니다.

피드백

이 페이지가 도움이 되었나요?