웹 캐시 서버를 이용한 서비스 구성과 확장

웹 캐시 서버를 이용한 서비스 구성과 확장

최근 다양해진 웹 컨텐츠와 대형화되고 복잡해지는 웹 서비스는 안정적인 서비스 제공을 위한 네트워크 대역폭과 성능 개선을 대한 문제를 야기하고 있다. 이를 해결하기 위해 웹 캐시 서버를 이용한 방법이 일반적으로 적용되고 있다. 웹 캐시 서버를 중심으로 성능 개선을 위한 방법을 알아보도록 한다.

2000년도를 전후해 웹의 폭발적인 성장과 함께 인터넷 접속환경도 다양화됐으며, 인프라의 규모도 점점 커지게 됐다. 갑작스런 사용자 환경 변화와 데이터 전송량의 증가로 인해 기존의 빈약한 인프라 환경은 이런 변화를 수용하기에는 한계가 있다.

인터넷 보급 초기에는 현재처럼 IDC가 활성화되지 않았기 때문에 전용선(T1, E1) 연결을 통한 최소한의 네트워크 대역폭만 확보하는 것이 일반적이었으며, 대부분 기업들의 네트워크와 인터넷 사용 환경은 그다지 좋은 상황이 아니었다.

웹 서비스가 보편화되고 사용자가 증가함에 따라 네트워크 대역폭 절약, 안정적인 서비스 등의 여러 이슈가 발생하고, 인프라의 확장과 더불어 부가적인 솔루션들이 등장하면서 웹 서비스는 크게 성장했다(그림1).

웹 서비스의 성능개선을 위해 초기 서버 증설에서부터 최근의 CDN과 같은 분산 환경에 이르기까지 다양한 방법이 적용되고 발전돼 왔지만, 이번 강좌에서는 웹 캐시 서버를 중심으로 웹 서비스 성능 향상을 위한 방법에 대해 알아본다.

캐싱 서버의 발전 과정

점차 증가하는 인터넷의 규모에 따라 네트워크 대역폭과 성능을 개선하기 위해 등장한 다양한 해결 방법 중 하나가 캐싱 서버다. 초기 캐싱 서버의 도입은 당시 전용선을 사용하는 여러 기업, 교육기관, 관공서 등을 위한 WAN 구간 대역폭 절약이 주 목적이었다. 자주 접속하는 사이트의 내용을 캐싱 서버에 저장해, 다음 접속시 WAN을 거치지 않고 LAN에 있는 캐싱 서버에서 해당 사이트 컨텐츠를 전송함으로써 획기적으로 WAN 대역폭을 절약할 수가 있었다.

(그림 2)와 같이 초기 인터넷 환경은 사용자와 서버가 직접 통신하면서 데이터를 주고 받았다. 이런 방식의 통신 횟수가 증가함에 따라 사용자 WAN 구간에서는 병목현상이 발생하고 이에 따른 회선비용에 대한 부담으로 대안을 찾게 됐다.

포워드 캐싱(Forward Caching)은 내부 네트워크에 캐싱 서버를 적용함으로써 WAN에서 발생하는 병목 현상을 해결하는 데에 효과적이었다. 대역폭 절약과 더불어 순간적인 트래픽 급증에 대해서도 안정적으로 처리할 수 있었다. 이와 더불어 증가하는 사용자들에 대한 안정적인 웹 서비스 제공을 위해 리버스 캐싱(Reverse Caching)도 고려됐다.

리버스 캐싱은 사용자와 웹 서비스가 각각 1대 N의 구조가 아닌 N 대 1로 구성해, 웹 서비스 운영의 효율을 높이기 위한 방안으로 등장했다. 일례로 지난 걸프 전쟁이 발발했던 때나 북한과의 서해 교전시 주요 언론사들이 대단히 만족스런 효과를 봤다.

