오늘은 웹 캐시 프록시 서버를 사용자가 적용하기 위한 방법에 대해 이야기 해보려 한다.
클라이언트에게 웹 캐시 서버를 적용시키는 방법에는 다음과 같은 방안이 존재한다.
1. 클라이언트의 직접 적용
2. 트랜스페런트 형태의 적용
클라이언트의 직접 적용
먼저 첫번째 방법이다.
클라이언트의 브라우저에 보면 다음과 같이 프록시 서버를 적용하는 옵션이 존재한다.
인터넷 익스플로어의 설정 화면이다.
프록시 서버의 IP 와 서비스 포트를 정의하는 곳에 프록시 정보를 입력하면 된다.
적용 후 사용자가 다음(www.daum.net) 이나 네이버(www.naver.com) 등 인터넷 홈페이지를 접속하게 되면 모든 요청을 프록시로 전달하게 된다.
프록시는 자신이 캐싱하고 있는 컨텐츠일 경우 직접 응답을 하게 되고, 그렇지 않은 경우에는 인터넷상에 있는 실제 서비스 홈페이지에 접속하여 해당 컨텐츠를 저장한 후 사용자에게 전달하게 된다.
하지만, 이 방법은 사용자의 수가 많지 않은 경우 큰 부담이 되지 않으나 사용자의 수가 엄청 많은 경우에는 관리적인 부담이 증가하게 된다. (사용자들의 브라우저 설정을 과연 어떻게 통제할것인가? )
또한 인터넷 접속이 원활하지 않은 경우 사용자의 설정을 점검해야 하기도 하고, 프록시의 IP 정보가 변경되면 모든 사용자에게 이를 알려야 한다.
그렇다면.. 사용자의 설정을 건들지 않은채 프록시 를 적용할 수 있는 방법은 없을까?
트랜스페런트(Transparent) 형태의 적용
트랜스페런트(Transparent) 형태의 적용이 바로 그 답이다.
트랜스페런트는 사전적 의미로 '투명한' 이란 뜻이다. 의미 그대로 프록시 서버를 투명하게 하여 사용자에게는 프록시가 없는 것처럼 한다는 의미이다.
사용자는 웹 브라우저에서 별도의 설정을 하지 않아도 된다. 그냥 여느때와 마찬가지로 인터넷 접속을 하면 그 요청을 프록시 캐시 서버를 통해 서비스를 하게끔 하는 것이다.
이런 형태의 적용을 위해서는 크게 다음 두가지 기술을 알아야 한다.
1. 라우터 / L3 스위치에서 적용하는 방법
2. L4 스위치에서 적용하는 방법
웹브라우저의 설정없이 사용자의 웹사이트 요청을 프록시가 처리하기 위해서는 중간에 L3 스위치 또는 L4 스위치가 프록시로 해당 요청을 전달해 주어야 한다.
1. WCCP (Web Cache Communication Protocol)
먼저 라우터 또는 L3 스위치가 그 역할을 하기 위해서는 WCCP 라는 프로토콜을 지원해야 한다.
WCCP는 Web Cache Communication Protocol 의 약어로 Cisco 가 개발한 프로토콜이다.
개념은 간단하다. 웹 캐시서버의 존재를 확인한 후 웹캐시서버가 동작을 잘 한다고 판단되면 사용자의 웹 요청을 프록시서버로 꺽어(Redirect) 주는 것이다.
먼저 WCCP 가 지원하는 메시지 형태를 살펴 보자.
- HERE_I_AM
- I_SEE_YOU
HERE_I_AM 은 캐시서버가 라우터/L3 스위치에 보내는 메시지로, "나 여기 있어요~" 의 뜻이다. 즉, 캐시서버가 나 서비스 할 준비가 되어 있다는 것을 알리는 목적이다.
I_SEE_YOU 는 캐시서버가 보낸 메시지에 대한 응답이다. "OK.. 캐시서버의 IP와 연결 포트를 확인했습니다." 라는 의미로 보면 되겠다.
이후 캐시서버는 보통 10초마다 지속적으로 HERE_I_AM 메시지를 보내게 되는데 라우터나 L3는 이 메시지를 통해 캐시버서의 상태를 확인한다.
HERE_I_AM 메시지가 지속적으로 들어오면 캐시서버가 살아 있는것으로 판단하고 웹트래픽을 캐시서버로 리다이렉트 해 주게 되고..
그렇지 않은 경우.. 즉.. HERE_I_AM 메시지가 전송되지 않게 되면, 캐시서버가 Down 된 것으로 보고 직접 웹서버로 전달하게 된다.
이후 캐시서버는 보통 10초마다 지속적으로 HERE_I_AM 메시지를 보내게 되는데 라우터나 L3는 이 메시지를 통해 캐시버서의 상태를 확인한다.
HERE_I_AM 메시지가 지속적으로 들어오면 캐시서버가 살아 있는것으로 판단하고 웹트래픽을 캐시서버로 리다이렉트 해 주게 되고..
그렇지 않은 경우.. 즉.. HERE_I_AM 메시지가 전송되지 않게 되면, 캐시서버가 Down 된 것으로 보고 직접 웹서버로 전달하게 된다.
그럼 WCCP를 통한 구성을 간단히 살펴보도록 하자.
위와 같이 라우터 혹은 L3 스위치에서 WCCP 기능을 통해 웹트래픽을 캐시서버로 리다이렉트하는 그림이고 아래는 캐시서버와 라우터/L3 스위치간 주고받는 WCCP 프로토콜 메시지이다.
HERE_I_AM 을 보내느 쪽이 캐시서버이고, I_SEE_YOU 메시지로 응답하는 쪽이 라우터이다.
사용하는 전송 프로토콜은 UDP 이며, 포트는 2048을 이용한다.
추가적으로 캐시서버가 여러대일 경우에는 WCCP 프로토콜의 분산알고리즘을 통해 서비스 트래픽 분산을 이용할 수 있다.
부하분산 방식은 두가지인데.. 첫번째로는 IP 주소의 mask 값을 사용하여 캐시서버를 할당하는 방법이고 나머지 한가지는 Hash 값을 이용하여 할당하는 방식을 취하고 있다.
2. L4 Redirect
다른 한가지는 L4 스위치를 이용하는 것이다.
우리 HTTP 가속의 첫시간에 "로드 밸런서" 라는 것을 다루었는데, L4 스위치는 로드 밸런서의 역할을 하는 대표적인 스위치 장비이다.
로드 밸런싱 이라는 주요 기능 이외에 WCR (Web Cache Redirection) 또는 CSLB ( Cache Server Load Balancing) 라는 이름의 기능을 가지고 있는데, 바로 이 기능을 통해서 트랜스페런트한 웹 캐시서버 동작을 지원할 수 있는 것이다.
동작 흐름을 살펴보면 다음과 같다.
L4 스위치는 위와 같이 HTTP 서비스 (웹트래픽) 에 대해서는 캐시서버로 전달하고, 그외 서비스(메일등)에 대해서는 직접 서버로 전송하게 한다.
때문에 클라이언트는 웹브라우저에 별도의 설정없이 캐시서버의 적용을 받을 수 있게 된다.
또한, L4 스위치는 주기적으로 캐시서버의 서비스 상태를 체크하여 Up/Down 여부를 확인한다. 캐시서버가 서비스 불능(Down) 상태에 빠지게 되면 L4 스위치는 웹트래픽을 곧바로 웹서버에게 전달하여 서비스의 가용성을 유지시켜 주게 된다.
하나 더..
L4 스위치의 주된 기능인 로드밸런싱을 통해 다수의 캐시서버 두고 운영을 할 수 있다. 다수의 캐시서버를 통해 좀 더 안정적인 서비스를 가능하게 하고, 캐시서버가 성능문제에 직면하게 되면 유연하게 확장을 할 수 있게 한다.
이렇게 트랜스페런트 동작을 위한 두가지 구성을 살펴보았다.
캐시서버 뿐만 아니라 프록시서버 기반의 네트워크/보안 장비들의 구성에도 위 두가지 방법은 활용할 수 있고.. 현재도 많이 활용되고 있다.
오늘은 여기까지.. 끝~
댓글 없음:
댓글 쓰기