Share via

리소스 상태 및 인바운드 가용성 문제 해결

  • 아티클

이 문서는 부하 분산 장치 프런트 엔드 IP 및 백 엔드 리소스의 가용성에 영향을 주는 문제를 조사하는 가이드입니다.

Load Balancer의 Resource Health 검사(RHC)는 부하 분산 장치의 상태를 확인하는 데 사용됩니다. 2분 간격으로 데이터 경로 가용성 메트릭을 분석하여 부하 분산 규칙을 사용해 부하 분산 엔드포인트, 프런트 엔드 IP 및 프런트 엔드 포트 조합을 사용할 수 있는지를 확인합니다.

참고: 기본 SKU Load Balancer에는 RHC가 지원되지 않습니다.

아래 표에서는 부하 분산 장치의 상태를 확인하는 데 사용되는 RHC 논리에 대해 설명합니다.

Resource Health 상태 Description
사용 가능 표준 부하 분산 장치 리소스는 정상 상태이며 사용 가능합니다.
성능 저하됨 표준 부하 분산 장치에는 성능에 영향을 미치는 플랫폼 또는 사용자 시작 이벤트가 있습니다. 데이터 경로 가용성 메트릭 상태가 2분 이상 90% 미만이지만 25%는 넘는다고 보고했습니다. 보통에서 심각한 수준의 성능 저하를 겪게 됩니다.
Unavailable 표준 Load Balancer 리소스가 정상이 아닙니다. 데이터 경로 가용성 메트릭 상태가 2분 이상 25% 미만이라고 보고했습니다. 인바운드 연결에 대한 심각한 성능 저하 또는 가용성 부족을 겪게 됩니다. 사용 불가를 유발하는 사용자 또는 플랫폼 이벤트가 있을 수 있습니다.
Unknown 표준 부하 분산 장치 리소스의 리소스 상태가 아직 업데이트되지 않았거나 지난 10분 동안 데이터 경로 가용성 정보를 받지 못했습니다. 이 상태는 일시적이어야 하며 데이터가 수신되는 즉시 올바른 상태를 반영합니다.

사용할 메트릭 정보

사용되는 두 개의 메트릭은 데이터 경로 가용성 및 상태 프로브 상태이며 올바른 정보를 얻기 위해 해당 의미를 이해하는 것이 중요합니다.

데이터 경로 가용성

데이터 경로 가용성 메트릭은 부하 분산 및 인바운드 NAT 규칙이 구성된 모든 프런트 엔드 포트에서 25초마다 TCP ping을 통해 생성됩니다. 그러면 이 TCP ping은 정상(프로브 업) 백 엔드 인스턴스로 라우팅됩니다. 서비스에서 ping에 대한 응답을 받으면 성공적인 응답이며 메트릭의 합계가 한 번 반복됩니다. 응답이 없으면 반복되지 않습니다. 이 메트릭의 수는 샘플 기간별 총 TCP ping의 1/100입니다. 따라서 기간의 합계/개수의 평균을 고려하려고 합니다. 데이터는 평균으로 집계된 경로 가용성 메트릭을 보여주므로 각 부하 분산 및 인바운드 NAT 규칙에 대한 프런트 엔드 IP:포트의 TCP ping 성공률을 제공합니다.

상태 프로브 상태

상태 프로브 상태 메트릭은 상태 프로브에 정의된 프로토콜의 ping을 통해 생성됩니다. 이 ping은 백 엔드 풀의 각 인스턴스와 상태 프로브에 정의된 포트로 전송됩니다. HTTP 및 HTTPS 프로브의 경우 성공적인 ping에는 HTTP 200 OK 응답이 필요하지만, TCP 프로브를 사용하면 모든 응답이 성공으로 간주됩니다. 각 프로브의 연속적인 성공 또는 실패에 따라 백 엔드 인스턴스의 상태와 할당된 백 엔드 풀이 트래픽을 수신할 수 있는지 여부가 결정됩니다. 데이터 경로 가용성과 유사하게 평균 집계를 사용하여 샘플링 간격으로 평균 성공/총 ping을 알려줍니다. 이 상태 프로브 상태 값은 프런트 엔드를 통해 트래픽을 전송하지 않고 백 엔드 인스턴스를 프로브하여 부하 분산 장치에서 격리된 백 엔드 상태를 나타냅니다.

Important

상태 프로브 상태는 1분마다 샘플링됩니다. 이렇게 하면 다른 경우에는 값이 조금씩 변동될 수 있습니다. 예를 들어 두 개의 백 엔드 인스턴스(하나는 프로브 업되고 다른 하나는 프로브 다운)가 있는 경우 상태 프로브 서비스는 정상 인스턴스에 대해 7개의 샘플과 비정상 인스턴스에 대해 6개의 샘플을 캡처할 수 있습니다. 이 경우 1분 간격으로 이전 안정된 값 50(46.15로 표시)이 발생합니다.

성능 저하되고 사용할 수 없는 부하 분산 장치 진단

