KR101023622B1

KR101023622B1 - 적응적 고성능 프락시 캐시 서버 및 캐싱방법

Info

Publication number: KR101023622B1
Application number: KR1020080127972A
Authority: KR
Inventors: 서정인; 박정수; 호용환
Original assignee: 지에스네오텍(주)
Priority date: 2008-12-16
Filing date: 2008-12-16
Publication date: 2011-03-22
Also published as: KR20100069316A

Abstract

적응적 고성능 프락시 캐시 서버 및 캐싱 방법이 개시된다. 본 발명의 일 실시 예에 따른 적응적 고성능 프락시 캐시 서버는 응용 서버에서 커널 영역으로의 파일 요청을 캐쉬 모듈에 전달하고, 상기 캐쉬 모듈에 저장된 파일 중 상기 파일 요청에 해당하는 파일을 상기 응용 서버에 전송하는 캐시용 API 후커, 상기 파일 요청에 해당하는 파일이 캐쉬 내 메모리에 존재하면 해당 파일을 상기 캐시용 API 후커에 전달하고, 존재하지 않는 경우 전송 모듈에 상기 파일에 대한 요청을 전달하는 캐쉬 모듈, 하나 이상의 전송 프로토콜을 지원하고, 상기 캐쉬 모듈로부터 요청된 파일을 원본 서버에 요청하고, 상기 원본 서버로부터 수신된 파일을 상기 캐쉬 모듈에 전달하여 저장하는 전송 모듈을 포함한다. 본 발명의 실시 예들에 의하면, 대용량 컨텐츠에 대한 적합성을 갖추고, 어플리케이션이나 HTTP 등의 프로토콜에 종속되지 않고, 기존 어플리케이션의 구조를 변경하지 않아도 다양한 프로토콜 지원할 수 있는 캐시 서버를 제공하여 원본 서버와의 통신에서 제약을 없앨 수 있고, 부분 컨텐츠 처리를 적용할 경우, 불필요한 트래픽을 줄이고 저장 공간을 절약할 수 있다.

content delivery network, cache server, HTTP, FTP, RSync, Partial Contents

Description

적응적 고성능 프락시 캐시 서버 및 캐싱방법 {Adaptive high-performance proxy cache server and Caching method}

본 발명은 컨테츠 전달 네트워크(CDN)에 관한 것으로, 특히, 파일 시스템상의 하위 레벨에서의 컨텐츠 캐싱 및 분산 처리가 필요하거나 기존 웹 캐시에 사용되는 HTTP 의 종속적 한계를 벗어나 비표준 프로토콜을 사용하는 시스템을 위한 프락시 캐시 서버에 관한 것이다.

CDN(content delivery network) 기술은 서로 다른 지리적 위치에서의 캐시 서버(cache server), 즉, 저장 및 전송 능력을 갖는 네트워크 노드들로 구성된다. CDN 기술의 기본 전제는 캐시 서버와 클라이언트 간 링크가 저비용 및 고대역폭을 갖도록 하는 것이다. 클라이언트가 컨텐츠 파일을 요청하는 때에, 컨텐츠 파일이 사용자에 가까운 캐시 서버에 저장되어 있으면, 로딩 속도가 향상될 수 있다. 그렇지 않다면, 클라이언트는 더 긴 속도 지연을 경험할 수 있다. 따라서, 가장 가까운 서버에서 클라이언트가 컨텐츠 파일을 다운로드 하게 하는 것이 바람직하다.

도 1은 미러링 방식을 이용하는 종래의 IP TV 등 대용량 컨텐츠 기반의 서비스 제공 시스템의 예를 간략화하여 도시한 것이다.

메인 서버(Main Storage)에는 원본 데이터가 존재한다. 지역 서버와 서비스 서버는 미러링 방식의 동기화를 사용한다. 지역 서버나 서비스 서버에 요청 컨텐츠가 존재하지 않을 경우 상단 서버로 우회하게 된다. 이때, 하단 서버의 우회 요청이 많을 경우 부하도 증가한다.

또한, 지역 서버의 동작 불능 및 오류의 상황에 대비하여 서버별 중복 컨텐츠가 존재할 가능성이 크므로, 스토리지의 효율성이 떨어진다. 가장 하단의 클라이언트는 주로 셋탑 박스(SetTopBox; STB)에 해당한다. 요청된 컨텐츠가 서비스 서버에 존재하지 않을 경우 QoS 및 QoE의 보장이 어렵다. 이 밖에도 미러링 방식은 서버별 처리 트래픽의 밸런싱이 맞춰지지 않아 서버별 QoS를 적용하기 어렵고, 각 지역별 중복 서버가 존재하므로 이중투자가 이루어질 수 있으며, 지역 서버의 장애 발생시 대처가 어렵다.

