NGINX 및 NGINX Plus Load Balancer, 1부

Load Balancer 로서의 NGINX는 광범위한 HTTP 기반 애플리케이션에 사용할 수 있는 가속 프록시(Proxy)입니다. 캐싱, HTTP 연결 처리 및 오프로드(Offload)는 특히 부하가 높은 기간 동안 애플리케이션 성능을 크게 향상시킵니다.

NGINX Plus는 TCP 기반 응용 프로그램의 로드 밸런싱(load balancing)을 수행할 수도 있습니다. 상태 점검, 동적 재구성, SSL 종료 등을 추가하여 TCP 로드 밸런싱이 크게 확장되었습니다. 또한 TCP 로드 밸런서(load balancer)가 HTTP 로드 밸런서와 전체 기능 패리티(Parity)을 가집니다. UDP 로드 밸런싱도 지원합니다.

HTTP 컨텍스트 대신 스트림 컨텍스트에서 TCP 및 UDP 로드 밸런싱을 구성합니다. 사용 가능한 지시어와 매개 변수는 HTTP와 TCP/UDP 간의 고유한 차이 때문에 약간 다릅니다. 자세한 내용은 HTTP 및 TCP 업스트림 모듈에 대한 설명서를 참조하십시오.

NGINX Plus는 상태 점검, 세션 지속성, 실시간 작업 모니터링 및 로드 밸런싱된 서버 그룹의 동적 구성과 같은 추가적인 로드 밸런싱 기능을 추가하여 NGINX의 기능을 확장합니다.

이 포스트는 일련의 웹 서버에 대한 트래픽 로드 밸런싱을 위해 NGINX를 구성하는 단계를 게시합니다. NGINX Plus의 몇 가지 추가 기능을 강조합니다.

자세한 내용은 NGINX Plus 관리 가이드와 이에 대한 후속 포스트인 NGINX 및 NGINX Plus를 사용한 로드 load balancer, 2부도 확인보세요.(Comming soon)

목차

1. NGINX로 트래픽 프록시 처리
1-1. Load Balancer 방법 설정
2. 장애 감지
3. 일반적인 ‘Gotcha’ – 호스트 헤더 수정
4. NGINX Plus를 사용한 고급 Load Balancer

1. NGINX로 트래픽 프록시 처리

먼저 트래픽을 업스트림 웹 서버 쌍으로 프록시합니다. 다음 NGINX 구성은 포트 80에 대한 모든 HTTP 요청을 종료하고 업스트림 그룹의 웹 서버에 라운드 로빈(RR) 방식으로 전달하기에 충분합니다.

http {
    server {
        listen 80;

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

    upstream backend {
        server web-server1:80;
        server web-server2:80;
    }
}

이 간단한 구성으로 NGINX는 포트 80에서 수신된 각 요청을 web-server1 과 web-server2로 차례로 전달하여 각각의 경우에 새로운 HTTP 연결을 설정합니다.

1-1. Load Balancer 방법 설정

기본적으로 NGINX는 라운드 로빈 방식을 사용하여 서버 간에 트래픽을 균등하게 분산시키고, 각 서버에 할당된 선택적 “가중치(weight)”로 상대 용량을 나타냅니다.

IP 해시 메서드는 소스 IP 주소의 해시를 기반으로 트래픽을 배포합니다. 동일한 클라이언트 IP 주소의 요청은 항상 동일한 업스트림(upstream)서버로 전송됩니다. 이것은 서버가 실패하거나 복구되거나 업스트림 그룹이 수정될 때마다 재 계산되는 원시 세션 지속성 방법입니다. NGINX Plus는 세션 지속성이 필요한 경우 더 나은 솔루션을 제공합니다.

최소 연결 메서드는 각 요청을 활성 연결이 가장 적은 업스트림 서버로 라우팅합니다. 이 방법은 빠르고 복잡한 여러 요청을 처리할 때 효과적으로 작동합니다.

모든 로드 밸런싱 방법은 서버 지시문의 선택적 가중치 매개변수를 사용하여 조정할 수 있습니다. 이는 서버의 처리 용량이 다를 때 의미가 있습니다. 다음 예제에서 NGINX는 web-server1보다 4배 많은 요청을 web-server2로 보냅니다.

upstream backend {
    zone backend 64k;
    least_conn;

    server web-server1 weight=1;
    server web-server2 weight=4;
}

NGINX에서 가중치는 각 작업자 프로세스에서 독립적으로 관리됩니다. NGINX Plus는 업스트림 데이터(존 디렉티브로 구성)에 공유 메모리 세그먼트를 사용하기 때문에 작업자 간에 가중치가 공유되고 트래픽이 보다 정확하게 분산됩니다.

2. 장애 감지

NGINX가 서버에 연결을 시도하거나 요청을 전달하거나 응답 헤더를 읽을 때 오류 또는 시간 초과가 발생하면 NGINX는 다른 서버와의 연결 요청을 재시도합니다. (요청을 재시도하기 위한 다른 조건을 정의하기 위해 구성에 proxy_next_upstream 지시어를 포함할 수 있습니다.) 또한 NGINX는 잠재적인 서버 집합에서 장애가 발생한 서버를 제거하고 때때로 복구 시점을 탐지하기 위해 해당 서버에 요청을 시도할 수 있습니다. 서버 지시문에 대한 max_fails 및 fail_timeout 매개변수는 이 동작을 제어합니다.

NGINX Plus에는 각 업스트림 서버에 대해 정교한 HTTP 테스트를 수행하여 활성 여부를 확인하는 대역 외 상태 검사 집합과 복구된 서버를 로드 밸런싱된 그룹에 점진적으로 도입하는 슬로우 스타트 메커니즘이 추가되었습니다.

server web-server1 slow_start=30s;

3. 일반적인 ‘Gotcha’ – 호스트 헤더 수정

일반적으로 업스트림 서버는 Host 요청 헤더를 사용하여 제공할 콘텐츠를 결정합니다. 서버에서 예기치 않은 404 오류가 발생하거나 잘못된 콘텐츠를 제공하고 있음을 시사하는 다른 오류가 발생할 경우 가장 먼저 확인해야 할 사항입니다. 그런 다음 구성에 proxy_set_header 지시어를 포함하여 헤더에 적절한 값을 설정합니다.

location / {
    proxy_pass http://backend;

    # Rewrite the 'Host' header to the value in the client request
    # or primary server name
    proxy_set_header Host $host;

    # Alternatively, put the value in the config:
    #proxy_set_header Host www.example.com;
}

4. NGINX Plus를 사용한 고급 Load Balancer

NGINX Plus의 다양한 고급 기능을 통해 업스트림 서버 팜 앞에 이상적인 Load Balancer를 구축할 수 잇습니다.

  • 로드 밸런싱 및 세션 지속성 – 작업자 프로세스 및 세션 지속성 방법 간에 로드 밸런싱이 개선되어 애플리케이션 세션을 식별하고 준수합니다.
  • HTTP 상태 점검 및 서버 slow start – 각 업스트림 서버의 올바른 작동을 조사하기 위한 비동기식 ‘합성 트랜잭션’ 및 복구 시 서버의 정상적인 ‘slow start’ 재도입
  • 실시간 활동 모니터링 – 활동 및 성과에 대한 즉각적인 보고
  • 동적으로 구성된 업스트림 서버 그룹 – 서버를 안전하게 임시적으로 제거 하는 것과 같은 일반적인 업스트림 관리 작업을 용이하게 하는 도구