의사의 정기 검진이 건강을 유지하는 데 중요한 부분인 것처럼 앱의 상태를 정기적으로 확인하는 것은 안정적인 성능을 위해 필수적입니다. 역방향 프록싱 및 트래픽 로드 밸런싱 시 NGINX는 수동 상태 검사를 사용하여 요청에 응답하지 않는 서버에서 트래픽을 자동으로 전환하여 애플리케이션 사용자를 중단으로부터 보호합니다. NGINX Plus는 활성 상태 검사를 추가하여 요청을 처리하지 못하기 전에도 비정상 서버를 감지할 수 있는 특수 프로브를 보냅니다. 어떤 유형의 상태 검사가 애플리케이션에 적합할까요? 이 게시물에서는 해당 결정을 내리는 데 필요한 정보를 제공합니다.
Health-Check 란?
가장 기본적인 의미에서, 헬스 체크는 서버가 트래픽을 처리할 수 있는지 여부를 판단하는 방법입니다. NGINX는 헬스 체크를 사용하여 리버스 프록싱 또는 로드 밸런싱 트래픽을 처리하는 서버( 업스트림 서버 라고 함)를 모니터링합니다 .
Passive Health Check
NGINX Open Source와 NGINX Plus에서 모두 사용 가능한 수동적 상태 검사는 연결과 트래픽을 처리하는 동안 서버가 어떻게 동작하는지 관찰하는 데 의존합니다. NGINX가 서버가 비정상임을 발견하면 즉시 다른 서버로 요청을 전달하고, 비정상 서버로 요청을 보내는 것을 중단하고, 향후 요청을 업스트림 그룹의 나머지 정상 서버에 분배하기 때문에 사용자가 서버 시간 초과로 인해 중단을 경험하지 않도록 방지하는 데 도움이 됩니다.
수동 상태 검사는 업스트림 그룹이 여러 멤버를 갖도록 정의된 경우에만 효과적입니다. 업스트림 서버가 하나만 정의된 경우, 사용할 수 없음으로 표시되지 않으며, 상태가 좋지 않으면 사용자에게 중단이 표시됩니다.
Passive Health Check Flow
여기에서는 수동적 건강 검진의 작동 방식을 자세히 살펴보겠습니다 . 관심이 없다면 능동적 건강 검진 으로 넘어가세요.
기본적으로 NGINX는 연결을 설정하는 동안 단일 오류나 시간 초과가 발생하는 경우 TCP/UDP(스트림) 서버를 비정상 으로 간주합니다.
NGINX는 HTTP 서버 와 연결을 설정하는 동안, 요청을 전달하는 동안 또는 응답 헤더를 읽는 동안 단일 오류나 시간 초과가 발생하는 경우 해당 HTTP 서버를 건강하지 않은 것으로 간주합니다(응답을 전혀 받지 못하는 경우 이러한 유형의 오류로 간주). 이 지시문을 사용하여 HTTPproxy_next_upstream 프록싱 에 대한 이러한 조건을 사용자 정의할 수 있으며 FastCGI , gRPC , memcached , SCGI , TCP/UDP 및 uwsgi 프로토콜 에 대한 병렬 지시문이 있습니다 .
HTTP와 TCP/UDP 모두의 경우 NGINX는 다시 연결하고 건강에 해로운 서버에 요청을 보내기 전에 기본적으로 10초 동안 기다립니다. [ HTTP ][ Stream ]fail_timeout 지시문 에 매개변수를 사용하여 이 시간을 변경할 수 있습니다.server
max_fails지시문 에 매개변수를 사용하여 serverNGINX가 서버를 비정상으로 간주하기 위해 발생해야 하는 오류 또는 시간 초과의 수를 늘릴 수 있습니다. 이 경우 매개 fail_timeout변수는 해당 횟수의 오류 또는 시간 초과가 발생해야 하는 기간과 NGINX가 서버를 비정상으로 표시한 후 다시 시도하기 위해 기다리는 시간을 설정합니다.
Active Health Check
NGINX Plus에서만 제공되는 활성 상태 검사는 애플리케이션 엔드포인트에 정기적으로 전송되어 올바르게 응답하는지 확인하는 특수 요청입니다. 이는 수동 상태 검사와 별개이며 이에 추가됩니다. 예를 들어, NGINX Plus는 애플리케이션의 웹 서버에 주기적인 HTTP 요청을 전송하여 유효한 응답 코드와 올바른 콘텐츠로 응답하는지 확인할 수 있습니다. 활성 상태 검사를 통해 특정 애플리케이션 구성 요소와 프로세스의 상태를 지속적으로 모니터링할 수 있습니다. 이는 애플리케이션 가용성을 직접 측정하는 것이지만 지정된 상태 검사가 전체 애플리케이션 상태를 얼마나 잘 나타내는지에 따라 달라집니다.
활성 상태 검사의 많은 측면을 사용자 정의할 수 있습니다. 활성 상태 검사 사용 사례를 참조하세요 .
Passive Health Check Reference
수동적 상태 점검은 기본입니다. 모든 애플리케이션 개발, DevOps, DevSecOps 및 플랫폼 운영 팀이 프로덕션 인프라에 대한 모니터링 프로그램의 일부로 수동적 상태 점검을 실행하는 것이 모범 사례입니다. NGINX는 기본적으로 HTTP, TCP 및 UDP 구성을 포함하여 부하 분산 트래픽에 대해 수동적 상태 점검을 실행합니다.
수동 건강 검진의 장점은 다음과 같습니다.
- NGINX 오픈 소스에서 사용 가능
- upstream{}구성 블록 에 포함된 서버에 대해 기본적으로 활성화됨
- 업스트림 서버에 추가 부하가 발생하지 않습니다.
- 수동 상태 검사 작동 방식 에 설명된 대로 시간 기간 내 최소 실패 횟수에 따라 구성 가능
- 구성 가능한 느린 시작 (NGINX Plus에만 해당) - 서버가 정상 상태로 돌아오면 NGINX Plus는 점진적으로 해당 서버로 전달되는 트래픽 양을 늘려 "워밍업"할 시간을 줍니다.
NGINX 오픈 소스의 장점은 비용(물론 없음), 구성 가능성, 방대한 타사 모듈 라이브러리입니다. 소스 코드를 사용할 수 있으므로 개발자는 특정 요구 사항에 맞게 기능을 수정하고 확장할 수 있습니다.
많은 애플리케이션(및 해당 개발자)의 경우 수동 상태 검사로 충분합니다. 예를 들어, 능동적 상태 검사는 고객을 마주하지 않고 더 작은 작업을 수행하는 마이크로서비스에 과도할 수 있습니다. 마찬가지로 캐싱으로 대기 시간 문제의 가능성을 줄일 수 있거나 콘텐츠 배포 네트워크(CDN)가 일부 애플리케이션 작업을 인계할 수 있는 애플리케이션에는 필요하지 않을 수 있습니다. 요약하자면, 수동적 상태 검사만으로는 다음과 같은 경우에 가장 좋습니다.
- HTTP 트래픽 모니터링
- 애플리케이션과 별도로 인프라 모니터링
- 대기 시간이 허용되는 애플리케이션 모니터링
- 고성능이 중요하지 않은 내부 애플리케이션 모니터링
Active Health Check Reference
미션 크리티컬 애플리케이션의 경우 고객과 주요 프로세스가 문제의 직접적인 영향을 받기 때문에 활성 상태 검사가 종종 중요합니다. 이러한 애플리케이션의 경우 본질적으로 애플리케이션의 고객 또는 소비자가 하는 것처럼 애플리케이션을 테스트하는 것이 중요하며, 이를 위해 활성 상태 검사가 필요합니다. 활성 상태 검사는 New Relic 및 AppDynamics와 같은 애플리케이션 성능 모니터링 도구와 유사하며, 이는 대역 외 검사를 사용하여 애플리케이션 지연 시간과 응답을 측정합니다. 활성 상태 검사의 경우 NGINX Plus에는 NGINX Open Source에 포함되지 않은 여러 기능과 역량이 포함되어 있습니다.
- 애플리케이션 가용성에 대한 대역 외 상태 검사
- 구성된 엔드포인트를 테스트하고 특정 응답을 찾습니다.
- 실제 애플리케이션 트래픽을 처리하는 포트와 다른 포트를 테스트합니다.
- 상태 점검을 위한 Keepalive HTTP 연결을 통해 각 점검에 대해 새 연결을 설정할 필요성이 없어집니다.
- 실패 및 통과 조건에 대한 더 큰 제어
- 실제 애플리케이션 트래픽을 수신하기 전에 새로 추가된 서버를 선택적으로 테스트합니다.
활성 상태 검사를 통해 개발자는 NGINX Plus를 설정하여 백엔드 서버가 다운되거나 문제가 발생할 때 자동으로 감지한 다음 문제가 해결될 때까지 트래픽을 정상 서버로 라우팅할 수 있습니다. 활성 상태 검사의 더 큰 구성 가능성으로 인해 보다 정교한 상태 검사를 수행하여 실제 애플리케이션 사용자에게 영향을 미치기 전에 애플리케이션 문제를 감지할 수 있습니다. 이를 통해 다운타임을 최소화하고 애플리케이션에 대한 사용자 액세스가 중단되는 것을 방지할 수 있습니다.
Health Check 방안
수동 상태 검사는 기본적으로 활성화되어 있지만, 수동 상태 검사의 작동 원리 에 설명된 대로, 서비스가 비정상으로 표시되기 전에 발생하는 실패 횟수와 빈도를 사용자 지정할 수 있습니다 . 수동 및 활성 상태 검사에 대한 전체 구성 지침은 다음 설명서를 참조하세요.
- HTTP 상태 검사
- TCP 상태 검사
- UDP 상태 검사
- gRPC 상태 점검
결론: 귀하의 애플리케이션 요구 사항에 맞는 Health Check 방안을 선택하세요
상태 점검은 모든 프로덕션 애플리케이션을 원활하고 반응성 있게 실행하는 데 중요한 부분입니다. 이는 문제를 감지하고 최종 사용자에게 영향을 미치기 전에 증가하는 지연 소스를 식별하는 가장 좋은 방법입니다. 많은 애플리케이션의 경우 수동 상태 점검으로 충분합니다.
사용자 수준에서 애플리케이션 동작에 대한 직접적인 통찰력이 필요한 더욱 중요한 애플리케이션의 경우, 능동적 검사가 더 좋습니다. NGINX Open Source는 무료로 사용할 수 있으며 구성 가능한 수동적 상태 검사를 제공합니다. NGINX Plus는 고급 능동적 상태 검사 기능과 상업적 지원을 제공합니다.
의사의 정기 검진이 건강을 유지하는 데 중요한 부분인 것처럼 앱의 상태를 정기적으로 확인하는 것은 안정적인 성능을 위해 필수적입니다. 역방향 프록싱 및 트래픽 로드 밸런싱 시 NGINX는 수동 상태 검사를 사용하여 요청에 응답하지 않는 서버에서 트래픽을 자동으로 전환하여 애플리케이션 사용자를 중단으로부터 보호합니다. NGINX Plus는 활성 상태 검사를 추가하여 요청을 처리하지 못하기 전에도 비정상 서버를 감지할 수 있는 특수 프로브를 보냅니다. 어떤 유형의 상태 검사가 애플리케이션에 적합할까요? 이 게시물에서는 해당 결정을 내리는 데 필요한 정보를 제공합니다.
Health-Check 란?
가장 기본적인 의미에서, 헬스 체크는 서버가 트래픽을 처리할 수 있는지 여부를 판단하는 방법입니다. NGINX는 헬스 체크를 사용하여 리버스 프록싱 또는 로드 밸런싱 트래픽을 처리하는 서버( 업스트림 서버 라고 함)를 모니터링합니다 .
Passive Health Check
NGINX Open Source와 NGINX Plus에서 모두 사용 가능한 수동적 상태 검사는 연결과 트래픽을 처리하는 동안 서버가 어떻게 동작하는지 관찰하는 데 의존합니다. NGINX가 서버가 비정상임을 발견하면 즉시 다른 서버로 요청을 전달하고, 비정상 서버로 요청을 보내는 것을 중단하고, 향후 요청을 업스트림 그룹의 나머지 정상 서버에 분배하기 때문에 사용자가 서버 시간 초과로 인해 중단을 경험하지 않도록 방지하는 데 도움이 됩니다.
수동 상태 검사는 업스트림 그룹이 여러 멤버를 갖도록 정의된 경우에만 효과적입니다. 업스트림 서버가 하나만 정의된 경우, 사용할 수 없음으로 표시되지 않으며, 상태가 좋지 않으면 사용자에게 중단이 표시됩니다.
Passive Health Check Flow
여기에서는 수동적 건강 검진의 작동 방식을 자세히 살펴보겠습니다 . 관심이 없다면 능동적 건강 검진 으로 넘어가세요.
기본적으로 NGINX는 연결을 설정하는 동안 단일 오류나 시간 초과가 발생하는 경우 TCP/UDP(스트림) 서버를 비정상 으로 간주합니다.
NGINX는 HTTP 서버 와 연결을 설정하는 동안, 요청을 전달하는 동안 또는 응답 헤더를 읽는 동안 단일 오류나 시간 초과가 발생하는 경우 해당 HTTP 서버를 건강하지 않은 것으로 간주합니다(응답을 전혀 받지 못하는 경우 이러한 유형의 오류로 간주). 이 지시문을 사용하여 HTTPproxy_next_upstream 프록싱 에 대한 이러한 조건을 사용자 정의할 수 있으며 FastCGI , gRPC , memcached , SCGI , TCP/UDP 및 uwsgi 프로토콜 에 대한 병렬 지시문이 있습니다 .
HTTP와 TCP/UDP 모두의 경우 NGINX는 다시 연결하고 건강에 해로운 서버에 요청을 보내기 전에 기본적으로 10초 동안 기다립니다. [ HTTP ][ Stream ]fail_timeout 지시문 에 매개변수를 사용하여 이 시간을 변경할 수 있습니다.server
max_fails지시문 에 매개변수를 사용하여 serverNGINX가 서버를 비정상으로 간주하기 위해 발생해야 하는 오류 또는 시간 초과의 수를 늘릴 수 있습니다. 이 경우 매개 fail_timeout변수는 해당 횟수의 오류 또는 시간 초과가 발생해야 하는 기간과 NGINX가 서버를 비정상으로 표시한 후 다시 시도하기 위해 기다리는 시간을 설정합니다.
Active Health Check
NGINX Plus에서만 제공되는 활성 상태 검사는 애플리케이션 엔드포인트에 정기적으로 전송되어 올바르게 응답하는지 확인하는 특수 요청입니다. 이는 수동 상태 검사와 별개이며 이에 추가됩니다. 예를 들어, NGINX Plus는 애플리케이션의 웹 서버에 주기적인 HTTP 요청을 전송하여 유효한 응답 코드와 올바른 콘텐츠로 응답하는지 확인할 수 있습니다. 활성 상태 검사를 통해 특정 애플리케이션 구성 요소와 프로세스의 상태를 지속적으로 모니터링할 수 있습니다. 이는 애플리케이션 가용성을 직접 측정하는 것이지만 지정된 상태 검사가 전체 애플리케이션 상태를 얼마나 잘 나타내는지에 따라 달라집니다.
활성 상태 검사의 많은 측면을 사용자 정의할 수 있습니다. 활성 상태 검사 사용 사례를 참조하세요 .
Passive Health Check Reference
수동적 상태 점검은 기본입니다. 모든 애플리케이션 개발, DevOps, DevSecOps 및 플랫폼 운영 팀이 프로덕션 인프라에 대한 모니터링 프로그램의 일부로 수동적 상태 점검을 실행하는 것이 모범 사례입니다. NGINX는 기본적으로 HTTP, TCP 및 UDP 구성을 포함하여 부하 분산 트래픽에 대해 수동적 상태 점검을 실행합니다.
수동 건강 검진의 장점은 다음과 같습니다.
NGINX 오픈 소스의 장점은 비용(물론 없음), 구성 가능성, 방대한 타사 모듈 라이브러리입니다. 소스 코드를 사용할 수 있으므로 개발자는 특정 요구 사항에 맞게 기능을 수정하고 확장할 수 있습니다.
많은 애플리케이션(및 해당 개발자)의 경우 수동 상태 검사로 충분합니다. 예를 들어, 능동적 상태 검사는 고객을 마주하지 않고 더 작은 작업을 수행하는 마이크로서비스에 과도할 수 있습니다. 마찬가지로 캐싱으로 대기 시간 문제의 가능성을 줄일 수 있거나 콘텐츠 배포 네트워크(CDN)가 일부 애플리케이션 작업을 인계할 수 있는 애플리케이션에는 필요하지 않을 수 있습니다. 요약하자면, 수동적 상태 검사만으로는 다음과 같은 경우에 가장 좋습니다.
Active Health Check Reference
미션 크리티컬 애플리케이션의 경우 고객과 주요 프로세스가 문제의 직접적인 영향을 받기 때문에 활성 상태 검사가 종종 중요합니다. 이러한 애플리케이션의 경우 본질적으로 애플리케이션의 고객 또는 소비자가 하는 것처럼 애플리케이션을 테스트하는 것이 중요하며, 이를 위해 활성 상태 검사가 필요합니다. 활성 상태 검사는 New Relic 및 AppDynamics와 같은 애플리케이션 성능 모니터링 도구와 유사하며, 이는 대역 외 검사를 사용하여 애플리케이션 지연 시간과 응답을 측정합니다. 활성 상태 검사의 경우 NGINX Plus에는 NGINX Open Source에 포함되지 않은 여러 기능과 역량이 포함되어 있습니다.
활성 상태 검사를 통해 개발자는 NGINX Plus를 설정하여 백엔드 서버가 다운되거나 문제가 발생할 때 자동으로 감지한 다음 문제가 해결될 때까지 트래픽을 정상 서버로 라우팅할 수 있습니다. 활성 상태 검사의 더 큰 구성 가능성으로 인해 보다 정교한 상태 검사를 수행하여 실제 애플리케이션 사용자에게 영향을 미치기 전에 애플리케이션 문제를 감지할 수 있습니다. 이를 통해 다운타임을 최소화하고 애플리케이션에 대한 사용자 액세스가 중단되는 것을 방지할 수 있습니다.
Health Check 방안
수동 상태 검사는 기본적으로 활성화되어 있지만, 수동 상태 검사의 작동 원리 에 설명된 대로, 서비스가 비정상으로 표시되기 전에 발생하는 실패 횟수와 빈도를 사용자 지정할 수 있습니다 . 수동 및 활성 상태 검사에 대한 전체 구성 지침은 다음 설명서를 참조하세요.
결론: 귀하의 애플리케이션 요구 사항에 맞는 Health Check 방안을 선택하세요
상태 점검은 모든 프로덕션 애플리케이션을 원활하고 반응성 있게 실행하는 데 중요한 부분입니다. 이는 문제를 감지하고 최종 사용자에게 영향을 미치기 전에 증가하는 지연 소스를 식별하는 가장 좋은 방법입니다. 많은 애플리케이션의 경우 수동 상태 점검으로 충분합니다.
사용자 수준에서 애플리케이션 동작에 대한 직접적인 통찰력이 필요한 더욱 중요한 애플리케이션의 경우, 능동적 검사가 더 좋습니다. NGINX Open Source는 무료로 사용할 수 있으며 구성 가능한 수동적 상태 검사를 제공합니다. NGINX Plus는 고급 능동적 상태 검사 기능과 상업적 지원을 제공합니다.
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기