이와 같은 이유로 캐시 서버가 사용된다.

도 2는 종래의 웹 캐시 서버(220)의 구조를 도시한 것이다.

클라이언트(210)는 캐시 서버(220)에 특정 컨텐츠에 대한 URL 요청을 보낸다. 캐시 서버(220)는 파일 시스템을 포함하는 운영 체제(222)와 그 위에 설치된 어플리케이션(221)으로 구성된다. 만약 요청된 URL이 가리키는 데이터가 캐시 서버에 저장되어 있지 않은 데이터라면 원본 서버(Origin Server)(230)로 요청하면 해당 컨텐츠 데이터를 자신의 인터널 디스크에 저장하고 클라이언트에 컨텐츠를 전송하는 역할을 한다. 또한, 캐시 서버는 내부적으로 자주 사용되는 데이터는 메모리로 올리고, 자주 사용되지 않는 데이터는 인터널 디스크에서 서비스를 하는 형태로 구성된다.

최근, IPTV, UCC, 웹하드 등 컨텐츠 용량이 점차적으로 늘어나고 있다. 이를 처리하기 위한 코덱 기술, 압축 기술 등도 발전하고 있지만, 컨텐츠 용량의 증가 추이를 현재 기술로 따라잡기는 역부족이다.

반면, 종래의 웹 캐시는 이미지 등 소용량 데이터 처리에 초점을 맞추어 설계되었다. 또한, 정적 데이터의 처리를 주목적으로 설계된 웹 캐시는 어플리케이션에 종속되어, 추가 로직을 유연하게 적용하기가 사실상 불가능하다.

또한, 종래의 웹 캐시는 일반적으로 HTTP 만을 지원하고, 분산 구조로 만들기가 어렵다. 또한, 종래의 웹 캐시는 범용성에 초점이 맞춰져 있고, 유연한 대용량 컨텐츠 처리 능력이 미약하며,

결론적으로, 종래의 캐시 서버는 대용량 컨텐츠에는 비적합하고, 어플리케이션 뿐만아니라, HTTP에 종속되어 다양한 프로토콜 지원이 용이하지 않다.

본 발명이 이루고자 하는 첫 번째 기술적 과제는 대용량 컨텐츠에 대한 적합성을 갖추고, 어플리케이션이나 HTTP, FTP 등의 프로토콜에 종속되지 않고, 다양한 프로토콜 지원할 수 있는 캐시 서버를 제공할 수 있는 적응적 고성능 프락시 캐시 서버를 제공하는 데 있다.

본 발명이 이루고자 하는 두 번째 기술적 과제는 상기의 적응적 고성능 프락시 캐시 서버를 이용한 캐싱 방법을 제공하는 데 있다.

상기의 첫 번째 기술적 과제를 이루기 위하여, 본 발명의 일 실시 예에 따른 적응적 웹 캐시 서버는 응용 서버에서 커널 영역으로의 파일 요청을 캐쉬 모듈에 전달하고, 상기 캐쉬 모듈에 저장된 파일 중 상기 파일 요청에 해당하는 파일을 상기 응용 서버에 전송하는 캐시용 API 후커, 상기 파일 요청에 해당하는 파일이 캐쉬 내 메모리에 존재하면 해당 파일을 상기 캐시용 API 후커에 전달하고, 존재하지 않는 경우 전송 모듈에 상기 파일에 대한 요청을 전달하는 캐쉬 모듈, 하나 이상의 전송 프로토콜을 지원하고, 상기 캐쉬 모듈로부터 요청된 파일을 원본 서버에 요청하고, 상기 원본 서버로부터 수신된 파일을 상기 캐쉬 모듈에 전달하여 저장하는 전송 모듈을 포함한다.

바람직하게는, 상기 응용 서버에는 HTTP, FTP, TCP 등을 기반으로 독자적으로 설계된 프로토콜의 전송을 위한 어플리케이션이 설치될 수 있다.

바람직하게는, 상기 캐쉬 모듈은 상기 파일 요청의 빈도수에 따라 파일마다 랭킹을 부여하고, 상기 랭킹에 따라 캐쉬 접근 우선 순위를 적용할 수 있다.

바람직하게는, 상기 캐시용 API 후커는 상기 파일 요청을 상기 커널 영역에 전달하여 인터널 디스크에 해당 파일이 존재하는지 확인할 수 있다.

바람직하게는, 상기 캐시용 API 후커는 동일한 컨텐츠를 가지고 있는 캐시 그룹이 설정되는 경우, 원본 서버에 직접 데이터를 전송하지 않고, 같은 그룹 내에 컨텐츠가 존재하는지를 체크하고 필요한 컨텐츠를 전송받을 수 있다.

