Active Health Check vs Passive Health Check : 적합한 것은?

의사의 정기 검진이 건강을 유지하는 데 중요한 부분인 것처럼, 애플리케이션의 상태를 정기적으로 점검하는 것은 안정적인 성능을 위해 매우 중요합니다. 오늘 다룰 주제는 Active Health Check 와 Passive Health Check를 사용하는 게 적합한지 알아볼 것 입니다. 트래픽을 Reverse Proxy하고 Load Balancing할 때 NGINX는 Passive Health Check을 사용하여 요청에 응답하지 않는 서버로부터 트래픽을 자동으로 우회하여 애플리케이션 사용자를 서비스 중단으로부터 보호합니다. NGINX Plus는 요청 처리에 실패하기 전에도 비정상적인 서버를 감지할 수 있는 특수 Probe를 전송하는 Active Health Check를 추가합니다. 어떤 유형의 상태 확인이 애플리케이션에 적합할까요? 이 포스트에서는 결정을 내리는 데 필요한 정보를 제공합니다.

목차

1. Health Check란?
1-1. Passive Health Check
1-1-1. Passive Health Check 작동 방식
1-2. Active Health Check
2. Passive Health Check 사용 사례
3. Active Health Check 사용 사례
4. Health Check을 구성하는 방법
5. 결론: 애플리케이션 요구 사항에 맞는 Health Check를 선택하세요.

1. Active Health Check 및 Passive Health Check란?

가장 기본적인 의미에서 Health Check는 서버가 트래픽을 처리할 수 있는지를 판단하는 방법입니다. NGINX는 Health Check을 사용하여 트래픽을 Reverse Proxy하거나 Load Balancing하는 서버(Upstream 서버라고 합니다.)를 모니터링합니다.
Active Health Check와 Passive Health Check는 서버의 가용성 및 건강 상태를 확인하는 두 가지 다른 방법입니다. 이들 체크는 로드 밸런서, API Gateway, 그리고 기타 인프라스트럭처 구성 요소들에 의해 사용되어 트래픽을 안정적으로 처리하고 시스템의 전반적인 성능을 유지합니다.

1-1. Passive Health Check

Passive Health Check – NGINX Open Source와 NGINX Plus에서 모두 사용 가능 – 연결 및 트래픽을 처리하는 동안 서버가 어떻게 동작하는지 관찰하는 데 의존합니다. 서버가 정상적이지 않은 것을 발견하면 즉시 다른 서버로 요청을 전달하고, 정상적이지 않은 서버로의 요청 전송을 중지하고, 향후 요청을 Upstream 그룹의 나머지 정상 서버로 분산하기 때문에 서버 시간 초과로 인한 사용자 중단 문제를 방지하는 데 도움이 됩니다.

Note: Passive Health Check은 Upstream 그룹에 여러 구성원이 있도록 정의된 경우에만 유효합니다. Upstream 서버가 하나만 정의되어 있는 경우에는 사용 불가능으로 표시되지 않으며, 정상적이지 않은 경우 사용자에게 중단 메시지가 표시됩니다.

1-1-1. Passive Health Check 작동 방식

Passive Health Check가 어떻게 작동하는지에 대한 자세한 내용은 여기에서 확인할 수 있으나, 관심이 없으시면 Active Health Check로 건너뛰셔도 됩니다.

기본적으로 NGINX는 연결을 설정하는 동안 오류(Error) 또는 시간 초과가 한 번이라도 발생하면 TCP/UDP(stream) 서버가 정상적이지 않은 것으로 간주합니다.

NGINX는 HTTP 서버와 연결을 설정하거나, 요청을 전달하거나, 응답 헤더를 읽는 동안 한 번이라도 오류나 시간 초과가 발생하면 HTTP 서버가 정상적이지 않은 것으로 간주합니다(응답을 전혀 받지 못하는 것도 이러한 유형의 오류로 간주합니다). proxy_next_upstream 지시문을 사용하여 HTTP Proxy에 대한 이러한 조건을 사용자 정의할 수 있으며, FastCGI, gRPC, memcached, SCGI, TCP/UDP 및 uwsgi 프로토콜에 대한 parallel 지시문도 있습니다.

HTTP와 TCP/UDP 모두에서 NGINX는 정상적이지 않은 서버에 다시 연결하여 요청을 보내기 전에 기본 10초를 기다립니다. server[HTTP][Stream] 지시문에 fail_timeout 매개변수를 사용하여 이 시간을 변경할 수 있습니다.

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

1-2. Active Health Check

Active Health Check – NGINX Plus 전용 – 애플리케이션 Endpoint가 올바르게 응답하는지 확인하기 위해 애플리케이션 Endpoint에 정기적으로 전송되는 특별한 요청입니다. Passive Health Check와는 별개이며 Passive Health Check에 추가됩니다. 예를 들어, NGINX Plus는 애플리케이션의 웹 서버가 유효한 응답 코드와 올바른 콘텐츠로 응답하는지 확인하기 위해 애플리케이션의 웹 서버에 주기적으로 HTTP 요청을 보낼 수 있습니다. Active Health Check를 통해 특정 애플리케이션 구성 요소 및 프로세스의 상태를 지속적으로 모니터링할 수 있습니다. 이는 애플리케이션 가용성을 직접적으로 측정하는 것이지만, 지정된 Health Check가 전체 애플리케이션 상태를 얼마나 대표적으로 나타내는지에 따라 달라집니다.

