서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술
사업의 규모가 확장되고, 클라이언트의 수가 늘어나게 되면 기존 서버만으로는 정상적인 서비스가 불가능하게 되는데, 이러한 증가한 트래픽에 대처할 수 있는 방법은 크게 두 가지임
Scale Out 방식은 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드밸런싱이 반드시 필요함!
물리적인 서버에서 Scale Out하는 건 한계가 있음(메인보드에는 그래픽 카드를 최대 2개밖에 장착하지 못함)
-> 하지만 클라우드는 공간의 제약이 없기 때문에 Scale Out이 무한대로 가능함💡 AWS의 Auto Scaling
- Scale Out을 자동화해주는 서비스
- 애플리케이션을 모니터링해서 용량을 자동으로 조절함(자동으로 Scale In/Out 해줌)
- EC2 인스턴스들을 그룹으로 구성(=Auto Scaling 그룹)하고 최소/최대 인스턴스 수를 지정하면 이 범위 안에서 Scale In/Out이 일어남
- Auto Scaling 그룹을 로드 밸런서에 연결할 수 있음
로드밸런서는 클라이언트와 서버풀(=서버팜, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치함
서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식
각 서버에 가중치를 매기고 가중치가 높은 서버에 요청을 우선적으로 배정하는 방식
클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식
요청이 들어온 시점에 가장 적은 연결 상태를 보이는 서버에 트래픽을 배정하는 방식
서버의 응답시간을 측정하여 가장 빠른 응답을 보인 서버에게 요청을 전달하는 방식
‘OSI 7계층을 기준으로 부하를 어떻게 분산할지’에 따라 종류가 나뉨
즉, 로드밸런서의 종류로는 L2, L3, L4, L7이 있고, 로드 밸런싱에는 L4와 L7이 가장 많이 사용됨
L4 로드밸런서부터 포트 번호를 바탕으로 로드를 분산하는 것이 가능하기 때문이고, 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드 밸런서 이상을 사용해야 함
4계층(네트워크 계층)이나 3계층(전송 계층)의 정보를 바탕으로 로드를 분산함 → IP 주소, 포트번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽 분산 가능
7계층(애플리케이션 계층)에서 로드를 분산하기 때문에, HTTP 헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽 분산 가능
L4 로드밸런서의 기능을 포함하며, 추가로 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능함
특정한 패턴을 지닌 바이러스를 감지해 네트워크 보호가 가능함
Dos/DDos와 같은 비정상적인 트래픽 필터링이 가능함
방식
장점
단점
https://velog.io/@jisoo1170/Load-Balancing이란
https://chunsubyeong.tistory.com/106
https://co-no.tistory.com/22
https://m.post.naver.com/viewer/postView.naver?volumeNo=27046347&memberNo=2521903
https://velog.io/@lom/로드-밸런싱-알고리즘-별-장단점
https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-EC2-%EC%98%A4%ED%86%A0-%EC%8A%A4%EC%BC%80%EC%9D%BC%EB%A7%81-ELB-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-%EA%B0%9C%EB%85%90-%EA%B5%AC%EC%B6%95-%EC%84%B8%ED%8C%85-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#%EC%8A%A4%EC%BC%80%EC%9D%BC_%EC%95%84%EC%9B%83scale_out