웹 애플리케이션의 부하와 프록시/캐시 시스템

웹 애플리케이션의 부하가 서서히 증가해서 시스템 용량이 부족해졌을 때에는 AP 서버나 DB 서버를 증설함으로써 대응을 할 수도 있지만, HTTP 레벨의 캐싱을 수행하는 HTTP 가속기를 사용함으로써 낮은 비용으로 효과가 높은 대책을 세울 수도 있다.

HTTP 액세스를 고속화하는 HTTP 가속기는 크게 포워드 프록시와 리버스 프록시, 2 종류가 있따. 포워드 프록시(Forward Proxy)는 클라이언트가 외부 서버에 액세스할 때 사이에 두는 프록시다. 반면, 리버스 프록시는 역으로 외부의 클라이언트가 내부 서버에 액세스할 때 사이에 두는 프록시다.

프록시에서는 요청에 대한 응답을 캐싱해둠으로써 다음에 같은 요청이 전달됐을 때 캐싱해둔 응답을 반환할 수 있다. 이에 따라 대역이나 서버 리소스를 소비하지 않고 빠르게 요청을 처리할 수가 있다. 어느 정도 규모에 달한 웹 애플리케이션에서는 리버스 프록시를 이용한 캐시 서버를 효과적으로 이용함으로써 리소스 소비를 억제하면서 대량의 요청을 처리할 수 있게 된다. 특히 갱신빈도가 낮은 동적인 페이지가 많을 경우에 유효하다.

리버스 프록시 캐시 서버의 구현으로 Squid가 가장 유명하고, nginx도 있다.

Squid

리버스 프록시와 AP 서버, 2대로 이루어진 구성을 전제로 해보자. 이 구성에서 캐시 서버를 도입할 경우, 리버스 프록시와 AP 서버 사이에 배치한다. 이에 따라 AP 서버로 전송되고 있던 요청 중 일부를 캐시 서버에서 처리할 수 있게 되어 시스템 전체 성능을 향상시킬 수 있다.

여러 대의 서버로 분산하라

Squid 서버를 2대 나열함으로써 다중성을 띄게 할 수 있다. 2대를 구성할 때 1대를 스탠바이로 남겨두거나, 각각을 독립된 캐시 서버로 동작시킬 수도 있고, 2대의 서버를 연계해서 동작하도록 설정할 수도 있다.

2대의 Squid를 연계시키는 것은 ICP(Inter-Cache-Protocol)를 사용하는 것이 기본이다. ICP는 Internet-Draft로 정의되어 있는 프로토콜의 일종으로, 캐시를 제어하기 위한 프로토콜이다.

두 캐시 서버 모두 보유하고 있지 않은 경우 AP 서버로 질의 한다.

2단 구성 캐시 서버

이미지 파일 등 크기가 큰 파일을 캐싱하게 되면 캐시 서버의 부하가 높아지면 1대나 2대 정도로는 용량이 턱 없이 부족해질 경우가 있다. 이런 경우 서버를 2단으로 구성함으로써 보다 확장성이 높은 캐시 서버군을 구성할 수 있다.

상단 Squid 프록시는 요청을 받아서 자신은 캐시를 보유하지 않고 하단 Squid 하단 캐시 서버로 요청을 전송한다. 이때 CARP (Cache Array Routing Protocol) 프로토콜에 따라 URL을 키로 적잘한 Squid 캐시 서버로 전송한다. URL을 키로 해서 하단 캐시 서버를 선택함으로써 특정 URL에 대해 특정 캐시 서버만 사용하게 된다. 따라서 캐시 서버 대수가 늘어난 경우에도 효율적으로 캐싱할 수 있다. 또한 캐시 대상 URL 수가 증가하더라도 하단 캐시 서버 대수만 늘려주면 부드럽게 확장시킬 수 있다.

게다가 Squid에 의한 CARP 구현에서는 하단이 되는 캐시 서버의 사활감시도 수행해서 일부가 반응하지 않게 된 경우에도 작동하는 다른 서버로 처리를 할당하게 되어, 일시적으로 캐시 히트율은 낮아지더라도 전체로서는 정상적으로 동작할 수 있게 된다.

COSS 크기 결정방법

히트율을 높이기 위해서는 충분한 캐시 용량을 준비해둘 필요가 있다. 다만 캐시 용량이 너무 크면 다음과 같은 단점이 있다.

• 초기 시작 시에 COSS 파일 생성에 시간이 걸린다.
• 서버 재시작 등으로 메모리가 초기화된 후에 디스크 상의 파일이 메모리에 올라가고 Squid의 성능이 안정되기까지 시간이 걸린다.
• 디스크 용량을 압박한다.

반대로 너무 작으면 캐시 히트율이 떨어진다.