Practical guide to content delivery networks 1-4

1.2.5 Pull Technology

 Push(push) 기술이 도입되기 전까지, 정보 검색은 풀(Pull) 기술을 기반으로 이루어졌습니다. 즉, 사용자가 미리 관심 있는 항목을 찾아두거나, Google이나 Yahoo!와 같은 검색 엔진을 이용해 관심 있는 항목을 찾는 방식이었습니다. 관심 있는 항목을 찾으면, 소비자는 클라이언트 운영자로서 브라우저를 사용하여 서버의 URL을 지정해 해당 정보를 가져왔습니다.

 

1.2.5.1 Role of Caching 클라이언트-서버 풀 작업을 촉진하기 위해 개발된 인기 있는 방법 중 하나가 캐싱입니다. 대부분의 독자가 익숙한 브라우저 환경에서는 캐싱이 하드 드라이브의 미리 정의된 폴더에 인터넷 파일을 임시로 저장하는 방식으로 이루어집니다. 저장된 파일은 이전에 방문했던 웹 페이지와 해당 페이지에 표시된 그래픽 파일 등을 포함합니다.

 

Microsoft Explorer 브라우저 환경에서는 임시 인터넷 파일이 C:\Documents and Settings\Owner\Local Settings\Temporary Internet Files에 위치한 미리 정의된 폴더에 저장됩니다. 브라우저 사용자는 Microsoft Internet Explorer에서 "도구 > 일반 > 설정"으로 이동하여 캐시 파일을 확인하고, 캐싱에 사용할 디스크 공간의 양을 조정하거나, 캐시 폴더의 위치를 변경하고, 캐싱 방식을 정의할 수 있습니다.

그림 1.8  Microsoft Edge Cache 설정

 

 그림 1.8은 이 저자가 Microsoft Edge를 사용할 때 자신의 컴퓨터에서 Shorcut를 선택하여 나타난 설정 창을 보여줍니다. 이 브라우저를 사용할 때, 캐싱 업데이트가 발생하는 방식을 설정할 수 있는 여러 옵션이 제공되었음을 알 수 있습니다. 예를 들어, 브라우저가 페이지를 방문할 때마다, Edge Browser를 시작할 때마다, 자동으로(브라우저 기본 설정), 혹은 절대 확인하지 않도록 설정할 수 있었습니다. 또한, 캐싱에 사용할 공간의 크기도 조정할 수 있었습니다. 디스크 공간을 늘리면 이전에 방문한 페이지가 더 빠르게 표시될 수 있지만, 더 많은 페이지를 검색해야 하기 때문에 추가적인 처리 작업이 발생할 수 있습니다. 그리고 디스크 캐시 크기가 증가하면, 당연히 컴퓨터에서 다른 파일이 사용할 수 있는 공간이 줄어듭니다.

 

 새로운 버전의 Internet Explorer에서는 캐시를 직접 제어하는 옵션이 눈에 띄게 사라졌습니다. 예를 들어, Internet Explorer 8에서 Tools 메뉴로 이동하여 Internet Options를 선택하면, 나타나는 대화 상자가 그림 1.8에 표시된 것과 상당히 다르며 캐시를 제어할 수 있는 옵션을 제공하지 않습니다. 그러나 Tools 메뉴로 이동한 후 Developer Tools를 선택하거나 F12 키를 누르면, 나타나는 대화 상자에서 브라우저 캐시를 지우거나 특정 도메인에 대해서만 캐시를 지울 수 있는 옵션을 제공합니다. 이는 그림 1.9에 설명되어 있습니다.

 

 다른 브라우저를 사용하는 경우, 캐시를 제어할 수 있는 능력은 사용하는 브라우저와 그 버전에 따라 다릅니다. 예를 들어, 저자는 또한 Mozilla Firefox 브라우저를 사용하는데, 이 책이 개정될 당시 최신 버전은 3.6.3이었습니다. 이 버전의 Firefox 브라우저는 이전 버전의 Internet Explorer와 유사하게 캐시를 직접 제어할 수 있는 기능을 제공합니다. 예를 들어, Tools 메뉴로 이동하여 Options를 선택한 다음 Advanced를 선택하면 네 개의 탭이 표시된 대화 상자가 나타납니다. 여기서 Network 탭을 선택하면 현재 캐시 설정이 표시됩니다. 또한, 대화 상자에서 표시된 값을 원하는 경우 다른 값으로 재설정할 수 있는 기능도 제공합니다. 그림 1.10은 Mozilla Firefox 브라우저를 사용하여 캐시를 제어하는 방법을 보여주며, 이때 사용 중인 버전이 3.6.3이거나 유사한 기능을 제공하는 다른 버전이라고 가정합니다.

 

 웹 캐싱은 아마도 가장 널리 사용되는 캐싱 형태일 것입니다. 하지만 몇 가지 장점과 제한 사항이 있습니다. 웹 캐싱은 문서가 자주 변경되지 않는 경우에 효과적이지만, 문서 변경이 빈번해질수록 그 효과는 감소합니다. 따라서 풀(Pull) 기술과 캐싱의 사용에는 여러 가지 결점과 한계가 존재합니다.

 

그림 1.9  Tools 메뉴에서 Developer Tools 항목을 사용하면 캐시를 지우는 두 가지 메커니즘을 제공합니다.