Active Health Check의 여러 측면을 사용자 정의할 수 있습니다(Active Health Check의 사용 사례 참조).

2. Passive Health Check 사용 사례

Passive Health Check은 필수입니다. 모든 애플리케이션 개발, DevOps, DevSecOps, 플랫폼 운영팀은 Production 인프라에 대한 모니터링 프로그램의 일부로 Passive Health Check를 실행하는 것이 바람직한 방향입니다. NGINX는 기본적으로 Load Balancing된 트래픽에 대해 Passive Health Check를 실행하며, 여기에는 HTTP, TCP 및 UDP 구성이 포함됩니다.

Passive Health Check의 장점은 다음과 같습니다.

• NGINX Open Source에서 사용 가능
• upstream{ } 구성 블록에 포함된 서버에 대해 기본적으로 사용하도록 설정됩니다.
• Upstream 서버에 추가 부하가 발생하지 않습니다.
• Passive Health Check 작동 방식에 설명된 대로 기간 내 최소 장애 횟수를 기준으로 구성할 수 있습니다.
• 구성 가능한 Slow Start(NGINX Plus 전용) – 서버가 정상으로 돌아오면 NGINX Plus는 서버로 전달되는 트래픽 양을 서서히 증가시켜 서버가 “준비”할 시간을 줍니다.

NGINX Open Source의 장점은 비용이 전혀 들지 않고 구성 가능하며 방대한 Third-Party 모듈 라이브러리가 있다는 점입니다. Source 코드를 사용할 수 있으므로 개발자는 특정 요구 사항에 맞게 기능을 수정하고 확장할 수 있습니다.

많은 애플리케이션(및 개발자)의 경우 Passive Health Check로 충분합니다. 예를 들어, 고객을 대면하지 않고 소규모 작업을 수행하는 Microservices의 경우 Active Health Check는 과할 수 있습니다. 마찬가지로 캐싱을 통해 지연 시간문제를 줄일 수 있거나 콘텐츠 배포 네트워크(CDN)가 애플리케이션 작업의 일부를 대신할 수 있는 애플리케이션에는 필요하지 않을 수 있습니다. 요약하자면, Passive Health Check만으로도 충분히 만족할 수 있습니다.

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

3. Active Health Check 사용 사례

Mission‑Critical 애플리케이션의 경우, 고객과 주요 프로세스가 문제의 직접적인 영향을 받기 때문에 Active Health Check이 중요한 경우가 많습니다. 이러한 애플리케이션의 경우, 애플리케이션의 고객 또는 소비자와 동일하게 애플리케이션을 테스트하는 것이 중요하며, 이를 위해서는 Active Health Check이 필요합니다. Active Health Check은 대역 외 점검을 사용하여 애플리케이션 지연 시간 및 응답을 측정하는 New Relic 및 AppDynamics와 같은 애플리케이션 성능 모니터링 도구와 유사합니다. Active Health Check을 위해 NGINX Plus에는 NGINX Open Source에 포함되지 않은 여러 기능이 포함되어 있습니다.

• 애플리케이션 가용성에 대한 대역 외 Health Check
• 구성된 Endpoint를 테스트하고 특정 응답을 확인합니다.
• 실제 애플리케이션 트래픽을 처리하는 포트와 다른 포트를 테스트하세요.
• Health Check을 위해 Keepalive HTTP 연결을 유지하여 각 점검마다 새롭게 연결을 설정할 필요가 없습니다.
• 실패 및 통과 조건에 대한 더 강력한 제어
• 새로 추가된 서버가 실제 애플리케이션 트래픽을 받기 전에 선택적으로 테스트할 수 있습니다.

Active Health Check를 통해 개발자는 Backend 서버가 다운되거나 문제가 발생했을 때 자동으로 감지한 다음 문제가 해결될 때까지 트래픽을 정상 서버로 라우팅하도록 NGINX Plus를 설정할 수 있습니다. Active Health Check의 구성 기능이 향상되면 보다 정교한 Health Check를 수행할 수 있으므로 실제 애플리케이션 사용자에게 영향을 미치기 전에 애플리케이션 문제를 감지할 수 있습니다. 이렇게 하면 Downtime을 최소화하고 애플리케이션에 대한 사용자 액세스가 중단되는 것을 방지할 수 있습니다.

4. Health Check을 구성하는 방법

Passive Health Check는 기본적으로 사용 설정되어 있지만, Passive Health Check의 작동 방식에 설명된 대로 서비스가 비정상 상태로 표시되기 전에 발생하는 실패 횟수와 빈도를 사용자 정의할 수 있습니다.

5. 결론: 애플리케이션 요구 사항에 맞는 Health Check를 선택하세요.

Health Check는 모든 Production 애플리케이션을 원활하고 신속하게 실행하는 데 있어 중요한 부분입니다. 최종 사용자에게 영향을 미치기 전에 문제를 감지하고 증가하는 지연 원인을 파악할 수 있는 가장 좋은 방법입니다. 많은 애플리케이션의 경우 Passive Health Check만으로도 충분합니다.

사용자 수준에서 애플리케이션 동작에 대한 직접적인 인사이트가 필요하고 더 중요한 애플리케이션의 경우 Active Health Check를 사용하는 것이 더 좋습니다. NGINX Open Source는 무료로 사용할 수 있으며 구성 가능한 Passive Health Check를 제공합니다. NGINX Plus는 고급 Active Health Check 기능과 함께 Production 지원을 제공합니다.

NGINX Plus로 Active Health Check를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.