Load Balancing 로드 밸런싱이란 서버에 주는 부하의 균형을 맞추어 주는 작업이다. 즉, 2대 이상의 서버가 동일한 역할을 수행하는 경우 각 서버들의 부하의 균형을 찾아 원활한 서비스를 가능하게 하는 과정이다. Scale Up, Scale Out 서버에 부하가 커졌을 경우 두 가지 방법중 하나를 택할 수 있다. Scale Up
: 기존 서버의 성능을 향상시킨다. 즉, 좋은 서버를 사서 쓴다. 다만, 좋은 건 비싸다. 비용과 성능이 같은 비율로 올라간다면 좋겠지만, 대게는 그렇지 못하다.물론, 그럼에도 불구하고 Scale Up
을 선택해야 하는 경우도 존재한다. 서버의 역할이 단일 요청에서 높은 수준의 연산처리를 요구하는 경우에는 Scale UP
방식이 적합하다. 10명의 대학원생보다 교수 혼자 하는게 낫다. 또한, 분산처리로 인한 데이터 정합성을 유지하기 힘든 경우에도 Scale Up
방식을 고려할 수 다. Scale Out
: 동일한 성능의 서버를 여러대 이어붙인다. 서버의 각격대비 성능비가 좋지 못하기 때문에, 비용을 절약할 수 있다. 일반적인 웹 서비스 같은 경우에 많이 사용된다. 대학원생 10명이 복사는 교수보다 잘할것이다. 대학원생은 저렴하다. Load Balancing Algorithm Round Robin
모든 서버에 우선 순위를 두지 않고 돌아가며 요청을 처리하는 방식이다. 여러 대의 서버가 동일 스펙을 갖고 있고, 다음 다음 순서까지 세션이 지속되지 않을 만큼 예상 연결시간이 짧은 경우 사용한다. Weighted Round Robin
: 가중 라운드 로빈 방식. 서버간의 스펙차이가 있는 경우에 밸런싱 비율을 정해주는 방식이다.robin이라는 새가 새끼들에게 먹이를 돌아가며 주는 것에서 유래 했다는 스토리도 있다. 사발통문처럼 이름을 둥글게 써넣은 것에서 유래했다는 스토리도 있다. Least Connection
요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 분배하는 방식이다. 세션 길이의 변화가 큰 경우에 적합하다. Source IP Hash
클라이언트 IP 주소를 특정 서버에 매핑하여 요청하는 방식이다. 클라이언트는 항상 같은 서버로 접속을 유지할 수 있다는 특징이 있다. NGINX && UPSTREAM NGINX
에는 LOAD BALANCING을 구현할 수 있는 Upstream
모듈을 지원한다.Upstream
이란 Origin
서버를 의미하며, 요청의 최종 목적지를 의미하며, 여기서 NGINX
는 Downstream
서버의 역할을 하게된다. Test 테스트를 위하여 GCP compute engine
3대를 빌렸다. 1대는 Downstream
즉 로드 밸런서의 역할을 하고 나머지 두 대는 각 각 Upstream
역할을 담당한다. nignx의 서버 설정의 http 항목에 넣어주면 되며, 아래와 같은 형식으로 입력해주면된다. upstream name {
server host : port [ option ];
...
}
optionip_hash
: 같은 방문자로부터 도착한 요청은 항상 같은 업스트림 서버가 처리 할 수 있게 한다.weight=n
: 업스트림 서버의 비중을 나타낸다. 이 값을 2로 설정하면 그렇지 않은 서버에 비해 두배 더 자주 선택된다.max_fails=n
: n으로 지정한 횟수만큼 실패가 일어나면 서버가 죽은 것으로 간주한다.fail_timeout=n
: max_fails가 지정된 상태에서 이 값이 설정만큼 서버가 응답하지 않으면 죽은 것으로 간주한다.down
: 해당 서버를 사용하지 않게 지정한다. ip_hash; 지시어가 설정된 상태에서만 유효하다.backup
: 모든 서버가 동작하지 않을 때 backup으로 표시된 서버가 사용되고 그 전까지는 사용되지 않는다. # nginx,conf
upstream balancer {
# default : round-robin
server 34.64.91.68 : 3000 weight = 2 ;
server 34.64.188.133 : 3000 ;
keepalive 100 ;
}
server {
listen 80 ;
location / {
proxy_pass http :// balancer ;
}
}
별도의 설정을 하지 않고 round-robin
을 사용했으며,weight=2
를 통해 2:1의 비율로 요청을 분산했다. keepalive 100
을 통해 100개의 요청에 대하여 tcp connection을 유지하도록했다. 로드밸런서와 origin서버간의 통신도 tcp connection이기 때문에 handshake
가 발생하며, keepalive
설정이 없다면 단 한번의 요청이후 소켓이 끊어지게된다.불필요한 handshake
가 매 요청마다 진행되고, 다 수의 time-wait
소켓이 생성되어 서버 성능에 악영향을 줄 수 있다.
refer https://m.post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903 https://brunch.co.kr/@alden/11 https://opentutorials.org/module/384/4328