캐시 서버(포워드 프록시, 리버스 프록시, 트랜스패어런트 프록시)

캐시 서버의 이용
여러 대의 웹 서버를 설치하는, 즉 같은 기능을 가진 여러 대의 서버를 설치하는 것이 아니라 다른 방법으로 부하 분산을 하는 방법도 있습니다. 이것은 데이터베이스 서버와 웹 서버 같은 역할에 따라 서버를 나누는 방ㅂ버으로, 이러한 역할별 분산 처리 방법 중의 하나가 캐시 서버를 사용하는 방법입니다.

캐시 서버는 프록시라는 구조를 사용하여 데이터를 캐시에 저장하는 서버입니다. 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개하는 역할을 하는데 액세스 동작을 중개할 때 웹 서버에서 받은 데이터를 디스크에 저장해 두고 웹 서버를 대신하여 데이터를 클라이언트에 반송하는 기능을 가지고 있습니다. 이것을 캐시라고 부르며 캐시 서버는 이 기능을 이용합니다.

웹 서버는 URL을 점검하거나 액세스 권한을 점검하거나 페이지 안에 데이터를 내장하는 등의 처리를 내부에서 실행하기 위해 페이지의 데이터를 클라이언트에 송신할 때 다소 시간이 걸립니다. 한편 캐시 서버쪽은 웹 서버에서 받아 보존해 둔 데이터를 읽어서 클라이언트에 송신만 하므로 웹 서버보다 빨리 데이터를 송신할 수 있습니다.

캐시에 데이터를 저장한 후 웹 서버측에서 데이터가 변경되면 캐시의 데이터를 사용할 수 없습니다. 따라서 언제든지 캐시의 데이터를 이용할 수 있는 것은 아닙니다. 또한 CGI 애플리케이션 등이 출력하는 페이지 데이터도 내용이 매번 달리지므로 캐시를 이용할 수 없습니다. 그러나 액세스 동작의 일정부분은 웹서버를 번거롭게 하지 않고 캐시 서버에서 처리할 수 있습니다. 얼마라도 캐시 서버에서 액세스 동작을 고속화할 수 있으면 전체 성능이 항상된다고 생각하는 것입니다.

캐시서버는 갱신일로 콘텐츠를 관리한다
이번에는 캐시 서버의 동작을 살펴보겠습니다. 캐시 서버를 사용할 때는 부하 분산 장치와 마찬가지로 캐시 서버를 웹 서버 대신 DNS 서버에 등록합니다. 그러면 사용자는 캐시 서버에 HTTP의 리퀘스트 메시지를 보낼 것이고 캐시 서버가 메시지를 받습니다. 이때의 수신 동작은 웹 서버의 수신 동작과 같습니다. 접속을 기다리는 패킷을 마들고 여기에 사용자가 접속하면 접속 동작을 실행하여 사용자가 보낸 리퀘스트 메시지를 받는 것입니다. 사용자가 보면 캐시 서버가 웹 서버에 보일 것입니다. 그래서 리퀘스트 메시지를 받으면 캐시 서버는 리퀘스트 메시지의 내용을 조사하고 데이터가 자신의 캐시에 저장되었는지 조사합니다.

이 앞의 동작은 캐시에 저장되어 있는 경우와 저장되어 있지 않은 경우가 드르므로 후자의 경우부터 설명하겠습니다. 이 경우 캐시 서버는 리퀘스트 메시지에 캐시 서버를 경유한 것을 나타내는 'Via'라는 헤더 필드를 추가하여 웹 서버에 리퀘스트를 전송 합니다.
* Via로 프록시를 경유한 사실을 클라이언트에 알리기 위한 것, 단 이 정보는 그다지 중요하지 않고 캐시 서버의 설정에 따라 이 헤더를 추가하지 않는 경우도 있습니다.

우선 어느 웹 서버에 리퀘스트 메시지를 전송해야 할지 판단해야 합니다. 웹 서버가 한 대밖에 없으면 웹서버의 도메인명이나 IP주소를 캐시 서버에 설정해 두고 무조건 거기에 전송하는 방법을 취합니다. 그러나 한대의 캐시로 여러 대의 서버의 데이터를 캐시에 저장하는 경우에는 이러한 단순한 방법으로는 곤랍합니다. 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버를 판단하는 것 같은 방법이 필요합니다. 대표적인 것은 리퀘스트 메시지의 URI에 쓰여 있는 디렉토리를 보고 판단하는 것입니다.
- URI가 /dir1/이라는 디렉토리였다면 www1.example.com에 전송
- URI가 /dir2/이라는 디렉토리였다면 www2.example.com에 전송