그림 1.11  허리케인 ivan 이동경로

 

 1.2.5.2 Pull Limitations 변화하는 주제에 대해 인터넷에서 정보를 얻어본 경험이 있는 사람이라면, 자주 업데이트되는 정보를 얻으려면 서버를 주기적으로 확인해야 한다는 것을 알고 있을 것입니다. 예를 들어, 2004년 동안 허리케인 찰리(Charlie), 프랜시스(Francis), 그리고 아이반(Ivan)에 대한 정보는 미국 남동부에 거주하는 사람들에게 매우 중요한 관심사였습니다. 풀(Pull) 모델에서는 허리케인 정보에 관심이 있는 사용자가 미국 국립 허리케인 센터(National Hurricane Center) 웹사이트나 이와 유사한 사이트를 주기적으로 방문하여 현재 및 예상 이동 경로에 대한 예보를 확인해야 했습니다.

 

  위 내용을 설명하기 위해, 2004년 9월 허리케인 아이반(Ivan)이 미국을 향해 빠르게 이동하고 있을 때, 그 이동 경로 예측에 관심이 있다고 가정해 봅시다. 그림 1.11은 2004년 9월 13일 오전 1시를 기준으로 한 허리케인 아이반의 3일 이동 경로 예측을 보여줍니다. 이 허리케인의 예상 경로에 살고 있는 경우, 경로가 변경되었는지 확인하기 위해 주기적으로 새로운 예측 정보를 "끌어와야(pull)" 했을 것입니다.

네트워크 관점에서 보면, 새로운 예보가 언제 나올지 확실하지 않기 때문에 수백 명에서 수백만 명이 같은 정보를 반복해서 조회할 수 있습니다. 이는 웹 서버가 주기적으로 상당히 변동되는 연결량을 처리해야 함을 의미합니다. 클라이언트의 위치와 서버 간의 거리 및 클라이언트로 유입되는 트래픽 양에 따라 지연 시간이 크게 증가할 수 있습니다. 이는 특정 서버에 접근하는 사람들뿐만 아니라, 다른 애플리케이션을 실행하는 사람들에게도 부정적인 영향을 미칠 수 있습니다.

 

 또한, 다수의 사용자들이 동일한 데이터를 중복으로 요청하는 비효율적인 메커니즘을 갖고 있기 때문에, 풀 환경에서의 또 다른 한계는 트래픽의 양입니다. 예를 들어, 한 사용자가 256바이트 크기의 URL 요청 패킷을 서버로 전송하고, 서버가 10,000개의 1024바이트 응답 패킷을 보내온다고 가정해 봅시다. 만약 1000명의 사용자가 같은 정보를 요청하면, 서버는 10,000개의 1024바이트 패킷을 1000번 응답해야 합니다! 서버가 반복적으로 응답하는 것 외에도 네트워크 트래픽이 상당할 것입니다. 예를 들어, 서버가 마이애미에 위치하고 남동부 전역에 있는 클라이언트가 서버에 접근한다고 가정하면, 네트워크 트래픽은 인터넷을 통해 각 남동부 주에 위치한 클라이언트에게 전송됩니다. 예를 들어, 플로리다에 있는 클라이언트에게는 합리적인 인터넷 트래픽이 발생하겠지만, 조지아에 있는 사용자의 네트워크 트래픽은 플로리다를 먼저 거쳐 조지아로 전달됩니다. 마찬가지로 사우스캐롤라이나에 있는 사용자의 트래픽도 플로리다를 거쳐 조지아를 통과한 후 사우스캐롤라이나에 도착합니다. 노스캐롤라이나에 있는 사용자의 트래픽은 플로리다를 먼저 거쳐야 하기 때문에, 플로리다의 인터넷 대역폭 용량이 플로리다에 있는 서버에 접근하는 기상 정보 사용자들에게 주요 제약 조건이 됩니다. 따라서 마이애미 서버의 콘텐츠를 다른 주에 복제하는 방법은 네트워크 병목 현상을 줄이는 데 도움이 될 수 있으며, 이는 콘텐츠 전송 네트워크(content delivery network, CDN)와 관련된 또 다른 장점으로 간주될 수 있습니다.

 

 

1980년대와 1990년대 초반 동안, 널리 요청되는 정보를 배포하는 데 필요한 대역폭을 최소화하기 위한 여러 시도가 있었습니다. 아마도 오늘날까지도 여전히 사용되고 있는 가장 인기 있는 방법은 멀티캐스트(multicast) 전송일 것입니다.

1.2.6 멀티캐스트(Multicast)

 멀티캐스트 통신은 TCP/IP 프로토콜 환경에서 대역폭을 절약하기 위한 방법을 제공합니다. 멀티캐스트에서는 단일 데이터 소스와 멀티캐스트 그룹에 가입한 여러 수신자 간에 통신이 이루어집니다. 혼란을 피하기 위해 네트워크에서 발생할 수 있는 세 가지 유형의 주소 지정 방식을 알아두는 것이 중요합니다. 유니캐스트(unicast), 멀티캐스트(multicast), 브로드캐스트(broadcast).

유니캐스트 주소는 특정 개체의 주소를 나타내며, 브로드캐스트 주소는 네트워크의 모든 구성원이 데이터를 수신하도록 하는 방법을 나타냅니다. 따라서 멀티캐스트 주소는 하나 이상의 개체를 나타내며, 각 개체가 멀티캐스트 그룹에 가입한 경우 네트워크의 모든 개체를 나타낼 수도 있습니다.

 비록 멀티캐스트가 1990년대 기술이지만, 기존의 유니캐스트 및 브로드캐스트 전송 방식에 비해 그룹 통신에 중요한 여러 가지 이점을 제공합니다.

 

1.2.6.1 Advantages 멀티캐스트의 주요 장점은 네트워크 대역폭을 절약할 수 있다는 점입니다. 예를 들어, 네트워크에 있는 10명의 클라이언트가 멀티캐스트 동영상을 구독하면, 네트워크에 10개의 패킷 시퀀스가 흐르는 대신 단 하나의 패킷 시퀀스만이 흐르게 됩니다. 멀티캐스트 전송의 또 다른 중요한 장점은 대규모 사용자 그룹에 대해 매우 잘 확장된다는 점입니다. 즉, 멀티캐스트 동영상을 구독하려는 네트워크의 클라이언트 수가 100명 또는 1000명으로 증가하더라도, 네트워크에는 동일한 패킷 시퀀스가 흐르게 됩니다.

 