이후 이를 응용한 여러 방법들이 적용됐다. T3 전용선과 같은 대용량 전용회선의 도입이나 IDC 활성화와 같은 갑작스런 네트워크 인프라 환경의 변화로 인해 캐싱에 대한 수요가 한때 현저히 줄기도 했으나, 지속적인 성능 개선을 통해서 최근에도 다양한 분야에서 응용되고 있다.

웹 캐싱의 기본 개념

웹 캐싱은 지연을 최소화하고 네트워크 대역폭을 줄이기 위해 주로 사용한다. 성능이 뛰어난 웹 캐시 서버를 적용함으로써 사용자들에게 보다 빠르게 서비스를 제공할 수 있고. 반복되는 데이터 전송을 최소화함으로써 네트워크 대역폭도 최소화할 수 있다.

웹 캐시 서버는 주로 사용자와 웹 서버 사이에 위치하며, 접속이 잦은 컨텐츠를 미리 웹 캐시 서버에 저장해 두고, 웹 서버 대신에 웹 캐시 서버가 사용자들에게 서비스함으로써 실제 웹 서버로의 요청을 최소화해 네트워크 대역폭을 줄인다.

이런 웹 캐싱 기능은 서버 뿐만 아니라 각 사용자들의 브라우저에 기본적으로 탑재된 브라우저 캐싱에도 적용되고 있다. 브라우저 캐싱은 사용자 PC에 한번 접속한 사이트에 대한 컨텐츠를 저장해 재방문시 효과를 거두며, 브라우저 옵션에서 캐싱 크기와 캐싱 방법에 대해 조정할 수 있지만, 복잡하고 다양한 인터넷 사이트가 존재하므로 기능과 성능면에서는 한계가 있다. 일반적으로 사용하는 웹 캐싱은 이보다 더 확장된 형태의 고성능, 대용량 캐시 서버라고 생각하면 된다.

사용자, 웹 캐시 서버 그리고 웹 서버 간 통신에 있어 여러가지 규칙과 설정이 존재한다. 기본적인 HTTP 헤더 정보를 참조하기도 하고 웹 서버 또는 캐싱 서버의 설정에 따라 조정할 수도 있다.

캐싱 서버의 동작원리를 간단하게 정리하면 다음과 같다.

ㆍ해당 오브젝트의 헤더 정보를 참조해 캐싱 유무를 판단한다.
ㆍ기본적으로 암호화되거나 인증이 필요한 오브젝트에 대해서는 캐싱을 하지 않는다.
ㆍ최초 캐싱된 오브젝트는 재차 방문시 웹 서버쪽으로 요청하지 않고 바로 웹 캐시 서버를 이용해 사용자에게 전달된다.
ㆍ재차 방문시부터 여러가지 캐싱 유무 판단 항목들로 ‘fresh/stale’에 대한 검증 후 원본서버 참조 유무를 결정한다.
ㆍ해당 오브젝트가 유효기간이 만료된 경우 다시 원본 웹 서버에 요청해 해당 오브젝트를 갱신한다.

이처럼 웹 캐싱 알고리즘에 있어서 오브젝트의 ‘fresh’ 여부와 갱신주기는 가장 중요한 요소다. HTTP 1.0 이전 버전에서는 캐싱 성능과 관련된 항목들이 많이 부족했었지만 HTTP 1.1 이후로는 캐싱과 연관된 성능들이 많이 개선됨으로써 효과적으로 웹 캐싱을 적용할 수 있게 됐다.

해당 오브젝트의 캐싱 정책과 갱신여부 판단은 주로 HTTP 헤더 정보를 보고 판단하는데 마지막 수정 날짜와 ‘ETag’, ‘Cache-Control’ 등이 주요 요소들이다. 대부분은 웹 서버 설정이나 웹 서버와의 통신을 통해 결정된다. 오브젝트의 속성에 따라 이런 설정값을 적절하게 조정해 보다 더 효과적인 웹 캐싱 성능을 기대할 수 있다.

