블로그 | NGINX

활성 또는 수동 건강 검진: 어떤 것이 당신에게 맞을까요?

NGINX-F5-수평-검정-유형-RGB의 일부
로버트 헤인스 썸네일
로버트 헤인스
2023년 4월 11일 게시

건강을 유지하는 데 있어 정기적으로 의사의 진찰을 받는 것이 중요한 것처럼, 앱의 상태를 정기적으로 점검하는 것은 안정적인 성능을 위해 필수적입니다. NGINX는 역방향 프록싱 및 트래픽 부하 분산을 수행할 때 수동 상태 검사를 사용하여 요청에 응답하지 않는 서버에서 트래픽을 자동으로 분산시켜 애플리케이션 사용자를 중단으로부터 보호합니다. NGINX Plus는 활성 상태 검사를 추가하여 요청 처리에 실패하기 전에도 상태가 좋지 않은 서버를 감지할 수 있는 특수 프로브를 보냅니다. 귀하의 애플리케이션에는 어떤 유형의 상태 점검이 적합합니까? 이 글에서는 그러한 결정을 내리는 데 필요한 정보를 제공해 드리겠습니다.

건강검진이란?

가장 기본적인 의미에서, 상태 점검은 서버가 트래픽을 처리할 수 있는지 여부를 확인하는 방법입니다. NGINX는 역방향 프록싱이나 트래픽 부하 분산을 수행하는 서버( 업스트림 서버 라고 함)를 모니터링하기 위해 상태 검사를 사용합니다.

수동 건강 검진

NGINX 오픈 소스와 NGINX Plus에서 모두 사용 가능한 수동 상태 검사는 연결 및 트래픽을 처리하는 동안 서버의 동작을 관찰하는 데 의존합니다. 이러한 기능은 NGINX가 서버가 비정상임을 발견하면 요청을 다른 서버로 즉시 전달하고, 비정상 서버로는 요청을 보내는 것을 중단하고, 이후의 요청을 업스트림 그룹에 있는 나머지 정상 서버에 분산시키기 때문에 서버 시간 초과로 인해 사용자가 서비스 중단을 경험하는 것을 방지하는 데 도움이 됩니다.

수동 상태 검사는 업스트림 그룹에 여러 구성원이 정의된 경우에만 효과적입니다. 업스트림 서버가 하나만 정의된 경우 사용할 수 없음으로 표시되지 않으며 서버가 비정상적일 경우 사용자는 중단을 보게 됩니다.

수동 건강 검진의 작동 방식

여기에서는 수동적 건강 검진의 작동 방식을 자세히 살펴보겠습니다. 관심이 없다면 능동적 건강 검진 으로 넘어가세요.

기본적으로 NGINX는 연결을 설정하는 동안 단일 오류나 시간 초과가 발생하는 경우 TCP/UDP(스트림) 서버를 비정상 으로 간주합니다.

NGINX는 연결을 설정하는 동안, 요청을 전달하는 동안, 응답 헤더를 읽는 동안 단일 오류나 시간 초과가 발생하는 경우 HTTP 서버를 비정상적이라고 간주합니다(응답을 전혀 받지 못하는 경우도 이러한 유형의 오류로 간주). proxy_next_upstream 지시문을 사용하면 HTTP 프록싱에 대한 이러한 조건을 사용자 정의할 수 있으며 FastCGI , gRPC , memcached , SCGI , TCP/UDPuwsgi 프로토콜에 대한 병렬 지시문이 있습니다.

HTTP와 TCP/UDP 모두에 대해 NGINX는 기본적으로 10초 동안 기다렸다가 다시 연결을 시도하고 상태가 좋지 않은 서버에 요청을 보냅니다. 이 시간을 변경하려면 서버 [ HTTP ][ 스트림 ] 지시문에 fail_timeout 매개변수를 사용할 수 있습니다.