이렇게 클라이언트와 웹 서버 사이를 중개하는 것이 프록시 구조입니다. 그리고 중개할 때 페이지의 데이터를 저장하면 캐시 서버에 데이터가 축적되고, 사용자가 액세스한 페이지가 캐시 서버에 저장되어 있는 경우가 증가합니다. 다음은 데이터가 저장되어 있는 경우입니다.

먼저 사용자로부터 도착한 리퀘스트 메시지를 받아 캐시에 저장되었는지 조사하고 저장 되어있다면 웹 서버 측에서 데이터가 변경되었는지 조사하기 위한 'If-Modified-Since'라는 헤더 필드를 추가하여 웹서버에 전송합니다.
웹 서버는 'If-Modified-Since' 헤더 필드의 값과 페이지 데이터의 최종 갱신 일시를 비교하여 변경이 없다면 상태 코드 304 메시지를 반송합니다.
웹 서버측에서 데이터가 변경된 경우에는 캐시에 데이터가 저장되어 있지 않은 경우와 같습니다. 웹서버는 최신 데이터를 반송함으로 캐시 서버는 메시지에 Via 헤더를 부가하여 사용자에게 전송하고 데이터를 캐시에 저장합니다.

 

프록시의 원점은 포워드 프록시이다
지금까지 설명한 것은 프록시라는 구조를 웹 서버측에 두고 캐시 기능을 이용하는 것이지만 클라이언트측에 캐시 서버를 두는 방법도 있습니다.
사실 캐시 서버에서 이용하는 프록시라는 구조는 원래 클라이언트측에 두는 방법에서 시작되었습니다. 이 유형이 프록시의 원형으로, 포워드 프록시라고 합니다.

포워드 프록시가 처음 등장했을 때 캐시를 이용하는 것이 목적이였습니다. 이것은 서버측에 설치하는 캐시 서버와 같지만 당시의 포워드 프록시는 방화벽을 실현한다는 중요한 목적이 한 가지 더 있었습니다.

방화벽의 이용 목적은 인터넷에서의 부정 침입을 막는 것이지만 이 목적을 달성하는 가장 현실적인 방법은 인터넷과 사내 패킷 왕래를 전부 정시키는 것입니다. 그러나 패킷을 전부 정지시키면 인터넷에 대한 액세스도 정지됩니다. 이렇게 하면 도움이 되지 않으므로 필요한 것을 통과시키는 방법을 생각하기 위해 프록시라는 구조를 고안한 것입니다. 즉 프록시에서 리퀘스트 메시지를 일단 받아서 인터넷을 향해 전송하면 필요한 것을 통과시킬 수 있다는 개념입니다. 이때 프록시의 캐시를 이용하면 더 효과적입니다. 이전에 액세스한 페이지의 경우 사내 LAN에서 프록시에 액세스 하기만하면 데이터를 손에 넣을 수 있으므로 저속 회선에서 인터넷에 액세스 하는 것보다 매우 빨라질 것입니다.

포워드 프록시를 사용할 경우에는 보통 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정합니다. 그러며 브라우저의 리퀘스트 메시지 송신 동작이 조금 달라집니다. 포워드 프록시를 설정하지 않으면 브라우저는 URL 입력 상자에 입력된 http://....라는 문자열에서 액세스 대상의 웹 서버를 계산하고 여기에 리퀘스트 메시지를 보냅니다 하지만 포워드 프록시를 설정하면 URL의 내용에 상관 없이 리퀘스트를 전부 포워드 프록시가 보냅니다. 그리고 리퀘스트 메시지의 내용도 조금 다른 형태가 됩니다. 포워드 프록시를 설정하지 않는 경우에는 URL에서 웹 서버의 이름을 제외하고 파일이나 프로그램의 경로명의 일부를 추출하여 이것을 리퀘스트의 URI 부분에 기록합니다. 하지만 포워드 프록시를 설정하면 http://...라는 URL을 그대로 리퀘스트의 URL에 기록합니다.

