Nginx HTTP Proxy에서 Protocol 혼용에 따른 HTTP 502 발생 CASE 검토

1.server architect

client <-http-> nginx(proxy) <-http-> java was(tomcat, Armeria..etc)

(이 외에 tomcat AJP, weblogic,jboss등의 전용 proxy모듈등이 있을 수 있음, 케이스마다 다르다)

2. basic information
2.1 nginx의 proxy module을 사용하여  upstream(WAS등 여하의 뒷단 서비스)과 HTTP 통신시 프로토콜정보

porxy 모듈의 소스(메뉴얼에도 설명이 없다....)
 https://github.com/nginx/nginx/blob/68b50f71e193e58ee117ef36f25387cbaa75edf3/src/http/modules/ngx_http_proxy_module.c


2902 ngx_http_proxy_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child)
{....
3281 ngx_conf_merge_uint_value(conf->http_version, prev->http_version,
3282                              NGX_HTTP_VERSION_10);

- HTTP 1.0 지원
nginx의 proxy module의 기본 protocol은 http 1.0

- HTTP 1.1 지원
http 1.1로 동작시키기 위해서 keepalive 구문을 사용한다.

    upstream proxy_service {
        server 127.0.0.1:20080;
        keepalive 32;
    }

- HTTP 2.0 지원
일반적으로 우리는 revers proxy구조를 만들고 이때 Client와 upstream 사이에 정보확인 안되므로
프로토콜 업그레이드가 필요할 수 있다.이러한 경우 HTTP 2.0(websocket,SPDY)으로 동작시킬 수 있다 (1.3.13+)

http://nginx.org/en/docs/http/websocket.html

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

3. Case Study
3.1 HTTP 502
Client에서의 요청을 처리하던중 가끔 HTTP 502에러가 발생한다.????

3.1.1 WAS Restart, WAS Full GC
여하간의 문제로 upstream server가 nginx의 socket 생성 자체를 해주지 못한다면 502 (bad gateway)가 발생할 수 있다. (느리거나 용량문제로 발생하는 504와 다르다)
여기서는 이 문제를 다루지 않는다

3.1.2 proxy connection에 http 1.0, 1.1 혼용사용
HTTP 1.0은 keepalive를 지원하지 않는다
또한
HTTP 1.1도 keepalive를 off 할 수 있다. 다만 HTTP 1.1은 keep alive가 주요 목적이라고 감안하고 다음 이야기를 진행 한다.

client -> upstream 으로 접속시  keepalive를 켜는 경우와 끄는경우가 존재한다.
대부분 관리자의 취향(?)에 따르지만 이론적인 장단점은 다음과 같다 .

keepalive off(HTTP1.0) : 매 요청시 connection을 재 생성하여 upstream에 접속한다. 잘못된 요청에 의한 connection오염위험이 적으나 대량부하 사이트에서 다수의 socket자원이 생성된다
Keepalive on(HTTP1.1) : 일정수의 접속유지 connection을 생성하여 공유한다. connection이 오염되는경우 장애 위험이 있으나 proxy모듈과 upstream software적인 결함없이 안정적이라면 자원을 재활용하고 미리 생성해 놓을수 있으므로 안정적이고 속도가 빠르다

다음과 같이 설정하면 80으로 들어온 모든 요청은 keepalive로 접속하여 upstream으로 전달되고 32개의 connection은 지속적으로 재활용된다.


    upstream proxy_service {
        server 127.0.0.1:8080;
        keepalive 32;
    }


    server {
        listen 80;

        location / {
            proxy_pass http://proxy_service;

            proxy_http_version 1.1;
            proxy_connect_timeout 5;
.....
        }


문제는 다음과 같이 혼용되는 경우

    upstream proxy_service {
        server 127.0.0.1:8080;
        keepalive 32;
    }


    server {
        listen 80;
        #proxy_http_version 1.1; 지시자가 있으므로 1.1로 upstream으로 향한다.
        location / {
            proxy_pass http://proxy_service;

            proxy_http_version 1.1;
            proxy_connect_timeout 5;
.....
        }

        # 지시자가 없으므로 기본값인 1.0으로 upstream으로 향한다.
        location /statcheck {
            allow 127.0.0.1;
            deny all;
            proxy_pass http://proxy_service;
        }


모든 요청이 정상적으로 처리될 것 같으나

client가 /statcheck 를 호출하는 경우  http1.0 으로 upstream으로 요청이 넘어가고 upstream은 keepAlive off로 판단하여
기존의 KeepAlive로 생성된 해당 요청 Connection을 끊어버리게 된다.

client                                      upstream
1. A GET /index.html HTTP1.1 요청 전송 ->
2.                                          <- 응답 200 ok
3. B GET /statcheck HTTP1.0 요청 전송 ->
5.                                          <- 응답 200 ok
6.                                     <- Fin 전송
7. C GET /hello.html HTTP1.1 요청 전송 ->
8.                                     <- RST 전송

위의 경우 A 요청은 정상 처리가 되고 사용된 Connection정상
B 요청이 들어오면 1.0 이므로 정상처리후 해당 Connection을 끊는 동작시작
(HTTP Protocol의 정상 동작이나 추가 설명은 아래쪽에)
C요청을 전송하였으나 upstream에서 RST 전송으로 끊어지면서 HTTP 502오류 처리





3.1.3 upstream connection 구현체의 timeout (nginx proxy timeout 가 upstream보다 짧아야 문제가 없다. upstream으로 tomcat을 사용하는 경우 connectionTimeout에 지정된다.)
네트워크통신의 가장 일반적인 방법은 요청을 수행한 Client가 작업이 끝나면 Server쪽에 Connection을 끊는 요청을 하는 케이스다.
만약 Server쪽에서 끊어버리거나 중간의 방화벽, Porxy등에서 끊어지는현상이 있다면 의도한(과도한 자원잠식방지, 자원재활용, 보안정책)결과 일 수 있으나
간혹 nginx와 upstream간의 timeout문제로 connection이 끊어지면서 502 가 발생하는 경우가 있다

ex)
nginx proxy_timeout 10sec
tomcat connectionTimeout 5sec

인 경우 tomcat의 connection 관리자가 5초가 넘게 Idel인 Connection에 대하여 RST(reset)을 전송하여 요청을 끊어버릴 수 있다.
이런 경우 절묘한 타이밍에(?) 요청처리를 위해 connection을 사용중이였다면 완료되지 못하고 connection이 유실되고
해당 요청은 502처리된다.

client          upstream
1. A요청 전송 ->
2.              <- 응답
3.          5초 IDLE
4. <- Fin 전송
5. B요청 전송 ->
6. <- RST 전송

상기와 같이 Client에서 정상적으로 종료 요청을 해서 정리되는 케이스가 아니라면
upstream 에서 Fin 전송(끊기위해) 후 RST를 전송하기 전 까지 사이의 짧은 시간에 B 요청이 들어올 수 있고(낮은 확율로)
이 경우 사용자는 nginx log에서 HTTP 502에러를 보게 된다. 물론 WAS의 log에는 아무 내용이 없다.

대부분 이러한 케이스에 대하여
proxy_timeout (nginx proxy, AJP...etc)  == upstream timeout 을 권장하지만
WEB과 WAS가 같은 서버가 아닌경우 NTP로 동기화 한다고 하더라도 ms 수준의 차이가 발생할 수 있으므로

proxy_timeout (nginx proxy, AJP...etc)  < upstream timeout 로 설정 하는것이 권장된다.


4. WorkAround
상기의 타이밍 문제(Fin과 RST 사이의 짧은 시간에 요청이 들어오는)는 KeepAlive + http proxy모듈을 사용하는경우 다음사항이 검토되어야 한다.

4.1. upstream keepAlive OFF  (비권장)
KeepAlive를 끄면 모든 요청처리는 매번 새로운 Connection에서 처리되므로 상기 발생되는 문제를 회피할 수 있다
하지만
대량부하 사이트에서 proxy 처리를 하는 경우 다수의 socket자원이 생성되게 되며 자원관리를 위해 overhead가 필연적이므로 권장하지 않는다.

tomcat AJP, JBoss, Weblogic등의 경우 connection Pool을 사용하지 않는경우와 같아진다. 성능문제


4.2. upstream KeepAlive ON (권장)
Config시에 주의를 요한다
모든 요청은 KeepAlive로 upstream으로 전달 되도록 구성되어야 한다. 상기 3.1.2항의 프로토콜 혼용상태로 구성되면 문제가 발생한다.


5. 기타

그렇다면 tomcat mod_jk AJP, weblogic mod_wl, JBoss mod_cluster 등의 다른 proxy 모듈을 사용해도 이러한 제약 사항에 걸리는가?
그렇지는 않다
대표적인 AJP를 예를 들면 AJP는 별도의 프로토콜 stack을 구성하므로 상기와 같은 문제가 발생하지 않는다.
사용자의 http 요청이 web 으로 들어오면 AJP protocol로 wraping 되어 tomcat의 별도 AJP Port로 통신한다.
또한 keepalive의 지원여부가 AJP Connection의 생명주기와 무관하기 때문에 끊어지는 일은 없다.

다만 3.1.3항의 timeout 문제는 발생할 수 있으므로 주의가 필요하다 (이경우 AJP에 Cluster 설정이 없는 경우 502가 발생한다)


.이상