DevOps/NGINX

NGINX MSA 디지털 트레이닝 - 3강 : Load Balancing

갈색왜성 2022. 3. 13. 03:29
반응형

강의 동영상 : https://www.youtube.com/watch?v=sLoBvXNPTmk
원본 동영상 : https://www.youtube.com/watch?v=a41jxGP9Ic8

1. What is Load Balancing

1.1 Definition

Load Balancing is defined as the methodical and efficient distribution of network and application traffic across multiple servers in a server farm.

그림과 같이 Load Balancer는 클라이언트와 백엔드 서비스 사이에 위치해서 클라이언트로부터 Request를 받아 해당 Request를 수행할 수 있는 upstream 서비스 또는 Instance로 전달하는 역할을 수행한다

1.2 HTTP Load Balancing in NGINX

  • Client Request를 처리할 Server pool 혹은 group을 설정
  • proxy_pass 명령어를 통해 Client Request가 전달될 Server Pool이나 group을 지정.
  • Server는 IP address + Port number, Domain Name 또는 Unix Socket 으로 정의됨.

2. Load Balancing Configuration

2.1 주요 Directives

  • upstream

    • Server pool 설정
    • HTTP Context 내에 위치
  • proxy_pass

    • request를 정의된 upstream으로 전달.
  • Ex)

    upstream backend_servers { 
        server 192.168.10.1:9001; 
        server 192.168.10.2:9001; 
    } 
    server { 
        listen 80; 
        location / { 
                proxy_pass  http://backend_servers; 
         } 
    }
    • Line 1~4 : 10.1.1.4:9001, 10.1.1.5:9001 두 대의 Backend Server를 backend_servers라는 이름의 pool로 정의.
    • Line 5~10 : 80 port의 root path로 요청된 request를 backend_servers로 정의된 pool로 전달.

2.2 Load Balancing 방식

  • Round Robin
    • Default 방식. 각각의 Request들이 Server Group에 속한 개별 서버로 고르게 전달된다.
    • Ex) 192.168.10.1~3 3개의 서버에 차례대로 Request가 전달되게 된다.
    • upstream backend_servers { server 192.168.10.1:9001; server 192.168.10.2:9001; server 192.168.10.3:9001; }
  • Server Weights
    • 각각의 서버들이 가진 가중치를 더한 후에 (각 서버의 가중치) / (총 가중치) 만큼 개별 서버로 Request들이 분산 전달된다.
    • Ex) 각각 5,3,2의 가중치가 있고 20번의 Request가 오면 192.168.10.1에게 10개(=20 * 5 / (5+3+2))의 Request가 전달되고 192.168.10.2에게 6개(=20 * 3 / (5+3+2)), 192.168.10.3에게 4개(=20 * 2 / (5+3+2))의 Request가 전달되게 된다.
    • upstream backend_servers { server 192.168.10.1:9001 weight=5; server 192.168.10.2:9001 weight=3; server 192.168.10.3:9001 weight=2; }

2.3 Load Balancing 중 Fail 처리

  • Server Pool에 포함된 서버들 중에서 응답하지 않는 것으로 확인되는 서버를 제외할 수 있다.

  • max_fails : 최대 연결 시도 횟수를 저정.. 이 횟수만큼 서버가 응답이 없으면 죽은 것으로 가정해서 Request 전달에서 제외된다.

  • fail_timeout : 최대 연결 실패에 대한 시간 제한 지정 및 다시 재시도 하기까지 Request를 전달하지 않는 시간 지정

  • Ex) 192.168.10.1은 최대 90초 내에 10번의 연결 시도가 실패하게 되면 해당 서버는 죽은 것으로 가정하고 90초 동안은 다시 연결 시도를 하지 않게 된다.

    upstream backend_servers {
        server 192.168.10.1:9001 weight=5 max_fails=10 fail_timeout=90s;
        server 192.168.10.2:9001 weight=3 max_fails=4 fail_timeout=60s; 
        server 192.168.10.3:9001 weight=2 max_fails=2 fail_timeout=30s;
    }

