TCP Load Balancing NGINX Plus 사용하기

NGINX Plus 릴리스 5(R5)에서는 TCP Load Balancing 이라는 새로운 주요 기능이 도입되었습니다. NGINX Plus는 이제 로드 밸런싱을 수행하고 HTTP 외에도 광범위한 TCP 기반 프로토콜에 대한 고가용성을 제공할 수 있습니다.

이 포스트에서는 NGINX Plus의 TCP Load Balancing 기능에 대한 기술 개요를 제공합니다.

목차

1. TCP Load Balancing 소개
2. NGINX Plus가 TCP Load Balancing 하는 방법
3. Load Balancing 메소드
4. Health Checks
5. 구성 모범 사례

1. TCP Load Balancing 소개

새로운 Stream 모듈은 TCP Load Balancing 을 구현합니다. HTTP 및 mail 모듈과 마찬가지로 이 모듈을 사용하면 하나 이상의 수신 서버(이 경우 TCP 연결용)를 구성할 수 있습니다. 연결은 proxy_pass 지시문에 의해 명명된 업스트림 서버 그룹으로 전달됩니다. 로드 밸런싱 알고리즘은 업스트림 서버(이 예에서는 db1, db2 또는 db3) 중 하나를 선택하는 데 사용됩니다.

stream {
    server {
        listen 3306;
        proxy_pass db;
    }

    upstream db {
        server db1:3306;
        server db2:3306;
        server db3:3306;
    }
}

2. NGINX Plus가 TCP Load Balancing 하는 방법

새 연결(New connections) – NGINX Plus가 listen 소켓에서 새 클라이언트 연결을 수신하면 즉시 로드 밸런싱 결정을 내리고 선택한 업스트림 서버에 대한 새 연결을 생성합니다.

데이터 전송(Data transfer) – 그런 다음 NGINX Plus는 클라이언트 및 업스트림 연결을 모니터링합니다. 한 연결에서 데이터를 수신하는 즉시 NGINX Plus는 데이터를 읽고 다른 연결로 전달합니다. NGINX Plus는 클라이언트 및 업스트림 데이터(proxy_buffer_size 참조)에 대한 메모리 내 버퍼를 유지하고 데이터를 읽어 해당 버퍼를 채웁니다. 클라이언트 또는 서버가 대량의 데이터를 스트리밍하는 경우 NGINX Plus에서 추가 메모리를 사용하는 대신 적절한 버퍼의 크기를 늘려 작은 성능 이점을 볼 수 있습니다.

연결 닫기(Closing connections) – NGINX Plus가 두 연결 중 하나에서 닫기 알림을 받거나 TCP 스트림이 proxy_timeout 설정보다 오랫동안 유휴 상태인 경우 NGINX는 두 연결을 모두 닫습니다. 수명이 긴 TCP 연결의 경우 프록시_타임아웃 매개변수의 값을 늘리고 Listen 소켓에 대한 so_keepalive 매개변수를 조정하여 연결이 중간에 닫히지 않고 연결이 끊긴 피어를 빠르게 감지할 수 있습니다.

3. Load Balancing 메소드

라운드 로빈(기본값), 최소 연결 및 해시(선택적으로 ketama 일관된 해시 방법 사용)와 같은 다양한 로드 밸런싱 방법을 TCP Load Balancing 에 사용할 수 있습니다. 이들은 각 연결에 대한 대상 업스트림 서버를 선택하기 위해 상태 모니터링 데이터와 함께 사용됩니다.

NGINX Plus는 로드 밸런싱 결정을 즉시 내리고 TCP 연결의 데이터를 검사하지 않습니다. 해시 방법을 사용하면 클라이언트 IP 주소($remote_addr 변수로 캡처됨)를 Key로 사용하여 필요한 경우 세션 지속성의 단순 모드를 얻을 수 있습니다.

다른 upstream 모듈과 마찬가지로 TCP Load Balancing 용 stream 모듈은 로드 밸런싱 결정에 영향을 미치는 사용자 정의 가중치를 지원하며 backup 및 down 매개변수는 업스트림 서버를 활성 서비스에서 제외하는 데 사용됩니다. max_conns 매개변수는 업스트림 서버에 대한 TCP 연결 수를 제한합니다. 이는 서버에 동시성 제한이 있고 다른 서버를 사용하거나 모든 서버가 용량에 도달한 경우 빠르게 실패하려는 경우에 매우 유용합니다.

4. Health Checks

TCP Load Balancing 모듈은 인라인(동기식) 상태 확인을 지원합니다.

서버가 proxy_connect_timeout 기간 내에 TCP 연결을 거부하거나 연결 작업에 응답하지 않으면 실패한 것으로 간주됩니다. 이 경우 NGINX Plus는 즉시 업스트림 그룹의 다른 서버를 시도합니다.

모든 연결 실패는 NGINX Error Log에 기록됩니다.

2014/11/27 07:40:56 [error] 22300#0: *73 upstream timed out (110: Connection timed out) while connecting to upstream, client: 192.168.56.10, server: 0.0.0.0:3306

서버가 반복적으로 실패하면(max_fails 및 fail_timeout 매개변수로 정의됨) NGINX는 서버를 실패로 표시하고 새 연결 전송을 중지합니다.

서버에 장애가 발생하고 60초 후에 NGINX는 복구 여부를 결정하기 위해 로드 밸런싱 결정 중에 서버를 가끔 선택하여 프로브(probe)를 시작합니다. 서버가 새 연결에 응답하기 시작하면 NGINX는 천천히 다시 업스트림 클러스터에 다시 도입하여 slow_start 기간 동안 연결 속도를 높입니다. 이렇게 하면 트래픽 급증으로 인해 서버가 압도당하는 것을 방지하고 램프 업 시간 동안 서버가 다시 실패할 경우 영향을 최소화합니다.

5. 구성 모범 사례

NGINX Plus 구성의 별도 stream 컨텍스트에서 TCP Load Balancing 을 구성합니다. NGINX Plus 구성에는 스트림 서비스에 대한 기본 구조가 없습니다.

기본 nginx.conf 파일에서 TCP 부하 분산 구성을 정의할 수 있지만 이렇게 하면 위험 및 권한 문제가 발생합니다. 서비스를 정의하는 구성 파일에 대해 별도의 디렉터리를 생성하는 것이 가장 좋습니다. 그런 다음 기본 구성 파일에서 include 지시문을 사용하여 디렉토리에 있는 파일의 내용을 읽습니다.

HTTP 서비스의 표준 NGINX Plus 구성은 구성 파일을 별도의 conf.d 디렉토리에 넣습니다.

http {
    include /etc/nginx/conf.d/*.conf;
}

별도의 stream.d 디렉터리에서 해당 구성을 정의하는 TCP 서비스에 대해 유사한 접근 방식을 권장합니다. 적절한 권한으로 디렉터리를 보호한 후 기본 파일에 다음을 추가합니다.

stream {
    include /etc/nginx/stream.d/*.conf;
}

직접 TCP Load Balancing을 사용해 보십시오. 오늘 무료 30일 평가판을 시작하거나 사용 사례에 대해 논의하려면 NGINX STORE에 문의하십시오.