1.2.6.2 Addresses TCP/IP 환경에서는 IPv4 주소 범위 중 224.0.0.0부터 239.255.255.255까지가 멀티캐스트용으로 예약되어 있습니다. 이 주소들은 Class D 주소라고도 불립니다. 목적지 주소의 처음 네 비트가 1110으로 설정된 모든 IP 데이터그램은 IP 멀티캐스트 데이터그램을 나타냅니다. 주소의 나머지 28비트는 데이터그램이 전송되는 멀티캐스트 "그룹"을 식별합니다. 멀티캐스트 주소는 IP 장치 그룹을 나타내기 때문에, 데이터그램의 목적지로만 사용할 수 있으며, 따라서 절대 출처(Source)로는 사용되지 않습니다.

 

 IPv4 환경에서는 IP 주소의 선두 "1110" 이후의 28비트가 멀티캐스트 그룹 주소를 정의합니다. 따라서 Class D 멀티캐스트 주소 공간의 크기는 2^28, 즉 268,435,456개의 멀티캐스트 그룹을 나타내며, 이 주소 공간의 특정 부분은 특정 용도로 예약되어 있습니다. 표 1.1은 Class D 주소 공간의 일반적인 할당 방식을 보여줍니다.

 Class D 주소 블록 내에서, 224.0.0.0부터 224.0.0.255까지의 주소 범위는 "잘 알려진(well-known)" 멀티캐스트 주소로 간주되며, 라우팅 프로토콜, 토폴로지 탐색 프로토콜 및 유지 관리 프로토콜에서 사용하기 위해 예약되어 있습니다. 이 주소 범위에는 여러 잘 알려진 멀티캐스트 그룹이 포함되어 있습니다. 이러한 그룹의 두 가지 예는 다음과 같습니다.

224.0.0.1: 전체 호스트 그룹(all-hosts group), 이 Class D 주소로 핑을 보내면 네트워크의 모든 멀티캐스트 가능 호스트가 응답합니다.
224.0.0.2: 전체 라우터 그룹(all-routers group), 모든 멀티캐스트 라우터는 모든 멀티캐스트 가능 인터페이스에서 이 그룹에 가입해야 합니다. 

 

 Class D 주소 공간의 대부분은 중간 멀티캐스트 범위에 속하며, 이 범위에는 인터넷 전체에 걸쳐 사용할 수 있는 멀티캐스트 주소가 포함됩니다. 이들은 Class A, B, C 유니캐스트 주소와 유사하며, TCP/IP를 다루는 3장에서 자세히 설명할 예정이며, 다양한 그룹에 할당될 수 있습니다.

 

 표 1에 나타난 마지막 주소 범위는 로컬 멀티캐스트 주소로, 기술적으로는 관리 범위가 지정된 멀티캐스트 그룹(administratively scoped multicast groups)이라고도 합니다. 이 주소 그룹은 전체 멀티캐스트 주소 공간의 1/16을 차지하며, 사이트-로컬 멀티캐스트 주소(site-local multicast addresses), 조직-로컬 멀티캐스트 주소(organization-local addresses), 기타 로컬 멀티캐스트 주소로 세분화됩니다.

 

1.2.6.3 Limitations 멀티캐스트의 주요 단점 중 하나는 사용자가 멀티캐스트 데이터 스트림을 수신하려면 등록해야 한다는 점으로, 여러 웹 서버에서 다양한 정보를 가져오는 방식보다는 비디오 방송과 같은 사전에 정의된 이벤트에 더 적합한 기술입니다. 멀티캐스트의 또 다른 한계는 모든 라우터나 호스트가 멀티캐스트 사양을 준수하지 않는다는 사실입니다. 실제로, 멀티캐스트 사양에 대한 준수 수준은 세 가지가 있습니다.

• 레벨 0 (Level 0): 멀티캐스트 지원 없음.
• 레벨 1 (Level 1): 멀티캐스트 데이터그램을 전송할 수는 있지만 수신할 수 없음.
• 레벨 2 (Level 2): IP 멀티캐스트에 대한 완전한 지원.

따라서 모든 네트워크 장치가 멀티캐스트를 완전히 지원하지 않기 때문에, 멀티캐스트 기술의 활용에는 한계가 있을 수 있습니다.

1.2.7 Push Technology

 Push Technology의 개발은 소비자가 데이터를 직접 가져오는 대신, 관심 있는 정보를 소비자에게 전달할 필요성에 대한 대응책으로 시작되었습니다. Push Technology에서는 소비자가 Push 제공자와 등록을 하고, 인터넷을 통해 사용자 데스크탑으로 전송되는 특정 데이터를 수신하게 됩니다. 관심 있는 정보는 화면의 25번째 줄에 스트림으로 표시되거나, 디스플레이의 별도의 창에 표시될 수 있습니다. 사용자 데스크탑으로 전송되는 실제 데이터는 사용자가 관심을 가지고 있는 정보에 따라 다양한 웹 사이트에서 가져올 수 있습니다. 사용자가 Push 제공자와 함께 관심 정보를 포함한 프로필을 작성하면, 해당 프로필은 필터 역할을 하게 됩니다. 제공자의 서버는 다양한 웹 사이트를 검색하여 모든 구독자에게 관심 있는 정보를 수집합니다. 그러나 각 구독자의 프로필을 사용하여 개별 구독자에게 Push할 데이터를 결정하는 메커니즘으로 사용됩니다. 선택된 관심 정보가 텔레비전이나 라디오 방송과 유사하게 방송되기 때문에, 스트리밍, 채널링, 방송 등의 용어가 때때로 동의어로 사용됩니다.

 

 일부 사람들에 따르면, push라는 용어는 1996년 미국 대통령 선거 당시 사용된 push polling이라는 용어에서 유래했다고 합니다. push polling은 부정직한 여론 조사 담당자들이 전화 여론 조사를 수행하는 척하면서 실제로는 후보자의 장점을 부각하는 질문을 사용하여 여론을 "Pushed" 방식이었습니다.

 