포워드 프록시를 대상으로 리퀘스트

포워드 프록시를 개량한 리버스 프록시
포워드 프록시를 사용할 경우에는 브라우저에 대한 설정이 꼭 필요한데, 이것이 포워드 프록시의 특징이지만 이 방법은 브라우저의 설정이 번거롭고 잘못 설정할 경우에는 브라우저가 제대로 작동하지 않는 장애의 원이이 되기도 합니다.

브라우저에 설정할 필요하다는 점은 이런 수고나 장애의 원인뿐만 아니라 다른 제약 사항이 되기도 합니다. 인터넷에 공개하는 웹 서버는 누가 액세스 하는지 알 수 없고 브라우저에 프록시를 설정할 수 없기 때문에 웹 서버의 바로 앞에 프록시를 두는 방법을 선택하지 않습니다. 이에 따라 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 개량되었습니다. 즉 리퀘스트 메시지의 URI에 쓰여있는 디렉토리명과 전송 대상의 웹 서버를 대응시켜서 URI 부분에 http://....라고 쓰여있지 않은 보통의 리퀘스트 메시지를 전송할 수 있도록 했습니다. 이것이 서버측에 설치하는 캐시 서버에 채택하고 있는 방식으로, 리버스 프록시라고 부릅니다.

트랜스페어런트 프록시
캐시 서버에서 전송 대상을 판단하는 방법 즉 리퀘스트 메시지에서 패킷의 헤더를 조사하는 방법이 있습니다. 패킷의 맨 앞에 있는 IP헤더에는 수신처 IP 주소가 기록되어 있으므로 이것을 조사하면 액세스 대상 웹 서버가 어디에 있는지 알 수 있는데, 이 방법을 트랜스페어런트 프록시라고 부릅니다.

이 방법이라면 보통의 리퀘스트 메시지를 전송할 수 있으므로 포워드 프록시처럼 브라우저에 설정할 필요가 없습니다. 또한 전송 대상을 캐시 서버에 설정할 필요도 없고, 어느 웹 서버에서나 전송할 수 있습니다.

트랜스페어런트 프록시는 포워드 프록시와 리버스 프록시의 좋은 점만 모은 형태의 편리한 구조이지만 트랜스페어런트 프록시에 리퀘스트 메시지를 건네주는 방법을 주의해야 합니다. 트랜스페어런트 프록시는 브라우저에 설정하지 않으므로 브라우저는 웹 서버에 리퀘스트 메시지를 보냅니다. 리버스 프록시와 같이 DNS 서버에 등록하는 방법이라면 이 리퀘스트 메시지가 프록시에 도착하지만 트랜스페어런트 프록시는 DNS 서버에 등록하는 것도 없습니다. DNS 서버에 등록하며 트랜스페어런트 프록시 자체가 액세스 대상이 되어 수신처 IP 주소로 전송 대상의 웹 서버를 판단한다는 중요한 구조를 이용할 수 없게 됩니다. 이대로라면 리퀘스트 메시지는 브라우저에서 웹 서버로 흘러갈 뿐 트랜스페어런트 프록시에는 도착하지 않습니다.

이것을 해결하기 위해 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치합니다. 그리고 메시지가 트랜스페어런트 프록시를 설치합니다. 그리고 메시지가 트랜스페어런트 프록시를 통과할 때 그것을 가롭챕니다. 편법이라는 느낌도 있지만 이렇게 해서 리퀘스트 메시지가 트랜스페어런트 프록시에 도착하고 웹 서버에 전송할 수 있습니다. 또한 리퀘스트 메시지가 흐르는 길이 많으면 여기에 전부트랜스페어런트 ㅍ록시를 설치해야 하므로 길이 한 개로 수렴하는 형태로 네트워크를 만들고, 수렴되는 곳에 트랜스 페어런트 프록시를 설치하는 것이 보통입니다. 인터넷에 연결하는 액세스 회선 부분이 이러한 형태로 되어 있으므로 액세스 회선 부분에 설치해도 됩니다. 트랜스페어런트 프록시를 사용하면 사용자가 프록시의 존재를 알아차릴 필요가 거의 없습니다. 따라서 HTTP의 메시지를 전송한다는 구조에 대한 관심이 적어지고 캐시를 이용한다는 측면에서 비중이 높아지고 있습니다.