본문 바로가기
WEB/NGINX

5. Load Balancing 방식 및 가중치 설정

by coldplayer83 2024. 11. 7.
728x90

[Nginx의 로드밸런싱 설정 방법]

nginx.conf 파일에 설정

 

1. Round Robin (default)

upstream tomcat {
   server backend1.example.com;
   server backend2.example.com;
}

 

2. Least Connections

upstream tomcat {
least_conn;
   server backend1.example.com;
   server backend2.example.com;
}

 

가장 클라이언트 연결이 적은 서버로 전달

 

3. IP Hash

upstream tomcat {
ip_hash;
   server backend1.example.com;
   server backend2.example.com;
}

 

client ip를 hash하여 한 번 접속한 서버로 sticky 연결

 

- client ip의 해시 값으로 트래픽을 분산하여 동일한 client의 요청은 동일한 서버에 전달

- IPv4의 경우 첫 3자리로 해시값을 구하기 때문에 같은 대역의 클라이언트는 같은 서버에 트래픽이 할당됨

- IPv6의 경우 전체 주소로 해시값을 구함

- 모바일 wifi 환경에서 ip가 변경될 경우 세션 유지 x

- 대표 ip로 요청이 들어오는 경우 한쪽 서버에 부하 가능성 있음

- HTTP 프로토콜에서만 사용 가능

- 백엔드 서버의 클러스터 환경에서 세션 유지 가능

 

4. Generic Hash

upstream tomcat {
hash $request_uri consistent;
   server backend1.example.com;
   server backend2.example.com;
}

 

클라이언트를 텍스트 문자열, 변수 또는 사용자 정의 키를 기준으로 Hash Table에 저장

각 요청에 대해 Load Balancer는 사용자가 지정한 텍스트 및 nginx 변수의 조합을 기반으로 해시를 계산하고 이 해시를 서버 중 하나와 연결

해당 Hash가 포함된 모든 요청을 해당 서버로 전송하므로 session 지속성 설정 가능

 

5. Least Time

upstream tomcat {
 least_time header;
   server backend1.example.com;
   server backend2.example.com;
}

 

NGINX Plus Only

평균 latency와 연결을 기준으로 검사 후 로드가 적은 서버로 요청을 보냄

평균 응답 시간 값과 같은 서버의 최근 성능 기록을 고려하여 연결

Upstream 서버들의 평균 응답 시간이 매우 다른 경우에 특히 적합

 

- least_time header : 서버에서 첫 번째 바이트를 수신하는 시간

- least_time last_byte : 서버로부터 전체 응답을 수신하는 시간

- least_time last_byte inflight : 불완전한 요청을 고려하여 서버로부터 전체 응답을 받는 데 걸리는 시간

 


 

[가중치 설정]

 

라운드 로빈 방식을 사용하여 가중치로 요청 전송

upstream tomcat {
    server 192.168.56.102:12131 weight=3;
    server 192.168.56.102:12132 weight=2;
    server 192.168.56.102:12133;
    server 192.168.56.102:12134 max_fails=5 fail_timeout=30s;
    server 192.168.56.102:12135 backup;
    server backend1.example.com slow_start=10s;
}

 

weight(default 1) : 서버의 가중치 설정

12131, 12132, 12133 서버에 대해 가중치 3:2:1 비율로 로드 밸런싱

 

max_fails=5 fail_timeout=30s;

30초 동안 응답하지 않는 상태가 5번 지속되면 down으로 판단하고 요청을 보내지 않음

 

backup

활성화된 서버 전체가 down상태가 되었을 때 자동으로 활성화됨

 

slow_start (NGINX Plus Only)

서버가 복구 또는 응답 가능한 상태가 되었을 때 서서히 가중치가 0에서 설정값까지 회복되도록 함

서버에 대한 가중치가 최대가 될 때까지의 시간을 설정

 


 

Limiting the Number of Connections (NGINX Plus Only)

max_conns 항목을 설정하여 upstream 서버에 대한 연결 수를 제한할 수 있음

max_conns 한계에 도달한 요청은 추가 처리를 위해 queue에 배치

queue 지시자는 큐 최대 수를 설정하기 위해 사용

upstream backend {
    server backend1.example.com max_conns=50;
    server backend2.example.com;
    queue 100 timeout=70;
}

 

queue를 설정한 값인 100개까지 사용 후 timeout 설정값인 70초 동안 처리되지 않으면 이후 요청은 오류로 처리하고 클라이언트에 전달

keepalive 연결은 max_conns의 제한을 무시하고 서버에 대한 총 연결 수는 max_conns 값을 초과할 수 있음 

 

Passive Health Checks

서버가 비정상적인 경우 지속적으로 상태체크 가능

upstream backend {
    server backend1.example.com;
    server backend2.example.com max_fails=3 fail_timeout=30s;
    server backend3.example.com max_fails=2;
}

 

max_fails : 서버 접속 시도 횟수

fail_timeout : max_fails에 의해 서버가 사용할 수 없는 것으로 간주되는 시간

 

기본값은 max_fails=1, fail_timeout=10s; (10초 후 1회 재시도)

 

따라서 서버가 하나의 요청을 수락하지 않거나 응답하지 않으면 nginx는 즉시 서버를 10초 동안 사용할 수 없다고 간주함

 

※ 하나의 서버가 그룹에 설정된 경우 max_fails, fail_timeout, slow_start 지시어는 무시되고 사용할 수 없는 서버로 간주하지 않음

'WEB > NGINX' 카테고리의 다른 글

7. weblogic 연동  (0) 2024.11.19
6. Sticky Session  (0) 2024.11.12
4. tomcat 연동  (0) 2023.05.22
3. 기동/중지  (0) 2023.05.22
2. 1024 이하 포트 사용 설정  (0) 2023.05.22