2.4 Advanced Load Balancing in NGINX

  • hash

    • MD5 hash algorithm을 사용해서 Client request 중 하나를 key로 해서 Hash 겂을 계산 하고 그 값에 따라 특정한 서버로 Request전달.

    • Frontend 요청 보다는 backend나 Firewall 뒤에서 사용.

    • Remark : 세션 정보를 유지할 수 있기 때문에 새로운 Server가 추가되거나 기존 서버가 제거될 때는 Hash값이 손상되면서 세션 정보가 손실된다.

    • Ex) Request URI를 기반으로 한 경우 : target URI가 /api/a면 Request가 모두 1번 서버로 전달되고, target URI가 /api/b면 모두 3번 서버로 전달된다.

      upstream backend_servers {
          hash $request_uri;
          server 192.168.10.1:9001;
          server 192.168.10.2:9001;
          server 192.168.10.3:9001;
      }

  • ip_hash

    • 위의 hash와 동일. 단 Client IP를 key로 해서 Hash 값을 생성.

    • Client IP를 key로 사용하기 때문에 특정 Client에서 오는 요청을 특정 Server가 다 처리하게 된다.

    • Remark : 앞단에 Reverse Proxy와 같은 것이 있을 경우 모든 요청이 하나의 서버로만 전달되는 문제가 발생할 수 있음.

    • Ex) 아래와 같이 설정할 경우, 그 아래 그림처럼 A,D 사용자가 보낸 Request는 모두 1번 서버로, B가 보낸 Request는 모두 2번 서버로, C가 보낸 Reques는 모두 3번 서버로 전달하는 식으로 동작한다.

      upstream backend_servers {
          ip_hash;
          server 192.168.10.1:9001;
          server 192.168.10.2:9001;
          server 192.168.10.3:9001;
      }

  • least_conn

    • consecutive connection의 수가 가장 적은 서버로 Request를 전달

    • 연결 수가 동일한 경우 round robin 방식에 의해 서버가 선택됨.

    • Remark. weight가 설정되었을 경우 weight 값을 고려해서 최소 연결수를 계산함. 가중치 1인 1번 서버에 5개의 연결이 있고, 가중치 2인 2번 서버에 8개의 연결이 있으면 (5 / 1) > (8 / 2) 이기 떄문에 2번 서버로 Request가 전달된다.

    • Ex)

      upstream backend_servers {
          least_conn;
          server 192.168.10.1:9001;
          server 192.168.10.2:9001;
          server 192.168.10.3:9001;
      }
  • least_time (NGINX Plus 만 지원)

    • 평균 Response Time이 가장 빠르고 Active Connection 수가 가장 적은 서버로 Request를 전달.

    • 평균 Response Time을 측정할 때 사용하는 인자들에는 다음과 같은 것들이 있다.

      • header : Server에서 첫번째 Byte가 도착하는 시간
      • last_byte : Server에서 전체 Response가 도착하는 시간
      • last_byte inflight : 불완전한 request를 고려해서 Server에서 전체 Response가 도착하는 시간
    • Ex) least_time을 header로 설정한 경우

      upstream backend_servers {
          least_time header;
          server 192.168.10.1:9001;
          server 192.168.10.2:9001;
          server 192.168.10.3:9001;
      }
  • random (NGINX Plus 만 지원)

    • Server를 Random하게 선택해서 Request를 전달.

2.5 Session Persistence

  • NGINX plus에서 제공되는 기능으로 사용자 Session을 식별하고 해당 Session의 요청을 동일한 Server로 라우팅 하는 것을 의미
  • Session Persistence는 'sticky'명령어를 사용해서 3가지 방법으로 제공된다

2.5.1 sticky cookie

  • 맨처음 upstream group response에 대해 Cookie를 추가해서 특정 서버를 식별하고, Client의 다음 Request에서 이 Cookie를 사용할 때 응답을 보낸 Server로 다시 전달될 수 있게 한다.
  • Ex) srv_id라는 Cookie를 설정하고 1시간동안 유지되며, 쿠키를 설정한 Domain과 Path를 정의한 예
  • upstream backend_servers { server 192.168.10.1:9001; server 192.168.10.2:9001; server 192.168.10.3:9001; sticky cookie srv_id expires=1h domain=.abc.com path=/; }
  • Demo에서 lb_example로 정의된 Cookie를 설정해서 Client로 보낸 경우

2.5.2 sticky route

  • 클라이언트로부터의 첫 요청에 대해 "Route"를 할당하고, 이후 요청을 route 인자의 paramter와 비교해서 서버를 식별한다.

  • Route 정보는 cookie나 request URI로부터 가져온다.

  • Ex)

    upstream backend_servers {
            server 192.168.10.1:9001;
            server 192.168.10.2:9001;
            server 192.168.10.3:9001;
            sticky route $route_cookie $route_uri;
    }

2.5.3 sticky learn (?)

  • Request와 Response를 검사해 Session Identifier를 찾고, 이게 어떤 Server와 관련있는 지 "학습"하게 된다.

  • 일반적으로 이런 identifier가 HTTP cookie로 전달되고, 이 값을 통해 해당 Server로 Request가 전달됨.

  • Ex)

    upstream backend_servers {
        server 192.168.10.1:9001;
        server 192.168.10.2:9001;
        server 192.168.10.3:9001;
        sticky learn
                create=$upstream_cookie_examplecookie
                lookup=$cookie_examplecookie
                zone=client_sessions:1m
                timeout=1h
    }

2.6 기타

  • max_conns : 서버가 처리할 수 있는 최대 동시 연결 수를 설정
  • queue : max_conns로 설정한 최대 동시 연결 수를 넘어서 처리되지 않은 요청을 대기 시키는 Queue.
  • Ex)
    • 192.168.10.1은 최대 300개의 연결을 지원하고, 그 이상의 Request중 100개를 queue에 대기시킴.
    • Queue에 대기 상태로 있는 Request 중 70초를 넘는 Request는 HTTPS Status Code 503이 Client에 전달되게 됨.
  • upstream backend_servers { server 192.168.10.1:9001 max_conn=300; server 192.168.10.2:9001; server 192.168.10.3:9001; queue 100 timeout=70; }

3. Demo에서 기록할만한 사항들

  • HTTP Custom Header 추가 : 해당 서버의 ID (Application 1) 정보를 포함한 Response Header 추가

    server {
        listen    9001;
        index   index.html;
        add_header   Custom-Header   "Applicaion 1";
        ...
    }
  • curl -sI [ip-address:port | domain name] : Http Response Data를 제외한 Header 부분만 확인

  • 반복 Request 예제

    while true; do curl -sI <load-balancer-ip:port> | tr -d '\r' | sed -En 's/^Custom-Header: (.*)/\1/p'; sleep 1; done