1.2.7.1 Evolution 현대 Push Technology 환경에서, PointCast는 Push Technology을 개발한 일련의 회사들 중 선두 주자였습니다. 1992년에 설립되어 인터넷을 통해 뉴스와 기타 정보를 제공하였으며, 1996년에는 약 160만 부의 독점 웹캐스팅 소프트웨어를 배포했는데, 이는 당시로서는 엄청난 성과를 나타냈습니다. 1997년에는 Push Technology에 대한 과열된 관심으로 인해 BusinessWeek가 웹캐스팅에 관한 표지 기사에서 PointCast를 언급했으며, 당시 34세였던 CEO 크리스 해셋(Chris Hasset)은 "우리는 새로운 미디어를 정의하고 있다."라고 말했습니다.

 

PointCast의 명성은 일시적이었습니다. *PointCast가 고객들에게 광고와 함께 특정 요청된 정보를 제공할 수 있었음에도 불구하고, 많은 기업들은 직원들이 *PointCast 시스템을 사용함으로 인해 인터넷 연결 및 로컬 네트워크에 과부하가 발생한다고 판단하여, Push Technology을 회사 네트워크에서 제거했습니다. 점점 더 많은 회사들이 이 기술을 외면하면서, PointCast의 성공은 급격히 쇠퇴했습니다. 또한, 야후(Yahoo!) 및 기타 인터넷 관련 상업 업체들과의 경쟁으로 인해 비독점적인 인터넷 채널을 통한 Push Technology의 사용이 보편화되었습니다. 결국, Microsoft와 Netscape는 웹캐스팅 기술을 각자의 브라우저에 통합하여 PointCast의 독점 소프트웨어 필요성을 더욱 감소시켰습니다. 몇 년 후, PointCast는 다른 회사에 인수되었으며, Push Technology의 선구자였던 PointCast는 더 이상 존재하지 않게 되었습니다.

 

Windows Explore Channel Bar

 Push 기술의 도입은 가격표, 매뉴얼, 재고, 정책 등을 자동으로 업데이트하는 것과 같은 대규모 정보 전달 메커니즘이 필요한 조직들에게는 유용했습니다. 하지만 대중 시장에서는 Internet Explorer 버전 4.0에서 제공되었던 데스크탑 채널 바(desktop channel bar)를 적극적으로 사용하지 않았습니다. 사실, Windows XP, Vista, Windows 7과 같은 최신 Windows 버전은 데스크탑 채널 바를 지원하지 않거나, Internet Explorer 4.0 또는 Windows 98에서 업그레이드한 사용자들만 사용할 수 있도록 제한적으로 지원하고 있습니다.

 

대신 오늘날 대부분의 사람들은 Microsoft의 Windows Media Player, RealNetworks의 RealOne 또는 이와 유사한 프로그램을 사용하여 사전에 정의된 오디오 및 비디오를 시청합니다. 이러한 프로그램을 사용하여 뉴스를 가져오거나, 오디오 트랙을 재생, 굽기(burn), 추출(rip)하거나, 인터넷에서 다양한 콘텐츠를 찾을 수 있습니다. 그러나 이러한 최신 웹캐스팅 도구들은 푸셔(pusher)라기보다는 풀러(puller)에 더 가깝습니다.

 

 또한, 이러한 최신 웹캐스팅 도구들은 Internet Explorer 버전 4.0 및 많은 Push 제품에 내장되었던 핵심 기능 중 하나인 크롤(crawl) 기능을 제공하지 않습니다. 우리는 현대 콘텐츠 전송 방법에 집중하기 전에 이 크롤 기능에 대해 간략하게 논의하겠습니다.

1.2.7.2 Crawling 인터넷 크롤링에서는 사용자가 원하는 일반적인 정보 유형이나 특정 정보 유형을 지정합니다. 그런 다음, 클라이언트 프로그램은 관련 웹사이트를 크롤링하면서 데이터의 적합성을 확인하고, 업데이트된 콘텐츠가 있는지 검사한 후, 사용자에게 변경 사항을 알립니다. Internet Explorer 4.0의 사용자는 구독한 웹 페이지에서 최대 3단계 깊이까지 웹 크롤링을 지정할 수 있었으며, 비구독 사이트에서도 페이지를 가져올 수 있었습니다.

 

 크롤링을 수행하려면 시작할 웹 페이지를 지정해야 합니다. 해당 페이지가 주어지면 브라우저는 그 페이지의 각 링크를 크롤링하고, 설정에 따라 여러 단계의 깊이까지 크롤링할 수 있으며, 특정 목록에 있는 페이지로 작업 범위를 제한할 수도 있습니다. 크롤링 작업 중 브라우저는 파일 크기와 생성 날짜를 비교하여 페이지가 변경되었는지 확인합니다. 크롤링 구성에 따라 페이지를 확인한 후에는 변경 사항에 대한 알림을 보내거나, 실제 페이지 콘텐츠를 사용자에게 다운로드합니다. 오늘날 웹 크롤링은 주로 검색 엔진이나 구형 브라우저를 사용하는 사용자들이 수행합니다. 최신 브라우저는 웹 크롤링을 Atom 및 Really Simple Syndication(RSS) 피드로 대체했으며, 이에 대해서는 곧 논의하겠습니다.

 

