프록시와 로드밸런싱을 아라보자
Load Balancing
서버가 처리해야 하는 업무를 여러 대의 서버로 나누어 처리하는 것. 한대의 서버로 부하가 집중되지 않도록 트래픽을 관리하여 각 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것.
서비스 규모가 늘어나면 이를 분산하기 위한 방법으로 두가지 방법이 있다.
- Scale - Up
CPU, 메모리 등 하드웨어 기능을 업그레이드한다. 비용이 기하급수적으로 증가한다. 하나의 서버에 웹 서비스를 제공하므로 서버 장애시 가용성에 문제가 발생한다.
- Scale - out
저렴한 노드를 여러개를 하나의 클러스터로 구성하는 방식. 하나의 노드에 문제가 발생해도 웹 서비스가 중단되지 않는다. 만약 이를 통해 트래픽 대처를 한다면, 여러 대의 서버로 트래픽을 분산하기 위한 로드 밸런싱이 필요하다.
로드밸런싱 방식은 아래의 방식들이 있다.
Round Robin
서버에 들어온 요청을 순서대로 배정하는 방식. 클라이언트 요청을 순서대로 분배하기 때문에 여러대의 서버가 동일한 스펙을 가지고, 세션이 오래 지속되지 않는 경우에 활용하기 적합하다.
Weighted Round Robin(가중 라운드 로빈)
각 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용한다.
IP Hash
클라이언트 IP 주소를 특정 서버로 매핑하는 방식. 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.
Least Connection
요청이 들어온 시점에 가장 적은 연결을 보이는 서버에 트래픽을 배분. 세션이 길어지거나 서버에 분배된 트래픽이 일정하지 않은 경우에 적합
로드밸런서 종류
L2 Data link 계층을 사용, Mac주소 기반 부하 분산
| L3 | Network 계층을 사용, IP주소 기반 부하 분산 |
| L4 | Transport 계층을 사용, Port 기반 부하 분산 |
| L7 | Application 계층을 사용, 요청(URL) 기반 부하 분산 |
주로 부하 분산에서는 L4와 L7이 많이 사용된다. L4부터 port를 다룰 수 있기 때문
L4 Load Balancer
4계층(IP, TCP, UDP) 정보를 바탕으로 로드를 분산한다. 즉, IP, port, mac등에 따라 프로토콜을 분산하는 것이 가능하다.
장점
- 패킷의 내용을 확인하지 않고 로드를 분산하므로 속도가 빠르다.
- 데이터 복호화 과정이 필요 없다.
- L7보다 가격이 저렴
단점
- 패킷의 내용 확인 불가능하므로 섬세한 라우팅 불가
- 사용자의IP가 수시로 변경되는 경우면 연속적 서비스 제공 어려움
L7 Load Balancer
L7에서 동작하기 때문에 IP, Port외에도 URL, PayLoad, 헤더 등의 내용으로 부하 분산이 가능하다. 또한 요청의 세부적 사항으로 분리가 가능하여 가볍고 작은 단위로 여러 개의 서비스를 운영하고 요청을 각각의 서버에 분산할 수 있다. 또한 자원 소모가 크다.
장점
- 상위 계층으로 로드를 분산하기 때문에 더 섬세한 라우팅이 가능
- 캐싱
- 비정상 트래픽을 사전에 필터링이 가능하여 서비스 안정성이 높다.
단점
- L4보다 비쌈
- 패킷 내용을 복호화 해야 하므로 더 높은 비용 지불
- 클라이언트와 로드밸런서가 인증서를 공유해야 한다
Proxy Server
프록시 서버는 클라이언트와 다른 네트워트 서비스 간의 중계 역할을 하는 중간 서버이다. 클라이언트의 요청을 받아 대신 원격 서버로 전달하고, 원격 서버로 받은 응답을 대신 클라이언트에 전달한다. 즉, 클라이언트는 멀리 떨어진 서버와 직접 통신이 아닌 프록시 서버를 통해 통신할 수 있다.
프록시는 서버 내에 도메인 홈페이지의 페이지를 가지는지 체크한다. 만약 페이지를 가진다면 해당 페이지가 최신 버전인지 체크한 후, 필요한 경우 갱신할 부분만 가져온다. 페이지를 가지고 있지 않다면 홈페이지가 있는 서버와 연결하여 페이지를 가져온다.
필요성
- 캐싱
데이터를 릴레이 하는 과정에서 자주 사용되는 데이터는 저장한다. 재요청이 있을 때 원본서버까지 가지 않고, 캐시된 데이터를 전송한다. 이를 통해 클라이언트는 반복 요청에 대해 더 빠른 응답을 받을 수 있다.
Q. 프록시 서버 사용시 페이지 내용과 데이터의 값이 계속 바뀌면?
A. 실제 서버에서 응답할 때 캐시 만료 기한을 설정한다. 프록시 서버로 사용자가 요청했을 때 요청한 시각이 프록시에서 다운받은 시간에서 만료한 기간 이내면 프록시에서 다운로드 할 것이고, 그렇지 않으면 다시 실제 서버로 요청하게 된다.
- 보안
특정 프록시 서버를 통해서만 네트워크 접근이 이루어지도록 하면 악성 사이트로의 접근을 차단하거나, 트래픽을 검사하여 보안 위협을 탐지할 수 있다. 또한 프록시 서버를 통해 특정 사이트에 대한 접근 및 모니터링이 가능하다.
또한 클라이언트 IP주소를 숨기면서 웹 탐색이 가능하다.
- 로드밸런싱
- Foward Proxy
프록시 서버의 위치는 클라이언트 바로 뒤에 놓여있다. 같이 내부 망에 존재하는 클라이언트의 요청을 받아서 인터넷을 통해 외부 서버에서 데이터를 가져와 클라이언트에게 응답해준다.
즉, 클라이언트가 서버에 접근시 타겟 서버의 주소를 포워드 프록시에게 전달하여, 포워드 프록시가 요청된 내용을 가져온다.
- Reverse Proxy
프록시 서버의 위치는 WAS의 앞에 놓여있다. 클라이언트는 웹에 접근 시, 서버에 요청이 아닌 프록시로 요청하게 된다. 이후 프록시가 WAS의 서버로 부터 데이터를 가져오는 방식이다. 리버스 프록시 서버를 여러개의 본 서버 앞에 두면 특정 서버가 과부화 되지 않게 로드 밸런싱이 가능하다.
Load Balancing
서버가 처리해야 하는 업무를 여러 대의 서버로 나누어 처리하는 것. 한대의 서버로 부하가 집중되지 않도록 트래픽을 관리하여 각 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것.
서비스 규모가 늘어나면 이를 분산하기 위한 방법으로 두가지 방법이 있다.
- Scale - Up
CPU, 메모리 등 하드웨어 기능을 업그레이드한다. 비용이 기하급수적으로 증가한다. 하나의 서버에 웹 서비스를 제공하므로 서버 장애시 가용성에 문제가 발생한다.
- Scale - out
저렴한 노드를 여러개를 하나의 클러스터로 구성하는 방식. 하나의 노드에 문제가 발생해도 웹 서비스가 중단되지 않는다. 만약 이를 통해 트래픽 대처를 한다면, 여러 대의 서버로 트래픽을 분산하기 위한 로드 밸런싱이 필요하다.
로드밸런싱 방식은 아래의 방식들이 있다.
Round Robin
서버에 들어온 요청을 순서대로 배정하는 방식. 클라이언트 요청을 순서대로 분배하기 때문에 여러대의 서버가 동일한 스펙을 가지고, 세션이 오래 지속되지 않는 경우에 활용하기 적합하다.
Weighted Round Robin(가중 라운드 로빈)
각 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용한다.
IP Hash
클라이언트 IP 주소를 특정 서버로 매핑하는 방식. 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.
Least Connection
요청이 들어온 시점에 가장 적은 연결을 보이는 서버에 트래픽을 배분. 세션이 길어지거나 서버에 분배된 트래픽이 일정하지 않은 경우에 적합
로드밸런서 종류
L2 Data link 계층을 사용, Mac주소 기반 부하 분산
| L3 | Network 계층을 사용, IP주소 기반 부하 분산 |
| L4 | Transport 계층을 사용, Port 기반 부하 분산 |
| L7 | Application 계층을 사용, 요청(URL) 기반 부하 분산 |
주로 부하 분산에서는 L4와 L7이 많이 사용된다. L4부터 port를 다룰 수 있기 때문
L4 Load Balancer
4계층(IP, TCP, UDP) 정보를 바탕으로 로드를 분산한다. 즉, IP, port, mac등에 따라 프로토콜을 분산하는 것이 가능하다.
장점
- 패킷의 내용을 확인하지 않고 로드를 분산하므로 속도가 빠르다.
- 데이터 복호화 과정이 필요 없다.
- L7보다 가격이 저렴
단점
- 패킷의 내용 확인 불가능하므로 섬세한 라우팅 불가
- 사용자의IP가 수시로 변경되는 경우면 연속적 서비스 제공 어려움
L7 Load Balancer
L7에서 동작하기 때문에 IP, Port외에도 URL, PayLoad, 헤더 등의 내용으로 부하 분산이 가능하다. 또한 요청의 세부적 사항으로 분리가 가능하여 가볍고 작은 단위로 여러 개의 서비스를 운영하고 요청을 각각의 서버에 분산할 수 있다. 또한 자원 소모가 크다.
장점
- 상위 계층으로 로드를 분산하기 때문에 더 섬세한 라우팅이 가능
- 캐싱
- 비정상 트래픽을 사전에 필터링이 가능하여 서비스 안정성이 높다.
단점
- L4보다 비쌈
- 패킷 내용을 복호화 해야 하므로 더 높은 비용 지불
- 클라이언트와 로드밸런서가 인증서를 공유해야 한다
Proxy Server
프록시 서버는 클라이언트와 다른 네트워트 서비스 간의 중계 역할을 하는 중간 서버이다. 클라이언트의 요청을 받아 대신 원격 서버로 전달하고, 원격 서버로 받은 응답을 대신 클라이언트에 전달한다. 즉, 클라이언트는 멀리 떨어진 서버와 직접 통신이 아닌 프록시 서버를 통해 통신할 수 있다.
프록시는 서버 내에 도메인 홈페이지의 페이지를 가지는지 체크한다. 만약 페이지를 가진다면 해당 페이지가 최신 버전인지 체크한 후, 필요한 경우 갱신할 부분만 가져온다. 페이지를 가지고 있지 않다면 홈페이지가 있는 서버와 연결하여 페이지를 가져온다.
필요성
- 캐싱
데이터를 릴레이 하는 과정에서 자주 사용되는 데이터는 저장한다. 재요청이 있을 때 원본서버까지 가지 않고, 캐시된 데이터를 전송한다. 이를 통해 클라이언트는 반복 요청에 대해 더 빠른 응답을 받을 수 있다.
Q. 프록시 서버 사용시 페이지 내용과 데이터의 값이 계속 바뀌면?
A. 실제 서버에서 응답할 때 캐시 만료 기한을 설정한다. 프록시 서버로 사용자가 요청했을 때 요청한 시각이 프록시에서 다운받은 시간에서 만료한 기간 이내면 프록시에서 다운로드 할 것이고, 그렇지 않으면 다시 실제 서버로 요청하게 된다.
- 보안
특정 프록시 서버를 통해서만 네트워크 접근이 이루어지도록 하면 악성 사이트로의 접근을 차단하거나, 트래픽을 검사하여 보안 위협을 탐지할 수 있다. 또한 프록시 서버를 통해 특정 사이트에 대한 접근 및 모니터링이 가능하다.
또한 클라이언트 IP주소를 숨기면서 웹 탐색이 가능하다.
- 로드밸런싱
- Foward Proxy
프록시 서버의 위치는 클라이언트 바로 뒤에 놓여있다. 같이 내부 망에 존재하는 클라이언트의 요청을 받아서 인터넷을 통해 외부 서버에서 데이터를 가져와 클라이언트에게 응답해준다.
즉, 클라이언트가 서버에 접근시 타겟 서버의 주소를 포워드 프록시에게 전달하여, 포워드 프록시가 요청된 내용을 가져온다.
- Reverse Proxy
프록시 서버의 위치는 WAS의 앞에 놓여있다. 클라이언트는 웹에 접근 시, 서버에 요청이 아닌 프록시로 요청하게 된다. 이후 프록시가 WAS의 서버로 부터 데이터를 가져오는 방식이다. 리버스 프록시 서버를 여러개의 본 서버 앞에 두면 특정 서버가 과부화 되지 않게 로드 밸런싱이 가능하다.