HTTP Health Check
NGINX Plus 에서 사용자 정의 가능한 Active Health Check를 포함하여 주기적인 Health Check를 전송하여 Upstream 그룹에 있는 HTTP 서버의 상태를 모니터링합니다.
목차
1. 소개
2. 전제 조건
3. Passive Health Check
3-1. 서버 Slow Start
4. Active Health Check
4-1. 요청된 URI 지정
4-2. 사용자 정의 조건 설정하기
4-3. 필수 Health Check
1. 소개
NGINX 및 NGINX Plus는 Upstream 서버를 지속적으로 테스트하여 장애가 발생한 서버를 피하고 복구된 서버를 Load Balancing 그룹에 정상적으로 추가할 수 있습니다.
2. 전제 조건
- Passive Health Check의 경우, NGINX Open Source 또는 NGINX Plus
- Active Health Check 및 Live Activity 모니터링 대시보드의 경우, NGINX Plus
- Load Balancing된 HTTP Upstream 서버 그룹
3. Passive Health Check
Passive Health Check의 경우, NGINX와 NGINX Plus는 트랜잭션이 발생하는 대로 모니터링하고 실패한 연결을 재개하려고 시도합니다. 그래도 트랜잭션을 재개할 수 없는 경우, NGINX Open Source와 NGINX Plus는 서버를 사용할 수 없는 것으로 표시하고 다시 활성화될 때까지 서버에 대한 요청 전송을 일시적으로 중단합니다.
Upstream 서버를 사용할 수 없는 것으로 표시하는 조건은 upstream 블록의 server 지시문에 대한 매개변수를 사용하여 각 Upstream 서버에 대해 정의됩니다.
fail_timeout– 서버가 사용 불가능으로 표시되기 위해 실패한 시도가 여러 번 발생해야 하는 시간과 서버가 사용 불가능으로 표시되는 시간을 설정합니다(기본값은 10초).max_fails– 서버가 사용 불가능으로 표시되기 위해fail_timeout시간 동안 발생해야 하는 실패 시도 횟수를 설정합니다(기본값은 1회 시도가 됩니다).
다음 예제에서는 NGINX가 서버에 요청을 보내지 못하거나 서버로부터 30초 내에 3회 이상 응답을 받지 못하면 서버를 30초 동안 사용할 수 없는 것으로 설정합니다.
upstream backend {
server backend1.example.com;
server backend2.example.com max_fails=3 fail_timeout=30s;
}Note: 그룹에 서버가 하나만 있는 경우 fail_timeout 및 max_fails 매개 변수가 무시되고 서버가 사용 불가능으로 표시되지 않습니다.
3-1. 서버 Slow Start
최근에 복구된 서버는 연결에 쉽게 과부하가 걸릴 수 있으며, 이로 인해 서버가 다시 사용 불가능으로 표시될 수 있습니다. Slow Start를 사용하면 Upstream 서버가 복구되거나 사용할 수 있게 된 후 가중치를 0에서 정상 값으로 점진적으로 복구할 수 있습니다. 이 작업은 Upstream server 지시문의 slow_start 매개변수를 사용하여 수행할 수 있습니다:
upstream backend {
server backend1.example.com slow_start=30s;
server backend2.example.com;
server 192.0.0.1 backup;
}Note: 그룹에 서버가 하나만 있는 경우 slow_start 매개 변수가 무시되고 서버가 사용 불가능으로 표시되지 않습니다. Slow Start는 NGINX Plus 전용입니다.
4. Active Health Check
NGINX Plus는 각 서버에 특별한 Health Check 요청을 보내고 올바른 응답을 확인하여 Upstream 서버의 상태를 주기적으로 확인할 수 있습니다.
Active Health Check를 활성화하려면.
1. 요청을 Upstream 그룹에 전달하는 location(proxy_pass)에 health_check 지시문을 포함하세요.
server {
location / {
proxy_pass http://backend;
health_check;
}
}이 Snippet은 모든 요청(location /)을 backend라는 Upstream 그룹으로 전달하는 서버를 정의합니다. 또한 health_check 지시문을 사용하여 고급 상태 모니터링이 가능합니다. 기본적으로 NGINX Plus는 5초마다 backend 그룹의 각 서버에 “/”에 대한 요청을 보냅니다. 통신 오류 또는 시간 초과가 발생하면(서버가 200~399 범위를 벗어난 상태 코드로 응답하면) Health Check에 실패합니다. 해당 서버는 상태가 좋지 않은 것으로 표시되며, NGINX Plus는 다시 한 번 Health Check를 통과할 때까지 해당 서버에 클라이언트 요청을 보내지 않습니다.
선택적으로 동일한 호스트에 있는 여러 서비스의 상태를 모니터링하는 등 Health Check을 위해 다른 포트를 지정할 수 있습니다. health_check 지시문의 port 매개변수를 사용하여 새 포트를 지정합니다.
server {
location / {
proxy_pass http://backend;
health_check port=8080;
}
}2. Upstream 서버 그룹에서 zone 지시문을 사용하여 공유 메모리 Zone을 정의합니다.
http {
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
}이 Zone은 모든 Worker Processes 간에 공유되며 Upstream 그룹의 구성을 저장합니다. 이렇게 하면 Worker Process가 동일한 카운터 세트를 사용하여 그룹에 있는 서버의 응답을 추적할 수 있습니다.
Active Health Check의 기본값은 health_check 지시문에 대한 매개 변수를 사용하여 재정의할 수 있습니다.
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2;
}여기서 interval 매개변수는 Health Check 사이의 지연 시간을 기본값 5초에서 10초로 늘어났습니다. fails 매개 변수는 서버가 세 번의 Health Check에 실패해야 정상 상태가 아닌 것으로 표시되도록 합니다( 기본값보다 증가한 수치입니다). 마지막으로 passes 매개 변수는 서버가 기본값인 1회가 아닌 두 번의 검사를 연속으로 통과해야 정상으로 다시 표시되도록 합니다.
또한 keepalive_time 매개변수를 사용하여 연결 캐싱을 활성화할 수도 있습니다. TLS Upstream의 경우 모든 상태 확인 Probe에 대해 전체 TLS Handshake를 수행하지 않으며 지정된 기간 동안 연결을 재사용할 수 있습니다.
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass https://backend;
health_check interval=1 keepalive_time=60s;
}4-1. 요청된 URI 지정
health_check 지시문의 uri 매개 변수를 사용하여 Health Check에서 요청할 URI를 설정합니다.
location / {
proxy_pass http://backend;
health_check uri=/some/path;
}지정된 URI는 upstream 블록의 서버에 대해 설정된 서버 도메인 이름 또는 IP 주소에 추가됩니다. 위에 선언된 샘플 backend 그룹의 첫 번째 서버의 경우 Health Check에서 http://backend1.example.com/some/path URI를 요청합니다.
4-2. 사용자 정의 조건 설정하기
서버가 Health Check를 통과하기 위해 응답이 충족해야 하는 사용자 정의 조건을 설정할 수 있습니다. 조건은 match 블록에 정의되며, 이 조건은 health_check 지시문의 match 매개변수에서 참조됩니다.
1. http { } Level에서 match { } 블록을 정의하고 이름을 지정합니다(예: server_ok).
http {
#...
match server_ok {
# tests are here
}
}2. match 매개변수와 match 블록의 이름을 지정하여 health_check 지시문에서 블록을 참조합니다.
http {
#...
match server_ok {
status 200-399;
body !~ "maintenance mode";
}
server {
#...
location / {
proxy_pass http://backend;
health_check match=server_ok;
}
}
}여기서 응답의 상태 코드가 200–399 범위에 있고 본문에 문자열 유지 maintenance mode가 포함되어 있지 않으면 Health Check가 통과됩니다.
match 지시문을 사용하면 NGINX Plus 가 상태 코드, 헤더 필드 및 응답 본문을 확인할 수 있습니다. 이 지시문을 사용하면 상태가 지정된 범위에 있는지, 응답에 헤더가 포함되어 있는지, 헤더 또는 본문이 정규 표현식과 일치하는지 확인할 수 있습니다. match 지시문에는 하나의 상태 조건, 하나의 본문 조건, 여러 헤더 조건이 포함될 수 있습니다. 서버가 상태 검사를 통과하려면 응답이 match 블록에 정의된 모든 조건을 충족해야 합니다.
예를 들어, 다음 match 지시문은 상태 코드 200, Content-Type 헤더의 정확한 값 text/html, body에 Welcome to nginx! 텍스트가 있는 응답을 매칭합니다.
match welcome {
status 200;
header Content-Type = text/html;
body ~ "Welcome to nginx!";
}다음 예에서는 느낌표(!)를 사용하여 상태 확인을 통과하기 위해 응답에 없어야 하는 특성을 정의합니다. 이 경우 상태 코드가 301, 302, 303 또는 307이 아닌 다른 코드이고 새로 고침 헤더가 없는 경우 Health Check가 통과됩니다.
match not_redirect {
status ! 301-303 307;
header ! Refresh;
}4-3. 필수 Health Check
기본적으로 새 서버가 Upstream 그룹에 추가되면 NGINX Plus 는 정상 서버로 간주하고 즉시 트래픽을 보냅니다. 그러나 일부 서버의 경우, 특히 API 인터페이스 또는 DNS 확인을 통해 추가된 경우 트래픽을 처리하도록 허용하기 전에 먼저 Health Check를 수행하는 것이 좋습니다.
mandatory 매개변수는 새로 추가된 모든 서버가 NGINX Plus 에서 트래픽을 전송하기 전에 구성된 모든 Health Check를 통과해야 합니다.
slow start와 함께 사용하면 새 서버가 데이터베이스에 연결하고 전체 트래픽을 처리하도록 요청받기 전에 “준비”할 시간을 더 많이 확보할 수 있습니다.
필수 Health Check를 영구적으로 표시하여 구성을 Reload할 때 이전 상태가 기억되도록 할 수 있습니다. persistent 매개변수를 mandatory 매개변수와 함께 지정합니다.
upstream my_upstream {
zone my_upstream 64k;
server backend1.example.com slow_start=30s;
}
server {
location / {
proxy_pass http://my_upstream;
health_check mandatory persistent;
}
}여기에는 health_check 지시문의 mandatory 및 persistent 매개변수와 server 지시문의 slow_start 매개변수가 지정됩니다. API 또는 DNS 인터페이스를 사용하여 Upstream 그룹에 추가된 서버는 비정상 상태로 표시되어 Health Check를 통과할 때까지 트래픽을 수신하지 않으며, 그 시점부터 30초 동안 점진적으로 증가하는 트래픽을 수신하기 시작합니다. NGINX Plus 구성을 Reload하고 다시 Reload하기 전에 서버가 정상으로 표시된 경우, 필수 Health Check는 수행되지 않으며 서버 상태는 가동 중인 것으로 간주됩니다.