바람직하게는, 상기 전송 모듈은 추가적인 전송 프로토콜을 지원하기 위한 하나 이상의 프로토콜 모듈을 포함할 수 있다.

바람직하게는, 상기 전송 모듈은 컨텐츠를 구성하는 모든 부분을 원본 서버로부터 전송받지 않고, 필요한 부분만 나누어 요청할 수 있다.

상기의 두 번째 기술적 과제를 이루기 위하여, 본 발명의 일 실시 예에 따른 적응적 프락시 캐시 서버를 이용한 캐싱 방법은 캐시용 API 후커가 응용 서버에서 커널 영역으로의 파일 요청을 캐쉬 모듈에 전달하고, 상기 파일 요청에 해당하는 파일이 캐쉬 내 메모리에 존재하지 않는 경우 전송 모듈에 상기 파일에 대한 요청을 전달하며, 하나 이상의 전송 프로토콜을 지원하는 전송 모듈에서 상기 캐쉬 모듈로부터 요청된 파일을 원본 서버에 요청하고, 상기 원본 서버로부터 상기 전송 모듈로 파일이 수신되면, 상기 캐쉬 모듈에 전달하여 저장하고, 상기 캐시용 API 후커가 상기 캐쉬 모듈에 저장된 파일을 상기 응용 서버에 전송하는 과정을 포함한다.

본 발명의 실시 예들에 의하면, 대용량 컨텐츠에 대한 적합성을 갖추고, 어플리케이션이나 HTTP 등의 프로토콜에 종속되지 않고, 기존 어플리케이션의 구조를 변경하지 않아도 다양한 프로토콜 지원할 수 있는 캐시 서버를 제공하여 원본 서버와의 통신에서 제약을 없앨 수 있고, 부분 컨텐츠 처리를 적용할 경우, 불필요한 트래픽을 줄이고 저장 공간을 절약할 수 있다. 또한 자주 쓰는 데이터 블록을 집중적으로 처리할 수 있어, 성능 향상의 부가적인 이득을 얻을 수 있다.

이하에서는 도면을 참조하여 본 발명의 바람직한 실시 예를 설명하기로 한다. 그러나, 다음에 예시하는 본 발명의 실시 예는 여러 가지 다른 형태로 변형될 수 있으며, 본 발명의 범위가 다음에 상술하는 실시 예에 한정되는 것은 아니다.

본 발명의 일 실시 예에서는 어플리케이션에 종속되지 않는 캐시 서버를 제공한다. 이하에서는, 본 발명의 일 실시 예를 적용한 플랫폼을 적응적 고성능 프락시 캐시로 정의한다.

도 3은 본 발명의 일 실시 예에 따른 적응적 고성능 프락시 캐시 서버(320)의 구조를 도시한 것이다.

본 발명의 일 실시 예에 따른 프락시 캐시 모듈(320)는 비표준 프로토콜을 지원할 수 있으므로, 다양한 프로토콜을 통한 원본(Oringin) 통신을 수행할 수 있다.

어플리케이션(310)은 소스 코드의 변경 없이 파일 시스템에 접근할 수 있도 록 프락시 캐시용 API 후커(Hooker)(321)와 연결된다. 프락시 캐시용 API 후커는 기존 파일 시스템을 커널 레벨이 아닌 유저 레벨에서 접근하고 확장할 수 있는 어뎁터(Adpater)의 일종이다. 이를 이용하면, 프락시 캐시를 위한 파일 시스템 자체를 별도로 개발하지 않아도 새로운 어플리케이션을 확장하여 지원할 수 있다.

프락시 캐시용 API 후커(321)를 적용하면, OS(파일 시스템) 레벨에서 캐싱 알고리즘이 적용되므로, 기존의 어플리케이션을 변경할 필요가 없으며 기존 파일 시스템 접근 API를 그대로 사용하여 기능을 확장할 수 있다.

프락시 캐시용 API 후커(321)에 연결되는 어플리케이션(310)은 어떠한 형태든지 가능하다. 즉, 어플리케이션(310)은 아파치 등의 일반 웹서버, FTP 서버, TCP 기반 서버 등일 수 있다. 어플리케이션(310)에서 파일 시스템에 대한 접근은 일종의 표준 라이브러리를 사용하므로, 파일 작업을 위해 별도의 방법을 적용할 필요가 없다.

