F5 NGINX Plus

F5 NGINX Plus: 로드 밸런싱

고객 만족도를 유지하고 인프라를 최적화하려면 서버, 클라이언트, 프록시 전반에 걸쳐 네트워크 트래픽의 균형을 맞추는 것이 중요합니다. NGINX Plus 고성능 로드 밸런싱을 사용하면 수평으로 확장하고 중복성을 제공하고, 다시 시작할 필요 없이 인프라를 동적으로 재구성하고, Global Server Load Balancing(GSLB), 세션 지속성, 활성 상태 확인을 활성화할 수 있습니다. NGINX Plus는 HTTP 트래픽뿐만 아니라 TCP, UDP, gRPC의 로드 밸런싱도 수행합니다.

NGINX 및 NGINX Plus 로드 밸런싱을 통해 애플리케이션 확장
NGINX 및 NGINX Plus 로드 밸런싱을 통해 애플리케이션 확장

HTTP 로드 밸런싱

NGINX Plus는 HTTP 트래픽의 로드 밸런싱을 수행할 때 각 HTTP 연결을 종료하고 각 요청을 개별적으로 처리합니다. SSL/TLS 암호화를 제거하고, 요청을 검사 및 조작하고, 속도 제한을 사용하여 요청을 대기열에 넣은 다음 로드 밸런싱 정책을 선택할 수 있습니다.

NGINX Plus는 성능 개선을 위해 HTTP 프로토콜 업그레이드, keepalive 최적화, 콘텐츠 압축 및 응답 캐싱 같은 변환을 포함한 광범위한 최적화를 HTTP 트랜잭션에 자동으로 적용할 수 있습니다.

NGINX Plus를 사용하면 HTTP 트래픽 로드 밸런싱을 쉽게 수행할 수 있습니다.

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

먼저 server 지시문을 사용하여 가상 서버를 지정한 다음 트래픽을 listen할 포트를 지정합니다. location 블록을 사용하여 클라이언트 요청의 URL을 일치시키고, proxy_set_header 지시문을 사용하여 Host 헤더를 설정하고, 요청을 업스트림 그룹에 전달하기 위해 proxy_pass 지시문을 포함합니다. (upstream 블록은 NGINX Plus가 트래픽 로드 밸런싱을 수행하는 서버를 정의합니다.)

자세한 내용은 NGINX 및 NGINX Plus를 사용한 로드 밸런싱 소개를 확인하십시오.

TCP 및 UDP 로드 밸런싱

NGINX Plus는 MySQL 같은 TCP 애플리케이션과 DNS 및 RADIUS 같은 UDP 애플리케이션의 로드 밸런싱을 수행할 수도 있습니다. TCP 애플리케이션의 경우 NGINX Plus가 TCP 연결을 종료하고 백엔드에 대한 새 연결을 만듭니다.

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

구성은 HTTP와 유사합니다. server 지시문으로 가상 서버를 지정하고, 포트에서 트래픽을 listen하고, 요청을 upstream 그룹에 proxy_pass합니다.

TCP 및 UDP 로드 밸런싱에 대한 자세한 내용은 NGINX Plus Admin Guide를 참조하십시오.

로드 밸런싱 방법

NGINX Plus는 HTTP, TCP, UDP 로드 밸런싱에 다양한 애플리케이션 로드 밸런싱 방법을 지원합니다. 모든 방법은 각 업스트림 서버에 선택적으로 할당할 수 있는 가중치를 고려합니다.

  • Round Robin(라운드 로빈)(기본값) – 업스트림 서버에 요청을 순서대로 분산합니다.
  • Least Connections(최소 연결) – 활성 연결 수가 가장 적은 서버로 요청을 전달합니다.
  • Least Time(최소 시간) – 응답 시간과 활성 연결 수를 결합한 계산을 기반으로 로드가 가장 적은 서버로 요청을 전달합니다. NGINX Plus에만 적용됩니다.
  • Hash(해시) – 클라이언트 IP 주소 또는 요청 URL과 같은 지정된 키를 기반으로 요청을 분산합니다. NGINX Plus는 업스트림 서버 세트가 변경되는 경우 로드 재분배를 최소화하기 위해 선택적으로 일관된 해시를 적용할 수 있습니다.
  • IP Hash(IP 해시)(HTTP만 해당) – 클라이언트 IP 주소의 처음 3개 8진수를 기반으로 요청을 분산합니다.
  • Random with Two Choices(무작위로 2개 선택) – 두 개의 서버를 무작위로 선택하고 활성 연결 수가 더 적은 서버에 요청을 전달합니다(최소 연결 방법). NGINX Plus를 사용하면 최소 시간 방법도 사용할 수 있습니다.

NGINX Plus를 통한 연결 제한

NGINX Plus가 업스트림 HTTP 또는 TCP 서버와 설정하는 연결 수 또는 UDP 서버와의 세션 수를 제한할 수 있습니다. 서버와의 연결 또는 세션 수가 정의된 한도를 초과하면 NGINX Plus가 새로운 연결 설정을 중지합니다.

아래 구성 스니펫에서 webserver1의 연결 한도는 250이고 webserver2의 연결 한도는 150입니다. queue 지시문은 NGINX Plus가 운영 체제의 수신 대기열에 각각 최대 30초 동안 배치하는 최대 초과 연결 수를 지정합니다. 추가 초과 요청은 삭제됩니다.

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

서버의 활성 연결 수가 한도 미만으로 떨어지면 NGINX Plus는 대기열의 연결을 서버로 보냅니다. 연결을 제한하면 트래픽 급증 시에도 클라이언트 요청을 일관되고 예측 가능한 방식으로 처리하는 데 도움이 됩니다.

