NGINX Plus 부하 분산 기법 선택하기

Tony Mauro

웹사이트와 앱의 가용성과 안정성을 극대화하기 위해 NGINX Plus와 NGINX Open Source를 사용하여 부하를 분산하는 방법에 대해 많은 글을 작성했습니다. 부하 분산은 앱 성능 향상, 대규모 앱 제공, 그리고 컨테이너 및 마이크로서비스 배포를 위한 핵심 도구입니다.

이전에도 NGINX Plus를 데이터 센터에(기존 애플리케이션 전송 컨트롤러와 함께 사용할 수도 있음), 컨테이너에 배포하는 방법과 Amazon Web Services(AWS), Google Cloud Platform, Microsoft Azure 등의 클라우드 환경에 배포하는 방법을 설명한 바 있습니다.

이 게시물에서는 NGINX Plus와 NGINX의 부하 분산 기법(부하 분산 방식 또는 알고리즘이라고도 함)을 중점적으로 살펴보고, 다양한 사용 사례에 적합한 방식을 선택하는 방법에 관한 몇 가지 조언을 제공합니다. NGINX는 네 가지 부하 분산 기법(라운드 로빈, 해시, IP 해시, 최소 연결)을 제공하며, NGINX Plus에는 한 가지 방식(최소 시간)이 더 추가됩니다. HTTP 트래픽에 사용되는 모든 방식은 IP 해시를 제외하고 TCP에도 사용할 수 있으며, NGINX Plus 릴리스 9 이상에서는 UDP에도 사용할 수 있습니다.

[편집자 – NGINX Plus R16 및 NGINX Open Source 1.15.1에서는 추가 로드 밸런싱 알고리즘으로 두 가지 선택지를 사용하는 무작위 방식을 도입했습니다. 자세한 내용은 블로그의 NGINX와 ‘두 가지 선택지의 힘’ 로드 밸런싱 알고리즘을 참조하세요.]

부하 분산 기법 살펴보기

로드 밸런싱 구성의 기본 사항은 이미 알고 계신다고 가정하겠습니다. 다시 살펴보고 싶다면 다음 자료를 참고하세요:

• 전체 개요는 NGINX Plus 관리 가이드의 문서에서 확인할 수 있습니다.
• 고성능 부하 분산에서는 부하 분산 방식의 효율성을 한층 더 높일 수 있는 NGINX Plus의 향상된 기능을 자세히 설명하는 자료를 확인할 수 있습니다.
• NGINX 및 NGINX Plus를 사용한 부하 분산, 1부 및 2부에서는 간단한 리버스 프록시를 NGINX Plus의 향상된 기능을 활용한 종합적인 부하 분산 솔루션으로 구축하는 과정을 단계별로 안내합니다.
• The 로드 밸런싱 솔루션 페이지에서는 전자책, 웨비나, 백서 등 다양한 리소스를 확인할 수 있습니다.

간단히 설명하기 위해 여기서는 http 컨텍스트에서 구성하는 HTTP 부하 분산에 중점을 두겠습니다. TCP 부하 분산은 대신 stream 컨텍스트에서 구성합니다(NGINX Plus 릴리스 9 이상에서는 UDP 부하 분산도 마찬가지입니다). HTTP 및 TCP/UDP 부하 분산기는 기능 면에서는 동등하지만, 프로토콜 간의 본질적인 차이로 인해 사용 가능한 지시문과 매개변수에는 다소 차이가 있습니다. 자세한 내용은 HTTP 및 TCP/UDP용 Upstream 모듈 문서를 참조하세요.

로드 밸런싱은 두 개의 구성 블록을 사용하여 활성화합니다. 여기서는 선택적 매개변수나 부가 기능을 제외한 기본 형태로 살펴보겠습니다:

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