상기 적응적 프락시 캐시(320)는 어플리케이션에 대해 최대한의 독립성을 보장받는다. 이에 따라, 적응적 프락시 캐시(320)는 특정 모듈을 붙이거나 제거하기가 용이하다. 적응적 프락시 캐시(320)는 기존 스토리지를 효율적으로 분산한다. 이를 위해 파일 단위와 파일의 조각 단위의 부분 컨텐츠(Partial Contents) 처리를 위한 모듈을 웹 캐시용 API 후커(321)에 연결할 수 있다.

프락시 캐시용 API 후커(321)는 어플리케이션에서 API를 가로채기 위해 어플리케이션과 OS 영역 사이에 설치된다. 즉, 어플리케이션(310)에서는 기존과 동일한 API를 통해 접근하더라도, 웹 캐시용 API 후커(321)에서 웹 캐시를 위한 추가 모 듈(322, 323, 325, 326)을 어플리케이션(310)과 연동시킨다. 여기서, 추가 모듈은 프락시 캐시를 위한 저장 공간을 제공하고 랭킹 알고리즘을 적용할 수 있는 캐시 모듈(322)과 하나 이상의 전송 프로토콜을 지원하는 전송 모듈(323)을 포함한다.

전송 모듈(323)을 이용하면, 단순한 HTTP 기반의 한계를 극복하여 다양한 프로토콜을 지원할 수 있고, 보안, 압축 등 추가 기능을 독립 모듈로 구성할 수도 있다. 또한, 전송 모듈(323)은 원본 서버(330)와의 세션을 최소화하도록 할 수 있다. 전송 모듈(323)은 슬로우 링크(Slow Link)를 고려할 수 있다. 또한 프락시 캐시용 API 후커(321)의 정보와 연동되어, 원본 서버(330)로부터 데이터를 직접 가져오지 않고, 동일한 컨텐츠를 가지고 있는 캐시 서버 그룹에서 데이터를 전송받을 수 있다. 이때 디스크 공간을 절약하기 위하여, 해당 데이터를 저장하고 있는지 여부를 알려줄 수 있는 방법이 제공될 수 있고, 디스크에 저장하지 않을 경우에는 전송 모듈(323)이 서비스를 위한 통로 역할(프락시 기능)을 수행한다.

관리 모듈(325)은 시스템 설계자의 요구에 따라 생략될 수 있다. 관리 모듈(325)은 캐시 모듈(322)을 위한 Log를 제공한다. 또한, 관리 모듈(325)은 적응적 프락시 캐시(320)를 위한 설정 파일을 제공한다. 이와 같은 설정 파일은 XML 등의 언어로 확장할 수 있다. 관리 모듈(325)은 캐시용 API 후커(321)과 별도로 어플리케이션(310)을 위한 인터페이스를 제공할 수 있다. 또한 관리 모듈(325)은 프락시 캐시 서버의 통계 데이터를 제공을 위한 SNMP 등의 확장 기능을 제공할 수 있으며, 운영 자동화에 대한 기능을 수행하는 로직을 포함할 수 있다.

관리 시스템(326) 역시 생략될 수 있다. 관리 시스템(326)은 관리 모듈(325) 와 원본 서버(332) 사이의 통신을 매개한다.

리눅스나 기타 다른 OS에 적응적 프락시 캐시를 위한 모듈을 설치할 수도 있다. 적응적 프락시 캐시(320)는 대용량 서비스 (IPTV, UCC, 다운로드)를 기본적으로 지원하며, 소용량 정적 이미지까지 폭넓게 처리할 수 있다.

도 4는 본 발명의 다른 실시 예에 따른 적응적 프락시 캐시 서버(420)의 구조를 도시한 것이다.

어플리케이션(410)은 HTTP, FTP, TCP 기반의 독자적인 프로토콜 등의 전송 프로토콜을 위한 어플리케이션일 수 있다.

캐시용 API 후커(421)는 어플리케이션(410)에서 커널 영역(424)으로의 파일 요청을 캐쉬 모듈(422)에 전달한다. 또한, 캐시용 API 후커(421)는 캐쉬 모듈(422)에 저장된 파일 중 상기 파일 요청에 해당하는 파일을 어플리케이션(410)에 전송한다. 캐시용 API 후커(421)는 상기 파일 요청을 커널 영역(424)에 전달하여 인터널 디스크에 해당 파일이 존재하는지 확인할 수도 있다.