server 지시문에 max_fails 매개변수를 사용하면 NGINX가 서버를 비정상으로 간주하기 위해 발생해야 하는 오류 또는 시간 초과의 수를 늘릴 수 있습니다. 이 경우 fail_timeout 매개변수는 해당 횟수의 오류 또는 시간 초과가 발생해야 하는 기간과 NGINX가 서버를 비정상으로 표시한 후 다시 시도하기 위해 기다리는 시간을 설정합니다.

활성 건강 검진

NGINX Plus에서만 제공되는 활성 상태 검사는 애플리케이션 엔드포인트에 정기적으로 전송되어 올바르게 응답하는지 확인하는 특수 요청입니다. 이러한 검사는 수동 건강 검진과 별개이며 이에 추가됩니다. 예를 들어, NGINX Plus는 애플리케이션의 웹 서버에 주기적인 HTTP 요청을 보내 유효한 응답 코드와 올바른 콘텐츠로 응답하는지 확인할 수 있습니다. 활성 상태 검사를 통해 특정 애플리케이션 구성 요소와 프로세스의 상태를 지속적으로 모니터링할 수 있습니다. 이는 애플리케이션 가용성을 직접 측정하는 것으로, 지정된 상태 검사가 전체 애플리케이션 상태를 얼마나 잘 나타내는지에 따라 달라집니다.

활성 상태 검사의 많은 측면을 사용자 정의할 수 있습니다. 활성 상태 검사 사용 사례를 참조하세요.

수동 및 활성 상태 검사에 사용되는 NGINX 오픈 소스 및 NGINX Plus의 트래픽 유형을 보여주는 다이어그램

수동 건강 검진의 사용 사례

수동적 건강 검진은 기본입니다. 모든 애플리케이션 개발, DevOps, DevSecOps 및 플랫폼 운영 팀은 프로덕션 인프라에 대한 모니터링 프로그램의 일부로 수동 상태 검사를 실행하는 것이 모범 사례입니다. NGINX는 기본적으로 HTTP, TCP, UDP 구성을 포함하여 부하 분산 트래픽에 대한 수동 상태 검사를 실행합니다.

수동 건강 검진의 장점은 다음과 같습니다.

  • NGINX 오픈 소스에서 사용 가능
  • upstream{} 구성 블록에 포함된 서버에 대해 기본적으로 활성화됨
  • 업스트림 서버에 추가 부하가 발생하지 않습니다.
  • 수동 상태 검사 작동 방식 에 설명된 대로 특정 기간 내 최소 실패 횟수에 따라 구성 가능
  • 구성 가능한 느린 시작 (NGINX Plus에만 해당) - 서버가 정상 상태로 돌아오면 NGINX Plus는 점진적으로 해당 서버로 전달되는 트래픽 양을 늘려 "워밍업"할 시간을 줍니다.

NGINX 오픈 소스의 장점은 비용(당연히 없음), 구성 가능성, 광범위한 타사 모듈 라이브러리입니다. 소스 코드가 공개되어 있으므로 개발자는 특정 요구 사항에 맞게 기능을 수정하고 확장할 수 있습니다.

많은 애플리케이션(및 개발자)의 경우 수동적 상태 검사만으로 충분합니다. 예를 들어, 고객을 직접 상대하지 않고 소규모 작업을 수행하는 마이크로서비스의 경우 활성 상태 점검은 과도할 수 있습니다. 마찬가지로 캐싱으로 지연 문제가 발생할 가능성을 줄일 수 있는 애플리케이션이나 콘텐츠 배포 네트워크(CDN)가 일부 애플리케이션 작업을 대신 수행할 수 있는 애플리케이션에는 필요하지 않을 수 있습니다. 요약하자면, 수동 건강 검진만이 가장 좋은 경우는 다음과 같습니다.

  • HTTP 트래픽 모니터링
  • 애플리케이션과 별도로 인프라 모니터링
  • 대기 시간이 허용되는 애플리케이션 모니터링
  • 고성능이 중요하지 않은 내부 애플리케이션 모니터링