1.2.7.3 Feeds 피드는 일반적으로 웹사이트에서 게시되는 자주 업데이트되는 콘텐츠를 나타낼 수 있습니다. 피드의 일반적인 예로는 뉴스 사이트 및 블로그 사이트 업데이트가 있으며, 피드는 비디오와 오디오를 배포하는 데도 사용할 수 있습니다. 오디오는 주로 MP3 형식으로 배포되며, 이를 팟캐스팅(podcasting)이라고 부릅니다. 따라서 피드는 현대의 Push 기술로 간주될 수 있습니다.

가장 일반적인 피드는 Really Simple Syndication (RSS) 피드*입니다. 하지만 대부분의 소프트웨어와 마찬가지로 RSS도 여러 버전이 존재하며, 대표적인 예로 RSS 1.0과 RSS 2.0이 있습니다. RSS의 다양한 버전과 다른 피드들은 *Extensible Markup Language (XML) 을 기반으로 하고 있으며, XML은 구조화된 문서를 개발하기 위해 사용되는 텍스트 기반 컴퓨터 언어입니다.

현대 브라우저에서 피드(Feeds) 기능을 사용할 수 있는 경우, 웹 페이지를 방문하면 피드 버튼이 표시됩니다. 이 버튼을 클릭하면 하나 이상의 피드를 선택할 수 있습니다. 일부 웹사이트에서는 피드 버튼이 눈에 잘 띄게 표시되지만, 다른 사이트에서는 약간의 검색이 필요할 수 있습니다. 예를 들어, 뉴욕 타임스(New York Times) 웹사이트(www.nytimes.com)에서는 홈 페이지의 맨 아래로 스크롤해야 피드 버튼을 찾을 수 있습니다. 그림 1.12는 저자가 신문 웹사이트의 홈 페이지를 아래로 스크롤하여 피드 버튼과 그 오른쪽에 있는 RSS라는 약어를 관찰했을 때를 보여줍니다.

 

그림 1.12  Korea.net의 홈 페이지에서 피드 버튼을 선택하려면 페이지 하단으로 스크롤해야 합니다.

 피드 버튼을 선택하면, 그림 1.12에 표시된 웹사이트에서 사용자가 선택할 수 있는 피드 목록이 제공됩니다. 예를 들어, 저자가 사용 가능한 피드를 확인했을 때, 선택 가능한 피드 항목은 홈 페이지부터 세계, 미국, 지역, 비즈니스, 기술 및 기타 여러 카테고리로 다양했습니다. 그림 1.13은 저자가 뉴욕 타임스(New York Times) 웹사이트를 탐색할 때 사용자가 선택할 수 있는 잠재적 피드 목록을 보여줍니다. 추측컨대, 이렇게 풍부한 무료 정보를 제공한 것이 인쇄 매체의 재정적 어려움으로 이어졌을 수도 있습니다.

 

1.2.7.4 Advantages 대부분의 기술과 마찬가지로, Push 기술과 관련된 몇 가지 장점이 있습니다. 클라이언트 관점에서 볼 때, Push 기술은 미리 정의된 요청을 통해 관심 있는 항목이 웹 페이지 변경 시 수신될 수 있도록 합니다. 서버 관점에서 볼 때, Push 기술은 공통된 여러 요청을 Push 제공자에 대한 단일 응답으로 처리할 수 있으며, Push 제공자는 개별 클라이언트 구독자에게 웹 페이지를 전송하는 책임을 집니다. 이러한 이유로 Push 기술은 매우 높은 확장성을 지니며, 원격 서버와 네트워크의 부하를 줄일 수 있어 응답 시간이 향상될 수 있습니다.

 

1.2.7.5 Disadvantages 앞서 언급했듯이, 초기 Push 기술 버전이 기대에 미치지 못했던 주요 이유는 회사 네트워크에 과부하를 일으켰기 때문입니다. 오늘날에는 10-Mbps 이더넷 LAN이 1-Gbps 또는 10-Gbps LAN으로 대체되면서, RSS와 기타 피드 형태의 현대적인 Push 기술이 많은 기업 네트워크에 허용되고 있습니다. 회사 네트워크의 과부하 외에도, 초기 Push 기술 버전 및 현대적인 피드 방식의 두 가지 추가적인 한계는 서비스 구독 및 제어와 관련된 공통된 요구 사항입니다.

 

 구독료와 관련해서, 대부분의 인터넷 사용자는 인터넷을 무료 서비스로 인식하고 있으며, 항상 저렴하거나 비용이 들지 않는 정보를 원합니다. 제어와 관련해서는, 많은 사용자가 다운로드할 정보를 직접 제어할 수 있는 주문형 정보 검색(pull)을 선호합니다. Push 기술은 고속 LAN이 10-Mbps 속도로 운영되던 시대에 개발되었기 때문에, Push에서 발생하는 트래픽이 기업 네트워크에 상당한 영향을 미쳤습니다. 대부분의 초기 Push 제공자들이 구독 기반이었고, 웹 페이지 검색에 대한 사용자의 제어 선호도와 맞물려, 1990년대 동안 Push 기술이 몇 년 동안 인터넷 사용자의 관심을 유지한 것은 놀라운 일입니다.

 

 고속 네트워킹 기능의 발전과 구독 비용의 제거로 인해 Push 기술이 다시 활성화되었습니다. 오늘날 많은 사람들은 선호하는 투자 정보나 특정 유형의 최신 뉴스를 확인하기 위해 비즈니스 관련 피드에 구독합니다. 이제, 지난 반세기 동안 개발된 다양한 정보 검색 기술의 진화를 이해했으니, 현대 콘텐츠 전송 네트워크(Content Delivery Networking, CDN)의 역할과 그것이 Push, 풀(Pull), 웹 크롤링을 포함한 여러 유형의 클라이언트-서버 통신을 어떻게 지원하는지 살펴보겠습니다.