리소스 상태 문서에 설명된 대로 성능이 저하된 부하 분산 장치는 25%~90%의 데이터 경로 가용성을 보여 줍니다. 사용할 수 없는 부하 분산 장치는 2분 동안 데이터 경로 가용성이 25% 미만인 부하 분산 장치입니다. 구성된 상태 프로브 상태 또는 데이터 경로 가용성 경고에 표시되는 오류를 조사할 경우에도 동일한 단계를 수행합니다. 리소스 상태를 확인하여 데이터 경로 가용성이 0%으로 나타나 부하 분산 장치를 사용할 수 없는 상태, 즉 서비스가 중단된 사례를 살펴보겠습니다.

먼저 Azure Portal에서 부하 분산 장치 인사이트 페이지의 자세한 메트릭 보기로 이동합니다. 부하 분산 장치 리소스 페이지 또는 리소스 상태 메시지의 링크를 통해 보기에 액세스할 수 있습니다. 다음으로는 프런트 엔드 및 백 엔드 가용성 탭으로 이동하여 성능이 저하 되었거나 사용할 수 없는 상태가 발생한 기간의 30분을 검토합니다. 데이터 경로 가용성이 0%로 표시되면 모든 부하 분산 및 인바운드 NAT 규칙에 대한 트래픽을 차단하는 문제가 있음을 알 수 있으며, 이 문제가 얼마나 지속되었는지 확인할 수 있습니다.

다음으로 살펴보아야 할 곳은 데이터 경로를 사용할 수 없는지를 확인하기 위한 상태 프로브 상태 메트릭이며, 그 이유는 트래픽을 처리할 수 있는 정상 백 엔드 인스턴스가 없기 때문입니다. 모든 부하 분산 및 인바운드 규칙에 대해 정상 백 엔드 인스턴스가 하나 이상 있는 경우는 데이터 경로를 사용할 수 없게 하는 구성이 아닙니다. 이 시나리오는 Azure 플랫폼 문제를 나타냅니다. 플랫폼 문제는 드물지만 모든 플랫폼 문제를 신속하게 해결하기 위해 자동 경고가 팀에 전송됩니다.

상태 프로브 오류 진단

상태 프로브 상태를 확인하고 모든 인스턴스가 비정상으로 표시되는 것을 확인했다고 가정해 보겠습니다. 이 가정에서는 트래픽이 이동하지 않아도 데이터 경로를 사용할 수 없는 이유를 설명합니다. 그런 다음 일반적인 구성 오류를 제외하려면 다음 검사 목록을 검토해야 합니다.

  • 리소스의 CPU 사용률을 확인하여 부하가 높은지 확인합니다.
  • HTTP 또는 HTTPS 프로브를 사용하는 경우 애플리케이션이 정상 상태이고 응답하는지 확인합니다.
    • 백 엔드 인스턴스와 연결된 개인 IP 주소 또는 인스턴스 수준 공용 IP 주소를 통해 애플리케이션에 직접 액세스하여 애플리케이션이 작동하는지 확인합니다.
  • 백 엔드 리소스에 적용된 네트워크 보안 그룹을 검토합니다. 상태 프로브를 차단하는 AllowAzureLoadBalancerInBound보다 우선순위가 높은 규칙이 없는지 확인합니다.
    • 백 엔드 VM 또는 Virtual Machine Scale Sets의 네트워킹 설정을 방문하여 확인할 수 있습니다.
    • 이 NSG 문제를 발견한 경우 기존 허용 규칙을 이동하거나 AzureLoadBalancer 트래픽을 허용하는 새 높은 우선순위 규칙을 만듭니다.
  • OS를 확인합니다. VM이 프로브 포트에서 수신 대기하고 있는지 확인하고 해당 OS 방화벽 규칙을 검토하여 IP 주소 168.63.129.16에서 발생하는 프로브 트래픽을 차단하지 않는지 확인합니다.
    • Windows 명령 프롬프트에서 netstat -a 또는 Linux 터미널에서 netstat -l을 실행하여 수신 포트를 확인할 수 있습니다.
  • 올바른 프로토콜을 사용하고 있는지 확인합니다. 예를 들어, HTTP를 사용하여 HTTP가 아닌 애플리케이션을 수신 대기하는 포트를 검사하는 검사는 실패합니다.
  • Azure Firewall은 부하 분산 장치의 백 엔드 풀에 배치해서는 안 됩니다. 부하 분산 장치와 Azure Firewall을 올바르게 통합하려면 Azure 표준 Load Balancer에 Azure Firewall 통합을 참조하세요.

이 검사 목록을 살펴본 후에도 상태 프로브 오류가 계속 발생하는 경우 인스턴스의 프로브 서비스에 영향을 미치는 희귀 플랫폼 문제가 있을 수 있습니다. 이 경우 Azure는 사용자의 의견을 바탕으로 팀에게 자동으로 전송하여 모든 플랫폼 문제를 신속하게 해결합니다.

다음 단계