NGINX는 광범위한 HTTP 기반 애플리케이션을 가속화하는 강력한 프록시입니다. 캐싱, HTTP 연결 처리, 오프로드 기능을 통해 애플리케이션 성능이 크게 향상되며, 특히 부하가 높은 기간에 그 효과가 큽니다.
편집기 – NGINX Plus 릴리스 5 이상은 TCP 기반 애플리케이션의 부하를 분산할 수도 있습니다. 릴리스 6 에서는 상태 점검, 동적 재구성, SSL 종료 등의 기능이 추가되어 TCP 부하 분산 기능이 크게 확장되었습니다. NGINX Plus 릴리스 7<.htmla> 이상에서는 TCP 로드 밸런서가 HTTP 로드 밸런서와 모든 기능이 동일합니다. 지원 UDP 로드 밸런싱 릴리스 9에서 도입되었습니다.
http
컨텍스트 대신 스트림
컨텍스트에서 TCP 및 UDP 부하 분산을 구성합니다 . HTTP와 TCP/UDP 사이의 본질적인 차이로 인해 사용 가능한 지시어와 매개변수는 다소 다릅니다. 자세한 내용은 HTTP 및 TCP 업스트림 모듈에 대한 설명서를 참조하세요.
NGINX Plus는 추가적인 부하 분산 기능( 상태 확인 , 세션 지속성 , 라이브 활동 모니터링 , 부하 분산 서버 그룹의 동적 구성) 을 추가하여 NGINX의 기능을 확장합니다.
이 블로그 게시물에서는 NGINX를 구성하여 웹 서버 세트에 트래픽을 부하 분산하는 방법을 안내합니다. 여기서는 NGINX Plus의 추가 기능 중 일부를 강조해서 설명합니다.
더 자세한 내용을 알아보려면 NGINX Plus 관리자 가이드 와 이 가이드의 후속 문서 인 NGINX 및 NGINX Plus를 사용한 부하 분산, 2부를 살펴보세요.
우리는 업스트림 웹 서버 한 쌍으로 트래픽을 프록시하는 것으로 시작할 것입니다. 다음 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_fails
및 fail_timeout
매개변수가 이러한 동작을 제어합니다.
NGINX Plus는 각 업스트림 서버에 대해 정교한 HTTP 테스트를 수행하여 활성 상태인지 확인하는 일련의 대역 외 상태 확인 과 복구된 서버를 부하 분산 그룹에 점진적으로 다시 도입하는 슬로우 스타트 메커니즘을 추가합니다.
서버 웹 서버 1 slow_start=30초;
호스트
헤더 수정일반적으로 업스트림 서버는 요청의 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 및 NGINX Plus를 사용한 부하 분산, 2부를 참조하세요.
NGINX Plus를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 부하 분산 사용 사례에 대해 논의해 보세요 .
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."