1.3 Content Delivery Networking

 이 장의 첫 번째 섹션에서, 우리는 콘텐츠 전송 네트워킹(CDN)에 대한 간략한 정의를 통해 용어에 대해 소개받았습니다. 이후, 두 번째 섹션에서는 캐싱, 풀(Pull), Push(Push), 크롤링(Crawling) 작업을 포함한 클라이언트-서버 기술의 진화에 초점을 맞췄습니다. 이 섹션에서는 이전에 학습한 지식을 바탕으로, 콘텐츠 전송 네트워크가 다양한 유형의 클라이언트-서버 작업을 어떻게 지원하는지에 대해 이해하겠습니다. CDN 사용을 통해 얻을 수 있는 이점을 인식하려면 클라이언트-서버 작업의 한계와 인터넷의 일반적인 구조에 대한 지식이 필요합니다. CDN에 대한 검토를 시작하기 위해, 인터넷에서의 클라이언트-서버 작업에 대해 논의해보겠습니다.

1.3.1 Client-Server Operations on the Internet

 인터넷은 TCP/IP 프로토콜 모음을 지원하는 라우터를 통해 서로 연결된 네트워크들의 집합을 나타냅니다. 인터넷을 통해 데이터가 전달될 때 발생하는 콘텐츠 전송과 관련된 문제들을 설명하기 위해, 먼저 클라이언트와 서버가 같은 네트워크에 있는 최상의 시나리오를 가정해보겠습니다. 그런 다음, 클라이언트와 서버 사이의 거리를 라우터 홉(router hop)과 통과해야 할 네트워크의 수로 확장하여, 인터넷에서 별도의 네트워크를 상호 연결하는 데 사용되는 액세스 지점인 POP(Point of Presence)와 피어링 지점(peering point)에 대해 알아보겠습니다.

1.3.2 Client Server Operating on the Same Network

 인터넷 맥락에서 "네트워크"라는 용어는 인터넷 서비스 제공자(ISP)가 제공하는 연결성을 가진 서브넷의 집합을 나타냅니다. 따라서 인터넷에서 클라이언트와 서버가 동일한 네트워크에 위치한다고 할 때, 두 컴퓨터는 동일한 세그먼트에 있을 수도 있고, 한 컴퓨터가 다른 장치와 통신하기 위해 하나 이상의 라우터 홉을 통과해야 하는 서로 다른 서브넷에 있을 수도 있습니다.

 

 서버 콘텐츠 전송과 관련된 지연은 주로 네트워크 트래픽, 사용 가능한 네트워크 대역폭, 클라이언트에서 서버까지의 라우터 홉 수에 따라 달라집니다. 인터넷의 관점에서 "네트워크"는 ISP에 의해 제어되므로, 데이터 전송이 상호 연결된 "네트워크" 간에 이루어질 때보다 콘텐츠 전송을 더 효율적으로 관리할 수 있습니다. 즉, ISP는 추가적인 트래픽의 영향을 최소화하기 위해 더 많은 클라이언트를 유치하면서 대역폭과 라우터를 업그레이드할 수 있습니다.

1.3.3 Client-Server Operations on Different Networks

 클라이언트와 서버가 서로 다른 인터넷 "네트워크"에 위치할 때, 트래픽은 다른 ISP가 운영하는 네트워크 간의 상호 연결 지점을 통해 흐르게 됩니다. 인터넷에서 POP(Point of Presence)는 한 네트워크가 다른 네트워크에 연결되는 액세스 지점을 지칭하는 용어로 사용됩니다. 실제로 POP라는 용어는 원래 전화 통신에서 유래했으며, 로컬 전화 사업자가 네트워크를 하나 이상의 장거리 전화 사업자와 연결하는 물리적 위치를 나타냈습니다. POP라는 용어는 여전히 두 ISP가 네트워크를 상호 연결하는 위치를 나타내기 위해 사용되지만, 이 위치를 나타내는 더 일반적인 용어는 인터넷 피어링 지점(peering point)입니다.

1.3.4 Peering Point

 인터넷 피어링 지점은 두 개 이상의 네트워크가 상호 연결되는 물리적 위치를 나타냅니다. 이러한 위치는 ISP 간의 계약을 기반으로 하며, 그 기원은 고급 연구 프로젝트 기관 네트워크(ARPANET, Advanced Research Projects Agency Network)의 초기 확장으로 거슬러 올라갑니다. 인터넷이 발전함에 따라, ARPANET은 백본 네트워크로 간주되었으며, 다른 네트워크들은 백본과의 하나 이상의 연결을 통해 서로 연결되었습니다. 인터넷이 확장되고 발전하면서, 이제 전통적인 의미의 단일 백본 네트워크는 존재하지 않으며, 대신 다양한 상업적 ISP와 사설 네트워크 운영자들이 두 개 이상의 네트워크를 피어링 지점에서 상호 연결하는 피어링 계약을 체결하게 되었습니다.

 

 오늘날에는 두 가지 주요 피어링 유형이 있습니다. 사설 피어링(private peering)과 공공 피어링(public peering)입니다. 사설 피어링 지점은 두 ISP 간의 트래픽 흐름을 허용하기 위한 계약을 맺는 것을 의미합니다. 반면, 공공 피어링 지점(인터넷 익스체인지 포인트, Internet Exchange Point)은 특정 제공자와 독립적인 위치로, 네트워크가 상호 연결될 수 있는 장소를 나타냅니다. MCI(이전 WorldCom)와 같이 대량의 트래픽을 처리하는 ISP는 종종 Tier 1 사업자라고 불리며, 다른 Tier 1 사업자들과 상호 연결에 대해 서로 비용을 청구하지 않고 피어링 계약을 체결합니다. 더 적은 트래픽을 처리하는 소규모 제공자들은 상호 연결 서비스에 대한 비용을 지불해야 하는 인터넷 익스체인지 포인트를 이용하는 경향이 있습니다.

 

 피어링 지점의 한 예로 MAE-East를 들 수 있습니다. MAE는 Metropolitan Area Ethernet*의 약자로, 1993년 *Metropolitan Fiber Systems (이후 Verizon에 인수되기 전 MCI가 소유)에서 PSI, UUNET, 그리고 SprintLink를 위해 구축한 교환 시설을 나타냅니다. MAE-East는 미국 국가 과학 재단(National Science Foundation)이 인터넷 백본 사업에서 철수할 무렵에 설립되었으며, 이를 계기로 이 피어링 지점이 매우 성공을 거두어 실리콘 밸리에 MAE-West라는 유사한 시설이 개설되었습니다.

 

 2005년까지 MAE-East는 워싱턴 D.C. 대도시 지역에 네 개의 사이트와 뉴욕시에 한 개의 사이트로 확장되었으며, AT&T WorldNet, BT, Epoch Networks, Equant, Hurricane Electric, Infornet, Swisscom AG, UUNET, Verio, 그리고 Spedius 등 총 38명의 회원사가 있었습니다. 2009년까지 MAE-East는 SONET(동기 광 네트워크)을 통한 패킷 전송(Packet over SONET)을 사용하여 Optical Carrier(OC) 데이터 속도의 프레임 릴레이(Frame Relay) 캡슐화 기능을 제공했으며, OC-3, OC-12, OC-48 속도의 데이터 전송과 기가비트 이더넷(Gigabit Ethernet) 연결, 그리고 DS-3, OC-3, OC-12 속도의 ATM 연결을 제공했습니다.