세션 지속성

사용자 세션을 식별하고 세션 내의 모든 요청을 동일한 업스트림 서버로 보내도록 NGINX Plus를 구성할 수 있습니다. 앱 서버가 상태를 로컬에 저장하는 경우 진행 중인 사용자 세션에 대한 요청이 다른 서버로 전송되면 치명적인 오류가 발생하므로 이는 매우 중요합니다. 세션 지속성은 애플리케이션이 클러스터 전체에서 정보를 공유할 때 성능을 개선할 수도 있습니다.

NGINX Open Source에서 지원하는 해시 기반 세션 지속성(해시 및 IP 해시 로드 밸런싱 방법) 외에도 NGINX Plus는 고정 쿠키를 포함한 쿠키 기반 세션 지속성을 지원합니다. NGINX Plus는 특정 클라이언트에 대한 업스트림 그룹의 첫 번째 응답에 세션 쿠키를 추가하여 응답을 생성한 서버를 안전하게 식별합니다. 후속 클라이언트 요청에는 NGINX Plus가 요청을 동일한 업스트림 서버로 라우팅하는 데 사용하는 쿠키가 포함됩니다.

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

위 예에서 NGINX Plus는 요청을 처리한 서버를 식별하기 위해 초기 클라이언트 응답에 srv_id라는 쿠키를 삽입합니다. 후속 요청에 쿠키가 포함되면 NGINX Plus는 이를 동일한 서버로 전달합니다.

NGINX Plus는 고정 학습 및 고정 경로 지속성 방법도 지원합니다.

참고: 쿠키 기반 세션 지속성은 NGINX Plus에만 적용됩니다.

활성 상태 확인

기본적으로 NGINX는 업스트림 서버의 응답에 대한 기본 검사를 수행하고 가능한 경우 실패한 요청을 다시 시도합니다. NGINX Plus는 대역 외 애플리케이션 상태 확인(합성 트랜잭션이라고도 함)과 느린 시작 기능을 추가하여 신규 서버와 복구된 서버를 로드 밸런싱 그룹에 정상적으로 추가합니다.

이러한 기능을 통해 NGINX Plus는 훨씬 더 다양한 문제를 탐지하고 해결하여 HTTP 및 TCP/UDP 애플리케이션의 안정성을 크게 향상시킬 수 있습니다.

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

위 예에서 NGINX Plus는 5초마다 /test.php에 대한 요청을 보냅니다. match 블록은 업스트림 서버가 정상으로 간주되기 위해 응답이 충족해야 하는 조건, 즉 상태 코드 200 OKServerN is alive라는 텍스트를 포함하는 응답 본문을 정의합니다.

참고: 활성 상태 확인은 NGINX Plus에만 적용됩니다.

DNS를 사용한 서비스 검색

기본적으로 NGINX Plus 서버는 시작 시 DNS 이름을 확인하고 확인된 값을 지속적으로 캐시합니다. 사용자가 example.com과 같은 도메인 이름을 사용하여 server 지시문 및 resolve 매개변수로 업스트림 서버 그룹을 식별하는 경우 NGINX Plus는 주기적으로 도메인 이름을 다시 확인합니다. 연결된 IP 주소 목록이 변경된 경우 NGINX Plus는 업데이트된 서버 그룹 전체에 즉시 로드 밸런싱을 시작합니다.

DNS SRV 레코드를 사용하도록 NGINX Plus를 구성하려면 다음과 같이 server 지시문에 service=http 매개변수와 resolver 지시문을 포함하십시오.

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

위 예에서 NGINX Plus는 도메인 이름 service1을 다시 확인하기 위해 10초마다 127.0.0.11(내장 Docker DNS 서버)을 쿼리합니다.

참고: DNS를 사용한 서비스 검색은 NGINX Plus에만 적용됩니다.

NGINX Plus API

NGINX Plus에는 단일 API 엔드포인트가 있는 RESTful API가 포함되어 있습니다. NGINX Plus API를 사용하면 다운타임 없이 업스트림 구성과 키 값 저장소를 즉시 업데이트할 수 있습니다.

다음 구성 조각에는 /api 엔드포인트에 대한 읽기/쓰기 액세스를 활성화하는 api 지시문이 포함되어 있습니다.

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

위의 예와 같이 API가 활성화된 상태에서 다음 curl 명령을 사용하여 기존 업스트림 그룹에 새 서버를 추가할 수 있습니다. POST 메서드와 JSON 인코딩을 사용하여 서버의 IP 주소를 192.168.78.66으로, 가중치를 200으로, 최대 동시 연결 수를 150으로 설정합니다. (version참조 문서에 지정된 API의 현재 버전 번호로 대체하십시오.)

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/

모든 백엔드 업스트림 서버의 전체 구성을 JSON 형식으로 표시하려면 다음을 실행하십시오.

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

기존 업스트림 서버의 구성을 수정하려면 위 출력의 id 필드에 나타나는 내부 ID로 이를 식별하십시오. 다음 명령은 PATCH 메서드를 사용하여 ID 2로 서버를 재구성하고 IP 주소와 수신 포트를 192.168.78.55:80으로, 가중치를 500으로, 연결 한도를 350으로 설정합니다.

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2

https://demo.nginx.com/swagger-ui/에서 NGINX Plus API의 전체 Swagger(OpenAPI 사양) 문서에 액세스할 수 있습니다.

참고: NGINX Plus API는 NGINX Plus에만 적용됩니다.

다음 단계