상태 프로브
Important
Azure Front Door(클래식)는 2027년 3월 31일에 사용이 중지됩니다. 서비스가 중단되지 않도록 하려면 2027년 3월까지 Azure Front Door(클래식) 프로필을 Azure Front Door 표준 또는 프리미엄 계층으로 마이그레이션하는 것이 중요합니다. 자세한 내용은 Azure Front Door(클래식) 사용 중지를 참조하세요.
참고 항목
이 문서에서 원본 및 원본 그룹은 Azure Front Door(클래식) 구성의 백 엔드 및 백 엔드 풀을 나타냅니다.
지정된 Azure Front Door 환경에 대한 각 원본의 상태 및 근접성을 확인하기 위해 각 Front Door 환경은 구성된 각각의 원본으로 가상 HTTP/HTTPS 요청을 주기적으로 보냅니다. 그런 다음, Azure Front Door는 상태 프로브의 응답을 사용하여 클라이언트 요청을 라우팅하는 최상의 원본을 결정합니다.
Warning
각 Azure Front Door 에지 위치가 상태 프로브를 원본으로 보내기 때문에 원본에 대한 상태 프로브 볼륨이 높을 수 있습니다. 프로브 수는 고객의 트래픽 위치와 상태 프로브 빈도에 따라 다릅니다. Azure Front Door 에지 위치가 최종 사용자로부터 실제 트래픽을 수신하지 않는 경우 에지 위치에서 상태 프로브의 빈도가 구성된 빈도에서 감소합니다. 모든 Azure Front Door 에지 위치에 대한 트래픽이 있는 경우 상태 프로브 빈도에 따라 상태 프로브 볼륨이 높을 수 있습니다.
기본 프로브 빈도인 30초를 사용할 때 원본에 대한 분당 상태 프로브 볼륨을 대략적으로 예측하는 예입니다. 각 원본의 프로브 볼륨은 에지 위치 수에 분당 두 요청을 곱한 것과 같습니다. 모든 에지 위치로 전송되는 트래픽이 없으면 검색 요청이 줄어듭니다. 에지 위치 목록은 지역별 에지 위치를 참조하세요.
지원되는 프로토콜
Azure Front Door는 HTTP 또는 HTTPS 프로토콜을 통한 프로브 전송을 지원합니다. 이러한 프로브는 클라이언트 요청을 라우팅하도록 구성된 동일한 TCP 포트를 통해 전송되며 재정의할 수 없습니다. Front Door HTTP/HTTPS 프로브는 값이 Edge Health Probe로 설정된 User-Agent 헤더와 함께 전송됩니다.
상태 프로브에 지원되는 HTTP 메서드
Azure Front Door는 상태 프로브를 보내기 위해 다음과 같은 HTTP 메서드를 지원합니다.
- GET: GET 메서드는 요청 URI로 식별되는 모든 정보(엔터티 형식)를 검색하는 것을 의미합니다.
- HEAD: HEAD 메서드는 서버가 응답에서 메시지 본문을 반환해서는 안 된다는 점을 제외하면 GET 메서드와 동일합니다. 새 Front Door 프로필의 경우 기본적으로 프로브 메서드가 HEAD로 설정됩니다.
팁
원본에 대한 부하 및 비용을 낮추기 위해 Front Door는 상태 프로브에 HEAD 요청을 사용하는 것이 좋습니다.
상태 프로브 응답
| 응답 | 설명 |
|---|---|
| 상태 확인 | 200 OK 상태 코드는 원본이 정상임을 나타냅니다. 다른 상태 코드는 오류로 간주됩니다. 어떤 이유로든 프로브에 대해 유효한 HTTP 응답을 받지 못하면 프로브는 실패로 계산됩니다. |
| 대기 시간 측정 | 대기 시간은 프로브 요청이 전송되기 직전부터 Front Door가 응답의 마지막 바이트를 수신하는 순간까지 측정된 벽시계 시간입니다. Front Door는 각 요청에 대해 새 TCP 연결을 사용합니다. 측정값은 기존 웜 연결이 있는 원본 쪽으로 편향되지 않습니다. |
Front Door가 원본 상태를 결정하는 방법
Azure Front Door는 모든 알고리즘에서 3단계 프로세스를 사용하여 상태를 확인합니다.
비활성화된 원본을 제외합니다.
상태 프로브 오류가 있는 원본을 제외합니다.
이 선택은 마지막 n 상태 프로브 응답을 확인하여 완료합니다. 최소한 x가 정상적인 경우 원본은 정상 상태로 간주됩니다.
n은 부하 분산 설정의 SampleSize 속성을 변경하여 구성됩니다.
x는 부하 분산 설정의 SuccessfulSamplesRequired 속성을 변경하여 구성됩니다.
원본 그룹의 정상 원본 세트에 대해 Front Door는 각 원본에 대한 대기 시간을 측정하고 유지 관리합니다.
참고 항목
단일 엔드포인트가 여러 원본 그룹의 멤버인 경우 Front Door는 원본으로 전송되는 상태 프로브 수를 최적화하여 원본의 부하를 줄입니다. 상태 프로브 요청은 가장 낮은 구성된 샘플 간격에 따라 전송됩니다. 동일한 상태 프로브의 응답은 모든 원본 그룹의 엔드포인트 상태를 결정합니다.
장기 시작 컨테이너에 대한 프로브 설정 조정
장기 시작 컨테이너를 처리할 때 프로브 설정을 조정하면 조기 오류를 방지할 수 있습니다.
ProbeTimeout 값을 Interval 늘리면 Front Door에서 컨테이너를 비정상으로 표시하기 전에 컨테이너를 시작하는 데 더 많은 시간이 걸립니다.
장기 시작 컨테이너의 값
- ProbeTimeout: 제한 시간을 10~30초로 늘입니다.
- 간격: 프로브 간에 더 긴 간격(예: 30~60초)을 설정합니다.
- UnhealthyThreshold: 컨테이너가 비정상으로 간주되기 전에 연속 실패 프로브 수를 늘입니다(예: 3-5 다시 시도).
참고 항목
에 제공된 ProbeTimeoutInterval값이며 UnhealthyThreshold 예제 용도로는 샘플 범위입니다. 특정 컨테이너의 시작 동작 및 요구 사항에 따라 이러한 값을 조정할 수 있습니다.
참고 항목
이러한 변경으로 인해 실제 오류 검색이 지연될 수 있으므로 컨테이너의 시작 동작에 따라 이러한 값의 균형을 신중하게 조정합니다.
컨테이너 수명 주기 단계 중 프로브 상호 작용
컨테이너 시작 단계: 이 단계에서 컨테이너가 트래픽을 처리할 준비가 되지 않았을 수 있습니다. 상태 프로브는 특정 HTTP 상태 코드(예
200 OK: )를 확인하여 컨테이너가 응답하지 않는 시기를 감지하는 데 도움이 됩니다. 프로브 빈도가 너무 높거나 시간 제한이 너무 짧으면 초기화 전에 컨테이너가 비정상으로 표시됩니다. 이 단계에서 프로브 시간 제한 또는 간격을 늘입니다.실행 단계: 컨테이너가 실행되면 프로브는 상태 응답을 계속 확인합니다. 상태 검사가 일관되게 반환
200 OK되면 Front Door는 트래픽에 대한 원점 회전을 유지합니다. 예를 들어 컨테이너 크래시로 인해 프로브가 지속적으로 실패하는 경우 Front Door는 원본을 비정상으로 표시합니다.실패 단계: 구성된 임계값(예
UnhealthyThreshold: )에 대해 상태 프로브가 실패하면 원본이 비정상으로 간주되고 트래픽이 다른 정상 원본으로 라우팅됩니다.
상태 프로브 실패 완료
원본 그룹의 모든 원본에 대해 상태 프로브가 실패하는 경우 Front Door는 모든 원본을 비정상으로 간주하고 모든 원본에 걸쳐 라운드 로빈 배포에서 트래픽을 라우팅합니다.
원본이 정상 상태로 돌아오면 Front Door는 정상적인 부하 분산 알고리즘을 다시 시작합니다.
상태 프로브 사용 안 함
원본 그룹에 단일 원본이 있는 경우 상태 프로브를 사용하지 않도록 선택하여 애플리케이션의 부하를 줄일 수 있습니다. 원본 그룹에 원본이 여러 개 있고 둘 이상의 원본이 활성화된 상태인 경우 상태 프로브를 사용하지 않도록 설정할 수 없습니다.
참고 항목
원본 그룹에 단일 원본만 있는 경우 단일 원본은 몇 가지 상태 프로브를 가져옵니다. 이로 인해 원본 상태 메트릭이 감소할 수 있지만 트래픽은 영향을 받지 않습니다.
다음 단계
- Azure Front Door 프로필을 만드는 방법을 알아봅니다.
- Front Door 라우팅 아키텍처에 대해 알아봅니다.