NGINX 및 NGINX Plus를 사용한 로드 밸런싱, 1부 에서 여러 웹 서버에 걸쳐 트래픽을 로드 밸런싱하기 위한 간단한 HTTP 프록시를 설정했습니다. 이 문서에서는 NGINX Plus 에서 사용할 수 있는 추가 기능인 keepalives를 사용한 성능 최적화 , 상태 검사 , 세션 지속성 , 리디렉션 및 콘텐츠 재작성 을 살펴보겠습니다 .
NGINX 및 NGINX Plus의 부하 분산 기능에 대한 자세한 내용은 NGINX Plus 관리자 가이드를 확인하세요 .
컨텍스트 대신 컨텍스트 에서 TCP 및 UDP 부하 분산을 구성합니다 . 사용 가능한 지시문과 매개변수는 HTTP와 TCP/UDP 간의 고유한 차이로 인해 다소 다릅니다. 자세한 내용은 HTTP 및 TCP/UDP Upstream 모듈 에 대한 설명서를 참조하세요 .streamhttp
간단한 검토
검토해 보면, 이는 이전 문서에서 구축한 구성입니다 .
server { listen 80;
location / { proxy_pass http://backend;
# Rewrite the 'Host' header to the value in the client request,
# or primary server name
proxy_set_header Host $host;
# Alternatively, put the value in the config: # proxy_set_header Host www.example.com; }
}
upstream backend { zone backend 64k; # Use NGINX Plus' shared memory least_conn;
server webserver1 weight=1; server webserver2 weight=4;
}
이 글에서는 로드 밸런싱의 효율성을 향상하기 위한 NGINX 및 NGINX Plus를 구성하는 몇 가지 간단한 방법을 살펴보겠습니다.
HTTP Keepalives
NGINX 또는 NGINX Plus와 업스트림 서버 간에 HTTP keepalive를 활성화하면 지연 시간이 줄어들어 성능이 향상되고,
NGINX에서 임시 포트가 부족해질 가능성이 줄어듭니다.
HTTP 프로토콜은 기본 TCP 연결을 사용하여 HTTP 요청을 전송하고 HTTP 응답을 수신합니다.
HTTP keepalive 연결은 이러한 TCP 연결을 재사용할 수 있으므로 각 요청에 대한 연결을 만들고 파괴하는 오버헤드를 피할 수 있습니다.
NGINX는 전체 프록시이며 클라이언트(프런트엔드 keepalive 연결)로부터의
연결과 서버(업스트림 keepalive 연결)로의 연결을 독립적으로 관리합니다.
NGINX는 keepalive 연결의 "캐시"를 유지합니다. 이는 업스트림 서버에 대한 유휴 keepalive 연결 세트이며,
업스트림에 요청을 전달해야 할 때 새 TCP 연결을 만드는 대신 캐시에서 이미 설정된 keepalive 연결을 사용합니다.
이를 통해 NGINX와 업스트림 서버 간의 트랜잭션 지연 시간이 줄어들고
임시 포트가 사용되는 속도가 줄어들어 NGINX가 대량의 트래픽을 흡수하고 부하를 분산할 수 있습니다.
트래픽이 급증하면 캐시를 비울 수 있으며, 이 경우 NGINX가 업스트림 서버에 대한 새 HTTP 연결을 설정합니다.
다른 부하 분산 도구에서는 이 기술을 멀티플렉싱 , 연결 풀링 , 연결 재사용 또는 OneConnect 라고도 합니다 .
구성에 proxy_http_version, proxy_set_header및 지침을 포함하여 keepalive 연결 캐시를 구성합니다 .keepalive
server { listen 80;
location / { proxy_pass http://backend;
proxy_http_version 1.1; proxy_set_header Connection "";
}
}
upstream backend { server webserver1;
server webserver2;
# maintain up to 20 idle connections to the group of upstream servers keepalive 20;
}
Health Check
상태 점검을 활성화하면 부하 분산 서비스의 안정성이 향상되고,
최종 사용자에게 오류 메시지가 표시될 가능성이 줄어들며, 일반적인 유지 관리 작업도 원활하게 수행할 수 있습니다.
NGINX Plus의 상태 점검 기능 은 업스트림 서버의 장애를 감지하는 데 사용할 수 있습니다.
NGINX Plus는 "합성 트랜잭션"을 사용하여 각 서버를 조사하고 지시문에서 구성한 매개변수 health_check(매개변수를 포함하는 경우
match연관된 match구성 블록)에 대해 응답을 확인합니다.
server { listen 80;
location / { proxy_pass http://backend;
health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;
# The health checks inherit other proxy settings proxy_set_header Host www.foo.com; }
}
match statusok { # Used for /test.php health check status 200; header Content-Type = text/html; body ~ "Server[0-9]+ is alive";
}
상태 검사는 부모 location블록에서 일부 매개변수를 상속합니다. 구성에서 런타임 변수를 사용하는 경우 문제가 발생할 수 있습니다. 예를 들어, 다음 구성은 Host클라이언트 요청에서 헤더 값을 추출하기 때문에 실제 HTTP 트래픽에 작동합니다. 상태 검사에서 사용하는 합성 트랜잭션에는 작동하지 않을 수 있습니다. 이는 헤더 Host가 설정되지 않았기 때문입니다. 즉 Host합성 트랜잭션에서 헤더가 사용되지 않습니다.
location / { proxy_pass http://backend;
# This health check might not work... health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;
# Extract the 'Host' header from the request proxy_set_header Host $host;
}
location좋은 해결책 중 하나는 상태 확인 트랜잭션에서 사용되는 모든 매개변수를 정적으로 정의하는 더미 블록을 만드는 것입니다 .
location /internal-health-check1 { internal; # Prevent external requests from matching this location block
proxy_pass http://backend;
health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;
# Explicitly set request parameters; don't use run-time variables proxy_set_header Host www.example.com;
}
세션 지속성
세션 지속성을 사용하면 클러스터에 배포할 수 없는 애플리케이션도 로드 밸런싱하고 안정적으로 확장할 수 있습니다.
세션 상태를 저장하고 복제하는 애플리케이션은 더 효율적으로 작동하고 최종 사용자 성능이 향상됩니다.
특정 애플리케이션은 때때로 업스트림 서버에 상태 정보를 저장합니다.
예를 들어, 사용자가 가상 쇼핑 카트에 항목을 넣거나 업로드된 이미지를 편집할 때입니다.
이런 경우 해당 사용자의 모든 후속 요청을 동일한 서버로 보낼 수 있습니다.
세션 지속성은 요청이 어디로 라우팅되어야 하는지 지정하는 반면,
로드 밸런싱은 NGINX가 최적의 업스트림 서버를 선택할 수 있는 자유를 제공합니다.
두 프로세스는 NGINX Plus의 세션 지속성 기능을 사용하여 공존할 수 있습니다.
요청이 세션 지속성 규칙과 일치하는 경우 대상 업스트림 서버를 사용하고
그렇지 않은 경우 부하 분산 알고리즘을 적용하여 업스트림 서버를 선택합니다.
대상 서버를 사용할 수 없어 세션 지속성 결정이 실패하면 NGINX Plus는 부하 분산 결정을 내립니다.
가장 간단한 세션 지속성 방법은 " 스티키 쿠키 " 접근 방식으로,
NGINX Plus는 첫 번째 응답에 스티키 업스트림 서버를 식별하는 쿠키를 삽입합니다.
sticky cookie srv_id expires=1h domain=.example.com path=/;
대체 " sticky route " 방식에서 NGINX는 JSESSIONID 쿠키와 같은 요청 매개변수를 기반으로 업스트림 서버를 선택합니다.
upstream backend { server backend1.example.com route=a; server backend2.example.com route=b;
# select first non-empty variable; it should contain either 'a' or 'b' sticky route $route_cookie $route_uri;
}
HTTP 리디렉션 다시 쓰기
일부 리디렉션이 끊어지는 경우 HTTP 리디렉션을 다시 작성하세요.
특히 프록시에서 실제 업스트림 서버로 리디렉션되는 경우 다시 작성하세요.
업스트림 서버로 프록시할 때 서버는 로컬 주소에 애플리케이션을 게시하지만,
사용자는 다른 주소(프록시 주소)를 통해 애플리케이션에 액세스합니다.
이러한 주소는 일반적으로 도메인 이름으로 확인되며, 서버와 프록시가 다른 도메인을 가지고 있는 경우 문제가 발생할 수 있습니다.
예를 들어, 테스트 환경에서 프록시를 직접(IP 주소로) 또는 localhost 로 지정할 수 있습니다. 그러나 업스트림 서버는 실제 도메인 이름(예: www.nginx.com )에서 수신 대기할 수 있습니다. 업스트림 서버가 리디렉션 메시지를 발행하면( 3xx상태 및 Location헤더 사용 또는 Refresh헤더 사용) 메시지에 서버의 실제 도메인이 포함될 수 있습니다.
NGINX는 이 문제의 가장 흔한 사례를 가로채서 수정하려고 합니다. 특정 재작성을 강제하기 위해 전체 제어가 필요한 경우 proxy_redirect다음과 같이 지시문을 사용합니다.
proxy_redirect http://staging.mysite.com/ http://$host/;
HTTP 응답 다시 쓰기
때로는 HTTP 응답의 내용을 다시 써야 합니다.
아마도 위의 예처럼 응답에 프록시가 아닌 다른 서버를 참조하는 절대 링크가 포함되어 있을 수 있습니다.
sub_filter다음 지시어를 사용하여 적용할 다시 쓰기를 정의할 수 있습니다.
sub_filter /blog/ /blog-staging/;
sub_filter_once off;
매우 흔한 함정 중 하나는 HTTP 압축을 사용하는 것입니다. 클라이언트가 압축된 데이터를 허용할 수 있다는 신호를 보내고 서버가 응답을 압축하면 NGINX는 응답을 검사하고 수정할 수 없습니다. 가장 간단한 방법은 Accept-Encoding클라이언트의 요청에서 헤더를 제거하여 빈 문자열( "")로 설정하는 것입니다.
proxy_set_header Accept-Encoding "";
완전한 예
이 문서에서 논의된 모든 기술을 사용하는 로드 밸런싱 구성에 대한 템플릿은 다음과 같습니다.
NGINX Plus에서 사용할 수 있는 고급 기능은 주황색으로 강조 표시됩니다.
[편집기 - 다음 구성은 라이브 활동 모니터링 및 업스트림 그룹의 동적 구성을 위해 NGINX Plus API를 사용하도록 업데이트되었으며 원래 사용되었던 별도 모듈을 대체했습니다.]
server { listen 80;
location / { proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection ""; proxy_set_header Accept-Encoding "";
proxy_redirect http://staging.example.com/ http://$host/;
# Rewrite the Host header to the value in the client request
proxy_set_header Host $host;
# Replace any references inline to staging.example.com sub_filter http://staging.example.com/ /; sub_filter_once off;
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
NGINX 및 NGINX Plus를 사용한 로드 밸런싱, 1부 에서 여러 웹 서버에 걸쳐 트래픽을 로드 밸런싱하기 위한 간단한 HTTP 프록시를 설정했습니다. 이 문서에서는 NGINX Plus 에서 사용할 수 있는 추가 기능인 keepalives를 사용한 성능 최적화 , 상태 검사 , 세션 지속성 , 리디렉션 및 콘텐츠 재작성 을 살펴보겠습니다 .
NGINX 및 NGINX Plus의 부하 분산 기능에 대한 자세한 내용은 NGINX Plus 관리자 가이드를 확인하세요 .
컨텍스트 대신 컨텍스트 에서 TCP 및 UDP 부하 분산을 구성합니다 . 사용 가능한 지시문과 매개변수는 HTTP와 TCP/UDP 간의 고유한 차이로 인해 다소 다릅니다. 자세한 내용은 HTTP 및 TCP/UDP Upstream 모듈 에 대한 설명서를 참조하세요 .streamhttp
간단한 검토
검토해 보면, 이는 이전 문서에서 구축한 구성입니다 .
이 글에서는 로드 밸런싱의 효율성을 향상하기 위한 NGINX 및 NGINX Plus를 구성하는 몇 가지 간단한 방법을 살펴보겠습니다.
HTTP Keepalives
NGINX 또는 NGINX Plus와 업스트림 서버 간에 HTTP keepalive를 활성화하면 지연 시간이 줄어들어 성능이 향상되고,
NGINX에서 임시 포트가 부족해질 가능성이 줄어듭니다.
HTTP 프로토콜은 기본 TCP 연결을 사용하여 HTTP 요청을 전송하고 HTTP 응답을 수신합니다.
HTTP keepalive 연결은 이러한 TCP 연결을 재사용할 수 있으므로 각 요청에 대한 연결을 만들고 파괴하는 오버헤드를 피할 수 있습니다.
NGINX는 전체 프록시이며 클라이언트(프런트엔드 keepalive 연결)로부터의
연결과 서버(업스트림 keepalive 연결)로의 연결을 독립적으로 관리합니다.
NGINX는 keepalive 연결의 "캐시"를 유지합니다. 이는 업스트림 서버에 대한 유휴 keepalive 연결 세트이며,
업스트림에 요청을 전달해야 할 때 새 TCP 연결을 만드는 대신 캐시에서 이미 설정된 keepalive 연결을 사용합니다.
이를 통해 NGINX와 업스트림 서버 간의 트랜잭션 지연 시간이 줄어들고
임시 포트가 사용되는 속도가 줄어들어 NGINX가 대량의 트래픽을 흡수하고 부하를 분산할 수 있습니다.
트래픽이 급증하면 캐시를 비울 수 있으며, 이 경우 NGINX가 업스트림 서버에 대한 새 HTTP 연결을 설정합니다.
다른 부하 분산 도구에서는 이 기술을 멀티플렉싱 , 연결 풀링 , 연결 재사용 또는 OneConnect 라고도 합니다 .
구성에 proxy_http_version, proxy_set_header및 지침을 포함하여 keepalive 연결 캐시를 구성합니다 .keepalive
Health Check
상태 점검을 활성화하면 부하 분산 서비스의 안정성이 향상되고,
최종 사용자에게 오류 메시지가 표시될 가능성이 줄어들며, 일반적인 유지 관리 작업도 원활하게 수행할 수 있습니다.
NGINX Plus의 상태 점검 기능 은 업스트림 서버의 장애를 감지하는 데 사용할 수 있습니다.
NGINX Plus는 "합성 트랜잭션"을 사용하여 각 서버를 조사하고 지시문에서 구성한 매개변수 health_check(매개변수를 포함하는 경우
match연관된 match구성 블록)에 대해 응답을 확인합니다.
상태 검사는 부모 location블록에서 일부 매개변수를 상속합니다. 구성에서 런타임 변수를 사용하는 경우 문제가 발생할 수 있습니다. 예를 들어, 다음 구성은 Host클라이언트 요청에서 헤더 값을 추출하기 때문에 실제 HTTP 트래픽에 작동합니다. 상태 검사에서 사용하는 합성 트랜잭션에는 작동하지 않을 수 있습니다. 이는 헤더 Host가 설정되지 않았기 때문입니다. 즉 Host합성 트랜잭션에서 헤더가 사용되지 않습니다.
location좋은 해결책 중 하나는 상태 확인 트랜잭션에서 사용되는 모든 매개변수를 정적으로 정의하는 더미 블록을 만드는 것입니다 .
세션 지속성
세션 지속성을 사용하면 클러스터에 배포할 수 없는 애플리케이션도 로드 밸런싱하고 안정적으로 확장할 수 있습니다.
세션 상태를 저장하고 복제하는 애플리케이션은 더 효율적으로 작동하고 최종 사용자 성능이 향상됩니다.
특정 애플리케이션은 때때로 업스트림 서버에 상태 정보를 저장합니다.
예를 들어, 사용자가 가상 쇼핑 카트에 항목을 넣거나 업로드된 이미지를 편집할 때입니다.
이런 경우 해당 사용자의 모든 후속 요청을 동일한 서버로 보낼 수 있습니다.
세션 지속성은 요청이 어디로 라우팅되어야 하는지 지정하는 반면,
로드 밸런싱은 NGINX가 최적의 업스트림 서버를 선택할 수 있는 자유를 제공합니다.
두 프로세스는 NGINX Plus의 세션 지속성 기능을 사용하여 공존할 수 있습니다.
요청이 세션 지속성 규칙과 일치하는 경우 대상 업스트림 서버를 사용하고
그렇지 않은 경우 부하 분산 알고리즘을 적용하여 업스트림 서버를 선택합니다.
대상 서버를 사용할 수 없어 세션 지속성 결정이 실패하면 NGINX Plus는 부하 분산 결정을 내립니다.
가장 간단한 세션 지속성 방법은 " 스티키 쿠키 " 접근 방식으로,
NGINX Plus는 첫 번째 응답에 스티키 업스트림 서버를 식별하는 쿠키를 삽입합니다.
대체 " sticky route " 방식에서 NGINX는 JSESSIONID 쿠키와 같은 요청 매개변수를 기반으로 업스트림 서버를 선택합니다.
HTTP 리디렉션 다시 쓰기
일부 리디렉션이 끊어지는 경우 HTTP 리디렉션을 다시 작성하세요.
특히 프록시에서 실제 업스트림 서버로 리디렉션되는 경우 다시 작성하세요.
업스트림 서버로 프록시할 때 서버는 로컬 주소에 애플리케이션을 게시하지만,
사용자는 다른 주소(프록시 주소)를 통해 애플리케이션에 액세스합니다.
이러한 주소는 일반적으로 도메인 이름으로 확인되며, 서버와 프록시가 다른 도메인을 가지고 있는 경우 문제가 발생할 수 있습니다.
예를 들어, 테스트 환경에서 프록시를 직접(IP 주소로) 또는 localhost 로 지정할 수 있습니다. 그러나 업스트림 서버는 실제 도메인 이름(예: www.nginx.com )에서 수신 대기할 수 있습니다. 업스트림 서버가 리디렉션 메시지를 발행하면( 3xx상태 및 Location헤더 사용 또는 Refresh헤더 사용) 메시지에 서버의 실제 도메인이 포함될 수 있습니다.
NGINX는 이 문제의 가장 흔한 사례를 가로채서 수정하려고 합니다. 특정 재작성을 강제하기 위해 전체 제어가 필요한 경우 proxy_redirect다음과 같이 지시문을 사용합니다.
HTTP 응답 다시 쓰기
때로는 HTTP 응답의 내용을 다시 써야 합니다.
아마도 위의 예처럼 응답에 프록시가 아닌 다른 서버를 참조하는 절대 링크가 포함되어 있을 수 있습니다.
sub_filter다음 지시어를 사용하여 적용할 다시 쓰기를 정의할 수 있습니다.
매우 흔한 함정 중 하나는 HTTP 압축을 사용하는 것입니다. 클라이언트가 압축된 데이터를 허용할 수 있다는 신호를 보내고 서버가 응답을 압축하면 NGINX는 응답을 검사하고 수정할 수 없습니다. 가장 간단한 방법은 Accept-Encoding클라이언트의 요청에서 헤더를 제거하여 빈 문자열( "")로 설정하는 것입니다.
완전한 예
이 문서에서 논의된 모든 기술을 사용하는 로드 밸런싱 구성에 대한 템플릿은 다음과 같습니다.
NGINX Plus에서 사용할 수 있는 고급 기능은 주황색으로 강조 표시됩니다.
[편집기 - 다음 구성은 라이브 활동 모니터링 및 업스트림 그룹의 동적 구성을 위해 NGINX Plus API를 사용하도록 업데이트되었으며 원래 사용되었던 별도 모듈을 대체했습니다.]
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기