
프록시에는 크게 클라이언트와 상호작용하는 포워드 프록시와 서버와 상호작용하는 리버스 프록시가 존재한다.
이 중 리버스 프록시의 기능 중 하나가 로드 밸런싱으로 애플리케이션을 지원하는 리소스 풀에 들어오는 네트워크 트래픽을 여러 서버들로, 분산시켜, 서버의 부하를 줄여준다. 더불어 일반적으로 AWS에서는 이 로드 밸런서를 통해서 https를 적용하며, 로드밸런서에 인증서를 설치해서, 암,복호화를 적용해서 보안을 강화할 수 있다.
AWS에서는 다음과 같은 작업을 통해서 로드 밸런싱을 수행한다.
1. 클라이언트가 요청을 보낸다.
2. 보낸 요청이 http(80)인지 https(443)인지 판별한다.
3. 보낸 요청이 http요청이라면 안전하지 않은 요청이므로, 클라이언트로
리다이렉션 코드를 보내고, https 요청이라면 80포트로 포워딩을 통해서,
서버로 http코드를 보낸다.
모든 요청이 순서대로 서버에 분배 되는 방식이다.
A,B,C라는 서버가 있고, 요청이 6개가 있을 때, ABCABC로 그냥 순서대로 분배된다.
이 알고리즘은 매우 단순하고, 고르게 분산된다는 장점이 있지만, 현재 서버의 부하, 응답시간, 처리 능력이 다른 경우를 고려하지 않기 때문에 비효율적이라는 단점이 있다.
각 서버에는 처리능력과 자원을 활용할 수 있는 능력이 다른경우가 많다.

따라서 각 가중치를 두어서, 조금 더 많은 요청을 처리할 수 있는 서버에 높은 가중치를 두어서, 로드 밸런서에서 요청을 분배한다.
물론 서버의 처리 능력은 고려하기에, 기존의 Round Robin보다는 낫다고 보여진다. 하지만, 현재 연결 수행중인 task에 대해서는 고려하지 않기에 여전히 부족한 점이 있다.
Least Connection은 각 서버의 활성 연결수를 모니터링해서 가장 적은 연결을 하고 있는 서버에 요청을 전달한다.
이 방식은 서버의 처리 능력은 반영하지 않기에, 서버의 처리 능력이 비슷한 경우에 고려할 수 있다.
이 방식은 Weighted Round Robin 방식과 Least Connection을 결합한 방식이다.
현재의 각 서버의 활성연결이 적은지와, 서버의 처리능력인 가중치, 이 두가지를 모두 고려해서 서버에 요청을 할당한다.

수식으로 따지만 이런 느낌이다.
즉 Connection수가 적을 수록 가중치가 높을 수록 해당 서버로 요청을 할당할 가능성이 높아진다.
각 서버마다 응답시간이 다른 경우에 활용된다.
각 서버중 응답시간이 가장 빠른 서버에 요청하는 방식이다.
이게 과연 서버의 부하상태, 서버의 task 처리 상태등을 반영할 수 있는지는 의문이고, 적합하지 않다고 보여진다.
IP 주소를 기반으로 해싱을 통해서 서버에 할당하는 방식이다.
이를 통해서 각 서버에 유지되는 세션을 안정되게 유지할 수 있기에, 클라이언트의 상태에 관리해 용이하다.
하지만, 특정 IP만 계속 요청하게 된다면, 부하가 균등하게 이루어지지 않을 것이다.
