Nginx 서버 부하 균형 역방향 프 록 시 슈퍼 공략

nginx 가 역방향 대 리 를 할 때 백 엔 드 호스트 는 여러 대 입 니 다. upstream 을 사용 하여 백 엔 드 호스트 풀 을 정의 할 수 있 습 니 다. 역방향 대 리 를 할 때 호스트 풀 의 이름 을 직접 사용 할 수 있 습 니 다.upstream 에서 부하 균형 스케줄 링 알고리즘, 가중치, 건강 상태 검사 등 매개 변 수 를 정의 할 수 있 습 니 다.
예 를 들 면:

upstream backend {
  server 172.16.0.1:80 weight=1 max-fails=3 fail_timeout=10;
  server 172.16.0.2:80 weight=1max-fails=3 fail_timeout=10;;
}

기본 요청 에 서 는 round - robin 알고리즘 을 사용 하고 건강 상태 검사 와 호스트 복구 능력 이 있 습 니 다.
ningx 는 이러한 알고리즘 을 사용 할 수 있 습 니 다:

    ip_hash: 원본 주소 기반 해시, 주요 목적 은 세 션 유지

    least_conn: 최소 활동 연결 을 기반 으로 스케줄 링

    sticky: 쿠키 를 기반 으로 세 션 바 인 딩 을 합 니 다. nginx 는 클 라 이언 트 가 처음 방문 할 때 경로 정 보 를 쿠키 에 삽입 하거나 쿠키 의 한 필드 의 값 을 키 로 선택 합 니 다. 이후 요청 할 때마다 이 정 보 를 기반 으로 예약 합 니 다

쿠키 기반 세 션 바 인 딩 은 모두 쿠키, route, learn 세 가지 가 있 습 니 다.
예 를 들 어 쿠키 name 기반 스케줄 링:

upstream backend {
  server backend1.example.com;
  server backend2.example.com;

  sticky cookie srv_id expires=1h domain=.example.com path=/;
}

이 호스트 그룹 을 사용 하여 역방향 프 록 시 를 진행 합 니 다:

location / {
  proxy_pass http://backend;
  proxy_set_header Host $host;
  proxy_set_haeder X-Forwared-For $proxy_add_x_forwarded_for;
}

proxy_pass URL 은 프 록 시 백 엔 드 호스트 를 지정 합 니 다. "http" 또는 "https" 프로 토 콜 을 지정 할 수 있 습 니 다. 도 메 인 이름 은 ip 주소 일 수도 있 고 upstream 풀 이름 일 수도 있 습 니 다.

    프 록 시가 지정 한 URI 주소 라면,http://127.0.0.1/remote요청 한 URI 가 무엇이든 지 정 된 URI 로 대 리 됩 니 다

    만약 에이전트 가 지정 한 호스트 에 URI 가 없다 면,http://127.0.0.1클 라 이언 트 가 요청 한 URI 는 지 정 된 도 메 인 이름

으로 전 달 됩 니 다.

    location 에서 url 과 일치 하 는 패턴 을 사용 하면 url 도 프 록 시 URL 의 끝 에 전 달 됩 니 다

    location 에서 URI 재 작성 을 사용 했다 면 proxy패스 는 재 작성 한 결 과 를 사용 하여 처리 합 니 다

proxy_set_header HEADER VALUE 가 리 트 윗 한 메시지 의 첫 부분 을 수정 합 니 다.
역방향 프 록 시 캐 시 관련 설정
proxy_cache_path PATH [levels=levels] keys_zone=NAME:SIZE
디스크 캐 시 경 로 를 정의 합 니 다. Nignx 캐 시 는 키 로 저 장 됩 니 다. keyszone 은 키 에 저 장 된 메모리 공간의 이름과 크기 를 지정 하 는 데 사용 되 며, 해당 값 은 PATH 가 지정 한 경로 에 저 장 됩 니 다.levels 는 캐 시 저장 경로 의 급수 와 이름 문자 수 를 지정 할 수 있 습 니 다.이 설정 은 http 세그먼트 에서 만 정의 할 수 있 습 니 다.
예:

proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=one:10m;

proxy_cache_valid [code...] time 서로 다른 응답 코드 의 내용 의 캐 시 시간 을 지정 합 니 다.
예:

proxy_cache_valid 200 302 10m;
proxy_cache_valid 404   1m;
proxy_cache_valid any   1m;

proxy_cache_method METHOD 는 다음 과 같은 요청 결 과 를 캐 시 할 수 있 는 방법 을 정의 합 니 다.

proxy_cache_method GET;
proxy_cache_method HEAD;