server {    server_name www.example.com;

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

• (NGINX Plus와 NGINX는 FastCGI, memcached, SCGI 및 uwsgi 백엔드 서버의 부하도 분산할 수 있습니다. proxy_pass를 적절한 지시어인 fastcgi_pass, memcached_pass, scgi_pass 또는 uwsgi_pass로 바꾸십시오.)
• The upstream 블록은 업스트림 그룹의 이름을 지정하고, 호스트 이름, IP 주소 또는 UNIX 도메인 소켓 경로로 식별되는 소속 서버를 나열합니다. 이 예시에서 backend라는 업스트림 그룹에는 web1, web2, web3의 세 서버가 포함됩니다. upstream 블록에서는 부하 분산 기법을 지정하며, 다음 섹션에서 이를 중점적으로 설명합니다. 예를 들어 기본 방식인 라운드 로빈의 블록은 다음과 같습니다.

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

라운드 로빈

라운드 로빈은 NGINX Plus와 NGINX 모두에서 사용하는 기본 부하 분산 방식입니다. 부하 분산기는 업스트림 서버 목록을 순서대로 순회하며, 각 서버에 다음 연결 요청을 차례로 할당합니다.

다음과 같이 backend 업스트림 그룹을 구성한 경우, 로드 밸런서는 처음 세 개의 연결 요청을 순서대로 web1, web2, web3에 보내고, 네 번째 요청은 web1에, 다섯 번째 요청은 web2에 보내는 식으로 계속 반복합니다.

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

server {
    server_name www.example.com;

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

해시

해시 방식에서는 각 요청에 대해 로드 밸런서가 사용자가 지정한 텍스트와 NGIN 변수의 조합을 기반으로 해시를 계산하고, 해당 해시를 서버 중 하나와 연결합니다. 동일한 해시를 가진 모든 요청을 해당 서버로 전송하므로, 이 방식은 기본적인 형태의 세션 지속성을 제공합니다.

다음 예제에서 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;
    }
}

IP 해시

IP 해시(HTTP에서만 사용 가능)는 해시가 클라이언트의 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 주소가 있으면 전체 주소를 기준으로 해시가 생성됩니다. IPv4 주소가 있으면 주소의 처음 세 옥텟만을 기준으로 해시가 생성됩니다. 이는 서브네트워크(/24) 범위에서 IP 주소를 동적으로 할당받는 ISP 클라이언트에 최적화하기 위한 것입니다. 재부팅하거나 다시 연결하면 클라이언트의 주소가 /24 네트워크 범위 내의 다른 주소로 변경되는 경우가 많지만, 연결은 여전히 동일한 클라이언트를 나타내므로 서버 매핑을 변경할 필요가 없습니다.

하지만 사이트 트래픽의 대부분이 동일한 /24 네트워크의 클라이언트에서 발생한다면, 모든 클라이언트가 동일한 서버에 매핑되므로 IP Hash를 사용하는 것은 적절하지 않습니다. 이 경우(또는 다른 이유로 네 개 옥텟을 모두 기준으로 해시하려는 경우)에는 대신 $remote_addr 변수를 사용하는 Hash 방식을 사용하세요.

hash $remote_addr;

최소 연결

최소 연결 방식에서는 로드 밸런서가 각 서버에 현재 연결된 활성 연결 수를 비교한 후, 연결 수가 가장 적은 서버로 요청을 전송합니다. 이 방식은 least_conn 지시어로 설정합니다.

upstream backend {
    least_conn;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

최소 시간

최소 시간(Least Time) 방식(NGINX Plus에서만 사용 가능)에서는 로드 밸런서가 각 서버의 현재 활성 연결 수와 이전 요청에 대한 가중 평균 응답 시간이라는 두 가지 지표를 수학적으로 결합한 후, 그 값이 가장 낮은 서버로 요청을 전송합니다.

Your choice of parameter on the 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;
    }
}

참고:

• TCP 및 UDP 부하 분산의 경우(stream 컨텍스트에서) 다음 매개변수를 least_time 지시문에 지정하여 세 가지 응답 시간 유형 중 하나를 선택할 수 있습니다:
  • connect – 업스트림 서버에 연결하는 데 걸리는 시간
  • first_byte – 응답 데이터의 첫 번째 바이트를 수신하는 데 걸리는 시간
  • last_byte – 응답 데이터의 마지막 바이트를 수신하는 데 걸리는 시간
• HTTP 및 TCP/UDP 트래픽 모두에서 NGINX Plus R12 이상을 사용하는 경우, 각 메트릭에 완료되지 않은 연결을 포함하려면 inflight 매개변수를 추가합니다. 이전 릴리스에서는 이러한 연결이 기본적으로 포함됩니다.

부하 분산 기법 선택

그렇다면 어떤 부하 분산 기법이 웹사이트나 앱에 가장 적합한지 어떻게 알 수 있을까요?

트래픽 패턴은 사이트마다 크게 다르고, 심지어 같은 사이트에서도 시간대에 따라 달라지므로 단일 특성(예: 폭주형 트래픽과 일정한 트래픽, 단기 연결과 장기 연결 등)만을 기준으로 부하 분산 기법을 선택하는 것은 적절하지 않습니다. 그렇지만 고려할 선택지의 범위를 좁히는 데 도움이 되도록 각 방식의 장단점을 살펴보겠습니다.

