능동형 또는 수동형 상태 확인: 어떤 방식이 적합할까요?

Robert Haynes기술 마케팅 매니저

건강을 유지하려면 정기적으로 의사의 검진을 받는 것이 중요하듯, 애플리케이션의 안정적인 성능을 위해서는 상태를 정기적으로 점검하는 것이 매우 중요합니다. NGINX는 리버스 프록시 및 트래픽 부하 분산 시 수동 상태 점검을 사용하여 요청에 응답하지 않는 서버로 향하는 트래픽을 자동으로 다른 곳으로 전환함으로써 애플리케이션 사용자가 서비스 중단의 영향을 받지 않도록 보호합니다. NGINX Plus에는 능동 상태 점검 기능이 추가되어, 서버가 요청 처리에 실패하기 전에도 비정상 상태를 감지할 수 있는 특수 프로브를 전송합니다. 애플리케이션에는 어떤 유형의 상태 점검이 적합할까요? 이 게시물에서는 이를 결정하는 데 필요한 정보를 제공합니다.

상태 확인이란 무엇인가요?

가장 기본적인 의미에서 상태 확인은 서버가 트래픽을 처리할 수 있는지 판단하는 방법입니다. NGINX는 상태 확인을 사용하여 리버스 프록시 또는 부하 분산의 대상이 되는 서버, 즉 업스트림 서버를 모니터링합니다.

수동 상태 확인

NGINX Open Source와 NGINX Plus 모두에서 사용할 수 있는 수동 상태 점검은 서버가 연결과 트래픽을 처리하는 동안 어떻게 동작하는지 관찰하는 방식입니다. NGINX는 서버가 비정상 상태임을 감지하면 요청을 즉시 다른 서버로 전달하고, 비정상 서버로 요청 전송을 중단하며, 이후 요청을 업스트림 그룹에 남아 있는 정상 서버들에 분산하므로 서버 시간 초과로 인한 서비스 중단을 사용자가 겪지 않도록 방지하는 데 도움이 됩니다.

수동 상태 확인은 업스트림 그룹에 여러 서버가 구성된 경우에만 효과가 있다는 점에 유의하세요. 업스트림 서버가 하나만 구성된 경우에는 해당 서버가 사용 불가로 표시되지 않으므로, 서버에 문제가 발생하면 사용자가 서비스 중단을 겪게 됩니다.

수동 상태 확인의 작동 방식

다음은 수동 상태 확인의 작동 방식을 자세히 설명한 내용입니다. 관심이 없다면 능동 상태 확인으로 건너뛰세요.

기본적으로 NGINX는 TCP/UDP(스트림) 서버와의 연결을 설정하는 동안 오류나 시간 초과가 한 번이라도 발생하면 해당 서버를 비정상 상태로 간주합니다.

NGINX는 HTTP 서버가 비정상 상태인 것으로 간주합니다. 서버에 연결하거나, 요청을 전달하거나, 응답 헤더를 읽는 중에 오류 또는 시간 초과가 한 번이라도 발생하는 경우입니다(응답을 전혀 받지 못한 경우도 이러한 유형의 오류로 간주됨). proxy_next_upstream 지시어를 사용하여 HTTP 프록시의 이러한 조건을 사용자 지정할 수 있으며, FastCGI, gRPC, memcached, SCGI, TCP/UDP 및 uwsgi 프로토콜에도 이에 상응하는 지시어가 있습니다.

HTTP와 TCP/UDP 모두에서 NGINX는 비정상 서버에 다시 연결하고 요청을 전송하기 전에 기본적으로 10초 동안 기다립니다. 이 대기 시간을 변경하려면 fail_timeout 매개변수를 server[HTTP][Stream] 지시문에 사용할 수 있습니다.

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

능동 상태 확인

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

능동 상태 확인의 여러 측면을 사용자 지정할 수 있습니다. 자세한 내용은 능동 상태 확인 사용 사례를 참조하세요.

수동 상태 확인 사용 사례

수동 상태 확인은 기본적으로 갖춰야 할 요소입니다. 모든 애플리케이션 개발, DevOps, DevSecOps 및 플랫폼 운영 팀은 프로덕션 인프라 모니터링 프로그램의 일환으로 수동 상태 확인을 실행하는 것이 좋습니다. NGINX는 HTTP, TCP 및 UDP 구성을 포함하여 부하 분산된 트래픽에 대해 기본적으로 수동 상태 확인을 실행합니다.