캐쉬 모듈(422)은 상기 파일 요청에 해당하는 파일이 캐쉬 내 메모리에 존재하면 해당 파일을 캐시용 API 후커(421)에 전달하여 어플리케이션(410)에 전송되도록 한다. 또한, 캐쉬 모듈(422)은 해당하는 파일이 캐쉬 내 메모리에 존재하지 않는 경우 전송 모듈(423)에 상기 파일에 대한 요청을 전달한다. 캐쉬 모듈(422)은 파일 요청의 빈도수에 따라 파일마다 랭킹을 부여하고, 상기 랭킹에 따라 캐쉬 접근 우선 순위를 적용할 수도 있다. 우선 순위를 적용하기 위해 설정 값으로 별도의 규칙을 지정할 수 있으며, 우선 순위를 수동으로 조절하는 것도 가능하다.

전송 모듈(423)은 하나 이상의 전송 프로토콜을 지원한다. 전송 모듈(423)은 캐쉬 모듈(422)로부터 요청된 파일을 원본 서버(432)에 요청한다. 원본 서버(432)에 요청할 때, 전송 모듈(423)은 원본 서버(432)의 전송 모듈(431)과 통신을 수행한다. 전송 모듈(423)은 추가적인 전송 프로토콜을 지원하기 위한 하나 이상의 프로토콜 모듈을 포함하거나 상기 프로토콜 모듈과 연결될 수 있다. 도 4에는 프로토콜 모듈(425)이 전송 모듈(423)과 독립하여 연결되는 경우를 도시하였지만, 프로토콜 모듈(425)은 전송 모듈(423)에 기능적으로 포함될 수도 있다.

원본 서버(432)는 스토리지(433)를 검색하여 요청된 파일이 있는 경우 전송 모듈(431)을 통해 해당 파일을 적응적 프락시 캐시(420)에 전송한다. 전송 모듈(423)은 원본 서버(432)로부터 수신된 파일을 캐쉬 모듈(422)에 전달하여 저장한다.

도 5는 도 3에서 특정 파일을 요청하는 절차의 예를 도시한 것이다.

먼저, "/mnt/splatform/ABC.avi" 파일을 어플리케이션 서버(510)에서 요청하는 경우를 가정한다.

캐시용 API 후커(521)는 상기 파일 요청을 가로챈다. 캐시용 API 후커(521)는 파일 메타 데이터(File Meta Data)(522)로부터 해당 파일의 해당 부분이 존재하는지 여부를 확인한다.

해당 파일이 메모리 캐시(Mem Cache)(523)에 있는 경우 우선순위(Priority)를 높여주고 서비스한다. 해당 파일이 디스크 캐시(DiskCache)(524)에 있는 경우 우선순위를 높여주고 해당 파일의 해당 부분을 필요한 경우 메모리 캐시(523)로 읽 어 들여 서비스한다. 적응적 웹 캐시에서는 기본적으로 자주 쓰는 데이터의 블록을 메모리 캐시(523)에 올려서 서비스한다.

해당 파일이 디스크 캐시(524)에 없는 경우 임의의 프로토콜(525)을 이용하여 원본 서버(530)로부터 해당 파일(상기 예에서는 "ABC.avi" 파일)을 전송받으면서 서비스를 해준다. 해당 부분을 전송받는 동안에도 해당 부분에 대한 다른 요청의 블록을 방지하여 전송 지연을 최소화하는 방법이 적용될 수 있다. 이때, 적응적 프락시 캐시는 해당 부분을 전송 받으면서 디스크에 기록할 수 있다. 해당 파일에 대한 서비스도 이와 동시에 이루어질 수 있다. 서비스의 성격에 따라 원본에서 전송되어 온 데이터를 메모리를 통하여 바로 서비스를 실시하고, 이후 디스크에 저장하는 형태도 가능하다. 이는 관리자의 선택에 따른다. 프락시 캐시는 설정 정보를 읽어와 상기 기능을 수행할 것이다.

한편, 디스크 캐시(524)가 꽉 찰 경우, 디스크의 여유 공간을 항상 유지하여 디스크가 꽉 찰 수 있는 없도록 한다. 디스크의 여유 공간은 항상 프리 리스트(527)를 설정된 수치로 유지/확보한다. 디스크에서 파일을 지우기 위해, 처리 속도를 향상하기 위하여 파일을 실제 디스크에서 지우지 않고 메타데이타에서만 삭제가 되도록 할 수 있다. 부분 파일 관리자(526)는 해당 부분을 프리 리스트(527)로 보낸다. 프리 리스트에서 관리되는 디스크 영역은 유효하지 않은 데이터로, 이후 필요한 경우 무시하고 덮어 쓰기를 한다.

원본에서 파일이 변경된 경우, 도 3의 캐시 모듈(322)은 일정시간마다 서버에 정보를 요청해서 파일명, 파일 크기, 수정 날짜 등의 메타 정보가 다른지 확인 한다. 캐시 모듈(322)은 상기 정보가 달라진 경우, 해당 파일을 갱신한다.

