Load Balancer
서버로 요청하는 클라이언트의 수가 늘어나 액세스가 증가할 때, 어떻게 문제를 해결할 수 있을까?
- Scale-up : 서버의 하드웨어를 고성능으로 바꾸어 해결할 수 있다.
하지만 다수의 사용자가 집중적으로 액세스한다면, 아무리 고성능의 기종을 사용한다 해도 서버 한대로는 따라잡지 못할 수 있다. → 분산처리 필요
- 분산처리 : 복수의 서버를 사용하여 처리를 분담할 수 있다.
대표적인 분산처리 방법
여러 대의 웹 서버를 설치하고, 한 대가 담당하는 사용자의 수를 줄일 수 있다. 이때, 부하 분산 장치로서 Load Balancer를 이용할 수 있다.
Load Balancing 이란?
- 해야할 작업을 나누어서 서버의 부하를 분산시키는 것
Load Balancer 란?
- 여러 대의 서버가 분산처리 할 수 있도록 요청을 나누어주는 서비스
Load Balancer는 어떤 근거로 요청을 분배할까?
1. Request가 복수의 페이지에 걸쳐 있지 않을 때
일반적인 방법
- Request가 복수의 페이지에 걸쳐 있지 않은 단순한 액세스라면, 웹 서버의 부하 상태를 근거로 Request를 전송한다.
- 이때 서버의 부하 상태는 시험 패킷과 같은 것을 이용하여 웹 서버에 보내 응답 시간으로 부하를 판단할 수 있다.
다른 방법
- 너무 자세한 상황을 조사하려면 부하를 조사하는 동작 자체로 웹 서버에 부하가 증가해 버린다.
- 그래서 부하를 조사하지 않고 미리 웹 서버에 능력을 설정한 후 웹 서버의 성능 비율에 따라 Request를 분배하는 방법도 있다.
2. Request가 복수의 페이지에 걸쳐있을 때
- 웹 서버의 부하와 관계없이 이전의 Request와 같은 웹 서버에 전송해야 한다.
Load Balancer의 종류
L2 : 맥 주소를 바탕으로 로드밸런싱
L3 : IP 주소를 바탕으로 로드밸런싱
L4
- 전송 계층에서의 로드밸런싱
- 요청을 담당하는 여러 대의 서버로 로드밸런서가 요청을 나누어준다.
L7
- 응용 계층에서의 로드밸런싱
- https://velog.io/@oyeon 주소로 요청이 들어올 때, 뒤에 /OSI-7-Layer, /웹-소켓WebSocket 같이 뒤에 붙는 URL에 따라서 담당 서버들로 요청을 나누어주는 것을 의미한다.
Proxy
- 클라이언트와 서버 사이의 위치에서 그들간의 http 메시지를 정리하는 대리인처럼 동작
- 서버와 클라이언트간의 중계 서버로서 통신을 대신 수행하는 역할
- 클라이언트의 대리 역할을 하기도 하고, 서버의 대리 역할을 하기도 한다.
Forward Proxy
- 클라이언트와 인터넷 사이에 위치해서(Proxy가 내 컴퓨터 가까이 있다) 클라이언트 대신 서버에 요청(Request)을 보내주는 역할
- 로컬 네트워크와 인터넷 사이를 오가는 트래픽을 제어할 수 있는 이점이 있다.
- 예를 들어, 초등학교 같은 곳에서 학생들이 부적절한 콘텐츠를 브라우징하는 것을 막기 위해서 이러한 구조를 통해 필터링을 걸 수 있다.
Reverse Proxy
- 서버와 인터넷 사이에 위치해서(Proxy가 서버 가까이 있다) 서버의 응답(Response)을 대신 클라이언트에게 전달해 주는 역할
- 네트워크의 가장 끝에 있는 웹 서버의 바로 앞에 위치한다. 따라서, 웹 서버를 향하는 모든 요청을 처리할 수 있다.
- 웹 서버의 보안 기능을 추가하거나, 빠른 웹 서버 캐시를 느린 웹 서버 앞에 놓음으로써 성능을 개선할 수도 있다.
Proxy 서버가 배치될 수 있는 추가적인 방법
입구(접근) 프록시
- 인터넷 서비스 공급자(ISP) 접근 지점에 위치하여 속도를 개선
- 특히 고속 접속 사용자들을 위해 다운로드 속도를 개선하고, 인터넷 대역폭 비용을 줄이기 위해서 캐시 프록시를 이용해 많이 찾는 요청들을 저장하는 프록시 구조
네트워크 교환 프록시
- 캐시를 이용해서 인터넷 혼잡을 완화하고 트랙픽을 감시
- 충분한 처리 능력을 갖춘 프록시가 네트워크 사이인 인터넷 교환 지점에 놓일 수 있다.
왜 Proxy를 사용할까?
1. 필터
- 예를 들어, 학교에서 프록시는 허용한 컨텐츠에는 제한없는 접근을 허용하면서, 학생에게 부적절한 사이트에 접근을 거부할 수 있다.
2. 접근 제어
- 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 추적을 위해 사용
- 예를 들어, 특정 클라이언트만 접근할 수 있는 콘텐츠가 서버에 있다고 할 때 허가된 클라이언트는 접근을 허용하되, 그렇지 않은 클라이언트가 접근하려고 요청한다면 비밀번호를 요구하는 등 할 수 있다.
3. 캐싱
- 서버까지 거치지 않고 바로 프록시에서 캐싱된 정보를 이용해 응답할 수 있다.
- 프록시 캐시는 인기있는 요청을 관리하고 해당 요청이 온다면 서버까지 거치지 않고 바로 프록시에서 응답하여 느리고 비싼 커뮤니케이션 비용을 줄일 수 있다.
4. 익명화
- HTTP 메시지에서 신원을 식별할 수 있는 특성을 제거함으로써 개인 정보 보호와 익명성 보장에 기여할 수 있다.
- 즉, 클라이언트 요청이었으나 프록시 요청인 것처럼 위장할 수 있고, 리버스 프록시의 경우 서버인 척 응답을 보내기 때문에 보안에 기여할 수 있다.
5. 로드 밸런싱
- 리버스 프록시가 할 수 있는 특성
- 서버가 요청을 나누어 가질 수 있도록 프록시에서 결정할 수 있다.
정리