NGINX Load Balancing 사용 사례

이 포스트에서는 NGINX Load Balancing 기술에 중점을 두고 다양한 사용 사례에 적합한 방법을 선택하는 방법에 대한 조언을 제공합니다. NGINX는 네 가지 Load Balancing 기술(Round Robin, Hash, IP Hash, Least Connections)을 제공하며, NGINX Plus는 한 가지(Least Time)를 더 제공합니다. HTTP 트래픽에 대한 모든 메서드는 IP Hash를 제외한 TCP(NGINX Plus 릴리스 9 이상에서는 UDP)에서도 사용할 수 있습니다.

Load Balancing은 애플리케이션 성능 향상, 대규모 애플리케이션 제공, 컨테이너 및 Microservices 배포를 위한 기본 도구입니다.

Note: NGINX Plus R16 및 NGINX Open Source 1.15.1부터는 추가 Load Balancing 알고리즘으로 두 가지 선택이 있는 Random이 추가되었습니다.

목차

1. Load Balancing 기술 살펴보기
1-1. Round Robin
1-2. Hash
1-3. IP Hash
1-4. Least Connections
1-5. Least Time
2. Load Balancing 기술 선택
2-1. 메서드 비교를 위한 테스트 실행
3. 장단점 및 사용 사례
3-1. Hash 및 IP Hash
3-2. Round Robin
3-3. Least Connections 및 Least Time
4. 서버가 동일하지 않은 경우 가중치 설정하기
5. 요약

1. NGINX Load Balancing 기술 살펴보기

이해를 돕기 위해 http 컨텍스트에서 구성하는 HTTP Load Balancing에 초점을 맞추겠습니다. 대신 TCP Load Balancing은 stream 컨텍스트에서 구성됩니다(NGINX Plus 릴리스 9 이상에서는 UDP Load Balancing과 마찬가지로). HTTP 및 TCP/UDP Load Balancer는 기능이 동등하지만 프로토콜 간의 고유한 차이로 인해 사용 가능한 지시문과 매개변수가 다소 다릅니다. 자세한 내용은 HTTP 및 TCP/UDP용 Upstream 모듈에 대한 설명서를 참조하세요.

선택적 매개변수나 보조 기능 없이 기본 형태로 보여드리는 두 가지 구성 블록으로 Load Balancing을 활성화할 수 있습니다.

server 블록은 사용자가 정의한 특성을 가진 트래픽을 수신 대기하는 가상 서버를 정의하고 이를 지정된 Upstream 서버 그룹에 Proxy합니다. 이 예제에서 가상 서버는 기본 포트(80)에서 www.example.com로 전송되는 HTTP 트래픽을 수신 대기하고 이를 backend라는 Upstream 서버 그룹에 Proxy합니다. 이 블록은 모든 예제에서 동일합니다.

