Nginx - Using nginx as HTTP load balancer

Introduction

다수의 어플리케이션에 대한 로드 밸런싱은 일반적으로 optimizing resource utilization, maximizing throughput, reducing latency, ensuring fault-tolerant configurations과 같은 기술들을 사용한다.

nginx를 사용하면 매우 효율적인 HTTP 로드 밸런싱을 수행할 수 있다. 다수의 어플리케이션의 트래픽을 분산시켜서 성능, 확장성 그리고 신뢰성을 증대시킨다.

Load balancing methods

다음은 nginx에 지원하는 로드밸런싱 메커니즘이다.

• round-robin — 라운드 로빈으로 요청을 어플리케이션에 할당 한다.
• least-connected — 다음 요청이 수행중인 연결이 가장 적은 서버로 할당한다.
• ip-hash — 해쉬 함수에 의해 클라이언트 IP기반으로 다음 요청을 할당할 서버를 결정한다.

Default load balancing configuration

가장 기본적인 로드밸런싱 설정은 다음과 같다.

http {

    upstream myapp1 {

        server srv1.example.com;

        server srv2.example.com;

        server srv3.example.com;

    }

    server {

        listen 80;

        location / {

            proxy_pass http://myapp1;

        }

    }

}

위의 예제에서는 srv1-srv3까지 동일한 어플리케이션이 수행되고 있다. 밸런싱 모드를 설정하지 않았기 때문에 기본적으로 라운드-로빈이다. 모든 요청은 프록시된 서버 그룹 myapp1로 전달된다.

nginx에는 HTTP, HTTPS, FastCGI, uwsgi, SCGI, 그리고 memcached를 로드밸런싱하기 위해 리버스 프록시 구현이 포함되어 있다.

HTTP 대신에 HTTPS 로드 밸런싱을 설정하기 위해서는 프로토콜을 https로 사용하면 된다.

FastCGI, uwsgi, SCGI, 또는 memcached를 세팅하기 위해서는 fastcgi_pass, uwsgi_pass, scgi_pass, 그리고 memcached_pass 중에 적절한 지시어를 사용해야 한다.

Least connected load balancing

Another load balancing discipline is least-connected. Least-connected allows controlling the load on application instances more fairly in a situation when some of the requests take longer to complete.

With the least-connected load balancing, nginx will try not to overload a busy application server with excessive requests, distributing the new requests to a less busy server instead.

Least-connected load balancing in nginx is activated when the least_conn directive is used as part of the server group configuration:

    upstream myapp1 {

        least_conn;

        server srv1.example.com;

        server srv2.example.com;

        server srv3.example.com;

    }

Session persistence

라운드 로빈 또는 작은 연결 로드 밸런싱을 쓰면 주의할 점이 있다. 다음 클라이언트의 요청이 다른 서버로 전달될 수 있기 때문이다. 즉 같은 클라이언트가 같은 서버로 요청하는 것을 보장하지 않는다는 것이다.

만약 클라이언트를 특정한 어플리케이션과 연결을 sticky하게 연결하고 싶다면 ip-hash 로드 밸런싱을 사용하면 된다.

ip-hash를 사용하면 클라이언트 IP를 사용해 해싱키를 만들고 서버를 결정하기 때문이다. 이 방법은 해당 서버가 이용가능하지 않을때를 제외하곤 항상 같은 서버로 연결한다.

ip-hash 로드 밸런싱을 설정하기 위해서는 서버 그룹 설정에 ip_hash 지시어만 적어 넣으면 된다.

upstream myapp1 {

    ip_hash;

    server srv1.example.com;

    server srv2.example.com;

    server srv3.example.com;

}

Weighted load balancing

또한 nginx에서는 서버 가중치를 통한 로드 밸런싱 알고리즘도 지원한다.

위의 예제에서는 가중치가 설정되어 있지 않다. 이는 동일한 비율로 로드 밸런싱을 해달라는 것을 의미한다.

특히 라운드 로빈 방식에서는 이 가중치 옵션은 해당 서버로 요청을 더 많이 보내게 할 수 있다.

각 서버에 weight 파라미터를 명시하면 로드 밸런싱을 수행할때 가중치가 집계된다.

    upstream myapp1 {

        server srv1.example.com weight=3;

        server srv2.example.com;

        server srv3.example.com;

    }

이 설정대로라면 5개의 새로운 리퀘스트가 들어올때마다 3개는 srv1, 각 1개씩은 srv2와 srv3로 분산된다.

가중치 설정은 최신 버젼은 least-connected 및 ip-hash 로드 밸런싱에서도 사용 가능하다.

Health checks

nginx에서 리버스 프록시 구현은 in-band 또는 passive 서버 헬스 체크를 지원한다. 만약 특정 서버에서 응답이 실패하면 nginx는 해당 서버는 다운되었다고 판단하고 다음에 오는 요청에 일정시간 해당 서버를 선택하지 않는다.

max_fails 지시어는 일련의 실패수에 도달하면 fail_timeout 동안 해당 서버를 선택하지 않는다. 기본적으로 max_fails는 1로 세팅되어 있다. 만약 0으로 설정한다면 헬스체크를 하지 않는다. fail_timeout 파라미터는 얼마동안 서버를 실패로 표시할 것인가를 의미한다. fail_timeout 인터벌이 지난 후에 nginx는 클라이언트를 요청을 해당 서버가 동작하는지 검증하기 위해 전송할 것이다. 만약 성공하면 서버는 활성화된 상태로 표시될 것이다.