디스크 캐시(524) 등에 저장된 파일의 삭제가 필요한 경우, 부분 파일 관리자(526)는 해당 파일의 메타데이터를 이용하여 해당 파일에 속해있는 부분 파일들을 모두 프리 리스트(527)에 등록한다. 캐시용 API 후커(521)는 어플리케이션(510)에서 요청한 파일을 메모리 캐시(523) 또는 디스크 캐시(524)에서 검색하여 어플리케이션(510)에 전달한다.

도 6은 도 3의 프락시 캐시 서버를 컨텐츠 라우터와 함께 실제의 시스템에 적용한 예를 도시한 것이다.

웹 서버로 예를 들면, 클라이언트가 "http://xxx.xxx.com/ABC.avi"의 요청을 웹 서버로 보낸다. 웹 서버의 어플리케이션에서 요청을 받아들인다. 웹 서버의 로컬 디스크에 있는 ABC.avi에 접근하여 클라이언트에 보낼 준비를 한다. 이때, 적응적 웹 캐시에 마운팅된 디스크 디렉토리는 "/dev/XXX"라고 가정한다.

클라이언트로부터의 파일 요청은 어플리케이션에서 파일 오픈(open), 리드(read) API로 전환되는데, 적응적 웹 캐시에서는 이를 가로챈 후 본 발명에 따른 추가 로직에 전달한다. 예를 들어, 적응적 프락시 캐시에서는 어플리케이션으로부터 "/dev/XXX"으로 들어오는 모든 파일 시스템 접근에 대한 API를 가로챈다. 추가 로직은 메모리 캐시 또는 디스크 캐시를 액세스 하는 등 OS에 접근하고, 요청된 파일을 어플리케이션으로 올려준다.

클라이언트는 G7.GSCDN.COM에게 ABC.avi가 어디 있는지 요청한다. 이때, 컨텐츠 라우팅 시스템 즉, 컨텐츠 라우터는 ABC.avi의 요청 빈도를 계산하여 인기 컨 텐츠 여부를 판단한다.

컨텐츠 라우터는 클라이언트의 컨텐츠에 대한 모든 요청을 1차적으로 처리한다. 요청 컨텐츠를 분석하여 해당 컨텐츠가 인기도에 따라 어느 서버에서 적절 서비스를 하는 것이 적절한 지를 판단하고, 컨텐츠의 위치를 클라리언트에게 알려준다. 클라이언트는 컨텐츠 라우터 부터 받은 위치에서 컨텐츠를 서비스 받는다. 컨텐츠 라우터는 클라이언트가 요청한 ABC.avi가 요청 빈도수가 일정 횟수 이상인 인기 컨텐츠이면 해당 파일이 HOT서버에서 서비스된다고 클라이언트에 통보한다. 인기컨텐츠는 도 6과 같이 라운드 로빈 형태로 분산처리(HOT1.GSCDN.COM)한다.

클라이언트가 요청한 ABC.avi가 인기 컨텐츠가 아니면 해당 컨텐츠를 서비스 하는 서버가 어디인지를 클라이언트에 통보한다. 인기 컨텐츠가 아닌 경우는 GSS1.GSCDN.COM와 같은 그리스 서버 셋(Grid Server Set)에 분산되어 저장된다. 이후, 클라이언트는 서버 프로그램에 컨텐츠를 요청한다.

컨텐츠 라우터의 기능은 S-플랫폼의 내부에 로직으로 추가하는 것이 가능하다.

도 6에서 S-플랫폼은 본 발명의 일 실시 예에 따른 적응적 프락시 캐시를 의미한다. 적응적 웹 캐시가 설치된 서버는 아파치 등의 어플리케이션, 적응적 프락시 캐시, 리눅스 등의 운영체제로 구성될 수 있다. 적응적 웹 캐시에서는 OS 레벨에서 캐싱 기능이 추가 되므로, 기존 파일 시스템 접근 방법론을 그대로 사용하여 기능을 확장할 수 있다.

S-플랫폼은 고성능 CPU와 메모리, 디스크의 용량이 최대로 구성된 서버의 일 종이다. 클라이언트의 서버 프로그램은 S-플랫폼 위에 설치된다. S-플랫폼은 서비스 전용 플랫폼으로서, 서버 프로그램이 일반 스토리지로 간주할 수 있는 가상의 스토리지를 내장한다. 가상의 스토리지는 원본 서버와 캐싱 기술을 이용한 실시간 동기화 및 서비스가 가능하다. S-플랫폼은 일반 컨텐츠의 분산처리를 위한 그리드 서버 셋과 인기 컨텐츠 처리를 위한 핫 서버 셋으로 구성될 수 있으며, 이는 컨텐츠 라우터를 통하여 물리적, 논리적으로 확장될 수 있다.

