NGINX는 광범위한 HTTP 기반 애플리케이션을 위한 유능한 가속 프록시입니다.
캐싱, HTTP 연결 처리 및 오프로드는 특히 부하가 높은 기간 동안 애플리케이션 성능을 크게 향상시킵니다.
stream컨텍스트 대신 컨텍스트 에서 TCP 및 UDP 부하 분산을 구성합니다 . 사용 가능한 지시문과 매개변수는 HTTP와 TCP/UDP 간의 고유한 차이로 인해 다소 다릅니다. 자세한 내용은 HTTP 및 TCP Upstream 모듈 http에 대한 설명서를 참조하세요 .
NGINX Plus는 추가적인 부하 분산 기능( 상태 확인 , 세션 지속성 , 라이브 활동 모니터링 , 부하 분산 서버 그룹의 동적 구성) 을 추가하여 NGINX의 기능을 확장합니다 .
이 블로그 게시물은 NGINX를 구성하여 웹 서버 집합에 트래픽을 로드 밸런싱하는 방법을 안내합니다.
NGINX Plus의 추가 기능 중 일부를 강조합니다.
더 자세히 알아보려면 NGINX Plus 관리자 가이드 와 이 가이드의 후속 문서 인 NGINX 및 NGINX Plus를 사용한 부하 분산, 2부를 살펴보세요 .
NGINX를 사용한 트래픽 프록싱
트래픽을 업스트림 웹 서버 한 쌍으로 프록시하는 것으로 시작하겠습니다. 다음 NGINX 구성은 포트 80에 대한 모든 HTTP 요청을 종료하고 업스트림 그룹의 웹 서버를 통해 라운드 로빈 방식으로 전달하기에 충분합니다.
http { server { listen 80;
location / { proxy_pass http://backend; } }
upstream backend { server web-server1:80; server web-server2:80; }
}
이 간단한 구성을 통해 NGINX는 포트 80에서 수신된 각 요청을 차례로 웹 서버1 과 웹 서버2 에 전달하고 두 경우 모두 새로운 HTTP 연결을 설정합니다.
부하 분산 방법 설정
기본적으로 NGINX는 라운드 로빈 방식을 사용하여 트래픽을 서버 간에 균등하게 분산합니다. 이는 각 서버에 할당된 선택적 "가중치"를 통해 상대적 용량을 나타냅니다.
IP 해시 방법은 소스 IP 주소의 해시를 기반으로 트래픽을 분산합니다. 동일한 클라이언트 IP 주소의 요청은 항상 동일한 업스트림 서버로 전송됩니다. 이는 서버가 실패하거나 복구될 때마다 또는 업스트림 그룹이 수정될 때마다 재계산되는 원시 세션 지속성 방법입니다. 세션 지속성이 필요한 경우 NGINX Plus가 더 나은 솔루션을 제공합니다.
최소 연결 방법은 각 요청을 활성 연결이 가장 적은 업스트림 서버로 라우팅합니다.
이 방법은 빠르고 복잡한 요청이 혼합된 경우 잘 작동합니다.
weight모든 로드 밸런싱 방법은 지시문 에 선택적 매개변수를 사용하여 조정할 수 있습니다 server.
이는 서버의 처리 용량이 다를 때 의미가 있습니다. 다음 예에서 NGINX는 web-server1 보다 4배 많은 요청을 web-server2 로 보냅니다 .
upstream backend { zone backend 64k;
least_conn;
server web-server1 weight=1;
server web-server2 weight=4;
}
NGINX에서 가중치는 각 워커 프로세스에 의해 독립적으로 관리됩니다. NGINX Plus는 업스트림 데이터에 대해 공유 메모리 세그먼트를 사용하므로(지시어로 구성됨 zone) 가중치는 워커 간에 공유되고 트래픽은 더 정확하게 분산됩니다.
실패 감지
NGINX가 서버에 연결하거나, 서버에 요청을 전달하거나, 응답 헤더를 읽을 때 오류나 시간 초과가 발생하면 NGINX는 다른 서버와 연결 요청을 다시 시도합니다. ( proxy_next_upstream구성에 지시문을 포함시켜 요청을 다시 시도하기 위한 다른 조건을 정의할 수 있습니다.) 또한 NGINX는 실패한 서버를 잠재적인 서버 집합에서 제외하고 때때로 해당 서버에 대한 요청을 시도하여 복구 시 감지할 수 있습니다. 지시문에 대한 max_fails및 fail_timeout매개변수는 server이러한 동작을 제어합니다.
NGINX Plus는 각 업스트림 서버에 대해 정교한 HTTP 테스트를 수행하여 활성 상태인지 확인하는 일련의 대역 외 상태 확인 과 복구된 서버를 부하 분산 그룹에 점진적으로 다시 도입하는 슬로우 스타트 메커니즘을 추가합니다.
server web-server1 slow_start=30s;
일반적인 'Gotcha' - Host헤더 수정
매우 일반적으로 업스트림 서버는 Host요청의 헤더를 사용하여 어떤 콘텐츠를 제공할지 결정합니다. 서버에서 예상치 못한 오류가 발생하거나 잘못된 콘텐츠를 제공하고 있다는 것을 암시하는 다른 사항이 있는 경우 가장 먼저 확인해야 할 사항입니다. 그런 다음 구성에 지시문을 404포함하여 헤더에 적합한 값을 설정합니다.proxy_set_header
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;
}
NGINX Plus를 사용한 고급 로드 밸런싱
NGINX Plus의 다양한 고급 기능은 업스트림 서버 팜 앞에서 이상적인 로드 밸런서가 되도록 합니다.
- 부하 분산 및 세션 지속성 – 작업자 프로세스 전반의 더 나은 부하 분산 및 세션 지속성 방법을 통해 애플리케이션 세션을 식별하고 존중합니다.
- HTTP 상태 점검 및 서버 느린 시작 – 각 업스트림 서버의 올바른 작동을 조사하기 위한 비동기 '합성 트랜잭션' 및 복구 시 서버의 우아한 '느린 시작' 재도입
- 실시간 활동 모니터링 – 활동 및 성과에 대한 즉각적인 보고
- 동적으로 구성된 상류 서버 그룹 - 서버의 안전하고 일시적인 제거와 같은 일반적인 상류 관리 작업을 용이하게 해주는 도구
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
NGINX는 광범위한 HTTP 기반 애플리케이션을 위한 유능한 가속 프록시입니다.
캐싱, HTTP 연결 처리 및 오프로드는 특히 부하가 높은 기간 동안 애플리케이션 성능을 크게 향상시킵니다.
stream컨텍스트 대신 컨텍스트 에서 TCP 및 UDP 부하 분산을 구성합니다 . 사용 가능한 지시문과 매개변수는 HTTP와 TCP/UDP 간의 고유한 차이로 인해 다소 다릅니다. 자세한 내용은 HTTP 및 TCP Upstream 모듈 http에 대한 설명서를 참조하세요 .
NGINX Plus는 추가적인 부하 분산 기능( 상태 확인 , 세션 지속성 , 라이브 활동 모니터링 , 부하 분산 서버 그룹의 동적 구성) 을 추가하여 NGINX의 기능을 확장합니다 .
이 블로그 게시물은 NGINX를 구성하여 웹 서버 집합에 트래픽을 로드 밸런싱하는 방법을 안내합니다.
NGINX Plus의 추가 기능 중 일부를 강조합니다.
더 자세히 알아보려면 NGINX Plus 관리자 가이드 와 이 가이드의 후속 문서 인 NGINX 및 NGINX Plus를 사용한 부하 분산, 2부를 살펴보세요 .
NGINX를 사용한 트래픽 프록싱
트래픽을 업스트림 웹 서버 한 쌍으로 프록시하는 것으로 시작하겠습니다. 다음 NGINX 구성은 포트 80에 대한 모든 HTTP 요청을 종료하고 업스트림 그룹의 웹 서버를 통해 라운드 로빈 방식으로 전달하기에 충분합니다.
http { server { listen 80;
location / { proxy_pass http://backend; } }
upstream backend { server web-server1:80; server web-server2:80; }
}
이 간단한 구성을 통해 NGINX는 포트 80에서 수신된 각 요청을 차례로 웹 서버1 과 웹 서버2 에 전달하고 두 경우 모두 새로운 HTTP 연결을 설정합니다.
부하 분산 방법 설정
기본적으로 NGINX는 라운드 로빈 방식을 사용하여 트래픽을 서버 간에 균등하게 분산합니다. 이는 각 서버에 할당된 선택적 "가중치"를 통해 상대적 용량을 나타냅니다.
IP 해시 방법은 소스 IP 주소의 해시를 기반으로 트래픽을 분산합니다. 동일한 클라이언트 IP 주소의 요청은 항상 동일한 업스트림 서버로 전송됩니다. 이는 서버가 실패하거나 복구될 때마다 또는 업스트림 그룹이 수정될 때마다 재계산되는 원시 세션 지속성 방법입니다. 세션 지속성이 필요한 경우 NGINX Plus가 더 나은 솔루션을 제공합니다.
최소 연결 방법은 각 요청을 활성 연결이 가장 적은 업스트림 서버로 라우팅합니다.
이 방법은 빠르고 복잡한 요청이 혼합된 경우 잘 작동합니다.
weight모든 로드 밸런싱 방법은 지시문 에 선택적 매개변수를 사용하여 조정할 수 있습니다 server.
이는 서버의 처리 용량이 다를 때 의미가 있습니다. 다음 예에서 NGINX는 web-server1 보다 4배 많은 요청을 web-server2 로 보냅니다 .
NGINX에서 가중치는 각 워커 프로세스에 의해 독립적으로 관리됩니다. NGINX Plus는 업스트림 데이터에 대해 공유 메모리 세그먼트를 사용하므로(지시어로 구성됨 zone) 가중치는 워커 간에 공유되고 트래픽은 더 정확하게 분산됩니다.
실패 감지
NGINX가 서버에 연결하거나, 서버에 요청을 전달하거나, 응답 헤더를 읽을 때 오류나 시간 초과가 발생하면 NGINX는 다른 서버와 연결 요청을 다시 시도합니다. ( proxy_next_upstream구성에 지시문을 포함시켜 요청을 다시 시도하기 위한 다른 조건을 정의할 수 있습니다.) 또한 NGINX는 실패한 서버를 잠재적인 서버 집합에서 제외하고 때때로 해당 서버에 대한 요청을 시도하여 복구 시 감지할 수 있습니다. 지시문에 대한 max_fails및 fail_timeout매개변수는 server이러한 동작을 제어합니다.
NGINX Plus는 각 업스트림 서버에 대해 정교한 HTTP 테스트를 수행하여 활성 상태인지 확인하는 일련의 대역 외 상태 확인 과 복구된 서버를 부하 분산 그룹에 점진적으로 다시 도입하는 슬로우 스타트 메커니즘을 추가합니다.
일반적인 'Gotcha' - Host헤더 수정
매우 일반적으로 업스트림 서버는 Host요청의 헤더를 사용하여 어떤 콘텐츠를 제공할지 결정합니다. 서버에서 예상치 못한 오류가 발생하거나 잘못된 콘텐츠를 제공하고 있다는 것을 암시하는 다른 사항이 있는 경우 가장 먼저 확인해야 할 사항입니다. 그런 다음 구성에 지시문을 404포함하여 헤더에 적합한 값을 설정합니다.proxy_set_header
NGINX Plus를 사용한 고급 로드 밸런싱
NGINX Plus의 다양한 고급 기능은 업스트림 서버 팜 앞에서 이상적인 로드 밸런서가 되도록 합니다.
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기