활성 상태 점검을 위한 사용 사례

임무 수행에 중요한 애플리케이션의 경우, 고객과 주요 프로세스가 문제의 직접적인 영향을 받기 때문에 적극적인 상태 점검이 매우 중요합니다. 이러한 애플리케이션을 사용할 때는 기본적으로 애플리케이션의 고객 또는 소비자가 하는 것과 같은 방식으로 애플리케이션을 테스트하는 것이 중요하며, 이를 위해 적극적인 상태 검사가 필요합니다. 활성 상태 검사는 New Relic 및 AppDynamics와 같은 애플리케이션 성능 모니터링 도구와 유사합니다. 이러한 도구는 대역 외 검사를 사용하여 애플리케이션 지연 시간과 응답 시간을 측정합니다. 활성 상태 검사를 위해 NGINX Plus에는 NGINX 오픈 소스에 포함되지 않은 여러 기능과 성능이 포함되어 있습니다.

  • 애플리케이션 가용성에 대한 대역 외 상태 검사
  • 구성된 엔드포인트를 테스트하고 특정 응답을 찾습니다.
  • 실제 애플리케이션 트래픽을 처리하는 포트와 다른 포트를 테스트합니다.
  • 상태 점검을 위한 Keepalive HTTP 연결을 통해 각 점검에 대해 새 연결을 설정할 필요성이 없어집니다.
  • 실패 및 통과 조건에 대한 더 큰 제어
  • 실제 애플리케이션 트래픽을 수신하기 전에 새로 추가된 서버를 선택적으로 테스트합니다.

활성 상태 검사를 통해 개발자는 NGINX Plus를 설정하여 백엔드 서버가 다운되거나 문제가 발생할 경우를 자동으로 감지한 다음 문제가 해결될 때까지 트래픽을 정상적인 서버로 라우팅할 수 있습니다. 활성 상태 검사를 더 폭넓게 구성하면 보다 정교한 상태 검사를 수행할 수 있으며, 실제 애플리케이션 사용자에게 영향을 미치기 전에 애플리케이션 문제를 감지할 수도 있습니다. 이를 통해 다운타임을 최소화하고 사용자의 애플리케이션 접근이 중단되는 것을 방지할 수 있습니다.

상태 점검을 구성하는 방법

수동 상태 검사는 기본적으로 활성화되어 있지만, 수동 상태 검사의 작동 방식 에 설명된 대로 검사 빈도와 서비스가 비정상으로 표시되기 전에 발생하는 실패 횟수를 사용자 지정할 수 있습니다. 수동 및 활성 상태 검사에 대한 전체 구성 지침은 다음 설명서를 참조하세요.

결론: 귀하의 신청 요구 사항과 일치하는 건강 검진을 선택하십시오

상태 점검은 모든 프로덕션 애플리케이션을 원활하고 반응성 있게 실행하는 데 중요한 부분입니다. 이는 문제가 최종 사용자에게 영향을 미치기 전에 문제를 감지하고 지연의 증가하는 원인을 파악하는 가장 좋은 방법입니다. 많은 응용 프로그램의 경우 수동 상태 점검만으로 충분합니다.

사용자 수준에서 애플리케이션 동작에 대한 직접적인 통찰력이 필요한 보다 중요한 애플리케이션의 경우, 적극적인 검사가 더 좋습니다. NGINX 오픈 소스는 무료로 사용할 수 있으며 구성 가능한 수동 상태 검사를 제공합니다. NGINX Plus는 고급 활성 상태 점검 기능과 상용 지원을 제공합니다.

NGINX Plus로 활성 상태 검사를 시도해 보시겠습니까? 오늘 30일 무료 체험판을 시작하거나, 당사에 문의하여 사용 사례에 대해 논의해 보세요 .


"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."