nginx 에서 건강 검사 (health check) 메커니즘 깊이 분석

많은 사람들 이 nginx 가 역방향 대리 와 부하 균형 을 맞 출 수 있다 는 것 을 알 고 있 지만 nginx 에 대한 건강 검진 은(helh check) 메커니즘 에 대해 잘 알 지 못 합 니 다. 사실 커 뮤 니 티 판 nginx 가 제공 하 는 helh check 체 제 는 매우 약 합 니 다. 주로 upstream 에서 max fails 와 fail timeout 을 설정 하여 이 루어 집 니 다. 이 글 은 주로 커 뮤 니 티 판 helh check 체 제 를 깊이 분석 하 는 것 입 니 다. 물론 상업 판 nginx plus 나 아 리 의 tengine 등 더 좋 은 제안 도 있 습 니 다.강 검사 체 제 는 더욱 완선 되 고 효율 적 입 니 다. 만약 에 nginx 커 뮤 니 티 버 전 을 계속 사용한다 면 당연히 스스로 작성 하거나 제3자 모듈 을 찾 아 번역 할 수 있 습 니 다.
먼저 제 테스트 환경 을 말씀 드 리 겠 습 니 다. CentOS release 6.4 (Final) + nginx 1.6.0 + tomcat 8.0.15 2 대 를 백 엔 드 서버 로 사용 합 니 다.

#user  nobody;
worker_processes  1;
#pid        logs/nginx.pid;
events {
worker_connections  1024;
}

http {
include       mime.types;
default_type  application/octet-stream;

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

access_log  logs/access.log  main;

sendfile        on;
keepalive_timeout  65;
upstream backend {
    server localhost:9090 max_fails=1 fail_timeout=40s;
    server localhost:9191 max_fails=1 fail_timeout=40s;
}
server {
    listen       80;
    server_name  localhost;
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 1;
        proxy_read_timeout 1;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }   
}

}
nginx 와 tomcat 의 설정 에 대한 기본 설정 은 설명 되 지 않 습 니 다. 공식 문 서 를 보 러 갈 수 있 습 니 다. upstream 명령 에 두 대의 server 를 설정 한 것 을 볼 수 있 습 니 다. 모든 server 는 max fails 와 fail timeout 값 을 설정 합 니 다.
지금부터 nginx 를 시작 하고 백 엔 드 서버 2 대 를 시작 합 니 다. 일부러 Tomcat Listener 에서 10 분 동안 Sleep 을 합 니 다. 즉, tomcat 를 시작 하 는 데 10 분 정도 걸 립 니 다. 포트 가 열 렸 지만 요청 을 받 지 않 았 습 니 다. 그리고 방문 합 니 다.http://localhost/response/ (response 이 인 터 페 이 스 는 제 가 tomcat 에서 쓴 servlet 인터페이스 로 기능 이 간단 합 니 다. 9090 의 server 수신 요청 이 라면 9090 으로 돌아 가 고 9191 포트 의 server 라면 9191 로 돌아 갑 니 다.) 지금 nginx 의 표현 을 관찰 하고 있 습 니 다.
nginx
## access.log ##

192.168.42.254 - - [29/Dec/2014:11:24:23 +0800] "GET /response/ HTTP/1.1" 504 537 720 380 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 2.004 host:health.iflytek.com
192.168.42.254 - - [29/Dec/2014:11:24:24 +0800] "GET /favicon.ico HTTP/1.1" 502 537 715 311 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.000 host:health.iflytek.com

## error.log ##

2014/12/29 11:24:22 [error] 6318#0: *4785892017 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "http://192.168.42.249:9090/response/", host: "health.iflytek.com"
2014/12/29 11:24:23 [error] 6318#0: *4785892017 upstream timed out (110: Connection timed out) while reading response header from upstream, client:     192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "http://192.168.42.249:9191/response/", host: "health.iflytek.com"
2014/12/29 11:24:24 [error] 6318#0: *4785892017 no live upstreams while connecting to upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://health/favicon.ico", host: "health.iflytek.com"