그림 1.14  MAE-East의 운영과 관련된 세 가지 메트릭을 제공하는 웹 페이지의 상단 부분

 

 오늘날 미국에는 세 개의 주요 MAE가 있습니다: MAE-East, MAE-West, 그리고 텍사스주 댈러스에 위치한 MAE-Central입니다. 이와 더불어, 프레임 캡슐화(Frame Encapsulation, FE) 서비스를 위한 두 개의 중앙 MAE가 시카고와 뉴욕에 위치해 있습니다.

그림 1.14는 이 책의 초판이 작성되었을 때 MAE-East의 인터넷 트래픽 리포트를 보여줍니다. 그림 1.14에는 지난 24시간 동안의 활동을 나타내는 두 개의 그래프가 표시되어 있습니다. 상단 그래프는 트래픽 지수를 나타내며, 0에서 100까지의 점수로, 0은 느림을 의미하고 100은 빠름을 의미합니다. 트래픽 지수는 지난 7일 동안 동일한 라우터에서의 Ping 응답 결과를 기준으로 현재 응답을 비교하여 산출되며, 응답이 이전 응답들보다 더 나은지 혹은 더 나쁜지에 따라 현재 응답에 0에서 100까지의 점수가 할당됩니다.

두 번째 그래프는 밀리초(ms) 단위의 응답 시간을 나타냅니다. 응답 시간은 한 위치에서 다른 위치로 트래픽을 전송한 후 다시 원래 위치로 돌아오는 왕복 시간을 계산한 값입니다. 만약 그림 1.14를 아래로 스크롤할 수 있다면, 세 번째 그래프인 패킷 손실(packet loss)을 확인할 수 있습니다. 이 그래프는 라우터에 의해 폐기되거나 손실된 패킷의 비율을 나타냅니다. 일반적으로 라우터는 과부하 상태일 때 패킷을 폐기하기 때문에, 이 값은 네트워크 신뢰성을 측정하는 지표로 볼 수 있습니다.

 

 그림 1.14의 인터넷 트래픽 리포트에 표시된 세 가지 메트릭은 ISP 네트워크 간의 정보 흐름 시 병목 현상을 나타낼 수 있습니다. 즉, 피어링 지점은 한 인터넷 "네트워크"의 트래픽이 다른 "네트워크"로 전송될 때 모든 트래픽이 통과해야 하는 깔때기(funnel)처럼 작용할 수 있습니다. ISP 간의 데이터 흐름은 일반적으로 대칭적이지 않기 때문에, 특정 시점에서는 일부 ISP가 피어링 지점의 용량을 초과하는 데이터를 전송해야 하는 상황이 발생할 수 있습니다. 이 상황이 발생하면 해당 연결이 병목 현상을 겪게 됩니다. 피어링 지점을 업그레이드할 수도 있지만, 많은 경우 서버를 운영하는 소수의 고객들만이 문제를 겪기 때문에, 서버가 위치한 ISP는 비용 문제로 인해 피어링 지점을 업그레이드하기를 꺼릴 수 있습니다. 이와 유사하게, 추가적인 피어링 지점을 설치하는 것도 상당한 비용이 발생할 수 있습니다.

 

 기존 피어링 지점을 모두 업그레이드하고 추가적인 피어링 지점을 설치하여 네트워크 간 연결성을 강화하더라도, 이를 구현하는 데에는 시간이 걸리며, 현재 한 네트워크의 클라이언트가 다른 네트워크의 서버에 접근할 때 경험하는 지연이 눈에 띄게 감소하지 않을 수도 있습니다. 이러한 경우, 클라이언트가 다른 네트워크에 있는 서버에 접근해야 할 때 고정된 라우터 홉 수를 통과해야 하는 상황이 발생합니다.

이 새로운 책의 개정판을 준비하면서 저자는 다시 MAE-East를 방문했습니다. 방문 중, 지난 5년 동안 연결 속도의 업그레이드가 상당히 진전되었음을 확인했으나, 인터넷의 전체 트래픽 또한 증가했음을 깨달았습니다. 따라서, 용량 증가가 증가한 트래픽을 수용할 수 있는지 여부를 확인하는 것이 흥미로울 것입니다.

 

