로드 밸런싱이란,

서버에 가해지는 부하(로드, Load)를 분산(Balancing)해주는 장치 또는 기술

왜 로드 밸런싱을 사용하는가?

• 문제 : 서버에 접속한느 클라이언트의 수가 늘어나게 되면 기존 서버만으로는 정상적인 서비스가 불가능해짐
• 해결책 (2가지)
  • Scale Up : 단일 서버 자체의 성능 향상
  • Scale Out : 여러대의 서버를 두는 방법 -> 이 방식은 트래픽을 여러 서버로 균등히 나눠주는 로드밸런싱이 반드시 필요하다!

로드 밸런싱 역할

• 네트워크 트래픽 또는 클라이언트의 요청을 여러 서버에 적절히 분배가능함
• Active한 서버에게만 요청을 전송함. (만약 서버가 Down상태라면 Redirect -> 높은 신뢰성, 가용성을 보장)
• 서비스 중단없이 서버를 추가하거나 뺄 수 있음 (유연성 향상)
  

+) ✔️ 참고 : 하드웨어의 향상 비용이 더욱 비싸며, 서버가 여러대면 무중단 서비스를 제공한느 환경 구성이 용이해진다. 따라서 현재 흔히 사용하는 해결책은 Scale Out이다.

로드 밸런싱 종류

⛳ 'OSI 7 Layer를 기준으로 부하를 어떻게 분산할지'에 따라 종류가 나뉨. 따라서 2,3계층을 기준으로 나누고자 한다면 L2, L3인 방식이다.
로드 밸런싱에는 L4 로드 밸런서와 L7 로드 밸런서가 가장 많이 사용된다. 그 이유는 L4 로드 밸런서부터 포트 번호를 바탕으로 로드(부하)를 분산하는 것이 가능하기 때문이다.

L4 로드 밸런서

• 4 Layer 이하의 모든 계층의 정보를 가지기 때문에 IP 주소와 포트 번호 등을 로드 밸런싱에 활용
• 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드 밸런서 이상을 사용해야 함.

L7 로드 밸런서

• HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능 (즉, 패킷의 내용을 확인해서 그 내용에 따라 트래픽을 특정 서버에 전송하는 것이 가능)
• L7 로드밸런서는 서버의 응답까지도 알고 분석할 수 있다. 서버들로부터 필요한 정보를 응답 받아 클라의 요청을 전달하기 전에 서버의 상태를 파악한 후 로드밸런싱을 진행할 수 있음.

로드 밸런서의 서버 선택 방식

1. 라운드 로빈(Round Robin)

CPU 스케줄링의 라운드 로빈 방식과 동일하다. 가장 많이 사용되는 알고리즘이다.
즉, 프로세스가 할당받은 시간(time slice, time quantum) 동안 작업을 하다가 작업을 완료하지 못하면 ready queue의 맨 뒤로 가서 자기 차례를 기다리는 방식이다.

2. 가중 라운드 로빈(Weighted Round Robin)

각 서버에 처리량(가중치)를 지정한 후, 가중치가 높은 서버에 우선적으로 요청을 전달함. 특정 서버가 사양이 더 좋은 경우에 주로 사용함.
예시)
예를 들어, A 서버(가중치 3)와 B 서버(가중치 1)가 있고 로드 밸런서가 클라로부터 총 8개의 요청을 받았다면, A와 B 서버에 각 6개와 2개의 요청이 전달된다.

3. 최소 연결 방식 (Least Connections)

요청이 들어온 시점에서 가장 적게 연결되어 있던 서버에 요청을 전송하는 방식. 서버에 분배된 트래픽이 일정하지 않을 경우 주로 사용함.

4. 최소 응답 시간(Least Response Time)

서버의 현재 연결 상태와 응답 시간을 모두 고려하여 가장 짧은 응답 시간을 가지는 서버에게 우선적으로 요청을 보내는 방식

5. IP해시

클라이언트의 IP주소가 어떤 서버로 클라이언트의 요청이 전달될지를 결정하는 방식이다. IP주소가 바뀌지 않으면 동일한 서버로 요청이 전달되는 것이 보장됨. 라운드 로빈과 달리 서버에 Session Clustering이 구성되어 있지 않은 경우에 사용된다.

🎯 Session Clustering 이란,
여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하도록 만드는 것을 클러스터링이라고 한다. Session Clustering 역시 각 WAS의 세션을 묶어 관리하는 것이다.
이렇게하면 사용자가 같은 묶음으로만 접속한다면 동일한 세션 데이터를 받을 수 있도록 보장할 수 있다. 한 서버에 고정되지 않아도 되므로 트래픽 쏠림 문제를 해결할 수 있고, 개별 서버가 터지더라도 세션 정보를 유지할 수 있게 된다