NGINX Plus: Load Balancing 특집

서버, 클라이언트, 프록시 간에 네트워크 트래픽을 분산하는 것은 고객 만족도를 유지하고 인프라를 최적화하는 데 핵심적인 요소입니다. 고성능 load balancing인 NGINX Plus 를 사용하면 scale out 및 중복성을 제공하고, 재시작할 필요 없이 인프라를 동적으로 재구성하고, global server load balancing (GSLB), session persistence, active health check를 활성화할 수 있습니다. NGINX Plus는 HTTP 트래픽뿐만 아니라 TCP, UDP, gRPC까지 로드 밸런싱합니다.

NGINX 및 NGINX Plus는 HTTP, TCP 및 UDP를 위한 모든 기능을 갖춘 로드 밸런서 입니다.

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

목차

1. HTTP Load Balancing
2. TCP/UDP Load Balancing
3. Load-Balancing Methods
4. NGINX Plus를 사용한 연결 제한
5. Session Persistence
6. Active Health Check
7. DNS를 사용한 Service Discovery
8. NGINX Plus API

1. HTTP Load Balancing

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

성능을 개선하기 위해 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 지시문으로 호스트 헤더를 설정하고 proxy_pass 지시문을 포함시켜 요청을 업스트림 그룹으로 배포합니다. (upstream 블록은 NGINX Plus가 트래픽을 로드 밸런싱하는 서버를 정의합니다.)

자세한 내용은 NGINX 및 NGINX Plus를 사용한 로드 밸런싱 소개를 참조하세요.

2. TCP/UDP Load Balancing

또한 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;
    }
}

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

TCP 및 UDP Load Balancing에 대한 자세한 내용은 NGINX Plus 관리 가이드를 참조하세요.

3. Load-Balancing Methods

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

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

4. NGINX Plus를 사용한 연결 제한

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

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

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

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

서버의 활성 연결 수가 제한 아래로 떨어지면 NGINX Plus는 queue에서 연결을 보냅니다. 연결을 제한하면 트래픽이 급증하는 동안에도 클라이언트 요청을 일관되고 예측 가능하게 서비스할 수 있습니다.

5. Session Persistence

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

NGINX 오픈 소스에서 지원하는 hash-based session persistence(Hash 및 IP Hash Load Balancing)에 더해, NGINX Plus는 cookie-based session persistence(sticky cookie 포함)을 지원합니다. NGINX Plus는 업스트림 그룹에서 특정 클라이언트로 보내는 첫 번째 응답에 session cookie를 추가하여 응답을 생성한 서버를 안전하게 식별합니다. 후속 클라이언트 요청에는 이 cookie가 포함되며, NGINX Plus는 이 cookie를 사용하여 요청을 동일한 업스트림 서버로 라우팅합니다:

upstream backend {
    server webserver1;
    server webserver2;

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

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

NGINX Plus는 sticky learn 및 sticky route persistence 방법도 지원합니다.

참고: Cookie-based session persistence는 NGINX Plus에서만 사용할 수 있습니다.

6. Active Health Check

기본적으로 NGINX는 업스트림 서버의 응답에 대해 기본 검사를 수행하고 가능한 경우 실패한 요청을 재시도합니다. NGINX Plus는 out-of-band application health check(synthetic transactions라고도 함)와 slow-start 기능을 추가하여 새 서버와 복구된 서버를 로드 밸런싱 그룹에 정상적으로 추가합니다.

이러한 기능을 통해 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 블록은 업스트림 서버가 정상으로 간주하기 위해 응답이 충족해야 하는 조건을 정의합니다. status code가 200 OK이고 ServerN이 살아있다는 텍스트가 포함된 응답 본문입니다.

참고: Active Health Check는 NGINX Plus에서만 제공됩니다.

7. DNS를 사용한 Service Discovery

기본적으로 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는 10초 마다 127.0.0.11(기본 제공 Docker DNS 서버)을 쿼리하여 도메인명 service1을 다시 확인합니다.

참고: DNS를 사용한 Service Discovery는 NGINX Plus 전용입니다.

8. NGINX Plus API

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

다음 구성 스니펫에는 /api 엔드포인트에 대한 read-write 액세스를 활성화하는 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으로 설정합니다. (버전은 참조 문서에 명시된 대로 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 메서드를 사용하여 서버의 IP 주소와 수신 포트를 192.168.78.55:80으로, 가중치를 500으로, 연결 제한은 350으로 설정하여 ID 2로 서버를 재구성합니다.

$ 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

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

참고: NGINX Plus API는 NGINX Plus 전용입니다.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.