(그림 4)은 일반적인 웹 오브젝트에 대해 응답 헤더를 캡쳐한 내용이다.
해당 웹 오브젝트에 대한 HTTP 헤더를 확인함으로써 웹 캐싱 정책과 컨텐츠 유효성과 관련된 정보를 확인할 수 있다.

웹 캐싱 효율을 높이기 위한 고려사항

웹 서비스의 규모가 커지고 성능이슈가 발생함에 따라 다양한 솔루션이 등장했으며, 적재적소에 이런 솔루션을 적용해 안정적인 서비스를 제공하고 있다. 최근까지도 웹 캐싱은 가장 범용적으로 쓰이고 있는 웹성능 향상을 위한 솔루션 중 하나다. 물론 장단점이 있기도 하고 다른 유사 솔루션이 일부 뛰어난 성능을 보이기도 하지만, 성능과 확장을 고려할 때 가장 보편적인 방법이다.

더욱 중요한 것은 단순한 웹 캐싱 적용에 그치지 않고 웹 캐싱 성능의 효율을 높일 수 있도록 웹 서버 구축에서부터 웹페이지 제작까지 캐싱과 궁합이 잘 맞는 웹 서비스를 설계하는 것이다.

ㆍ캐싱 정책
기본적인 웹 캐싱 동작원리가 새로운 오브젝트를 저장하고 그 오브젝트에 대한 갱신주기를 판단해 적절한 오브젝트를 전송하는 것이기 때문에, 적절한 갱신주기 측정과 환경 설정은 효율적인 캐싱을 위한 요소 중의 하나다. 오브젝트에 대한 갱신 정책은 웹 서버에서 설정할 수 있으며, 캐싱 서버에서도 해당 컨텐츠에 대한 유효성 여부를 검사할 수 있는 항목을 제공한다.

(그림3)을 참고해 오브젝트의 유효성을 확인할 수 있는 몇 가지 항목을 살펴보면 (표)와 같다. (표)에서 보는 내용들은 일반적으로 웹 페이지 구성시 캐싱과 관련된 것이며 이외에도 다양한 항목들이 오브젝트 유효성 검사를 위한 캐싱 정책에 영향을 미친다.

ㆍ성능 관련 옵션 조정
웹 서비스에 캐싱 서버를 적용함에 있어서 효율을 높이기 위해 서비스별, 컨텐츠별 속성에 따라 갱신주기를 달리하고 기본적인 캐싱관련 옵션들을 설정했다고 하면 그 다음 고려돼야 할 사항은 서버 성능이다.

앞서도 언급했듯이 HTTP 서비스는 TCP를 통한 연결 기반 서비스이므로, 사용자와 서버 간 연결 관리를 얼마나 효과적으로 하느냐에 따라 성능이 2배 이상 차이가 날 수도 있다.

예를 들면 ‘Connection time-out’에 대한 값을 작게 설정해 불필요한 응답 시간이 발생하지 않도록 조정하거나, ‘Keep-alive time-out’ 값을 높여서 세션 재사용률을 높이는 방법 등 해당 서비스 특성에 따라 적절한 값을 설정해 최대한의 효과를 기대할 수 있다.

무조건 수치를 크게 하거나 모든 기능을 다 사용한다고 해서 성능이 나이지는 것은 아니므로, 반드시 해당 서비스의 동시 접속자 수와 전체적인 컨텐츠의 양이 어느정도 되는지의 여부 등을 잘 파악해 시행착오를 거치면서 설정값을 조정하는 것이 최선의 방법이다.

ㆍ웹 서버(원본 서버) 성능 개선

최근 웹 컨텐츠의 대형화와 다양화, 웹 페이지와 인프라 구성의 복잡화는 기존 인프라의 단순한 확장과 설정값 변경만으로는 성능 문제들을 해결하는 게 쉽지 않다. 웹 캐싱의 경우 웹 서버와 웹 캐시 서버 간의 데이터 교환을 기본으로 사용자에게 전달하므로 이중 한 가지의 요소라도 문제가 발생할 경우에는 제대로 된 성능을 기대하기 힘들다.