(listener 에서 수면 10 분 을 설정 하 는 이 유 는 우리 업무 에서 캐 시 예열 을 해 야 하기 때문에 이 10 분 은 아 날로 그 서버 시작 과정 에서 10 분 동안 사용 할 수 없습니다.)
관찰 로 그 는 두 대의 tomcat 시작 과정 에서 한 번 의 요청 을 보 내 면 nginx 가 모든 백 엔 드 서버 를 자동 으로 다시 시도 해 주 고 마지막 으로 no live upstreams while connecting to upstream 오 류 를 보고 합 니 다. 이것 은 nginx 가 health check 을 하 는 방식 이 라 고 할 수 있 습 니 다. 특히 강조해 야 할 것 은 proxy read timeout 을 1 초 로 설정 하 였 습 니 다. 다음 에 중점 을 두 겠 습 니 다.이 매개 변 수 를 푸 는 것 은 매우 중요 하 다.
40s 를 기다 리 고 있 습 니 다. 현재 9090 서버 를 시작 하 였 으 나 9191 서버 는 여전히 시작 되 고 있 습 니 다. nginx 로그 표현 을 관찰 하고 있 습 니 다.
access.log

192.168.42.254 - - [29/Dec/2014:11:54:18 +0800] "GET /response/ HTTP/1.1" 200 19 194 423 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.210 host:health.iflytek.com
192.168.42.254 - - [29/Dec/2014:11:54:18 +0800] "GET /favicon.ico HTTP/1.1" 404 453 674 311 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.212 host:health.iflytek.com                                                                                

error.log
인쇄 오류 없 음
브 라 우 저 는 9090 을 되 돌려 줍 니 다. nginx 가 정상적으로 요청 을 받 았 음 을 설명 합 니 다.
다시 한번 부탁 드 리 겠 습 니 다.
access.log

192.168.42.254 - - [29/Dec/2014:13:43:13 +0800] "GET /response/ HTTP/1.1" 200 19 194 423 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 1.005 host:health.iflytek.com

설명 정상 반환, 동시에 9090 반환
error.log

2014/12/29 13:43:13 [error] 6323#0: *4801368618 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "http://192.168.42.249:9191/response/", host: "health.iflytek.com"

nginx error. log 에 upstream time out 의 오류 가 추가 되 었 습 니 다. 그러나 클 라 이언 트 는 정상적으로 되 돌 아 왔 습 니 다. upstream 은 기본적으로 교대 훈련 부하 이기 때문에 이 요청 은 기본적으로 9191 이 기계 로 전 송 됩 니 다. 그러나 9191 이 시작 되 고 있 기 때문에 이번 요청 이 실 패 했 습 니 다. 그리고 nginx 는 9090 기계 로 다시 전 송 됩 니 다.
OK, 그런데 fail timeout = 40s 는 무슨 뜻 입 니까? 이 매개 변수의 중요성 을 재현 해 볼 까요? Let 's go! 지금 은 조용히 미남 이 되 어 9191 기계 가 작 동 할 때 까지 기 다 려 야 합 니 다! 몇 번 더 요청 을 보 내 주세요! 그리고 어, 9191 기계 가 9191 로 돌아 가 응답 하 는 것 을 발 견 했 습 니 다! fail timeout = 40s 는 사실 지난번 요청 에서 9191 이 정상적으로 돌아 오지 않 는 다 는 것 을 발견 하면...40s 시간 이 있 으 면 이 server 를 사용 할 수 없 지만 40s 요청 이 넘 으 면 다시 이 server 에 전 송 됩 니 다. 이 server 가 진정 으로 회복 되 었 든 없 든 간 에 nginx 커 뮤 니 티 판 helh check 체제 가 얼마나 약 한 지 알 수 있 습 니 다. 즉, 지연 차단 일 뿐 입 니 다. 이렇게 반복 되 는 것 입 니 다. nginx plus 를 사용 해 보면 nginx plus 가 제공 하 는 he 를 발견 할 수 있 습 니 다.alth check 메커니즘 이 더욱 강력 합 니 다. 몇 가지 키 워드 를 말 합 니 다. 직접 찾 아 보 세 요! zone slow start health check match! 이 slow start 는 캐 시 예열 문 제 를 잘 해결 합 니 다. 예 를 들 어 nginx 가 기계 가 재 부팅 된 것 을 발견 하면 slow starts 가 설정 한 시간 을 기 다 려 야 이 서버 에 다시 요청 을 보 낼 수 있 습 니 다. 이것 은 캐 시 예열 에 시간 을 제공 합 니 다.