블로그 | NGINX

NGINX 및 NGINX Plus를 사용한 로드 밸런싱, 1부

NGINX-F5-수평-검정-유형-RGB의 일부
오웬 개렛 썸네일
오웬 개렛
2014년 2월 20일 게시

NGINX는 광범위한 HTTP 기반 애플리케이션을 가속화하는 강력한 프록시입니다. 캐싱, HTTP 연결 처리, 오프로드 기능을 통해 애플리케이션 성능이 크게 향상되며, 특히 부하가 높은 기간에 그 효과가 큽니다.

편집기 – NGINX Plus 릴리스 5 이상은 TCP 기반 애플리케이션의 부하를 분산할 수도 있습니다. 릴리스 6 에서는 상태 점검, 동적 재구성, SSL 종료 등의 기능이 추가되어 TCP 부하 분산 기능이 크게 확장되었습니다. NGINX Plus 릴리스 7<.htmla> 이상에서는 TCP 로드 밸런서가 HTTP 로드 밸런서와 모든 기능이 동일합니다. 지원 UDP 로드 밸런싱 릴리스 9에서 도입되었습니다.

http 컨텍스트 대신 스트림 컨텍스트에서 TCP 및 UDP 부하 분산을 구성합니다 . HTTP와 TCP/UDP 사이의 본질적인 차이로 인해 사용 가능한 지시어와 매개변수는 다소 다릅니다. 자세한 내용은 HTTPTCP 업스트림 모듈에 대한 설명서를 참조하세요.

NGINX Plus는 추가적인 부하 분산 기능( 상태 확인 , 세션 지속성 , 라이브 활동 모니터링 , 부하 분산 서버 그룹의 동적 구성) 을 추가하여 NGINX의 기능을 확장합니다.

이 블로그 게시물에서는 NGINX를 구성하여 웹 서버 세트에 트래픽을 부하 분산하는 방법을 안내합니다. 여기서는 NGINX Plus의 추가 기능 중 일부를 강조해서 설명합니다.

더 자세한 내용을 알아보려면 NGINX Plus 관리자 가이드 와 이 가이드의 후속 문서 인 NGINX 및 NGINX Plus를 사용한 부하 분산, 2부를 살펴보세요.

NGINX를 사용한 트래픽 프록싱

우리는 업스트림 웹 서버 한 쌍으로 트래픽을 프록시하는 것으로 시작할 것입니다. 다음 NGINX 구성은 포트 80에 대한 모든 HTTP 요청을 종료하고 이를 업스트림 그룹의 웹 서버로 라운드 로빈 방식으로 전달하기에 충분합니다.

http { 서버 {
listen 80;

location / {
proxy_pass http://backend;
}
}

업스트림 백엔드 {
서버 웹 서버1:80;
서버 웹 서버2:80;
}
}

이 간단한 구성을 사용하면 NGINX는 포트 80에서 수신된 각 요청을 차례로 웹 서버1웹 서버2 에 전달하고 각 경우에 새로운 HTTP 연결을 설정합니다.

부하 분산 방법 설정

기본적으로 NGINX는 라운드 로빈 방식을 사용하여 트래픽을 서버 간에 균등하게 분산합니다. 이는 각 서버에 할당된 선택적 "가중치"를 통해 상대적 용량을 나타냅니다.

IP 해시 방법은 소스 IP 주소의 해시를 기반으로 트래픽을 분산합니다. 동일한 클라이언트 IP 주소에서 온 요청은 항상 동일한 업스트림 서버로 전송됩니다. 이는 서버에 장애가 발생하거나 복구될 때마다, 또는 업스트림 그룹이 수정될 때마다 다시 계산되는 간단한 세션 지속성 방법입니다. 세션 지속성이 필요한 경우 NGINX Plus는 더 나은 솔루션을 제공합니다.

최소 연결 방법은 각 요청을 활성 연결이 가장 적은 상위 서버로 라우팅합니다. 이 방법은 빠른 요청과 복잡한 요청이 혼합된 경우 효과적입니다.

모든 부하 분산 방법은 서버 지시문에서 선택적 가중치 매개변수를 사용하여 조정할 수 있습니다. 이는 서버의 처리 용량이 서로 다른 경우에 적합합니다. 다음 예에서 NGINX는 web- server1보다 4배 더 많은 요청을 web-server2 에 보냅니다.

업스트림 백엔드 { 존 백엔드 64k; least_conn; 서버 웹 서버1 가중치=1; 서버 웹 서버2 가중치=4 ; }

NGINX에서는 각 작업자 프로세스가 가중치를 독립적으로 관리합니다. NGINX Plus는 업스트림 데이터에 공유 메모리 세그먼트를 사용하므로( zone 지시어로 구성됨) 작업자 간에 가중치가 공유되고 트래픽이 더 정확하게 분산됩니다.

실패 감지

NGINX가 서버에 연결하거나, 서버에 요청을 전달하거나, 응답 헤더를 읽을 때 오류나 시간 초과가 발생하면, NGINX는 다른 서버에 연결 요청을 다시 시도합니다. (요청을 재시도하기 위한 다른 조건을 정의하기 위해 구성에 proxy_next_upstream 지시문을 포함할 수 있습니다.) 또한 NGINX는 실패한 서버를 잠재적인 서버 집합에서 제외하고 가끔 해당 서버에 대한 요청을 시도하여 복구되는 경우를 감지할 수 있습니다. 서버 지시문의 max_failsfail_timeout 매개변수가 이러한 동작을 제어합니다.

NGINX Plus는 각 업스트림 서버에 대해 정교한 HTTP 테스트를 수행하여 활성 상태인지 확인하는 일련의 대역 외 상태 확인 과 복구된 서버를 부하 분산 그룹에 점진적으로 다시 도입하는 슬로우 스타트 메커니즘을 추가합니다.

서버 웹 서버 1 slow_start=30초;

일반적인 'Gotcha' - 호스트 헤더 수정

일반적으로 업스트림 서버는 요청의 Host 헤더를 사용하여 어떤 콘텐츠를 제공할지 결정합니다. 예상치 못한 일이 생기면404 서버 오류가 발생했거나 잘못된 콘텐츠를 제공하고 있다는 의심이 드는 경우 가장 먼저 확인해야 할 사항입니다. 그런 다음 구성에 proxy_set_header 지시문을 포함하여 헤더에 적합한 값을 설정합니다.

위치 / { proxy_pass http://backend; # 'Host' 헤더를 클라이언트 요청이나 기본 서버 이름의 값으로 다시 작성합니다. proxy_set_header Host $host ; # 아니면 config에 값을 넣습니다. #proxy_set_header Host www.example.com; }

NGINX Plus를 사용한 고급 로드 밸런싱

NGINX Plus의 다양한 고급 기능은 업스트림 서버 팜 앞에서 이상적인 로드 밸런서가 되도록 합니다.

고급 부하 분산 및 프록싱에 대한 자세한 내용은 이 게시물의 후속 게시물인 NGINX 및 NGINX Plus를 사용한 부하 분산, 2부를 참조하세요.

NGINX Plus를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 부하 분산 사용 사례에 대해 논의해 보세요 .


"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."