방법 비교를 위한 테스트 실행

어떤 부하 분산 방식들을 고려하든, 실제로 테스트하여 트래픽에 가장 적합한 방식을 확인하는 것이 좋습니다. 일반적으로 “가장 적합하다”는 것은 클라이언트에 응답을 전달하는 데 걸리는 시간이 가장 짧다는 의미이지만, 다른 기준을 적용할 수도 있습니다.

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

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

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

• CPU 및 메모리 부하 – CPU와 메모리 각각에 대해 전체 용량 중 사용 중인 비율을 확인합니다. 모든 서버의 부하가 균등하지 않다면 트래픽이 효율적으로 분산되고 있지 않은 것입니다.
• 서버 응답 시간 – 일부 서버의 응답 시간이 다른 서버보다 지속적으로 길다면, 더 많은 연산이나 데이터베이스 또는 기타 서비스 호출이 필요한 ‘무거운’ 요청이 해당 서버로 불균형하게 전달되고 있는 것입니다. 이러한 불균형은 부하 분산 기법의 문제가 아니라 잘못된 가중치로 인해 발생할 수 있으므로 가중치를 조정해 보세요.
• 클라이언트에 응답하는 데 걸리는 총 시간 – 마찬가지로 일부 서버의 응답 시간이 지속적으로 더 길다면, 처리 시간이 오래 걸리는 요청이 해당 서버에 지나치게 많이 할당되고 있다는 의미일 수 있습니다. 이 경우에도 가중치를 조정하여 문제가 해결되는지 확인해 볼 수 있습니다.
• 오류 및 실패한 요청 – 테스트 중 발생한 실패한 요청과 기타 오류의 수가 사이트에서 평소 발생하는 수준보다 많지 않은지 확인해야 합니다. 그렇지 않으면 실제 트래픽이 아닌 오류 상황을 바탕으로 결정을 내리게 됩니다. 일부 오류의 경우 서버는 요청이 성공했을 때보다 더 빠르게 응답할 수 있습니다. 예를 들어 HTTP 응답 코드 404 (파일 찾을 수 없음)의 경우, 서버는 해당 파일이 실제로 존재할 때 이를 전송하는 데 걸리는 시간보다 훨씬 빠르게 오류를 반환할 가능성이 큽니다. 최소 연결 및 최소 시간 부하 분산 알고리즘을 사용하면, 이로 인해 부하 분산 장치가 실제로는 제대로 작동하지 않는 서버를 선호하게 될 수 있습니다.

장단점 및 사용 사례

이제 각 부하 분산 기법의 장단점을 살펴보고, 각 기법이 특히 적합한 몇 가지 사용 사례를 설명하겠습니다. 대부분의 사용 사례에 대한 적합성이 높아지는 순서대로 살펴보겠습니다. 먼저 간단히 말씀드리면, 가장 광범위한 사용 사례에 가장 적합한 선택은 최소 연결(Least Connections) 방식이며, NGINX Plus의 경우 최소 시간(Least Time) 방식도 이에 해당합니다.

해시 및 IP 해시

해시 및 IP 해시 부하 분산 기법은 특정 유형의 클라이언트 요청(해시 값으로 표현됨)을 특정 서버에 고정적으로 연결합니다. 이는 세션 지속성이라고도 하며, 동일한 해시 값을 가진 모든 요청은 항상 같은 서버로 전달됩니다.

이러한 방식의 가장 큰 단점은 서버 간에 요청 수를 균등하게 분산한다고 보장할 수 없으며, 부하를 고르게 분산하는 것은 더더욱 보장할 수 없다는 점입니다. 해싱 알고리즘은 가능한 모든 해시 값의 집합을 업스트림 그룹의 각 서버에 하나씩 할당되는 “버킷”으로 균등하게 나누지만, 실제로 발생하는 요청의 해시가 고르게 분포할지는 예측할 수 없습니다. 예를 들어 10개의 클라이언트가 사이트에 액세스하고 있으며, IP Hash 알고리즘이 우연히 7개 IP 주소의 해시를 web1에, 1개를 web2에, 2개를 web3에 연결한다고 가정해 보겠습니다. 그러면 web1 서버는 다른 서버들이 받는 요청을 모두 합친 것보다 두 배 이상 많은 요청을 받게 됩니다.