S-플랫폼은 서버 프로그램이 요청한 컨텐츠를 자신이 가지고 있는지를 판단하고 해당 파일을 서버 프로그램에 제공한다. S-플랫폼이 현재 컨텐츠를 가지고 있지 않으면 원본 서버에 요청하여 컨텐츠를 전송받으면서 서버 프로그램에 제공한다. S-플랫폼은 주기적으로 파일 정합성을 판단하여 원본 서버와 동기화를 수행한다.

S-플랫폼은 상술한 캐싱 로직을 포함하는데, 메모리 캐시나 디스크 캐시에 ABC.avi이 없는 경우, 설정된 원본 서버에 접속하여 해당 데이터를 가져온다. 해당 데이터는 디스크 캐시나 메모리 캐시에 저장될 수 있다. 만약 메모리 캐시나 디스크 캐시에 이미 저장된 데이터가 존재하면, 저장된 데이터를 읽어올들이고, 읽어들인 데이터는 어플리케이션에 전달한다. 어플리케이션은 상기 데이터를 클라이언트에 전달함으로써 응답한다.

원본 서버는 각각의 스토리지 앞 단에 위치한 서버를 현재의 기설정된 수치 이하로 유지한다. 원본 서버는 기존의 서비스 프로그램을 사용하지 않고, 단순히 Rsync, HTTP, FTP등의 표준화 프로토콜 또는 TCP 기반의 독자적으로 설계된 프로토 콜을 이용하여 S-플랫폼과의 동기화 및 업로드에만 관여한다. S-플랫폼을 통해 클라이언트의 모든 요청이 처리되므로 원본 서버의 디스크 액세스가 현저히 줄어들게 된다. 이에 따라, 스토리지의 물리적 장애 발생 리스크를 감소시키는 효과도 얻을 수 있다.

도 7은 도 4의 프락시 캐시 서버의 부분 컨텐츠 처리를 간략하게 도시한 것이다.

부분 컨텐츠 처리를 위해서, S 플랫폼에서 원본 서버로부터 파일을 수신할 때는 복수의 조각으로 나누어진 파일 조각을 수신한다. 파일 조각은 S 플랫폼의 캐시 메모리 또는 디스크에 저장되므로, 파일 조각별로 캐싱 처리가 가능하다.

도 8은 동일 컨텐츠 캐시 서버 그룹에서의 통신을 간략하게 도시한 것이다.

S 플랫폼은 복수의 프락시 캐시 서버로 구성될 수 있는데, 동일한 컨텐츠를 가지도록 그룹으로 묶여진 프락시 캐시 서버들은 서로간의 통신을 통해 사용자가 요청한 컨텐츠가 있는지 확인한다. 프락시 캐시 서버가 자신의 컨텐츠 그룹 내에서 사용자가 요청한 컨텐츠를 발견하면, 원본 서버에 컨텐츠를 요청하지 않는다.

본 발명은 도면에 도시된 일 실시 예를 참고로 하여 설명하였으나 이는 예시적인 것에 불과하며 당해 분야에서 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 실시 예의 변형이 가능하다는 점을 이해할 것이다. 그리고, 이와 같은 변형은 본 발명의 기술적 보호범위 내에 있다고 보아야 한다. 따라서, 본 발명의 진정한 기술적 보호범위는 첨부된 특허청구범위의 기술적 사상에 의해서 정해져야 할 것이다.

본 발명은 파일 시스템상의 하위 레벨에서의 캐싱 및 분산 처리가 필요하거나 비표준 프로토콜을 사용하는 시스템을 위한 프락시 캐시 서버에 관한 것으로, 컨테츠 전달 네트워크(CDN)에 적용될 수 있다.

도 1은 미러링 방식을 이용하는 종래의 IP TV 서비스 제공 시스템의 예를 도시한 것이다.

도 2는 종래의 웹 캐시 서버의 구조를 도시한 것이다.

도 3은 본 발명의 일 실시 예에 따른 적응적 고성능 프락시 캐시 서버의 구조를 도시한 것이다.

도 4는 본 발명의 다른 실시 예에 따른 적응적 고성능 프락시 캐시 서버의 구조를 도시한 것이다.

Claims

HTTP, FTP, RSync, 또는 TCP 기반의 프로토콜 중 적어도 하나의 전송 프로토콜을 위한 어플리케이션이 설치되는 응용 서버;