사이트가 대형화됨에 따라 원본 서버의 용량도 증가하고 사용자의 요청도 점점 다양해지고 있다. 다운로드에서부터 플래시 동영상까지 다양한 형태로 캐싱이 응용되고 있다.

원본과 캐싱 서버에서는 단일 서비스 형태가 아닌 다양한 형태의 서비스를 동시에 관리하고 있다. 이에 따라 원본 서버의 부하가 증가해 웹 캐싱 성능 자체에는 문제가 없음에도 불구하고, 원본과 캐싱 서버간의 병목현상으로 인해 서비스 응답속도가 지연되고 사용자의 불만도 증가하고 있다.

주로 이미지인 초기 원본 서버의 경우, 예전에는 DAS 방식의 스토리지로 운영했으나 점차 대용량화되고 성능상의 이슈가 발생함에 따라 NAS 또는 SAN으로 교체됐고, 최근에는 클러스터 스토리지가 등장하면서 확장성과 성능 두가지 모두를 충족시키는 형태로 발전하고 있다.

스토리지 자체의 성능 이슈 뿐만 아니라 기존 캐싱 구조의 한계는 증가하는 스토리지 용량을 캐싱 용량이 뒷받침하지 못해, 계속적인 오브젝트에 대한 ‘refresh’가 일어나면서 불필요한 부하를 발생시키고 있다.

이런 구조적인 문제들을 최소화하기 위해서는, 우선 안정적인 원본 서버 스토리지 구성이 필요하며, 다수의 대용량 컨텐츠를 효과적으로 처리하기 위해 원본 서버를 대신하는 캐시를 별도로 구성해 ‘원본 서버 -1차 캐시 -2차 캐시’ 형태의 구조로 변경함으로써 기존 원본서버 성능으로 인한 문제점을 어느 정도 해소할 수 있을 것이다.

좀더 나아가서 사용자의 요청별로 분산된 캐싱 서버팜을 구성해 디스크 사용량을 최적화하고 효과적인 웹 캐싱 구성을 적용할 수 있는 방법도 고려돼야 할 것이다. 이외에도 캐싱 가능 여부에 따른 도메인 분리, 불필요한 오브젝트 최소화, 프리캐싱(Pre Caching) 등의 방법도 웹 서비스와 더불어 웹 캐싱의 효율을 높일수 있다.

최근 서비스의 대형화에 따라 내부 인프라를 효율적으로 구성하기 위해 기존 웹 트래픽 처리를 분산된 형태의 외부 네트워크(CDN)로 구성함으로써 내부적인 인프라 관리와 증설 비용을 최소화하고 사용자들에게 안정적인 서비스를 제공할 수 있는 방법들도 적용되고 있다.

웹 캐싱을 이용한 이상적인 웹 서비스 인프라 구성은 (그림 5)와 같이 정리될 수 있으며, 서비스 성격이나 컨텐츠의 특성에 따라 다소 구성이 변경될 수 있다.

웹 캐싱의 한계를 극복하기 위한 노력 필요

웹 캐시 서버를 이용한 웹 서비스 구성과 확장에 대해서 알아봤다. 인터넷 서비스의 비즈니스 모델이 급속도로 발전하고 있지만 이런 트렌드를 뒷받침해 줄 수 있는 움직임들은 다소 더딘 것 같다.

웹 캐싱의 경우는 지속적인 성능개선이 이뤄졌지만 10여 년이 지난 지금도 초기에 설계된 캐싱 알고리즘을 바탕으로 성능과 기능을 강화하다 보니 최근 서비스 형태와는 다소 적합하지 않는 부분도 있으며 한계가 있다. 이런 한계를 극복하기 위한 노력들이 계속되고 있으며 조만간 보다 향상된 형태의 웹 서비스를 위한 방법들이 등장할 것이다.

출처 : 온더넷, 저자 : 윤노기/ GS네오텍 CDN 기술 과장
http://www.ionthenet.co.kr/newspaper/view.php?idx=13129