NGINX Plus 로드 밸런싱 기술 선택

최적의 가용성과 안정성을 위해 NGINX Plus와 NGINX 오픈 소스를 사용하여 웹사이트와 앱의 부하를 분산하는 방법에 대해 많은 글을 썼습니다. 부하 분산은 앱 성능을 높이고 , 대규모로 앱을 제공하고 , 컨테이너와 마이크로서비스를 배포하는 데 기본이 되는 도구입니다.

이전에 NGINX Plus를 데이터 센터 (레거시 애플리케이션 전송 컨트롤러와 함께), 컨테이너 및 Amazon Web Services (AWS), Google Cloud Platform , Microsoft Azure를 포함한 클라우드 환경에 배포하는 방법에 대해 설명했습니다.

이 게시물에서는 NGINX Plus와 NGINX의 부하 분산 기술(부하 분산 방법 또는 알고리즘 이라고도 함)에 초점을 맞추고, 다양한 사용 사례에 맞는 올바른 방법을 선택하는 방법에 대한 몇 가지 조언을 제공합니다. NGINX는 4가지 부하 분산 기술( 라운드 로빈 , 해시 , IP 해시 , 최소 연결 )을 제공하며 NGINX Plus는 하나( 최소 시간 )를 더 추가합니다. IP 해시를 제외한 모든 HTTP 트래픽 방법은 TCP(및 NGINX Plus 릴리스 9 이상에서 UDP)에서도 사용할 수 있습니다.

[ 편집기 – NGINX Plus R16 및 NGINX Open Source 1.15.1은 추가 부하 분산 알고리즘으로 Two Choices가 있는 Random을 도입했습니다. 토론을 위해 블로그에서 NGINX 및 "Power of Two Choices" 부하 분산 알고리즘을 참조하세요.]

부하 분산 기술 검토

로드 밸런싱을 구성하는 방법의 기본 사항을 알고 있다고 가정하지만 새로 고침이 필요한 경우 다음 리소스를 확인할 수 있습니다.

• NGINX Plus 관리자 가이드 의 문서에서는 전체적인 개요를 제공합니다.
• 고성능 부하 분산은 부하 분산 방법의 효율성을 한층 더 개선할 수 있는 NGINX Plus의 향상된 기능에 대한 자세한 설명으로 연결됩니다.
• NGINX 및 NGINX Plus를 사용한 부하 분산 , 1부 와 2부는 NGINX Plus의 향상된 기능을 사용하여 간단한 역방향 프록시를 포괄적인 부하 분산 솔루션으로 구축하는 과정을 안내하는 가이드입니다.
• 부하 분산 솔루션 페이지는 전자책, 웨비나, 백서를 포함한 다른 리소스로 연결됩니다.

단순화를 위해, http 컨텍스트에서 구성하는 HTTP 부하 분산에 초점을 맞추겠습니다. TCP 부하 분산은 대신 스트림 컨텍스트에서 구성됩니다(NGINX Plus 릴리스 9 이상에서는 UDP 부하 분산도 마찬가지입니다). HTTP와 TCP/UDP 부하 분산 장치는 기능이 동일하지만 프로토콜 간의 본질적인 차이로 인해 사용 가능한 지침과 매개변수는 다소 다릅니다. 자세한 내용은 HTTP 및 TCP/UDP 용 업스트림 모듈에 대한 설명서를 참조하세요.

두 가지 구성 블록으로 로드 밸런싱을 활성화합니다. 이는 선택 매개변수나 보조 기능 없이 기본 형태로 표시됩니다.