server {
    server_name www.example.com;

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

(NGINX Plus와 NGINX는 FastCGI, memcached, SCGI 및 uwsgi Backend 서버의 Load Balancing도 수행할 수 있습니다. proxy_pass를 적절한 지시문 – fastcgi_pass, memcached_pass, scgi_pass 또는 uwsgi_pass으로 대체합니다.)

upstream 블록은 Upstream 그룹의 이름을 지정하고 호스트명, IP 주소 또는 UNIX 도메인 소켓 경로로 식별되는 해당 그룹에 속하는 서버를 나열합니다. 이 예제에서 backend라는 Upstream 그룹에는 web1, web2, web3의 세 서버가 포함됩니다.

upstream 블록은 Load Balancing 기술을 지정하는 곳이므로 다음 섹션에서 이 부분을 중점적으로 다룰 것입니다. 예를 들어, 다음은 기본 방법인 Round Robin에 대한 블록입니다:

upstream backend {
    server web1;
    server web2;
    server web3;
}

1-1. Round Robin (NGINX Load Balancing)

Round Robin은 NGINX Plus와 NGINX 모두의 기본 Load Balancing 기술입니다. Load Balancer는 Upstream 서버 목록을 순차적으로 실행하여 다음 연결 요청을 각 서버에 차례로 할당합니다.

backend upstream 그룹의 다음 샘플 구성이 주어지면 Load Balancer는 처음 세 개의 연결 요청을 web1, web2, web3에 순서대로 보내고, 네 번째는 web1에, 다섯 번째는 web2에 보내는 식으로 연결 요청을 전송합니다.

upstream backend {
    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

1-2. Hash (NGINX Load Balancing)

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

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

upstream backend {
    hash $scheme$request_uri;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

1-3. IP Hash (NGINX Load Balancing)

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

upstream backend {
    ip_hash;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

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

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

hash $remote_addr;

1-4. Least Connections (NGINX Load Balancing)

Least Connections 메서드를 사용하면 Load Balancer가 각 서버에 대한 현재 활성화된 연결 수를 비교하여 연결이 가장 적은 서버로 요청을 보냅니다. least_conn 지시문을 사용하여 구성합니다.

upstream backend {
    least_conn;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

1-5. Least Time

Least Time 메서드(NGINX Plus에서만 사용 가능)를 사용하면 Load Balancer가 각 서버에 대해 현재 활성화된 연결 수와 과거 요청에 대한 가중 평균 응답 시간이라는 두 가지 지표를 산술적으로 계산하여 가장 낮은 값을 가진 서버로 요청을 보냅니다.

least_time 지시문의 매개변수 선택에 따라 응답 헤더를 수신하는 시간(header)과 전체 응답을 수신하는 시간(last_byte) 중 어떤 응답 시간을 추적할지 결정됩니다.

upstream backend {
    least_time (header | last_byte);

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}
  • stream 컨텍스트에서 TCP 및 UDP Load Balancing의 경우, 이러한 매개변수를 least_time 지시문에 사용하여 세 가지 유형의 응답 시간 중에서 선택할 수 있습니다.
    • connect – Upstream 서버에 연결하는 시간
    • first_byte – 응답 데이터의 첫 Byte 수신 시간
    • last_byte – 응답 데이터의 마지막 Byte 수신 시간
  • HTTP 및 TCP/UDP 트래픽 모두에 대해 NGINX Plus R12 이상에서는 각 지표에 불완전한 연결을 포함하도록 내부 매개변수를 추가합니다(이전 릴리스에서는 이러한 연결이 기본적으로 포함됩니다).

2. NGINX Load Balancing 기술 선택

그렇다면 어떠한 Load Balancing 기술이 웹사이트나 애플리케이션에 가장 적합한지 어떻게 알 수 있을까요?

트래픽 패턴은 사이트마다 매우 다양합니다. – 그리고 하루 중 다른 시간대의 단일 사이트 내에서도 Load Balancing 기술의 선택 기준을 단일 특성(예: 트래픽 급증 대 안정적, 연결 시간이 짧거나 길거나 등)에 두는 것은 합리적이지 않습니다. 하지만 고려해야 할 선택의 범위를 좁히는 데 도움이 되도록 각 방법의 장단점을 고려하겠습니다.

2-1. 메서드 비교를 위한 테스트 실행

Load Balancing 방법 중 어떤 방식을 고려하든 트래픽에 가장 적합한 방법을 테스트해 보는 것이 좋습니다. “최선”이란 일반적으로 고객에게 응답을 제공하는 데 걸리는 시간이 가장 짧다는 의미이지만 다른 기준이 있을 수 있습니다.

애플리케이션 성능 관리 도구는 이러한 종류의 테스트에 매우 유용합니다. Upstream 그룹의 각 서버에 대한 그래프가 포함된 사용자 정의 화면을 생성하여 테스트 중에 값이 변경될 때 실시간으로 비교할 수 있습니다. AppDynamics, Datadog, Dynatrace, New Relic 등 여러 APM에서 NGINX Plus 및 NGINX용 사용자 정의 플러그인을 제공합니다.

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

테스트 중에 확인해야 할 몇 가지 지표는 다음과 같습니다.

  • CPU 및 메모리 로드 – CPU와 메모리 모두에 대해 사용된 총 용량의 비율을 확인하세요. 모든 서버가 동일하게 로드되지 않는다면 트래픽이 효율적으로 분산되지 않는 것입니다.
  • 서버 응답 시간 – 일부 서버의 시간이 다른 서버에 비해 지속적으로 더 길다면, 더 많은 계산이나 데이터베이스 또는 기타 서비스에 대한 호출이 필요한 ‘무거운’ 요청이 불균형하게 해당 서버로 전달되고 있는 것입니다. Load Balancing 기술의 문제라기보다는 잘못된 가중치로 인해 불균형이 발생할 수 있으므로 가중치를 조정해 보세요.
  • 클라이언트에 응답하는 데 걸린 총 시간 – 다시 말하지만, 일부 서버의 시간이 지속적으로 길다는 것은 시간이 많이 걸리는 요청이 불균형적으로 많이 발생하고 있음을 의미합니다. 다시 한번 가중치를 조정하여 문제가 해결되는지 확인할 수 있습니다.
  • 오류 및 요청 실패 – 테스트 중 실패한 요청 및 기타 오류의 수가 사이트의 평소보다 많지 않은지 확인해야 합니다. 그렇지 않으면 실제 트래픽이 아닌 오류 조건을 기준으로 결정을 내리게 됩니다. 일부 오류의 경우 서버가 요청이 성공할 때보다 더 빨리 응답을 보낼 수 있습니다. 예를 들어 HTTP 응답 코드 404(파일을 찾을 수 없음)의 경우 서버는 실제 파일이 존재할 때보다 훨씬 더 빨리 오류를 반환할 수 있습니다. Least Connections 및 Least Time Load Balancing 알고리즘을 사용하면 Load Balancer가 실제로 제대로 작동하지 않는 서버를 선호하도록 유도할 수 있습니다.

3. 장단점 및 사용 사례

이제 각 Load Balancing 기술의 장단점을 살펴보고 해당 기술이 특히 적합한 몇 가지 사용 사례에 대해 설명해 보겠습니다. 대부분의 사용 사례에 적합성이 높은 순서대로 설명하겠습니다. 간단히 미리 말씀드리자면, 가장 광범위한 사용 사례에 가장 적합한 선택은 Least Connections(NGINX Plus의 경우, Least Time)라고 생각합니다.

3-1. Hash 및 IP Hash

Hash 및 IP Hash Load Balancing 기술은 특정 유형의 클라이언트 요청(해시 값에 캡처됨)과 특정 서버 간에 고정된 연결을 생성합니다. 이를 세션 지속성이라고 할 수 있는데, 특정 해시 값을 가진 모든 요청은 항상 동일한 서버로 이동합니다.

이러한 방법의 가장 큰 단점은 부하를 균등하게 분산하는 것은 물론 서버 간에 요청을 동일한 수로 분배한다는 보장이 없다는 것입니다. 해시 알고리즘은 가능한 모든 해시 값 집합을 Upstream 그룹의 각 서버마다 하나씩 “Bucket”으로 균등하게 나누지만, 실제로 발생하는 요청에 균등하게 분산된 해시가 있는지 예측할 수 있는 방법은 없습니다. 예를 들어 10개의 클라이언트가 사이트에 접속하고 있는데 IP Hash 알고리즘이 IP 주소 중 7개에 대한 해시를 web1, 1개는 web2, 2개는 web3에 연결한다고 가정해 보겠습니다. 결국 web1 서버는 다른 서버를 합친 것보다 두 배 이상 많은 요청을 수신하게 됩니다.

The Hash and IP Hash load-balancing techniques can result in uneven distribution of load

따라서 세션 유지의 이점이 불균형한 부하로 인해 발생할 수 있는 나쁜 영향보다 클 때는 Hash 또는 IP Hash를 사용하는 것이 합리적입니다. 이 두 가지는 NGINX에서 사용할 수 있는 유일한 세션 지속성 형태입니다. NGINX Plus는 더 정교하고 실제 Load Balancing과 함께 작동하는 세 가지 다른 세션 지속성 메커니즘을 제공합니다(sticky 지시문을 사용하여 구성). 그러나 다음과 같은 경우에는 세 가지 메커니즘이 작동하지 않으므로 NGINX Plus를 사용하더라도 Hash 또는 IP Hash를 선택할 수 있습니다.

  • 브라우저 또는 클라이언트 애플리케이션은 쿠키를 허용하지 않으며, 애플리케이션은 쿠키 없이 세션 지속성 메커니즘을 사용할 수 있는 방법이 없습니다. IP Hash 메서드를 사용하여 각 클라이언트(특히 IP 주소)를 특정 서버와 연결합니다.
  • 서버 자체의 캐싱을 활용하기 위해 특정 URL에 대한 요청을 매번 동일한 서버로 보내려고 합니다. 매번 동일한 서버에서 파일을 가져오려면 Hash 메서드와 $request_uri 변수를 함께 사용하면 됩니다.
    예를 들어 특정 .php 파일을 제공하는 데 시간이 많이 걸리는 데이터베이스 호출이 여러 번 필요하지만 가져온 데이터는 자주 변경되지 않으므로 캐시가 가능하다고 가정해 보겠습니다. 파일에 대한 모든 요청을 동일한 서버로 보내면 첫 번째 클라이언트만 데이터베이스 호출로 인해 긴 지연 시간을 경험하게 됩니다. 이후의 모든 클라이언트는 캐시에서 데이터를 빠르게 검색할 수 있습니다. 또 다른 장점은 하나의 서버만 특정 데이터 세트를 캐시하면 된다는 것입니다. 모든 서버에서 동일한 데이터를 중복 캐싱하지 않으므로 더 소규모의 캐시를 사용할 수 있습니다.

IP Hash 및 클라이언트 IP 주소가 Key에 있는 경우의 Hash가 작동하지 않는 경우가 몇 가지 있습니다.

  • 모바일 클라이언트가 WiFi 네트워크에서 셀룰러 네트워크로 전환하는 경우와 같이 세션 중에 클라이언트의 IP 주소가 변경될 수 있습니다.
  • 많은 클라이언트의 요청이 Forward Proxy를 통해 전달되는 경우 Proxy의 IP 주소가 모든 클라이언트에 사용되기 때문입니다.

해시는 결정론적입니다(해싱 알고리즘은 매번 동일한 결과를 산출합니다). 이는 몇 가지 긍정적인 측면이 있습니다. 배포에 포함된 모든 NGINX Plus 또는 NGINX 인스턴스가 정확히 동일한 방식으로 요청을 분산하고, Load Balancer를 다시 시작할 때에도 해시-서버 매핑이 지속된다는 점입니다. (실제로는 재시작 후 다시 계산되지만 결과가 항상 동일하기 때문에 사실상 지속됩니다.)

반면에 Upstream 서버 집합을 변경하면 일반적으로 적어도 일부 매핑을 다시 계산해야 하므로 세션 지속성이 깨집니다. 다시 계산되는 매핑의 수를 다소 줄일 수 있습니다:

  • Hash 메서드의 경우, hash 지시문에 일관된 매개변수를 포함하세요. NGINX Plus는 ketama 해싱 알고리즘을 사용하므로 중복 매핑이 적습니다.
  • IP Hash 메서드의 경우, Upstream 그룹에서 서버를 일시적으로 제거하기 전에 다음 예제의 web2와 같이 down 매개변수를 server 지시문에 추가합니다. 서버가 곧 서비스를 재개할 것이라는 가정 하에 매핑을 다시 계산하지 않습니다.
upstream backend {
    ip_hash;

    server web1;
    server web2 down;
    server web3;
}

3-2. Round Robin

앞서 언급했듯이 Round Robin은 NGINX Plus 및 NGINX의 기본 Load Balancing 방법입니다. 따라서 Upstream 그룹 자체 외에는 아무것도 구성할 필요가 없으므로 가장 쉽게 선택할 수 있는 방법입니다.

일반적으로 Round Robin은 서버 및 요청의 특성으로 인해 일부 서버가 다른 서버에 비해 과부하가 걸릴 가능성이 낮을 때 가장 잘 작동한다는 데 의견이 일치합니다. 몇 가지 조건은 다음과 같습니다.

  • 모든 서버의 용량은 거의 동일합니다. 서버 간 차이가 서버 가중치로 정확하게 표현되는 경우 이 요구 사항은 덜 중요합니다.
  • 모든 서버는 동일한 콘텐츠를 호스팅합니다.
  • 요청에 필요한 시간이나 처리 능력은 거의 비슷합니다. 요청 가중치의 차이가 큰 경우 Load Balancer가 무거운 요청을 연속적으로 많이 보내게 되어 서버에 과부하가 걸릴 수 있습니다.
  • 트래픽 양이 서버를 거의 최대 용량에 가깝게 밀어 넣을 만큼 충분히 많지 않습니다. 서버가 이미 과부하 상태인 경우 Round Robin의 자동화된 요청 분배로 인해 앞서 설명한 대로 일부 서버가 과부하 상태로 “가장자리로” 밀려날 가능성이 더 높습니다.

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

Round Robin에서는 특정 파일에 대한 요청을 동일한 서버에 보낼 방법이 없기 때문에 모든 서버가 광범위한 파일을 서비스하고 캐싱하게 되어 캐시가 가득 찰 가능성이 높습니다.

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

3-3. Least Connections 및 Least Time

위에서 언급했듯이 Least Connections는 가장 광범위한 사용 사례, 특히 Production 트래픽에 가장 적합한 Load Balancing 기술입니다. 이는 고객들의 사례를 통해 입증되었습니다. 성능이 안정적이고 예측 가능합니다.

또한 Least Connections는 서버의 용량에 따라 Workload를 효과적으로 분산합니다. 더 강력한 서버는 요청을 더 빨리 처리하므로 특정 순간에 용량이 적은 서버보다 처리 중인(또는 처리 시작을 기다리는) 연결 수가 더 적을 가능성이 높습니다. Least Connections는 현재 연결 수가 가장 적은 서버로 각 요청을 보내므로 강력한 서버로 요청을 보낼 가능성이 더 높습니다. (그러나 가중치를 설정하면 아래의 서버가 동일하지 않을 때 가중치 설정에 설명된 대로 요청을 훨씬 더 효율적으로 분배할 수 있습니다.)

Least Time(NGINX Plus만 해당)은 Least Connections의 더 민감한 버전이라고 생각할 수 있습니다. 평균 응답 시간을 포함함으로써 서버의 최근 성능 기록을 고려합니다(실제로는 기하급수적으로 가중치가 부여된 이동 평균이므로 이전 응답 시간이 최근 응답 시간보다 평균에 덜 영향을 미칩니다).

Least Time은 Upstream 서버의 평균 응답 시간이 매우 다른 경우에 특히 적합합니다. 예를 들어 재해 복구를 위해 서로 다른 데이터 센터에 서버가 있는 경우, 응답 속도가 더 빠른 로컬 서버에 더 많은 요청을 보내는 경향이 있습니다. 또 다른 사용 사례는 서버 성능을 예측할 수 없는 클라우드 환경입니다.

Least Time is one of the load-balancing techniques in NGINX Plus

4. 서버가 동일하지 않은 경우 가중치 설정하기

Upstream 그룹의 서버 용량이 서로 다른 경우 서버 가중치 설정의 중요성에 대해 여러 번 언급했습니다. 특히 각 서버에 동일한 수의 요청을 전송하는 Round Robin Load Balancer의 경우 이 설정이 중요합니다. 이렇게 하면 성능이 낮은 서버는 과부하가 걸리고 성능이 높은 서버는 부분적으로 유휴 상태가 될 수 있습니다.

가중치를 설정하려면 upstream 블록의 하나 이상의 server 지시문에 weight 매개변수를 포함하세요. 기본값은 1입니다.

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

upstream backend {
    server web1 weight=6;
    server web2 weight=3;
    server web3;
}
  • Round Robin – 각 서버는 들어오는 요청의 가중치를 가중치의 합으로 나눈 값과 동일한 비율을 가져옵니다. 이 예제에서는 요청 10건 중 web1이 6건(60%), web2가 3건(30%), web3이 1건(10%)을 받습니다.
  • Hash 및 IP Hash – 가중치가 없는 경우 해시 알고리즘은 가능한 모든 해시 값 집합을 Upstream 그룹의 각 서버에 대해 하나씩 “Bucket”으로 균등하게 나눈다는 점을 기억하세요. 가중치를 사용하면 대신 가중치를 합산하여 가능한 해시 집합을 해당 수의 Bucket으로 나누고 각 서버를 가중치에 해당하는 Bucket 수와 연결합니다.
    이 예제에서는 Bucket 10개가 있으며, 각 Bucket에는 사용 가능한 해시의 10%가 들어 있습니다. 6개 Bucket(사용 가능한 해시의 60%)은 web1, 3개 버킷(30%)은 web2, 1개 버킷(10%)은 web3에 연결됩니다.
  • Least Connections 및 Least Time – 앞서 이러한 알고리즘은 가중치가 없어도 서버의 용량에 따라 Workload를 분산하는 데 매우 효과적이라고 언급했습니다. 가중치를 설정하면 이와 관련하여 성능이 훨씬 더 향상됩니다.
    Least Connections와 Least Time은 각 요청을 가장 낮은 “점수”를 가진 서버로 보낸다는 점을 기억하세요. 가중치를 할당하면 Load Balancer는 각 서버의 점수를 가중치로 나눈 후 다시 가장 낮은 값을 가진 서버로 요청을 보냅니다.
    다음은 샘플 가중치와 표시된 활성화된 연결 수를 사용한 Least Connections의 예입니다. web1의 점수는 100으로 가장 낮으며 연결 수가 600으로 web2의 1.5배, web3의 4배 이상인데도 요청을 받습니다.
    • web1 – 활성화된 연결 600개 ÷ 6 = 100
    • web2 – 활성화된 연결 400개 ÷ 3 = 133
    • web3 – 활성화된 연결 125개 ÷ 1 = 125

5. NGINX Load Balancing 요약

NGINX Plus와 NGINX에서 사용할 수 있는 Load Balancing 기술의 장단점을 검토한 결과, 가장 광범위한 사용 사례에 가장 적합한 방법은 Least Connections(및 NGINX Plus의 경우, Least Time)라고 판단했습니다. 하지만 트래픽 및 서버 특성의 고유한 조합에 따라 다른 방법이 더 적합할 수 있으므로 배포 시 여러 가지 방법을 테스트하는 것이 중요합니다.