[네트워크] 로드 밸런서
수평확장 (horizental Scale out) 을 통해 여러 대의 서버로 증설이 될 경우
수 많은 트랙픽을 적절하게 분배하여 현재 트래픽을 감당할 수 있는 적절한 서버에 스위칭 해주는 장치가 로드 밸런서이다.
<로드 밸런서가 밸런싱 하는 방법>
1. 라운드 로빈
s1 -> s2 -> s3 -> s4 이렇게 순서대로 트래픽을 분산해준다.
2. least connection 방식
서버가 로드밸런서에게 현재 자신의 서버 상태를 전송해준다. (과부하 상태인지 여유 상태인지)
3. 가중치 기반 로드밸런싱(Weighted Load Balancing)
서버 스펙이 다를 때 이를 고려해 트래픽을 배분하는 로드밸런싱 방식
이러한 로드 밸런싱을 구현할 수 있는 방법에는 소프웨어적인 방식과 하드웨어적인 방식이 있다.
소프웨어적인 방식은 Nginx 같은 리버스 프록시로 적용 가능하다.
저렴하게 구현가능 하고 Scale-out 일 때도 쉽게 할 수 있다.
하드웨어적인 방식으로는 IDC 센터들 내의 물리서버들을 묶는 방식으로 이용한다. 여기에 L4, L7스위치가 사용된다.
안정성이 높고 시큐리티적인 측면에서도 우수하다.
로드밸런서를 하나만 두면 그 로드밸런서 자체가 단일 장애점(SPOF, Single Point of Failure )이 되기 때문에,
로드밸런서도 이중화(High Availability, HA)
L4 스위치
전송 계층 기반 로드밸런싱
TCP/UDP 포트 기반으로 트래픽을 분산
클라이언트 요청의 IP + Port 조합을 보고 서버를 선택 , 웹 서버, WAS 서버 등으로 트래픽을 단순하게 분산
- 패킷 내용을 깊게 보지 않음 (payload 분석 X)
- 속도가 매우 빠름 (커널 수준 패킷 처리)
- TCP/UDP 레벨에서 동작
- 다수의 연결 처리에 최적화
- 상태를 거의 보지 않고 단순 라우팅 → 가벼움
→ HTTP인지, 이미지 요청인지 알 수 없음
→ 단지 “Port 80으로 들어오면 서버 1~3 중 하나에 분배” 수준
L7 스위치
애플리케이션 계층 기반 로드밸런싱
HTTP(S), gRPC, WebSocket 등 요청의 내용까지 보고 트래픽을 분산
- HTTP Header 분석
- URL Path 분석
- 쿠키 기반 세션 스티키 운영
- 컨텐츠 기반 라우팅(Content-based routing)
- API 버전별 라우팅 가능
- 요청 내용을 “이해”하고 판단함
- 정교한 로드밸런싱 정책 가능
- SSL 종료(SSL Offloading) 가능
- 트래픽 제어(Throttle), 인증, 보안 기능 연동 쉬움
- 속도는 L4 대비 느리지만 기능은 압도적으로 다양
보통 API 게이트웨이 역할이나, URL 경로별로 다른 서버로 라우팅 할때 사용된다.
포워드 프록시
보통 클라이언트 앞단에 위치하여 클라이언트 대신 인터넷을 통해 외부서버에서 데이터 및 자원을 받아 클라이언트에게 대신 응답해줍니다.
이러한 포워드 프록시는 한 네트워크 내에서의 특정 사이트 접근 제한을 설정 할 수 있고
정적자원이나 페이지 정보 등을 캐싱하여 더욱 빠른시간 내에 결과값을 리턴해줍니다.
또한 클라이언트의 요청이 암호화 되고 ip를 감춰줄 수 있는 역할을 한다.
리버스 프록시
보통 웹서버 앞단에 위치하며 클라이언트는 이 리버스 프록시에 request를 날리고
이 리버스 프록시가 대신 받아 서버에게 전달해준다. 또한 서버는 리버스 프록시 서버로
데이터 및 자원을 전달하면 프록시가 대신 클라이언트에게 반환해줍니다.
부하 분산 (로브 밸런싱) 을 수행할 수 있는 장점이 있고,
얘 또한 캐싱기능을 제공하며 웹서버의 origin 주소를 감출 수 있어 보안에 좋다.