Load Blancing이란?
네트워크 애플리케이션 트래픽을 효율적으로 분배하는 것을 말한다.
클라이언트와 백엔드 서비스 사이에 위치하며,
클라이언트에서 들어오는 요청을 기반으로 해당 요청을 수행할 수 있는 upstream 서비스 또는 인스턴스로 요청을 전달한다.
LoadBalancing을 구성하기 위해서는 모든 수신 클라이언트 요청을 처리할 서비스 풀 또는 그룹이 필요하다
prox_pass 지시문은 이 요청을 풀에 전달한다.
그리고 풀 내의 서비스는 IP주소, 포트 번호, 도메인 이름, Unix 소켓의 조합으로 정의할 수 있다.
Load Balancing
CONFIGURATION
-
upstream directive
Describes server pool
Defined in HTTP Context -
proxy_pass
directive forwards request to upstream
upstream backend_servers{
server 10.1.1.4:9001;
server 10.1.1.4:9002;
}
server {
listen 80;
location / {
proxy_pass http://backend_servers;
}
}
여기서 중요한 것은 upstream 지시문이 http 컨텍스트 내에 있다는 것이다
proxy_pass 지시문을 사용하여 백엔드 서비스로 전달한다.
NGIX는 사용자가 정의한 로드 밸런싱 방법에 따라 적절한 서버를 선택한다.
(Default = 라운드 로빈)
1. LoadBalancing
1.1 Default mode
ROUND ROBIN
백엔드 서비스 풀 전체에 고르게 요청을 분산한다.
NGINX는 각 업스트림 또는 백엔드 서버에 가중치를 할당하는 이 메커니즘을 사용한다.
그리고 가중치를 커스터마이징 가능하다.
upstream bacckend servers{
server 10.1.1.4:9001 weight=2;
server 10.1.1.4:9002 weight=3;
server 10.1.1.4:9003 weight=5;
}
위와 같은 경우 전체 요청을 10이라고 하면 나줘서 배분한다.
default weight는 각각 1인 균등한 상태이다.1.2 Server Fails & Timeouts
upstream bacckend servers{
server 10.1.1.4:9001 weight=2 max_fails = 10 fail_timeout=90s;
# 90초 이내 10번이나 실패를 할 경우 제외를 한다
# 실패시점에서 90초가 지날 때까지 서버에 새 요청을 보내지 않는다.
server 10.1.1.4:9002 weight=3 max_fails = 4 fail_timeout=60s;
server 10.1.1.4:9003 weight=5 max_fails = 2 fail_timeout=30s;
}NGINX는 특정 횟수만큼 실패하면 server에서 제외할 수도 있다.
( 주요 파라미터는 max_fails, fail_timeout이 있다. )
max_fails는 서버가 사용 불가능으로 표시되기 전에 실패한 실행 연결 시도 횟수를 의미한다.
fail_timeout은 두 가지 특정 사항을 지정한다.
- 연속 실패에 대한 시간 제한과 서버가 사용할 수 없는 오류로 표시된 기간
1.3 Load Balancing Methods
- hash( ip_hash에 사용되는 기술 )
생성된 키 정보를 기반으로 특정 유형의 클라이언트 요청이 원래 연결되었던 동일한 서버로 전달된다.
( 백엔드 또는 방화벽 뒤에서 자주 사용이 된다. 그리고 세션 정보를 유지할 수 있다 )
하지만 새 서버를 추가하거나 풀에서 새 서버를 제거할 때마다
해시 키가 손실될 가능성이 높다.( 세션 정보가 무효화 )
- ip_hash
클라이언트 IP를 특정 키로 활용한다
- least_conn
연속 연결 수가 가장 적은 서버에 요청을 보낸다
- least_time ( NGINX PLUS )
평균 응답 시간이 가장 빠르고 활성 연결 수가 가장 적은 서버를 선택한다.
- random ( NGINX PLUS )
무작위로 선택된 서버에 요청을 전달한다.
2. Details in Method
2.1 hash
upstream backend_servers{
hash $request_uri;
server 10.1.1.4:9001;
server 10.1.1.4:9002;
server 10.1.1.4:9003;
}클라이언트 요청 URI를 사용하여 해시 키를 빌드한다
($request_uri는 NGINX가 요청 URI를 캡처하는 변수이다.)
만약 요청 URI가 /example인 클라이언트는 항상 동일한 서버에서 작동한다.
그리고 다른 URI를 가진 클라이언트는 다른 서버로 라우팅된다.
Ex)
/test1는 항상 1으로 간다
/test2는 항상 서버 2,3으로 이동한다.
또한 가중치를 추가할 수도 있다.
2.2 ip_hash
upstream backend_servers{
ip_hash;
server 10.1.1.4:9001;
server 10.1.1.4:9002;
server 10.1.1.4:9003;
}이전 hash 알고리즘과 매우 유사하다.
그러나 키는 이미 클라이언트 IP주소로 결정된다.
NGINX는 전체 IP주소를 사용 가능한 서버 수로 나눈다.
이것은 동일한 클라이언트의 요청이 동일한 서버로 보내는 것을 보장하지만,
이러한 애플리케이션 서비스 앞에 reverse_proxy 또는 proxy가 있다.
(모든 요청이 동일한 백엔드 서버로 라우팅될 수 있다)
만약 요청이 proxy에서 시작된 경우
서버는 모든 단일 요청이 프록시에서 오는 것으로 생각하고 동일한 서버로 라우팅을 한다.
2.3 least_conn
upstream backend_servers{
least_conn;
server 10.1.1.4:9001;
server 10.1.1.4:9002;
server 10.1.1.4:9003;
}동일한 수의 연결을 가진 여러 서버가 있는 경우
가중치 기반 라운드 로빈 방식이 해당 서버에 적용된다
ex) 서버 1 = 1, 서버 2 = 2 가중치를 가진다고 하면,
서버 2가 서버 1 보다 2배 더 많은 요청을 처리한다
여기서 서버 2가 활성 연결이 적다고 NGINX는 판단한다.
3. Enabling Session Persistence
3.1 Cookie (NGINX PLUS)
STICKY COOKIE
upstream backend_servers{
server 10.1.1.4:9001;
server 10.1.1.4:9002;
server 10.1.1.4:9003;
sticky cookie srv_id expires = 1h domain =.example.com pah=/;
}3.2 Route (NGINX PLUS)
STICKY ROUTE
upstream backend_servers{
server 10.1.1.4:9001;
server 10.1.1.4:9002;
server 10.1.1.4:9003;
sticky route $route_cookie $route_uri;
}3.3 Learn(NGINX PLUS)
STICKY LEARN
4. Other things to note
NGINX를 사용한 로드 밸런싱을 고려할 때 주의할 점은
구성할 수 있느 최대 연결 매개변수도 있다
따라서 최대 연결 매개변수는 서버가 처리할 수 있는 최대 동시 연결 수를 설정한다.
upstream backend_servers{
server 10.1.1.4:9001 max_conns=300;
server 10.1.1.4:9002;
server 10.1.1.4:9003;
queue 100 timeout=70;
}queue는 upstream이 최대 연결 제한수를 초과하는 처리되지 않은 요청을 대기열에 배치한다.
그래서 만약 서버1이 400개의 활성 연결이 제공된 경우, 100개는 대기열에 넣는다.
timeout은 대기열의 클라이언트에 503 오류르 보내기 전에 서버가 대기하는 시간을 제어한다.