proxy_cache NAME 는 캐 시 에 미리 정 의 된 캐 시 공간 을 지정 합 니 다.
몇몇 문제 의 해결 방법
다음은 Nginx 부하 균형 을 사용 한 후 발생 하 는 문 제 를 살 펴 보 겠 습 니 다.
일반적으로 서버 부하 문 제 를 해결 하려 면 다 중 서버 분 재 를 통 해 해결 된다.흔히 볼 수 있 는 해결 방안 은 다음 과 같다.
그러면 Nginx 가 부하 균형 을 어떻게 실현 하 는 지 살 펴 보 겠 습 니 다. Nginx 의 upstream 은 현재 다음 과 같은 몇 가지 방식 의 분 배 를 지원 합 니 다. 1. 폴 링 (기본) 모든 요청 은 시간 순서에 따라 서로 다른 백 엔 드 서버 에 하나씩 분 배 됩 니 다. 백 엔 드 서버 다운 이 떨 어 지면 자동 으로 제거 할 수 있 습 니 다.2. weight 는 폴 링 확률 을 지정 하고 weight 와 방문 비율 이 정비례 하여 백 엔 드 서버 의 성능 이 고 르 지 않 은 경우 에 사용 합 니 다.2、ip_hash 모든 요청 은 ip 에 접근 하 는 hash 결과 에 따라 분 배 됩 니 다. 모든 방문객 이 백 엔 드 서버 에 고정 적 으로 접근 하면 session 문 제 를 해결 할 수 있 습 니 다.3. fair (제3자) 는 백 엔 드 서버 의 응답 시간 에 따라 요청 을 분배 하고 응답 시간 이 짧 은 우선 배분 합 니 다.4、url_hash (제3자) 는 url 에 접근 한 hash 결과 에 따라 요청 을 할당 합 니 다. 모든 url 을 같은 백 엔 드 서버 로 지정 하고 백 엔 드 서버 가 캐 시 일 때 유효 합 니 다.
Upstream 설정 부하 어떻게 실현  

