콘텐츠 배포 서비스
콘텐츠 배포 서비스란?
포워드 프록시나 트랜스페어런트 프록시는 캐시 서버를 클라이언트 측에 두는 경우이며 리버스 프록시는 캐시 서버를 서버 측에 두는 경우이다.
이렇게 캐시 서버는 클라이언트 측과 서버 측에 둘 수 있는데 캐시 서버의 위치에 따라 이용 효과 면에서 차이가 난다.
서버 측에 캐시 서버를 두는 경우 웹 서버의 부하를 경감하는 효과가 존재하며 웹 서버 쪽에 캐시 서버가 존재하므로 웹 서버 운영자가 캐시 서버를 관리할 수 있다는 장점이 있다.
단지 사용자가 인터넷에 직접 패킷을 보내므로 인터넷 트래픽을 억제하는 효과는 없다.
인터넷의 트래픽을 억제하고 싶을 경우 클라이언트측에 캐시 서버를 두는 것이 좋다.
인터넷 내에는 트래픽이 많아 혼잡한 곳이 있을 수 있는데 그곳을 통과하려면 시간이 오래 걸린다. 만약 클라이언트 측에 캐시 서버가 존재한다면 이러한 혼잡에 휘말려드는 일이 없으므로 패킷의 흐름이 안정된다.
특히 화상이나 영상 같은 대용량 데이터를 포함하는 콘텐츠라면 이러한 효과가 더욱 커진다.
하지만 클라이언트 측에 두는 캐시 서버는 클라이언트측의 네트워크를 운영/관리하는 프로바이더가 소유하고 있다.
따라서 웹 서버 운영자는 클라이언트 측의 캐시 서버를 관리할 수 없다.
이처럼 캐시 서버는 위치에 따라 장단점이 존재하는데 양쪽의 장점만을 취한 방법도 있다.
바로 프로바이더와 계약하여 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트 측의 프로바이더에 두는 방법이다.
이렇게 되면 캐시 서버는 클라이언트 측에 존재하므로 트래픽을 억제할 수도 있으며 웹 서버 운영자는 프로바이더와 계약하여 캐시 서버를 직접 관리할 수도 있게 된다.
하지만 이 방법도 문제가 있다.
인터넷에 공개된 공개용 서버는 어떤 클라이언트라도 접근할 수 있기 때문에 웹 서버는 인터넷의 어디에서 액세스 요청이 들어올지 알 수 없다. 따라서 이 방법을 실현하기 위해선 프로바이더의 POP 전부에 캐시 서버를 설치해야 하는데 전 세계에 POP의 개수는 너무 많으므로 비현실적인 방법이다.
이 문제를 해결하기 위한 방법으로 중요한 프로바이더에만 캐시 서버를 설치하는 방법이 존재한다.
사용자 입장에서는 캐시 서버를 무조건 거쳐 웹 서버로 가야하기 때문에 최단 거리가 아닐 수는 있지만 웹 서버에 직접 액세스 하는 것보다는 짧은 시간을 들여 패킷이 도착할 수 있다.
현실성을 높였지만 여전히 문제점은 존재하는데 바로 캐시 서버를 설치하는 것에 많은 자원이 투자되어야 한다는 점이다.
아무리 중요한 프로바이더에만 캐시 서버를 설치한다 하더라도 웹 서버 운영자가 프로바이더와 계약한 뒤 프로바이더의 중요한 영역에 직접 캐시 서버를 설치한다는 것은 비용과 노력면에서 매우 어려운 일이다.
이러한 문제를 해결하기 위해 캐시 서버를 설치하고 이를 웹 서버 운영자에게 대출하는 서비스를 제공하는 사업자가 등장했는데, 이런 종류의 서비스를 "콘텐츠 배포 서비스(CDS; Content Delivery Service)"라고 한다.
CDS를 제공하는 사업자 CDSP는 중요한 프로바이더와 계약한 뒤 그 곳에 다수의 캐시 서버를 설치한다.
이렇게 CDSP가 프로바이더 측에 다수의 캐시 서버를 설치했다면 웹 서버 운영자와도 계약하여 웹 서버와 CDSP의 캐시 서버를 연결시킨다.
이렇게 CDSP의 캐시 서버와 웹 서버 운영자가 연결되었다면 최종적으로 사용자 → CDSP의 캐시 서버 → 웹 서버로 패킷이 흐르므로 위에서 말했던 프로바이더와 계약하여 프로바이더 측에 캐시 서버를 두는 방법이 실현 가능해지는 것이다.
캐시 서버는 다수의 웹 서버 데이터를 캐시에 저장할 수 있으므로 1개의 캐시 서버를 다수의 웹 서버 운영자가 공동으로 이용할 수도 있다.
이렇게 할 경우 웹 서버 운영자 1명 당 계약 비용이 줄어들기 때문에 비용 부담이 줄어들며 프로바이더와의 계약 또한 CDSP가 한 번에 수행하므로 노력면에서도 부담이 되지 않는다.
경로 정보를 통해 가장 가까운 캐시 서버 찾기
콘텐츠 배포 서비스를 사용하는 경우 CDSP가 설치한 다수의 캐시 서버 중 어떤 캐시 서버를 통해 웹 서버로 패킷을 보낼지 정해야 한다.
이를 위해 설치된 여러 캐시 서버 중 클라이언트측과 가장 가까운 캐시 서버를 찾아내 여기에 액세스 하도록 중재하는 구조가 필요하다.
최초의 방법은 DNS 서버가 클라이언트와 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 세밀하게 설정하는 방법이다.
이는 복수 서버를 설치하여 부하를 분산시킬 때 DNS 서버에서 액세스를 분배하는 것과 비슷한 방법인데 이를 이해하기 위해선 DNS 서버의 동작을 복습해 볼 필요가 있다.
DNS 서버는 인터넷에 다수 배치되어 있고 이들이 연대하여 도메인명에 해당하는 IP 주소를 찾는다.
먼저 클라이언트는 액세스 대상인 도메인명을 기록한 조회 메시지를 만들고 이를 클라이언측 LAN에 있는 DNS 서버에 보낸다.
클라이언트 측 DNS 서버는 도메인명의 계층 구조를 통해 웹 서버 측에 있는 DNS 서버를 찾아낼 것이고 그곳에 조회 메시지를 보낸다. 웹 서버 측의 DNS 서버라고 하니 뭔가 어려워 보이지만, 그냥 접근할 도메인명에 해당하는 IP 주소를 가진 DNS 서버이다.
웹 서버 측 DNS 서버는 도메인명에 대응하는 IP 주소를 조사하여 클라이언트측 DNS 서버에 IP 주소를 회답할 것이며 이를 통해 클라이언트는 도메인명에 해당하는 IP 주소를 찾을 수 있는 것이 DNS 서버의 동작 과정의 요약이다.
추가로 만약 1개의 도메인명에 복수의 IP 주소가 대응된다면 라운드 로빈(RR)에 의해 차례로 IP 주소를 회답할 것이다
하지만 이런 구조를 CDS에서 사용할 경우 라운드 로빈 방식으로 IP 주소를 회답하므로 클라이언트와 가장 먼 위치에 있는 캐시 서버의 IP 주소를 반환할 수도 있다.
따라서 라운드 로빈이 아니라 클라이언트와 캐시 서버 사이의 거리를 판단하여 클라이언트 측에 가장 가까운 캐시 서버 IP 주소를 회답하는 방식이 필요하다.
그렇다면 클라이언트와 캐시 서버 사이의 거리는 어떻게 판단할까?
먼저 준비단계로 서버측 DNS 서버에 CDSP가 설치한 캐시 서버에 있는 라우터의 경로 정보를 모아둔다.
그리고 이 경로 정보를 통해 각 캐시 서버에서 클라이언트 측의 DNS 서버에 이르는 경로 정보를 조사한다.
즉, 클라이언트측 DNS 서버는 서버 측 DNS 서버에 도메인명에 대응되는 IP 주소를 물어볼 것이며, 서버 측 DNS 서버에 저장된 캐시 서버 경로 정보를 통해 클라이언트와 모든 캐시 서버 사이의 경로 정보를 구할 수 있으므로 어느 캐시 서버 라우터가 클라이언트 측 DNS 서버에 가장 가까운지 알 수 있다.
이런 과정을 통해 클라이언트 DNS 서버는 자신과 가장 가까운 캐시 서버의 IP 주소를 반환 받을 수 있는 것이다.
여기에서 조금 헷갈리는게 있는데, 위 과정을 통해 알 수 있는 것은 "클라이언트 DNS 서버와 가장 가까운 캐시 서버"이다.
만약 클라이언트측 DNS 서버와 클라이언트가 같은 장소에 있지 않다면 정확한 거리를 측정하지 못할 수도 있다.
다르게 말하자면, 클라이언트 측 DNS 서버와 가장 가까운 캐시 서버가 클라이언트와 가장 가까운 캐시 서버임이 보장되지는 않는 것이다.
하지만 정확하지는 않더라도 어느 정도 정확하게 거리를 측정할 수 있으므로 이 방법을 선택한다.
리다이렉트를 통해 가장 가까운 캐시 서버 찾기
HTTP 사양에는 다양한 헤더 필드가 정의되어 있는데 이 중 "Location"이라는 헤더 필드가 존재한다.
웹 서버의 데이터가 다른 서버에 있을 경우 데이터가 존재하는 다른 서버로 액세스 하도록 처리하는 것을 "리다이렉트(Redirect)"라고 하며 이 떄 Location 헤더를 사용한다.
그리고 리다이렉트를 통해 액세스 대상을 가장 가까운 캐시 서버로 돌림으로써 가장 가까운 캐시 서버에 패킷을 보낼 수 있게 된다.
일단 이전에 서버 DNS 서버에서 처리했던 것처럼 리다이렉트용 웹 서버에 모든 캐시 서버 라우터들의 경로 정보를 모아 놓아야 한다.
사전 준비가 끝났다면 먼저 리다이렉트용 서버를 웹 서버 측의 DNS 서버에 등록한다.
이젠 클라이언트는 도메인명에 해당하는 IP 주소를 찾기 위해 웹 서버 측 DNS 서버에 접근할 것이고 결과적으로 리다이렉트용 서버 IP 주소를 받을 것이다.
클라이언트는 리다이렉트용 서버에 리퀘스트 메시지를 보낼 것이며 미리 저장해 놓은 라우터에서 모은 경로 정보를 통해 가장 가까운 캐시 서버를 찾아 클라이언트에게 회답한다.
클라이언트와 가장 가까운 캐시 서버를 Location 헤더에 붙여 응답으로 돌려보낸다면 클라이언트는 리다이렉트를 통해 캐시 서버로 다시 액세스 할 것이며 이런 과정을 통해 가장 가까운 캐시 서버에 리퀘스트를 보낼 수 있을 것이다.
이 방법은 리다이렉트를 수행하기 위해 패킷 전송을 여러번 수행하므로 HTTP 메시지의 대화가 증가한다.
따라서 그만큼 오버헤드(overhead)가 많지만 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하기 때문에 정밀도가 높다.
위에서 설명한 방법은 어디까지나 클라이언트 DNS 서버와 가까운 캐시 서버였으나 리다이렉트를 사용하면 클라이언트와 가장 가까운 캐시 서버를 찾기 때문에 정확도가 높아진다는 의미이다.
경로 정보를 사용하지 않고 다른 정보를 통해 거리를 계산하여 정밀도를 높일 수도 있다.
리다이렉트용 서버는 Location 헤더를 포함한 HTTP 메시지 이외에도 다른 데이터들을 클라이언트 측으로 반송할 수 있다.
이 중 리다이렉트용 서버에서 패킷의 왕복 시간을 통해 캐시 서버까지의 거리를 계산하여 최적의 캐시 서버에 액세스 하도록 도와주는 스크립트 프로그램을 내장한 페이지를 만든 뒤 클라이언트 측으로 반송하는 방법도 존재한다.
페이지에는 몇 개의 캐시 서버에 시험적으로 패킷을 보낸 뒤 왕복 시간을 계측하여 가장 왕복 시간이 짧은 캐시 서버에 리퀘스트를 다시 보낸다는 내용의 프로그램을 내장해둔다.
이렇게 하면 클라이언트 스스로 최적의 캐시 서버를 판단하여 액세스 할 수 있다.
캐시 내용 갱신 방법에 따른 성능 향상
캐시 서버 효율을 높이기 위하여 캐시 내용 갱신 방법을 새롭게 할 수도 있다.
원래 캐시의 개념은 한 번 액세스 한 데이터를 저장해 둔 뒤 두 번째 이후에는 웹 서버에 변화 여부를 물어본 뒤 변하지 않았다면 캐시 데이터를 보내주는 형식이었다.
이 방법의 경우 최초의 액세스 동작에 도움이 되지 않으며 캐시 데이터의 갱신 유무를 판단하는 동작이 얽히면 응답 시간이 악화될 수 있다는 단점을 가진다.
따라서 웹 서버에서 원래 데이터를 갱신할 경우 이를 즉시 캐시 서버에 반영하는 방법을 사용한다.
이 경우 캐시 데이터는 항상 최신 데이터이므로 데이터의 갱신 여부를 확인할 필요가 없으며 최초 액세스 동작에서도 캐시 데이터를 활용할 수 있다.
CDS에서 사용하는 캐시 서버에는 이러한 대책이 내장되어 있다.
여기에서 조금 더 생각해야 하는 것이 CGI 애플리케이션 등을 통해 동적인 페이지를 만들어야 하는 경우이다.
고려해야 할 점은 클라이언트에게 반환해야 하는 페이지는 사전에 준비한 정적 페이지가 아니고 사용자의 입력 등에 의하여 계속 변화해야 하는 페이지라는 것이다.
이 경우 페이지 전체를 캐시에 저장하지 않고 매번 페이지 내용이 달라지는 부분과 달라지지 않는 부분을 구분한다.
그리고 페이지 내용이 변하지 않는 부분만 캐시에 저장하고 매번 달라져야 하는 부분은 웹 서버에 요청함으로써 캐시 서버의 효율을 높일 수 있다.
