우클릭방지

글 목록

2017년 9월 13일 수요일

[HTTP 프로토콜 강좌]#26 HTTP 가속 - 웹 캐싱(Web Caching) I

HTTP 가속에 대한 내용 중 두번째 시간이다.

HTTP 통신에 대한 가속효과를 주기 위한 기술로 지난 시간 "부하 분산(Load Balancer)" 를 이야기 했다.
오늘은 그 두번째로 HTTP 통신의 가속 기술 중 단연 으뜸이라 할 수 있는 캐싱(Caching)에 대한 이야기를 한다.

HTTP 캐싱은 기능적 효과가 좋아 캐싱관련 HTTP 헤더가 있을 정도이다.
이미 프로토콜에 캐싱 관련된 내용이 들어가 있는 만큼 그 중요성이 얼마나 큰지 지레 짐작할 수 있으리라 본다.

HTTP 캐싱은 웹사이트를 접속할 때 사용하는 웹브라우저에서 직접 지원하기도 하지만, 캐싱만을 목적으로한 솔루션(제품)이 존재할 뿐만 아니라, 웹 캐싱에 다른 HTTP 가속기술들을 혼합한 웹 가속기라는 제품도 시장에 출시되어 있기도 하다.

웹캐싱은 오래된 HTTP 가속 기술이지만, 오늘날까지도 굳건히 사용되고 있는 기술이기도 하다.
따라서 HTTP 관련 제품을 지원하는 분들이라면, 반드시 웹 캐싱에 대한 이해를 선행하는 것이 좋다.

자 그럼 지금부터 웹캐싱을 지원하는 프록시 서버에 대해 알아보도록 한다.

구성 위치에 따른 분류

웹 프록시 서버는 구성 위치가 어디냐에 따라 다음과 같이 크게 두가지로 분류할 수 있다.

  • 포워드 프록시 (Forward Proxy)
  • 리버스 프록시 (Reverse Proxy)


앞에 단어가 포워드 / 리버스 와 같으니 정방향 , 역방향.. 정도로 이해할 수도 있겠다.
별로 어려운 이야기는 아니다. 다음 구성 그림을 보자.



포워드 프록시는 클라이언트에게 가깝게 위치하고 있고, 리버스 프록시는 웹서버에 가깝게 위치하고 있다.

프록시 캐시서버가 위치한 곳에 따라 사용 목적이 클라이언트를 위함이냐 웹서버를 위함이냐가 결정된다.

1. 포워드 프록시

먼저 포워드 프록시..
포워드 프록시는 클라이언트(사용자)에게 가깝게 위치하고 있다. 보통 사용자들이 인터넷을 통해 접속하는 웹사이트는 무수히 많은게 사실이다.
다시 말하면 사용자들은 특정 웹사이트만을 접속하는게 아니라 다양한 곳을 방문하기 때문에 캐시서버의 적용대상을 한정할 수 없다.
따라서 캐시서버의 적용대상은 클라이언트가 접속하는 인터넷상에 있는 모든 웹사이트가 되는 것이다.

이 경우 캐시서버를 이용하여 효과를 볼수 있는 것은 다음과 같다.

첫째, 밴드위스(Bandwidth) 절감!!
WAN 구간의 인터넷 트래픽을 캐시서버를 통해 줄일수 있다. 생각해 보자.
A라는 클라이언트가 웹사이트를 최초 접속하면, 캐싱된 컨텐츠가 없기 때문에 모두 실제 웹서버로 부터 응답을 받게 된다.
B,C,D 라는 각각의 사용자들이 A가 먼저 접속했던 웹사이트를 다시 접속하려 한다면..
A사용자에 의해 캐싱해 놓은 컨텐츠들이 이미 존재하기 때문에 B,C,D, ... 사용자들은 인터넷을 통해 실제 홈페이지에 방문할 필요가 없어지게 된다.

캐시서버가 있는 경우에는 캐싱된 컨텐츠에 대해서는 인터넷 구간에서 트래픽을 유발할 필요가 없게 되므로 밴드위스(Bandwidth) 사용량을 절감하게 된다.

두번째, 사용자의 인터넷 체감 속도 향상!!
이미 캐싱된 컨텐츠를 요구하는 사용자들은 인터넷구간을 통해 컨텐츠를 다시 받을 필요가 없다. LAN 구간에 위치한 캐시서버에게서 곧장 요청 컨텐츠를 제공받기 때문에 당연히 응답속도의 개선 또는 향상 효과가 나타난다. 즉, 클라이언트들의 인터넷 사용 환경이 좋아진다.





