Nginx가 ngx_http_upstream_module을 사용하여 로드 밸런싱 기능을 구현하는 방법

로드 밸런싱 소개

로드 밸런싱이란 무엇입니까

로드 밸런싱(Load Balance)은 로드(작업 작업, 액세스 요청)를 여러 운영 단위(서버, 구성 요소) 구현에 분산하고 할당하는 것을 의미합니다.

로드 밸런싱이 필요한 이유

단일 웹 서버가 사용자를 직접 대면할 경우 많은 수의 동시 요청을 처리할 수 있으며 단일 서버는 로드하기 어려울 수 있습니다. Nginx 로드 밸런싱 기능을 사용하여 로드 트래픽 분산을 달성하고 전체 성능 및 시스템 재해 복구 기능을 향상시키기 위해 다양한 백엔드 서버에 요청을 분산합니다.

• 로드 밸런싱과 프록시의 차이점은 무엇입니까

프록시는 URI 스케줄링을 기반으로 서버를 프록시하고 이를 다른 기능을 가진 애플리케이션 노드에 예약하는 것입니다.

로드 밸런싱은 클라이언트 요청을 다음 세트로 프록시하는 것입니다. Proxy_Pass를 통한 업스트림 리소스 풀

• 로드 밸런싱 시나리오 구현

로드 밸런싱 기능을 구현하려면 두 가지 모듈이 필요합니다. 예: 공식 로드 밸런싱 디스플레이

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

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

예: 직접 작은 예 완성

• upstream node {
      server 192.168.10.3:80;
      server 192.168.10.4:80;
  }
  server {
      listen 80;
      server_name www.yyang.com;
      location / {
          proxy_pass http://node;
          include prxoy_params;
      }
  }

  로드 밸런싱 스케줄링 알고리즘

• 폴링 스케줄링

다른 백엔드 노드에 순서대로 하나씩 배포되며, 이는 기본 알고리즘이기도 합니다. . (간단히 말하면 1:1:1 입니다)

가중 폴링

서버마다 다른 성능을 고려하여 노드에 서로 다른 가중치를 부여하여 해당 개수의 가중치 요청을 받게 됩니다

server 192.168.10.3:80 weight=3;
server 192.168.10.4:80 weight=1;

위의 예는 즉, 4개의 요청마다 10.3에 대한 3개의 요청과 10.4에 대한 1개의 요청에 할당되며 이러한 주기가 계속됩니다.

ip_hash

사용자가 요청한 IP에 따라 해당 IP에 대해 해시 연산을 수행하고, 계산된 값을 기반으로 처리하기 위해 백엔드의 특정 노드에 요청을 할당합니다.

값 범위는 ipv4 주소의 처음 3개 8비트 또는 해시 키인 ipv6의 전체 주소이며, 보조 서버를 사용할 수 없는 경우를 제외하고 한 클라이언트의 IP가 항상 동일한 서버로 전달되도록 합니다. 간단히 말하면 172.16.20.1과 172.16.20.2의 처음 3개 숫자는 동일합니다(모두 172.16.20)
ip_hash 연산식: hash(ip)%node_counts=index

ip_hash로 인한 문제:

동일한 IP에서 많은 요청이 발생하면 특정 노드에서 과도한 트래픽이 발생합니다. 노드가 일시적으로 오프라인 상태인 경우 다운 상태를 사용하는 것이 좋습니다. 예: ip_hash 및 가중치는 사용할 수 없습니다.

ip_hash;
server 192.168.10.3:80;
server 192.168.10.4:80;

일관된 해시

위의 문제를 피하기 위해 모듈로 방식을 사용하여 일관된 해싱이 탄생했지만 서버 노드 수를 모듈로하는 것이 아니라 모듈로 2의 32승을 수행합니다. .해시 함수 값은 0~2^32-1 입니다. (가상 링을 형성하면 사용자 요청이 시계 방향으로 인접한 노드로 전송됩니다)

문제가 있습니다. 백엔드 노드 수가 적으면 데이터 왜곡이 발생할 수 있으므로 일관된 해싱은 가상 노드 메커니즘을 도입합니다. 각각 서버는 여러 해시를 계산하고 계산된 각 결과 위치에 가상 노드를 배치합니다.

ip_hash를 사용하고 싶지만 계산 공식이 일관된 해시를 사용하는 경우 어떻게 해야 하나요?

hash $remote_addr consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

url_hash

는 사용자의 URL을 기반으로 해시 모듈로를 취하고 작업 값을 기반으로 특정 백엔드 서버에 요청을 할당합니다.

1. 사용자가 nginx 로드 밸런싱을 요청하고 URL 알고리즘을 통해 요청이 캐시1로 예약됩니다.

2.cache1에는 데이터가 없으며 백엔드에서 데이터를 가져오고 데이터를 반환하며 데이터를 캐시합니다3 .다른 사용자가 동일한 URL에 액세스하면 일정 서버는 여전히 캐시1 노드에 예약됩니다4.cache1은 데이터를 직접 반환합니다

hash $request_uri consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

least_conn

연결 수가 가장 적은 서버가 요청됩니다. 이 서버에 예약됨

least_conn;
server 192.168.10.3:80;
server 192.168.10.4:80;

로드 밸런싱 백엔드 노드 상태

down

서버 노드를 사용할 수 없는 것으로 표시하며 일반적으로 다운타임 유지 관리에 사용됩니다.

server 192.168.10.3:80 down;
server 192.168.10.4:80;

backup

대기 노드는 정상적인 상황에서 예약되지 않습니다. 모든 정상 작동 노드를 사용할 수 없으면 이 노드가 활성화되고, 이 노드는 계속 대기 상태를 복원합니다.

server 192.168.10.3:80;
server 192.168.10.4:80;
server 192.168.10.5:80 backup;

max_conns

는 각 백엔드 노드가 수신하는 최대 TCP 연결 수를 제한하는 데 사용됩니다. 제한을 초과하면 오류가 발생합니다.

server 192.168.10.3:80 max_conns=10;
server 192.168.10.4:80 max_conns=10;

1개는 10개 연결 가능. 2개는 20개 연결 가능. 20개 초과시 오류 발생.

keepalived

은 백엔드 서버, 즉 긴 링크와의 캐싱을 활성화하여 웹 사이트 처리량을 향상시킵니다.

이 기능은 기본적으로 활성화되어 있지 않습니다. 요청이 있으면 연결이 설정되고 유지되고 닫히므로 네트워크 소비가 발생하지만 모든 연결이 캐시되면 연결 시 다른 시스템 리소스가 점유됩니다. 유휴 상태이므로 keepalived 매개변수를 사용할 수 있습니다.

server 192.168.10.3:80;
server 192.168.10.4:80;

keepalived 32;   # 最大空闲连接数的个数
keepalived_timeout 100s; # 空闲连接的超时时间

# 需要配合以下两个参数使用

proxy_http_version 1.1;
proxy_set_header connection "";

max_fails 및 failure_timeout

max_fails=2：服务器通信失败两次，认为服务器不可用
fail_timeout=5s：服务器通信失败后，每5秒探测一次服务器是否恢复正常。
在fail_timeout设定时间内，与服务器连接失败次数达到max_fails数量，则认为服务器不可用。
如果不设置的话默认是探测一次，间隔10s。

server 192.168.10.3:80 max_fails=2 fail_timeout=5s;
server 192.168.10.4:80 max_fails=2 fail_timeout=5s;

위 내용은 Nginx가 ngx_http_upstream_module을 사용하여 로드 밸런싱 기능을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!