상기 어플리케이션과 OS 영역 사이에 설치되고, 리눅스의 표준 파일 시스템 API를 사용하면서 상기 표준 파일 시스템 API의 기능을 대체하여 상기 어플리케이션에 대해 투명하게 동작하되, 응용 서버의 어플리케이션에서 커널 영역으로의 파일 요청에 대해 상기 대체되는 기능을 위해 설치되는 모듈을 이용하여 상기 응용 서버에서 호출하는 상기 표준 파일 시스템 API의 기능을 대체하여 수행하는 방식으로 유저 레벨의 어댑터로 동작하고, 상기 설치되는 모듈은 캐쉬 모듈을 포함하는 캐시용 API 후커;

상기 캐시용 API 후커로부터 상기 파일 요청을 전달받고, 상기 파일 요청에 해당하는 파일이 캐쉬 내 저장 공간에 존재하면 해당 파일을 상기 캐시용 API 후커를 통해 상기 응용 서버에 전달하고, 존재하지 않는 경우 전송 모듈에 상기 파일에 대한 요청을 전달하는 캐쉬 모듈; 및

HTTP, FTP, RSync, 또는 TCP 기반의 프로토콜 중 적어도 하나의 전송 프로토콜을 지원하기 위한 하나 이상의 프로토콜 모듈을 포함하며, 상기 캐쉬 모듈로부터 요청된 파일을 원본 서버에 요청하고, 상기 원본 서버로부터 수신된 파일을 상기 캐쉬 모듈에 전달하여 저장하며, 부분 컨텐츠의 전송 및 저장을 지원하는 전송 모듈을 포함하는, 적응적 프락시 캐시 서버.
삭제
제 1 항에 있어서,

상기 캐쉬 모듈은,

상기 파일 요청의 빈도수에 따라 파일마다 랭킹을 부여하고, 상기 랭킹에 따 라 캐쉬 접근 우선 순위를 적용하는 것을 특징으로 하는, 적응적 프락시 캐시 서버.
제 1 항에 있어서,

상기 캐시용 API 후커는,

상기 파일 요청을 상기 커널 영역에 전달하여 인터널 디스크와 컨텐츠 캐시 그룹에 해당 파일이 존재하는지 확인하는 것을 특징으로 하는, 적응적 프락시 캐시 서버.
삭제
캐쉬 모듈, 및 HTTP, FTP, RSync, 또는 TCP 기반의 프로토콜 중 적어도 하나의 전송 프로토콜을 지원하기 위한 하나 이상의 프로토콜 모듈을 프락시 캐시 서버에 추가하는 단계;

어플리케이션과 OS 영역 사이에 설치되고 리눅스의 표준 파일 시스템 API를 사용하면서 상기 표준 파일 시스템 API의 기능을 대체하여 상기 어플리케이션에 대해 투명하게 동작하는 캐시용 API 후커가 응용 서버의 어플리케이션에서 커널 영역으로의 파일 요청을 가로채어 상기 캐쉬 모듈에 전달하는 단계;

상기 캐쉬 모듈이 상기 캐시용 API 후커로부터 상기 파일 요청을 전달받으면, 상기 파일 요청에 해당하는 파일이 캐쉬 내 저장 공간에 존재하면 해당 파일을 상기 캐시용 API 후커를 통해 상기 응용 서버에 전달하는 단계;

상기 파일 요청에 해당하는 파일이 캐쉬 내 저장 공간에 존재하지 않는 경우 전송 모듈에 상기 파일에 대한 요청을 전달하는 단계;

부분 컨텐츠 전송 및 저장을 지원하는 전송 모듈에서 상기 캐쉬 모듈로부터 요청된 파일을 원본 서버에 상기 프로토콜 모듈을 이용하여 요청하는 단계;

상기 원본 서버로부터 상기 전송 모듈로 파일이 상기 프로토콜 모듈을 이용하여 수신되면, 상기 캐쉬 모듈에 전달하여 저장하는 단계; 및

상기 캐시용 API 후커가 상기 캐쉬 모듈에 저장된 파일을 상기 응용 서버에 전송하는 단계를 포함하고

상기 캐시용 API 후커는

응용 서버의 어플리케이션에서 커널 영역으로의 파일 요청에 대해 상기 대체되는 기능을 위해 설치되는 모듈들을 이용하여 상기 응용 서버에서 호출하는 상기 표준 파일 시스템 API의 기능을 대체하여 수행하는 방식으로 유저 레벨의 어댑터로 동작하고

상기 응용 서버는

HTTP, FTP, RSync, 또는 TCP 기반의 프로토콜 중 적어도 하나의 전송 프로토콜을 위한 어플리케이션이 설치되는 것을 특징으로 하는, 적응적 프락시 캐시 서버를 이용한 캐싱 방법.