http {  
  
  upstream www.test1.com {
     ip_hash;
     server  172.16.125.76:8066 weight=10;
     server  172.16.125.76:8077 down;
     server  172.16.0.18:8066 max_fails=3 fail_timeout=30s;
     server  172.16.0.18:8077 backup;
   }
   
   upstream www.test2.com {
     server  172.16.0.21:8066;
     server  192.168.76.98:8066;     
   }


   server {
    listen    80;
    server_name www.test1.com;    
    
    location /{
      proxy_pass    http://www.test1.com;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }   
   } 
   
   server {
    listen    80;
    server_name www.test2.com;    
    
    location /{
      proxy_pass    http://www.test2.com;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

www. test1. com / www. test2. com 에 요청 이 있 으 면 해당 하 는 upstream 설정 서버 목록 에 배 포 됩 니 다.test 2 의 모든 요청 이 배 포 된 서버 는 무 작위 로 첫 번 째 상황 을 열거 합 니 다.test 1 은 ip 에 접근 하 는 hashid 에 따라 지정 한 서버 에 배포 되 었 습 니 다. 즉, 이 IP 의 요청 은 모두 이 지정 한 서버 로 전 환 된 것 입 니 다.
서버 자체 의 성능 차이 와 기능 에 따라 서로 다른 매개 변수 통 제 를 설정 할 수 있 습 니 다.
다운 은 부하 가 너무 무 겁 거나 부하 에 참여 하지 않 음 을 나타 낸다.
weight 가중치 가 너무 클 수록 대표 가 부담 하 는 부하 가 커진다.
다른 서버 를 백업 할 때 나 다운 할 때 만 백업 서버 를 요청 합 니 다.
max_fails 실패 가 지정 한 횟수 를 초과 하면 다른 서버 로 이동 을 일시 정지 하거나 요청 합 니 다.
fail_timeout 실패 지 정 된 횟수 를 초과 한 후 일시 정지 시간
이상 Nginx 의 부하 균형 에 대한 간단 한 설정 입 니 다.그럼 우리 의 이 절 토론 내용 을 계속 합 시다.
1. 세 션 문제
우리 가 일련의 부하 서버 를 확정 한 후에, 우리 의 WEB 사 이 트 는 이 서버 에 분 포 될 것 이다.이 럴 때 Test 2 를 사용 하여 모든 서버 에 무 작위 로 접근 할 것 을 요청 하면 A 서버 에 접근 한 후 다음 요청 은 갑자기 B 서버 로 넘 어 갑 니 다.이때 A 서버 와 만들어 진 Session 은 B 사이트 서버 에 전 달 된 것 은 정상적으로 응답 할 수 없 을 것 입 니 다.자주 사용 하 는 해결 방안 을 살 펴 보 자.

Session 또는 증빙서류 캐 시 를 독립 된 서버

Session 또는 증빙서류 저장 데이터베이스 중

nginx ip_hash 같은 IP 유지 요청 은 고정된 서버

로 지 정 됩 니 다.
첫 번 째 캐 시 방식 은 비교적 이상 적 이 고 캐 시 효율 도 비교적 높다.그러나 모든 요청 서버 가 세 션 세 션 세 션 서버 에 접근 하 는 것 은 세 션 서버 의 부담 을 가중 시 키 는 것 이 아 닙 니까?
두 번 째 는 데이터베이스 에 저장 되 는데 Session 의 유효기간 을 제어 하 는 동시에 데이터 뱅 크 의 부담 을 가중 시 키 기 때문에 최종 적 으로 SQL Server 부하 균형 으로 바 뀌 었 고 읽 기, 쓰기, 만 료, 동기 화 와 관련된다.
세 번 째 는 nginx iphash 부하 가 같은 서버 에 대한 세 션 을 유지 하 는 것 이 가장 편리 하고 가 벼 워 보 입 니 다.
정상 적 인 상황 에서 구조 가 간단 하 다 면, iphash 는 세 션 문 제 를 해결 할 수 있 지만 다음 과 같은 상황 을 살 펴 보 겠 습 니 다.
이때 iphash 가 받 은 요청 은 모두 고정 IP 에이전트 의 요청 입 니 다. 프 록 시 IP 의 부하 가 너무 높 으 면 iphash 에 대응 하 는 서버 부하 압력 이 너무 커서 iphash 는 부하 균형 을 잃 었 다.
캐 시가 동기 화 공 유 를 실현 할 수 있다 면, 다 중 세 션 서버 를 통 해 단일 부하 과중 문 제 를 해결 할 수 있 습 니 다.그럼 Memcached 는 세 션 캐 시 서버 를 만 들 수 있 습 니까?Memcached Provider 는 Session 기능 을 제공 하여 곧 Session 을 데이터베이스 에 저장 합 니 다.그런데 왜 데이터베이스 에 직접 저장 하지 않 고 Memcached 를 통 해 데이터베이스 에 저장 합 니까?간단 합 니 다. 데이터베이스 에 직접 저장 하면 세 션 의 유효성 을 데이터베이스 로 검증 해 야 합 니 다.그 다음 에 우리 가 데이터 베 이 스 를 위해 캐 시 를 만 들 더 라 도 이 캐 시 는 분포 식 공 유 를 실현 할 수 없 으 며 같은 캐 시 서버 에 과부하 가 걸 립 니 다.인터넷 에서 도 Memcached 로 Session 캐 시 를 실현 하 는 성공 사례 를 볼 수 있다. 물론 데이터 베이스 방식 이 실현 되 는 것 은 비교적 자주 사용 되 는 것 이다. 예 를 들 어 오픈 소스 Disuz. net 포럼 이다.캐 시 가 실현 하 는 작은 범위 분포 식 도 비교적 자주 사용 되 는데 예 를 들 어 단일 로그 인 도 특수 한 상황 이다.
파일 업로드
부하 균형 이 잡 히 면 세 션 문제 외 에 도 파일 업로드 와 다운로드 문제 에 부 딪 힐 수 있다.파일 이 다른 서버 에 업로드 되 지 않 으 면 해당 파일 을 다운로드 하지 못 하 는 문제 가 발생 할 수 있 습 니 다.다음 방안 을 살 펴 보 겠 습 니 다.

독립 파일 서버 

파일 압축 데이터베이스

두 가지 방안 은 모두 자주 사용 되 는 것 이다. 우 리 는 파일 압축 데이터 베 이 스 를 말 해 보 자. 예전 의 방식 은 모두 파일 바 이 너 리 를 관계 형 데이터 베이스 로 압축 하 는 것 이 었 는데 지금 은 NOSQL 이 유행 하 는 데다 가 MongoDB 처리 파일 도 비교적 편리 하기 때문에 파일 압축 라 이브 러 리 에 또 하나의 선택 이 생 겼 다.파일 서버 의 효율 과 관리, 보안 이 데이터베이스 에 미 치지 못 하기 때문이다.
이런 일 을 마음대로 이야기 하 는 것 은 바로 응용 추세 와 여러 가지 해결 방안 의 실현 이다.