따라서 세션 유지의 이점이 불균형한 부하로 인해 발생할 수 있는 부정적인 영향보다 크다면 Hash 또는 IP Hash를 사용하는 것이 좋습니다. 이 두 방식은 NGINX에서 사용할 수 있는 유일한 세션 지속성 방식입니다. NGINX Plus는 실제 부하 분산과 함께 작동하는 더욱 정교한 세 가지 세션 지속성 메커니즘을 추가로 제공합니다(이러한 메커니즘은 sticky 지시어로 구성합니다). 하지만 다음과 같은 경우에는 이 세 가지 메커니즘이 작동하지 않으므로 NGINX Plus에서도 Hash 또는 IP Hash를 선택할 수 있습니다.

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

IP Hash와 클라이언트 IP 주소가 키에 포함된 Hash가 작동하지 않는 경우가 몇 가지 있습니다:

• 세션 도중 클라이언트의 IP 주소가 변경될 수 있는 경우(예: 모바일 클라이언트가 WiFi 네트워크에서 셀룰러 네트워크로 전환하는 경우).
• 다수의 클라이언트에서 보낸 요청이 포워드 프록시를 통과하여 모든 요청에 프록시의 IP 주소가 사용되는 경우.

해시는 결정적입니다(해싱 알고리즘은 매번 동일한 결과를 생성합니다). 이로 인해 몇 가지 긍정적인 부수 효과가 있습니다. 배포 환경의 모든 NGINX Plus 또는 NGINX 인스턴스가 정확히 동일한 방식으로 요청의 부하를 분산하며, 해시와 서버 간의 매핑은 로드 밸런서가 다시 시작된 후에도 유지됩니다. (실제로는 다시 시작한 후 재계산되지만, 결과가 항상 동일하므로 사실상 유지되는 것과 같습니다.)

반면 업스트림 서버 집합을 변경하면 일반적으로 매핑 중 적어도 일부를 다시 계산해야 하므로 세션 지속성이 깨집니다. 다음과 같이 다시 계산되는 매핑 수를 어느 정도 줄일 수 있습니다.

• 해시 방식의 경우 consistent 매개변수를 hash 지시문에 포함합니다. NGINX Plus는 재매핑을 줄여 주는 ketama 해싱 알고리즘을 사용합니다.
• IP 해시 방식에서는 업스트림 그룹에서 서버를 일시적으로 제거하기 전에 다음 예의 down 매개변수를 server 지시문에 추가합니다. 예를 들어 다음 예에서는 web2에 이 매개변수를 추가합니다. 서버가 곧 서비스에 복귀할 것으로 간주하므로 매핑은 다시 계산되지 않습니다.

upstream backend {    ip_hash;

    server web1;
    server web2 down;
    server web3;
}

라운드 로빈

앞서 언급했듯이 라운드 로빈은 NGINX Plus와 NGINX의 기본 부하 분산 방식입니다. 따라서 가장 쉽게 선택할 수 있는 방식임이 분명합니다. 업스트림 그룹 자체 외에는 아무것도 구성할 필요가 없습니다.

일반적으로 서버와 요청의 특성상 일부 서버가 다른 서버보다 과부하될 가능성이 낮을 때 라운드 로빈이 가장 효과적으로 작동한다고 알려져 있습니다. 이러한 조건의 예는 다음과 같습니다.

• 모든 서버의 용량이 대체로 동일합니다. 서버 간의 차이가 서버 가중치에 정확하게 반영되어 있다면 이 요구 사항은 그다지 중요하지 않습니다.
• 모든 서버가 동일한 콘텐츠를 호스팅합니다.
• 요청을 처리하는 데 필요한 시간이나 처리 능력은 요청마다 대체로 비슷합니다. 요청별 부하에 큰 차이가 있으면 로드 밸런서가 우연히 부하가 큰 요청을 특정 서버에 연달아 많이 보내 해당 서버에 과부하가 발생할 수 있습니다.
• 트래픽 양이 서버를 거의 최대 용량까지 몰아붙일 정도로 많은 경우가 자주 발생하지 않습니다. 서버에 이미 부하가 많이 걸린 상태라면, 이전 항목에서 설명한 것처럼 라운드 로빈 방식의 기계적인 요청 분배로 인해 일부 서버가 한계를 넘어 과부하 상태에 빠질 가능성이 더 높습니다.

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

균등한 분산 특성을 통해 캐시가 제대로 작동하며 최대 용량으로 활용되고 있는지도 확인할 수 있습니다. 라운드 로빈 방식에서는 특정 파일에 대한 요청을 항상 동일한 서버로 보낼 수 없으므로, 각 서버가 다양한 파일을 제공하고 캐싱하게 될 가능성이 높습니다(대개 다른 서버와 동일한 파일도 많이 캐싱함). 따라서 캐시가 가득 찰 가능성도 커집니다.

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