• 서버 블록은 사용자가 정의한 특성을 가진 트래픽을 수신하는 가상 서버를 정의하고, 이를 명명된 상위 서버 그룹으로 프록시합니다. 예제에서 가상 서버는 www.example.com 으로 전송된 HTTP 트래픽을 기본 포트(80)에서 수신하고 이를 백엔드 라는 업스트림 서버 그룹으로 프록시합니다. 이 블록은 모든 예에서 동일합니다.

  서버 { 서버 이름 www.example.com;
  
  위치 / {
  프록시 패스 http://백엔드;
  }
  }

  (NGINX Plus와 NGINX는 FastCGI, memcached, SCGI, uwsgi 백엔드 서버의 부하를 분산할 수도 있습니다. proxy_pass를 적절한 지시어( fastcgi_pass , memcached_pass , scgi_pass 또는 uwsgi_pass )로 바꾸세요.

• 업스트림 블록은 업스트림 그룹의 이름을 지정하고 호스트 이름, IP 주소 또는 UNIX 도메인 소켓 경로로 식별된 해당 그룹에 속한 서버를 나열합니다. 우리의 예에서 백엔드 라는 업스트림 그룹에는 web1 , web2 , web3 이라는 세 개의 서버가 포함됩니다.

  업스트림 블록은 부하 분산 기술을 지정하는 곳이므로 다음 섹션에서 이에 대해 강조하겠습니다. 예를 들어, 기본 방식인 라운드 로빈에 대한 블록은 다음과 같습니다.

  업스트림 백엔드 { 서버 web1;
  서버 web2;
  서버 web3;
  }

라운드 로빈

라운드 로빈은 NGINX Plus와 NGINX 모두에 대한 기본 로드 밸런싱 기술입니다. 로드 밸런서는 순서대로 업스트림 서버 목록을 실행하여 차례로 다음 연결 요청을 각 서버에 할당합니다.

백엔드 업스트림 그룹의 다음 샘플 구성을 고려할 때, 로드 밸런서는 처음 세 개의 연결 요청을 순서대로 web1 , web2 , web3 에 보내고, 네 번째는 web1 에, 다섯 번째는 web2 에 보내는 식으로 진행합니다.

업스트림 백엔드 { 서버 web1;
서버 web2;
서버 web3;
}

서버 {
서버 이름 www.example.com;

위치 / {
프록시 패스 http://백엔드;
}
}

해시시

해시 방식을 사용하면 각 요청에 대해 로드 밸런서는 사용자가 지정한 텍스트와 NGINX 변수 의 조합을 기반으로 해시를 계산하고, 해당 해시를 서버 중 하나와 연결합니다. 이 해시가 포함된 모든 요청을 해당 서버로 전송하므로 이 방법은 기본적인 종류의 세션 지속성을 설정합니다.

다음 예에서 해시 지시문은 해시의 기준으로 스키마( http 또는 https )와 요청의 전체 URI를 사용합니다.

업스트림 백엔드 { 해시 $scheme$request_uri; 서버 web1; 서버 web2; 서버 web3; } 서버 { 서버 이름 www.example.com; 위치 / { 프록시 패스 http://backend; } }

IP 해시

IP 해시(HTTP에서만 사용 가능)는 해시 방식의 미리 정의된 변형으로, 해시는 클라이언트의 IP 주소를 기반으로 합니다. ip_hash 지시어로 설정합니다.

업스트림 백엔드 { ip_hash ; 서버 web1; 서버 web2; 서버 web3; } 서버 { 서버 이름 www.example.com; 위치 / { 프록시 패스 http://backend; } }

클라이언트에 IPv6 주소가 있는 경우 해시는 전체 주소를 기반으로 합니다. IPv4 주소가 있는 경우 해시는 주소의 처음 세 옥텟만을 기준으로 합니다. 이 기능은 하위 네트워크(/24) 범위에서 동적으로 IP 주소가 할당되는 ISP 클라이언트를 최적화하도록 설계되었습니다. 재부팅이나 재연결 시 클라이언트의 주소는 종종 /24 네트워크 범위의 다른 주소로 변경되지만 연결은 여전히 동일한 클라이언트를 나타내므로 서버에 대한 매핑을 변경할 이유가 없습니다.

그러나 사이트 트래픽 대부분이 동일한 /24 네트워크의 클라이언트에서 발생하는 경우 IP 해시는 모든 클라이언트를 동일한 서버에 매핑하므로 의미가 없습니다. 그런 경우(또는 다른 이유로 4개 옥텟 모두를 해시하려는 경우) 대신 $remote_addr 변수와 함께 Hash 메서드를 사용하세요.

해시 $remote_addr;

최소 연결

최소 연결 방법을 사용하면 로드 밸런서는 각 서버에 대한 현재 활성 연결 수를 비교하고 연결이 가장 적은 서버로 요청을 보냅니다. least_conn 명령어를 사용하여 구성합니다.

업스트림 백엔드 { least_conn ; 서버 web1; 서버 web2; 서버 web3; } 서버 { 서버 이름 www.example.com; 위치 / { proxy_pass http://backend; } }

최소 시간

최소 시간 방식(NGINX Plus에서만 사용 가능)을 사용하면 로드 밸런서는 각 서버에 대한 두 가지 측정 항목(현재 활성 연결 수와 이전 요청에 대한 가중 평균 응답 시간)을 수학적으로 결합하여 가장 낮은 값을 가진 서버로 요청을 보냅니다.

least_time 지시문에서 선택한 매개변수는 두 가지 응답 시간 중 어느 것을 추적할지 제어합니다. 즉, 응답 헤더를 수신하는 시간( header ) 또는 전체 응답을 수신하는 시간( last_byte )을 추적할지입니다.

업스트림 백엔드 { least_time (헤더 | last_byte) ; 서버 web1; 서버 web2; 서버 web3; } 서버 { 서버 이름 www.example.com; 위치 / { proxy_pass http://backend; } }

참고사항:

• TCP 및 UDP 부하 분산( 스트림 컨텍스트에서)의 경우 least_time 지시문에 대한 다음 매개변수를 사용하여 세 가지 유형의 응답 시간 중에서 선택할 수 있습니다.

  • connect – 업스트림 서버에 연결하는 시간
  • first_byte – 응답 데이터의 첫 번째 바이트를 수신하는 시간
  • last_byte – 응답 데이터의 마지막 바이트를 수신하는 시간

• NGINX Plus R12 이상에서는 HTTP와 TCP/UDP 트래픽 모두에 대해 각 메트릭에 완료되지 않은 연결을 포함하기 위해 inflight 매개변수를 추가합니다. 이러한 연결은 이전 릴리스에서는 기본적으로 포함됩니다.

부하 분산 기술 선택

그렇다면 귀하의 웹사이트나 앱에 가장 적합한 부하 분산 기술은 무엇인지 어떻게 알 수 있을까요?

트래픽 패턴은 사이트마다 매우 다르고 심지어 단일 사이트 내에서도 하루 중 다른 시간대에 따라 다르기 때문에 단일 특성(예: 폭발적인 트래픽 대 안정적이고 단기간 지속되는 연결 대 장기간 지속되는 연결 등)을 기준으로 부하 분산 기술을 선택하는 것은 말이 되지 않습니다. 즉, 우리는 각 방법의 장단점을 고려하여 고려할 선택 범위를 좁히는 데 도움을 드리겠습니다.

방법을 비교하기 위한 테스트 실행

어떤 부하 분산 방법을 고려하든, 트래픽에 가장 적합한 방법을 알아보기 위해 테스트를 실시하는 것이 좋습니다. "최상"은 일반적으로 고객에게 응답을 전달하는 데 걸리는 가장 짧은 시간을 의미하지만 다른 기준이 있을 수도 있습니다.

이런 종류의 테스트에는 애플리케이션 성능 관리 도구가 매우 편리합니다. 업스트림 그룹의 각 서버에 대한 그래프가 있는 사용자 지정 화면을 만들 수 있으므로 테스트 중에 값이 변경됨에 따라 실시간으로 비교할 수 있습니다. AppDynamics , Datadog , Dynatrace , New Relic 등 여러 APM이 NGINX Plus 및 NGINX용 맞춤 플러그인을 제공합니다.

모든 서버의 용량이 동일하다면 테스트가 가장 간단합니다. 그렇지 않은 경우, 더 많은 용량을 갖춘 머신이 더 많은 요청을 받을 수 있도록 서버 가중치를 설정해야 합니다. 서버가 동일하지 않을 때 가중치 설정을 아래에서 참조하세요.

테스트 중에 확인해야 할 몇 가지 측정 항목은 다음과 같습니다.

• CPU 및 메모리 부하 – CPU와 메모리 모두에서 사용된 총 용량의 백분율을 살펴보세요. 모든 서버에 동일한 부하가 걸리지 않으면 트래픽이 효율적으로 분산되지 않습니다.
• 서버 응답 시간 - 일부 서버의 시간이 다른 서버보다 지속적으로 더 길다면 어떻게 된 일인지, 더 많은 계산이나 데이터베이스 또는 다른 서비스에 대한 호출이 필요한 "더 무거운" 요청이 불균형하게 해당 서버로 전송되고 있는 것입니다. 부하 분산 기술의 문제라기보다는 잘못된 가중치로 인해 불균형이 발생할 수 있으므로 가중치를 조정해 보세요.
• 클라이언트에 응답하는 데 걸리는 총 시간 - 다시 말해서, 일부 서버의 경우 지속적으로 시간이 더 길다는 것은 시간이 많이 걸리는 요청이 비례적으로 많이 발생한다는 것을 의미합니다. 그리고 다시 한번, 무게를 조절해서 문제가 해결되는지 확인해보세요.
• 오류 및 실패한 요청 – 테스트 중에 실패한 요청과 기타 오류의 수가 사이트에서 일반적인 경우보다 많지 않은지 확인해야 합니다. 그렇지 않으면 현실적인 트래픽 대신 오류 상황에 따라 결정을 내리게 됩니다. 일부 오류의 경우 서버는 요청이 성공하는 경우보다 더 빨리 응답을 보낼 수 있습니다. HTTP 응답 코드의 경우 404 (파일 아니다 설립하다), 예를 들어, 서버는 실제 파일이 존재한다면 전달할 수 있는 속도보다 훨씬 더 빠르게 오류를 반환할 가능성이 높습니다. 최소 연결 및 최소 시간 부하 분산 알고리즘을 사용하면 부하 분산 장치가 실제로 제대로 작동하지 않는 서버를 선호할 수 있습니다.

장점, 단점 및 사용 사례

이제 각 부하 분산 기술의 이점과 단점을 살펴보고, 특히 적합한 몇 가지 사용 사례를 설명하겠습니다. 대부분의 사용 사례에 대한 적합성이 높아지는 순서대로 논의하겠습니다. 간략하게 살펴보면, 우리는 최소 연결(NGINX Plus의 경우 최소 시간)이 가장 광범위한 사용 사례에 가장 적합한 선택이라고 생각합니다.

해시 및 IP 해시

해시 및 IP 해시 부하 분산 기술은 해시 값으로 캡처된 주어진 유형의 클라이언트 요청과 특정 서버 간에 고정된 연결을 생성합니다. 이것을 세션 지속성이라고 알고 있을 겁니다. 주어진 해시 값을 가진 모든 요청은 항상 동일한 서버로 이동합니다.

이러한 방법의 가장 큰 단점은 여러 서버에 동일한 양의 요청을 분산시키는 것이 보장되지 않고, 더 나아가 부하를 균등하게 분산시킨다는 것입니다. 해싱 알고리즘은 가능한 모든 해시 값의 집합을 업스트림 그룹의 각 서버마다 하나씩 "버킷"으로 균등하게 분할하지만 실제로 발생하는 요청의 해시가 균등하게 분산되는지 예측할 방법은 없습니다. 예를 들어, 10명의 클라이언트가 사이트에 접속하고 IP 해시 알고리즘이 우연히 IP 주소 중 7개의 해시를 web1 과, 1개를 web2 와, 2개를 web3 과 연관시켰다고 가정해 보겠습니다. web1 서버는 다른 서버를 합친 것보다 두 배 이상 많은 요청을 받게 됩니다.

따라서 불균형한 부하로 인한 나쁜 영향보다 세션을 유지하는 이점이 더 큰 경우 해시 또는 IP 해시를 사용하는 것이 합리적입니다. 이들은 NGINX에서 사용할 수 있는 유일한 형태의 세션 지속성입니다. NGINX Plus는 더욱 정교하고 실제 로드 밸런싱과 함께 작동하는 세 가지 다른 세션 지속성 메커니즘을 제공합니다( sticky 지시문으로 구성). 하지만 NGINX Plus를 사용하더라도 Hash 또는 IP Hash를 선택할 수 있습니다. 왜냐하면 다음과 같은 경우에는 이 세 가지 메커니즘이 작동하지 않기 때문입니다.

• 브라우저나 클라이언트 앱은 쿠키를 허용하지 않으며, 애플리케이션은 쿠키 없이 세션 지속성 메커니즘을 사용할 방법이 없습니다. IP 해시 방법을 사용하여 각 클라이언트(특히 IP 주소)를 특정 서버와 연결합니다.

• 서버 자체의 캐싱을 활용하기 위해 매번 동일한 서버에 주어진 URL에 대한 요청을 보내려고 합니다. $request_uri 변수와 Hash 메서드를 사용하면 매번 동일한 서버에서 파일을 가져옵니다.

  예를 들어, 특정 .php 파일을 제공하는 데 시간이 많이 걸리는 데이터베이스 호출이 여러 번 필요하지만, 가져온 데이터는 자주 변경되지 않으므로 캐시할 수 있다고 가정해 보겠습니다. 모든 파일 요청을 동일한 서버로 보내면 데이터베이스 호출로 인해 첫 번째 클라이언트만 긴 지연을 경험하게 됩니다. 이후의 모든 클라이언트에 대한 데이터는 캐시에서 빠르게 검색됩니다. 또 다른 장점은 단 하나의 서버만 특정 데이터 세트를 캐시하면 된다는 것입니다. 모든 서버에 동일한 데이터를 중복 캐싱하지 않아도 되므로 더 작은 캐시를 사용할 수 있습니다.

IP 해시(클라이언트 IP 주소가 키에 있는 경우 해시)가 작동하지 않는 몇 가지 경우가 있습니다.

• 예를 들어 모바일 클라이언트가 WiFi 네트워크에서 셀룰러 네트워크로 전환하는 경우처럼 세션 중에 클라이언트의 IP 주소가 변경될 수 있는 경우입니다.
• 많은 수의 클라이언트의 요청이 전방 프록시를 통과하는 경우, 프록시의 IP 주소가 모든 클라이언트에 사용되기 때문입니다.

해시는 결정적입니다(해싱 알고리즘은 항상 동일한 결과를 생성합니다). 이러한 방식에는 몇 가지 긍정적인 부작용이 있습니다. 배포된 모든 NGINX Plus 또는 NGINX 인스턴스는 정확히 동일한 방식으로 요청을 로드 밸런싱하고, 로드 밸런서를 다시 시작해도 해시-서버 매핑이 지속됩니다. (실제로는 재시작 후에 다시 계산되지만, 결과가 항상 동일하기 때문에 효과적으로 유지됩니다.)

반면, 업스트림 서버 세트를 변경하면 일반적으로 일부 매핑을 다시 계산해야 하므로 세션 지속성이 손상됩니다. 재계산된 매핑의 수를 다소 줄일 수 있습니다.

• 해시 방법의 경우 해시 지시문에 일관된 매개변수를 포함합니다. NGINX Plus는 케타마 해싱 알고리즘을 사용하는데, 이로 인해 리매핑이 줄어듭니다.

• IP 해시 방법의 경우, 업스트림 그룹에서 서버를 일시적으로 제거하기 전에 다음 예와 같이 web2 의 경우와 같이 서버 지시문에 down 매개변수를 추가합니다. 서버가 곧 서비스로 돌아올 것이라는 가정 하에 매핑은 다시 계산되지 않습니다.

  업스트림 백엔드 { ip_hash; 서버 web1; 서버 web2 다운 ; 서버 web3; }

라운드 로빈

이전에 언급했듯이 라운드 로빈은 NGINX Plus 및 NGINX의 기본 부하 분산 방법입니다. 이는 확실히 선택하기 가장 쉬운 방법입니다. 업스트림 그룹 자체 외에는 아무것도 구성할 필요가 없습니다.

일반적인 의견은 라운드 로빈이 서버와 요청의 특성으로 인해 일부 서버가 다른 서버에 비해 과부하가 걸릴 가능성이 낮을 때 가장 잘 작동한다는 것입니다. 일부 조건은 다음과 같습니다.

• 모든 서버의 용량은 거의 비슷합니다. 서버 간 차이가 서버 가중치를 통해 정확하게 표현되는 경우에는 이 요구 사항이 덜 중요합니다.
• 모든 서버는 동일한 콘텐츠를 호스팅합니다.
• 요청은 필요한 시간이나 처리 능력 면에서 매우 유사합니다. 요청 가중치에 큰 차이가 있는 경우 로드 밸런서가 빠른 속도로 많은 중량 요청을 연속해서 보내서 서버가 과부하될 수 있습니다.
• 트래픽 양이 너무 많아서 서버가 최대 용량에 가깝게 작동하는 경우가 많지 않습니다. 서버에 이미 과부하가 발생한 경우 라운드 로빈의 자동화된 요청 분배 방식으로 인해 일부 서버가 이전에 설명한 대로 과부하 상태에 빠질 가능성이 더 큽니다.

라운드 로빈은 특히 시나리오 테스트에 적합합니다. 이는 요청이 모든 서버에 동일한 수(또는 적절한 가중치가 적용된 비율)로 분산되도록 보장하기 때문입니다. 일부 다른 방법은 볼륨이 낮을 때 트래픽을 항상 균등하게 분산시키지 않아 테스트 결과가 왜곡될 수 있습니다.

분포의 균등한 특성은 캐시가 제대로 작동하고 전체 용량으로 작동하는지 여부를 보여줄 수도 있습니다. 라운드 로빈에서는 주어진 파일에 대한 요청을 동일한 서버로 보낼 방법이 없기 때문에 각 서버는 광범위한 파일(일반적으로 피어와 동일한 파일)을 제공하고 캐싱하게 되어 캐시가 채워질 가능성이 더 큽니다.

마지막으로, 균등한 초기 분포는 NGINX Plus에서 세션 지속성과 관련된 문제를 발견하는 데 도움이 됩니다( sticky 지시문으로 구성).

최소 연결 및 최소 시간

앞서 언급했듯이 최소 연결은 가장 광범위한 사용 사례, 특히 프로덕션 트래픽에 가장 적합한 부하 분산 기술입니다. 이는 고객의 일화적 증거에 의해 뒷받침됩니다. 성능이 안정적이고 예측 가능합니다.

최소 연결은 또한 서버의 용량에 따라 작업 부하를 효과적으로 분산시킵니다. 더 강력한 서버는 요청을 더 빠르게 처리하므로 특정 순간에 처리 중인 연결(또는 처리가 시작되기를 기다리는 연결)의 수가 용량이 작은 서버보다 적을 가능성이 높습니다. 최소 연결 방식은 각 요청을 현재 연결 수가 가장 적은 서버로 전송하므로 강력한 서버로 요청을 전송할 가능성이 더 높습니다. (하지만 가중치를 설정하면 요청이 훨씬 더 효율적으로 분산됩니다. 이에 대해서는 아래 서버가 동일하지 않을 때의 가중치 설정 에서 설명합니다.)

최소 시간(NGINX Plus 전용)은 최소 연결의 더 민감한 버전으로 간주할 수 있습니다. 평균 응답 시간을 포함함으로써 서버의 최근 성능 기록을 고려합니다(실제로는 지수 가중 이동 평균이므로 이전 응답 시간은 최근 응답 시간보다 평균에 미치는 영향이 적습니다).

최소 시간은 특히 업스트림 서버의 평균 응답 시간이 매우 다를 때 적합합니다. 예를 들어 재해 복구 목적으로 여러 데이터 센터에 서버가 있는 경우 Least Time은 로컬 서버로 더 많은 요청을 보내는 경향이 있습니다. 이는 로컬 서버가 더 빠르게 응답하기 때문입니다. 또 다른 사용 사례는 서버 성능이 매우 예측 불가능한 클라우드 환경입니다.

서버가 동일하지 않을 때 가중치 설정

업스트림 그룹의 서버가 서로 다른 용량을 가지고 있는 경우 서버 가중치를 설정하는 것의 중요성에 대해 여러 번 언급했습니다. 이는 라운드 로빈 로드 밸런서에 특히 중요한데, 그렇지 않으면 각 서버에 동일한 수의 요청을 보냅니다. 그 결과 덜 강력한 서버가 과부하 상태이고, 더 강력한 서버가 부분적으로 유휴 상태로 방치될 가능성이 높습니다.

가중치를 설정하려면 업스트림 블록의 하나 이상의 서버 지시문에 가중치 매개변수를 포함합니다. 기본값은 1입니다.

다양한 부하 분산 기술에 대한 가중치 설정 효과에 대해 다음과 같이 생각해 볼 수 있습니다. 설명은 개념적으로 정확하지만 NGINX Plus 코드의 구현에서는 반드시 표시된 수학 연산을 사용하지 않는다는 점에 유의하세요. 다음은 예제의 상류 그룹입니다.

업스트림 백엔드 { 서버 웹1 가중치=6;
서버 웹2 가중치=3;
서버 웹3;
}

• 라운드 로빈 - 각 서버는 가중치를 가중치 합계로 나눈 값에 해당하는 수신 요청의 백분율을 받습니다. 예를 들어, 10개의 요청 중 web1은 6개(60%)를 받고, web2는 3개(30%)를 받고, web3은 1개(10%)를 받습니다.

• 해시 및 IP 해시 - 가중치가 없으면 해싱 알고리즘은 모든 가능한 해시 값의 집합을 업스트림 그룹의 각 서버마다 하나씩 "버킷"으로 균등하게 나눕니다. 가중치를 사용하는 경우 가중치를 합산하고, 가능한 해시 집합을 해당 개수의 버킷으로 나누고, 각 서버를 가중치와 동일한 개수의 버킷에 연결합니다.

  우리의 예에서는 10개의 버킷이 있고, 각 버킷에는 가능한 해시의 10%가 들어 있습니다. 6개의 버킷(가능한 해시의 60%)은 web1 과 연관되고, 3개의 버킷(30%)은 web2 와 연관되고, 1개의 버킷(10%)은 web3 과 연관됩니다.

• 최소 연결 및 최소 시간 – 우리는 이전에 가중치가 없더라도 이러한 알고리즘이 용량에 따라 서버 간에 작업 부하를 분산하는 데 매우 효과적이라고 언급했습니다. 이런 측면에서 가중치를 설정하면 성과가 더욱 향상됩니다.

  최소 연결 및 최소 시간은 각 요청을 가장 낮은 "점수"(각각 연결 수 또는 연결과 시간의 수학적 조합)를 가진 서버로 전송한다는 점을 기억하세요. 가중치를 할당하면 로드 밸런서는 각 서버의 점수를 가중치로 나누고 다시 가장 낮은 값을 가진 서버로 요청을 보냅니다.

  다음은 샘플 가중치와 표시된 활성 연결 수에 따른 최소 연결의 예입니다. web1 의 점수인 100은 가장 낮으며, 연결 수가 600개로 web2 의 1.5배, web3 의 4배 이상이지만 요청을 받습니다.

  • web1 – 600개 활성 연결 ÷ 6 = 100
  • web2 – 400개 활성 연결 ÷ 3 = 133
  • web3 – 125개 활성 연결 ÷ 1 = 125

요약

NGINX Plus와 NGINX에서 사용 가능한 부하 분산 기술의 장단점을 검토한 결과, 가장 광범위한 사용 사례에는 최소 연결(NGINX Plus의 경우 최소 시간)이 가장 적합하다고 생각합니다. 하지만 트래픽과 서버 특성의 고유한 조합으로 인해 다른 방법이 더 나을 수 있으므로 배포 시 여러 방법을 테스트하는 것이 중요합니다.

NGINX Plus 로드 밸런싱을 직접 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요.

다양한 사용 사례에서 로드 밸런싱을 사용한 여러분의 경험을 들려주시기 바랍니다. 아래의 댓글 섹션에 추가해 주세요.