수동 상태 확인의 장점은 다음과 같습니다:

• NGINX Open Source에서 사용 가능
• 다음 upstream{} 구성 블록에 포함된 서버에 대해 기본적으로 활성화됨
• 업스트림 서버에 추가 부하 없음
• 일정 기간 내 최소 실패 횟수를 기준으로 구성할 수 있습니다. 자세한 내용은 수동 상태 확인 작동 방식
• 구성 가능한 느린 시작(NGINX Plus 전용) – 서버가 정상 상태로 복구되면 NGINX Plus는 서버가 준비될 시간을 확보할 수 있도록 해당 서버로 전달되는 트래픽 양을 점진적으로 늘립니다.

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

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

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

능동 상태 확인의 사용 사례

미션 크리티컬 애플리케이션에서는 문제가 고객과 핵심 프로세스에 직접적인 영향을 미치므로 능동 상태 확인이 매우 중요한 경우가 많습니다. 이러한 애플리케이션은 고객이나 사용자가 실제로 이용하는 방식과 동일하게 테스트하는 것이 중요하며, 이를 위해서는 능동 상태 확인이 필요합니다. 능동 상태 확인은 대역 외 검사를 통해 애플리케이션의 지연 시간과 응답을 측정하는 New Relic 및 AppDynamics와 같은 애플리케이션 성능 모니터링 도구와 유사합니다. 능동 상태 확인을 위해 NGINX Plus는 NGINX Open Source에 포함되지 않은 다양한 기능을 제공합니다:

• 애플리케이션 가용성을 위한 대역 외 상태 점검
• 구성된 엔드포인트를 테스트하고 특정 응답이 반환되는지 확인
• 실제 애플리케이션 트래픽을 처리하는 포트와 다른 포트를 테스트합니다
• 상태 확인을 위한 HTTP 연결을 유지하여 확인할 때마다 새 연결을 설정할 필요가 없도록 합니다
• 실패 및 통과 조건을 더욱 세밀하게 제어
• 새로 추가된 서버가 실제 애플리케이션 트래픽을 수신하기 전에 선택적으로 테스트

개발자는 능동 상태 확인을 사용하여 백엔드 서버가 중단되거나 문제를 겪을 때 NGINX Plus가 이를 자동으로 감지하고, 문제가 해결될 때까지 정상 서버로 트래픽을 라우팅하도록 설정할 수 있습니다. 능동 상태 확인은 구성 유연성이 뛰어나 더욱 정교한 상태 확인을 수행할 수 있으며, 실제 애플리케이션 사용자에게 영향을 미치기 전에 애플리케이션 문제를 감지할 수도 있습니다. 이를 통해 다운타임을 최소화하고 사용자의 애플리케이션 액세스가 중단되는 것을 방지할 수 있습니다.

상태 확인을 구성하는 방법

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

• HTTP 상태 확인
• TCP 상태 확인
• UDP 상태 확인
• gRPC 상태 확인

결론: 애플리케이션 요구 사항에 적합한 상태 확인 방식 선택하기

상태 확인은 프로덕션 애플리케이션이 원활하고 신속하게 응답하도록 유지하는 데 중요한 요소입니다. 최종 사용자에게 영향을 미치기 전에 문제를 감지하고 지연 시간이 증가하는 원인을 파악하는 가장 좋은 방법입니다. 많은 애플리케이션에서는 수동 상태 확인만으로도 충분합니다.

사용자 수준에서 애플리케이션 동작을 직접 파악해야 하는 더 중요한 애플리케이션에는 능동 상태 확인이 더 적합합니다. NGINX Open Source는 무료로 사용할 수 있으며 구성 가능한 수동 상태 확인 기능을 제공합니다. NGINX Plus는 고급 능동 상태 확인 기능과 상용 지원을 제공합니다.

NGINX Plus의 능동 상태 확인 기능을 사용해 보고 싶으신가요? 지금 30일 무료 체험을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Robert Haynes기술 마케팅 매니저

Robert Haynes의 다른 블로그 게시물