최소 연결 및 최소 시간

앞서 언급했듯이 최소 연결 방식은 가장 광범위한 사용 사례, 특히 프로덕션 트래픽에 가장 적합한 부하 분산 기법입니다. 이는 고객들의 실제 경험을 통해서도 뒷받침됩니다. 이 방식은 안정적이고 예측 가능한 성능을 제공합니다.

최소 연결 방식은 서버의 용량에 따라 워크로드를 효과적으로 분산하기도 합니다. 성능이 더 뛰어난 서버는 요청을 더 빠르게 처리하므로, 특정 시점에 아직 처리 중이거나 처리가 시작되기를 기다리는 연결 수가 용량이 더 작은 서버보다 적을 가능성이 높습니다. 최소 연결 방식은 현재 연결 수가 가장 적은 서버로 각 요청을 전송하므로, 성능이 뛰어난 서버로 요청을 보낼 가능성이 더 높습니다. (다만 아래의 서버 성능이 동일하지 않을 때 가중치 설정에서 설명한 것처럼 가중치를 설정하면 요청을 훨씬 더 효율적으로 분산할 수 있습니다.)

최소 시간(Least Time, NGINX Plus에서만 지원)은 최소 연결(Least Connections)보다 더 민감한 방식이라고 볼 수 있습니다. 평균 응답 시간을 반영하므로 서버의 최근 성능 이력까지 고려합니다. 실제로는 지수 가중 이동 평균을 사용하기 때문에 오래된 응답 시간보다 최근 응답 시간이 평균에 더 큰 영향을 미칩니다.

최소 시간(Least Time) 방식은 업스트림 서버의 평균 응답 시간이 서로 크게 다를 때 특히 적합합니다. 예를 들어 재해 복구를 위해 서로 다른 데이터 센터에 서버를 두고 있다면, 로컬 서버의 응답 속도가 더 빠르므로 최소 시간 방식은 로컬 서버에 더 많은 요청을 보내는 경향이 있습니다. 서버 성능을 예측하기 어려운 경우가 많은 클라우드 환경도 또 다른 활용 사례입니다.

서버 사양이 동일하지 않을 때 가중치 설정하기

업스트림 그룹의 서버마다 처리 용량이 다를 경우 서버 가중치를 설정하는 것이 중요하다고 여러 차례 언급했습니다. 이는 가중치를 설정하지 않으면 각 서버에 동일한 수의 요청을 보내는 라운드 로빈 부하 분산 방식에서 특히 중요합니다. 그렇지 않으면 성능이 낮은 서버에는 과부하가 걸리는 반면, 성능이 높은 서버는 일부 리소스가 유휴 상태로 남을 가능성이 큽니다.

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

다양한 부하 분산 기법에서 가중치를 설정했을 때의 효과는 다음과 같이 이해할 수 있습니다. 아래 설명은 개념적으로는 정확하지만, NGINX Plus 코드의 실제 구현에서 반드시 명시된 수학 연산을 사용하는 것은 아니라는 점에 유의하세요. 다음은 예제에서 사용할 업스트림 그룹입니다:

upstream backend {    server web1 weight=6;
    server web2 weight=3;
    server web3;
}

• 라운드 로빈 – 각 서버는 자신의 가중치를 전체 가중치의 합으로 나눈 비율만큼 들어오는 요청을 처리합니다. 이 예에서는 요청 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에서 사용할 수 있는 부하 분산 기법의 장단점을 검토한 결과, 가장 광범위한 사용 사례에는 최소 연결(Least Connections) 방식이 가장 적합하며, NGINX Plus의 경우에는 최소 시간(Least Time) 방식도 적합하다고 판단합니다. 하지만 배포 환경마다 트래픽과 서버 특성의 조합이 고유하므로 다른 방식이 더 적합할 수 있습니다. 따라서 실제 배포 환경에서 여러 방식을 테스트해 보는 것이 중요합니다.

NGINX Plus 로드 밸런싱을 직접 사용해 보려면 지금 30일 무료 평가판을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.

다양한 사용 사례에서 로드 밸런싱을 활용한 경험을 들려주세요. 아래 댓글란에 여러분의 경험을 남겨 주시기 바랍니다.

작성자 소개

Tony Mauro

Tony Mauro의 다른 블로그 게시물