마지막 세번째, 비업무 트래픽 제한!!
어느 회사의 사용자들이 업무시간에 인터넷 웹사이트를 통해 음악을 듣는다던지 동영상을 시청한다던지등의 불필요한 행위들을 제어할 수 있다.
모든 인터넷 웹사이트 접속을 프록시 캐시서버를 통해 이루어지다 보니, 당연히 사용자의 홈페이지 접속을 일부 제한할 수 있다.
비업무 사이트가 될수도 있고, C&C 서버와 같이 악의적인 사용자들의 해킹서버들도 포함된다. 이건 내부 사용자의 보안에 관련된 측면이 강하기 때문에 엄밀히 이야기 하면 클라이언트가 누리는 효과가 아니라 어느 조직의 관리자가 행하는 정책 지원이라는 성격이라 하겠다.

2. 리버스 프록시

포워드 프록시와는 다르게 리버스 프록시는 클라이언트보다는 웹서버의 안정성 측면에서 효과를 줄수 있는 구성이다.

위치적으로 웹서버와 가깝게 있다 보니, 적용 대상이 포워드 프록시와는 다르게 특정 웹서버로 한정된다.

그렇다 보니 포워드 프록시와는 다르게 다음의 효과를 기대할 수 있다.

첫째, 웹서버 안정성 향상!!
캐시서버를 통해 웹서버의 컨텐츠들이 거의 대부분 클라이언트들에게 제공되기 때문에,  웹서버에서는 TCP 세션의 부하가 많이 줄어든다.
캐싱되지 않는 컨텐츠에 대해서만 요청이 전달되기 때문에 당연한 결과이다.
웹서버가 실제 처리 해야 할 것들을 캐시서버가 대신 해주다보니 CPU사용량이나 메모리 사용량이 눈에 띄게 줄어든다. 그렇기에 당연히 안정적으로 서비스를 운영할 수 있는 환경이 마련된다.

뭐, 한발 더 나가서 생각해 보면 실제 웹서버가 처리해야 할 요청수가 줄어든다는 것은 운영 웹서버의 수를 줄일수 있는 상황이기도 하다. 줄인 서버들은 되려 다른 목적의 서버로 활용할 수 있는 측면으로 생각해 볼수도 있다.

또.. 뭐가 있을까? 사실 리버스 프록시의 주 목적은 웹서버의 안정성을 높혀 서비스 환경을 좋게 만드는데 있다.

3. 정리 

포워드 프록시와 리버스 프록시에 대해서 살펴 봤다.
좀 정리를 하자면..

먼저 접속 환경 비교.

포워드 프록시는 다음 그림과 같이 "특정 클라이언트 -> 랜덤 웹사이트" 이지만

리버스 프록시는 "랜덤 클라이언트 -> 특정 웹사이트" 이다.



두번째, 운영 효과 비교
포워드 프록시는 "밴드위스 절감, 인터넷 웹사이트 접속속도 향상, 웹사이트 접속 제어" 이고 리버스 프록시는 "웹서버의 처리 부하 감소" 를 통한 안정적인 서비스 환경 마련 이다.

세번째, 캐싱 효과 타켓
뭐 운영 효과와 겹치는 부분이지만, 캐시서버를 통해 실제 효과를 보는 대상이 누군지는 구분할 필요가 있을것 같아서..
포워드 프록시는 클라이언트(사용자)가 효과를 볼수 있는 대상이고, 리버스 프록시는 특정 웹사이트이다.




번외로.. 캐싱서비스에서 Hit Rate 라는 단어를 사용하는데 이게 뭐냐면..
프록시 캐시서버가 캐싱하고 요청한 컨텐츠 중에 얼마나 캐싱하고 있는 컨텐츠를 제공하고 있는가 를 확인하는 지표이다.

당연히 Hit Rate 가 높을 수록 캐싱에 의한 효과는 크다고 보는게 맞다.

보통 포워드 프록시 보다 리버스 프록시가 Hit Rate 가 높다.
나의 경험으로 보면 포워드는 60% 정도이고, 리버스는 90% 이상이다. 이건 왜 이럴까?
포워드 프록시는 캐싱효과가 왜 리버스 프록시보다 낮을까?

답은 위 내용에 있다.

포워드 프록시는 캐싱적용 대상이 인터넷상에 있는 다수의 랜덤한 웹사이트인 반면 리버스 프록시는 특정 웹서버이기 때문이다.
그렇기에 포워드 프록시는 요청 컨텐츠가 매우 다양한 반면, 리버스 프록시는 요청컨텐츠가 정해져 있다. 이 뜻은 캐시서버가 캐싱해야 할 컨텐츠가 무지 다양한 것과 그렇지 않은것의 차이이다.

이렇기에 캐싱된 컨텐츠가 재사용될 확률이 아주 높은 리버스가 당연히 Hit Rate 가 높은 것이다.

오늘은 여기까지.. ~
끝~~


댓글 1개: