회사의 규모와 상관없이, 웹 캐싱은 성능을 최적화하고 대역폭을 아끼는데 도움이 된다. 올바른 캐싱 솔루션을 고르면, 돈과 시간을 들이지 않고도 네트워크를 확장한 것과 같은 효과를 볼 수 있다.

웹 캐싱 솔루션은 인터넷 웹 서버보다는 사용자와 더 밀접한 솔루션으로, 자주 접속하는 웹 페이지와 객체들을 시스템에 저장하는 기능을 제공하고 이 저장된 객체에 다시 접근될 때 성능이 향상된다.

몇 년 전, 빠른 인터넷 접속이 가능하게 되면 웹 캐시가 필요없을 것이라는 얘기가 나오기도 했지만, 실상은 그렇지 않았다. 30~45Mbps의 대역폭을 제공하는 가장 빠른 광 인터넷 기술이라도 100Mbps~1Gbps까지의 대역폭을 제공하는 일반적인 LAN 속도에 비하면 느린 편이기 때문에, 인터넷 접속 성능은 여전히 문제가 되고 있다.

게다가 웹 캐싱은 객체의 복사본을 저장하고 있기 때문에 웹 서버가 다운되거나 네트워크 문제로 접속할 수 없는 상황에서도 접속을 가능하게 해 인터넷의 가용성을 증가시킨다. 또한 회사가 종량제 인터넷 서비스를 사용하는 경우 인터넷 접속에 대한 비용도 줄여준다.

따라서 웹 캐싱은 여전히 유용하고 인기를 얻고 있다. 캐싱은 회사의 규모가 아무리 작더라도 도움이 되며, 좋은 캐싱 솔루션은 회사 규모에 따라 확장할 수 있다.

캐싱의 종류
웹 캐싱은 두 가지 종류로 구분할 수 있다.

* 포워드 캐싱 : 사용자들이 자주 접속하는 인터넷 서버의 웹 객체들의 복사본이 로컬 네트워크에 저장된다.

* 리버스 캐싱 : 웹 서버의 웹 객체가 프록시 서버에 저장되며 외부 사용자들이 이 프록시 서버에 접속함으로써 빠르게 접속할 수 있다.

웹 캐시는 두 가지 다른 형태가 가능하다.

* 로컬 캐시 : 웹 객체의 복사본이 로컬 컴퓨터에 저장된다. 대부분의 인기있는 웹 브라우저들은 기본적으로 이전에 사용했던 웹 객체들의 복사본을 저장하고 있다. 예를 들어 인터넷 익스플로러는 "temporary Internet files" 폴더에 저장한다. 로컬에 저장된 복사본은 사용자가 복사본이 저장된 컴퓨터에서 자주 가는 웹 페이지들을 접속할 때에만 도움이 된다.

* 프록시 캐시 : 프록시 서버는 회사 내의 많은 사용자를 위해 웹 객체를 캐시하는 독립적인 기기이다. 프록시 서버는 웹 서버와 웹 클라이언트 사이에 있는 컴퓨터이며, 로컬 캐시보다 더 효과적이다. 왜냐하면, 로컬 네트워크의 어떠한 사용자라도 인터넷 서버에서 웹 객체를 읽어 올 필요 없이 캐시 된 웹 객체를 이용할 수 있기 때문이다. 프록시 캐시는 네트워크의 파이어월에 포함돼 있는 경우도 있다.

MS의 ISA 서버는 블루코트(BlueCoat)의 제품과 마찬가지로 파이어월과 캐싱 프록시 서버 두 가지를 포함하고 있다. 캐싱 서버는 단독으로 컴퓨터에 설치 가능하며, 다음과 같은 무료 캐싱 소프트웨어와 상용 제품들이 있다.

* 리눅스용 스퀴드(Squid) 무료 캐싱 프록시
* MOWS 자바 기반 분산 웹/캐시 서버
* 비컴소프트(Vicomsoft)의 윈도우 및 매킨토시용 래피드캐시(RapidCache) 서버
* 윈도우용 윈프록시(WinProxy)

종종 캐싱 프록시는 규모에 따라 시스코의 콘텐츠 엔진(Content Engines)과 스트라타캐시(Stratacache)의 액셀라(Axcela) 시리즈와 같은 형태로 팔리기도 한다.

확장 가능한 캐싱 솔루션
회사의 규모가 커지면, 한대의 웹 캐싱 서버로는 모든 트래픽을 처리하기 불가능하거나 웹 객체들 저장하는데 부족하게 된다. 그런 경우, 캐싱 로드를 여러 대의 컴퓨터로 나누어 처리하는 캐싱 어레이를 만들어 캐싱 솔루션을 확장할 수 있다. 또한 캐싱 어레이는 한대의 캐싱 서버가 다운 되었을 경우를 대비한 결함 허용 기능도 제공한다.

어레이를 만들기 위해서는 캐싱 서버가 다음과 같은 프로토콜을 이용해 다른 캐싱 서버와 통신할 수 있어야 한다.

* WCCP(Web Cache Coordination Protocol) : 시스코의 캐싱 제품이나 스퀴드와 같은 오픈소스 프록시에서 사용하는 프로토콜이다.
* ICP(Internet Cache Protocol) : 스퀴드나 블루코트에서 지원하는 프로토콜이다.
* CARP(Cache Array Routing Protocol) : ISA 서버 엔터프라이즈 에디션에서 페일오버(failover)와 캐싱 어레이 서버 간의 로드 밸런싱을 할 때 사용되는 프로토콜이다.

CARP는 급성장하는 회사들이 요구하는 거의 무한대의 확장을 지원한다. 어레이에서 서버가 추가되거나 제거되면, CARP는 일을 효과적으로 나누기 위해 동적으로 URL을 조정해 재할당한다.

캐싱 어레이는 계층적 구조나 분산 구조로 배치 가능하다. 분산 캐싱 구조에서는 어레이의 모든 프록시 서버는 동등한 위치를 가지고 서로 작업을 분산하여 처리하며, 분산 구조에서는 프록시 서버들이 서로 다른 처리 레벨을 가지도록 서버를 연결하여 서버들이 인터넷에 더 가까운 다른 캐싱 서버와 연결되도록 한다. 여기서 인터넷에 가깝다는 의미는 입력 데이터(읽기)를 의미한다. 이 방법으로 캐시 정보는 캐시를 이용하는 사용자에 더 가깝게 유지된다.

어레이는 매우 확장성이 좋다. 왜냐하면, 현재 사용하고 있는 캐싱 솔루션을 뒤집어 엎을 필요없이 어레이에 서버, 어레이 레벨을 추가할 수 있기 때문이다.

또 다른 확장성 문제는 캐싱을 사용해 회사의 지사 네트워크 대역폭을 줄일 수 있는가 하는 것이다. 지사의 프록시는 인터넷에 직접 연결되어 있지 않을 수도 있다. 하지만 모뎀 연결이나 직접 WAN 연결을 통해 본사에 있는 프록시 서버의 웹 객체를 요청할 수 있다.

또 다른 선택으로, 글로벌한 규모의 고객들을 위한 아카마이(Akamai)의 웹 기반 애플리케이션 서비스도 있다. 아카마이의 웹 애플리케이션 액셀레이터 서비스는 다음과 같은 기능을 제공한다.

* 동적으로 사용자 요청을 프록시 서버에 연결하고 가장 빠르고 신뢰성 있는 서버에 사용자 요청을 보내기 위해 인터넷 라우팅을 감시 한다.

* 대역폭을 최소화하기 위해 압축 기술과 미리 데이터를 읽어오는 기술을 이용한다.

* SSL을 이용한 보안 웹 연결을 지원한다.

* 회사에 맞는 저장 규칙을 만들어 웹 콘텐츠를 저장할 수 있다.

이커머스(e-commerce)와 같이 전문적인 애플리케이션의 경우, 인터넷과 오라클 데이터베이스를 둔 웹 애플리케이션 서버 사이에 설치하는 오라클AS 웹 캐시 등을 고려할 수도 있다.@