그림 1.15 2009년 11월에 다시 방문한 MAE-East

 

 그림 1.15는 5년 후인 2009년 11월에 다시 방문한 MAE-East를 보여줍니다. 이 그림에서 주목할 점은, 글로벌 지수(Global Index)가 83으로 유지되었지만, MAE-East는 데이터 전송 업그레이드를 통해 트래픽 증가를 초과하는 성장을 이루었다는 것입니다. 트래픽 지수, 응답 시간, 패킷 손실을 살펴보면, 각각의 지표가 거의 0에 가까운 선을 나타내고 있습니다.

따라서 MAE-East는 데이터를 손실하지 않고 수용 가능한 응답 시간을 유지하며 데이터 처리에 있어 큰 발전을 이루었습니다.

앞서 언급한 패킷 손실과 응답 시간 증가와 관련된 문제를 해결하기 위해 1990년대 동안 또 다른 솔루션이 발전했습니다. 이 솔루션은 서버 콘텐츠를 중앙 위치에서 인터넷 전역의 여러 분산된 위치로 이동시키는 방식에 기반을 두고 있습니다. 이를 통해 웹 페이지를 최종 클라이언트 요청자에게 더 가까운 위치로 이동시켜, 요청이 통과해야 하는 라우터 홉 수와 왕복 전파 시간을 줄였습니다. 또한, 웹 페이지가 이제 최종 사용자에게 더 가까운 위치에 있기 때문에, 트래픽이 피어링 지점의 병목 현상을 통과할 필요가 없어져 트래픽 흐름이 개선되고 지연이 최소화되었습니다.

 

 웹 페이지를 다양한 위치에서 사용할 수 있도록 배포하는 작업을 콘텐츠 전송 네트워킹(Content Delivery Networking, CDN)이라고 하며, 이것이 이 책의 주제입니다. 따라서 MAE-East의 성능 향상은 부분적으로 콘텐츠 전송 네트워크의 성장 덕분이라고 볼 수 있습니다. 후속 장들에서 이 주제를 더 깊이 탐구할 예정이지만, 지금은 현대 CDN의 역할이 웹 기반 정보를 최종 요청자와 더 가까운 위치로 배포하여 정보 검색을 용이하게 하는 것임을 알 수 있습니다. 이를 통해, CDN은 풀(Pull), Push(Push), 심지어 웹 크롤링(Web Crawling)까지 포함한 다양한 클라이언트-서버 통신을 지원합니다.

1.3.5 Video Considerations

 이 장을 마무리하며, 비디오에 관한 몇 가지 사항을 언급할 필요가 있습니다. 이 책의 초판이 작성될 당시 웹사이트에 비디오가 통합되고 있었지만, 서버 저장 용량과 네트워크 대역폭의 제약으로 인해 비디오 사용은 크게 제한되었습니다. 지난 10년 동안, 데이터 저장 용량은 기술에 따라 10배에서 100배까지 증가했습니다. 비교적 LAN 전송 속도는 빠른 이더넷(Fast Ethernet)의 100 Mbps에서 10 기가비트(Gigabit)로 증가했으며, 주로 T1(1.544 Mbps) 회선을 사용했던 광역 네트워크(WAN)는 많은 경우에 155.52 Mbps(OC-3), 622.08 Mbps(OC-12), 그리고 2488.32 Mbps(OC-48) 데이터 속도를 제공하는 광학 캐리어(Optical Carrier, OC) 데이터 속도로 대체되었습니다. 서버의 저장 용량 증가와 WAN 및 LAN이 증가된 데이터 흐름을 처리할 수 있는 능력 덕분에, 비디오는 사용자가 웹 페이지에서 볼 수 있는 하나의 선택 사항으로 크게 증가했습니다.

 

 또한, 이제 영화 다운로드, TV 에피소드 시청, TV를 인터넷에 연결하여 "대화면"에서 프로그램을 시청하는 것이 가능해졌습니다. 또한, 테러가 발생할 위험이 있는 시대에서, 많은 도시에는 방대한 비디오 카메라 네트워크가 설치되어 있으며, 여러 위치의 실시간 피드를 단일 콘솔에서 확인할 수 있습니다. 운영자가 추가 정보를 필요로 할 때는 화면을 전환하거나 전체 화면 이미지로 확대하여 필요한 정보를 확인할 수 있습니다. 많은 도시의 피드가 기존 인터넷을 우회하여 전송되지만, 비디오 카메라의 상대적으로 저렴한 비용 덕분에 많은 웹사이트에서는 리조트의 뷰, 일출 장면 및 "사진 한 장이 천 마디 말을 대신할 수 있는" 다른 장면들을 제공하고 있습니다.

 

 하지만 비디오가 성공적으로 전송되기 위해서는, 웹 개발자가 잠재적 시청자가 모두 동일하지 않다는 점을 고려해야 합니다. 즉, 일부 시청자는 10 Mbps로 작동하는 레거시 LAN을 사용할 수도 있고, 다른 시청자는 케이블이나 DSL 연결 또는 기가비트 LAN을 사용할 수 있습니다. 또한, 서버에서 잠재적 시청자로의 데이터 흐름은 다양한 경로를 통해 이루어질 수 있으며, 일부 데이터 흐름은 혼잡한 피어링 지점을 통과할 수 있고, 다른 데이터 흐름은 그렇지 않을 수 있습니다. 따라서 비디오를 통합하는 웹 개발자는 최소한 사용자가 사용하는 인터넷 연결 유형을 선택할 수 있는 옵션을 제공해야 합니다. 다른 옵션으로는 선택된 비디오를 시청할 때 사용할 프레임 속도와 해상도가 있습니다. 이러한 옵션을 통합함으로써, 잠재적 시청자의 네트워크 및 컴퓨터 성능에 맞게 비디오 전송을 조정할 수 있습니다.