Practical guide to content delivery networks 1-2

1.2.1 Client-Server Computing

클라이언트-서버 컴퓨팅이라는 용어는 보통 1980년대 PC 도입과 관련이 있다고 생각되지만, 실제로는 1950년대와 1960년대에 제조된 메인프레임 컴퓨터로 거슬러 올라갑니다. 따라서 이 섹션에서는 현대 클라이언트-서버 운영을 살펴보기 전에 클라이언트와 메인프레임 환경에서의 데이터 흐름을 간단히 검토하겠습니다.

 

1.2.1.1 Client-to-Mainframe Data Flow 1960년대 중반까지 많은 메인프레임 컴퓨터는 제어 장치를 사용하여 터미널 장치의 데이터 흐름을 그룹화하는 계층적 통신 구조를 가지고 있었습니다. 이 제어 장치는 클러스터 컨트롤러라고도 불렸으며, 각 제어 장치에 케이블로 연결된 여러 터미널 장치와 데이터를 주고받았습니다. 제어 장치는 메인프레임 컴퓨터와 동일한 건물에 있을 경우 메인프레임의 채널에 직접 케이블로 연결되었고, 다른 건물이나 도시에 메인프레임이 있을 경우 임대 회선을 통해 통신 컨트롤러와 연결되었습니다. 통신 컨트롤러는 프론트 엔드 프로세서라고도 불렸으며, 직렬-병렬 및 병렬-직렬 데이터 변환뿐만 아니라 다른 통신 관련 작업을 전문적으로 수행했습니다. 이로 인해 메인프레임이 이전에 수행했던 대부분의 통신 기능이 통신 컨트롤러로 이전되었습니다.

 

 사실, 이 글의 저자가 컴퓨터와 관련된 긴 경력을 시작했을 때, 그는 처음에 워싱턴 D.C. 교외의 위치에서 클러스터 컨트롤러가 터미널에 연결된 장소에서 일했고, 메인프레임은 미네소타주 미니애폴리스에 있었습니다. 예상할 수 있듯이 터미널이 모여 있는 방은 터미널 룸이라고 불렸습니다. 모든 것이 잘 진행되던 어느 날, 누군가 전화가 울리자 "터미널 룸"이라고 말하며 전화를 받았고, 상대방은 "오 마이 갓"이라고 답한 후 전화를 끊었습니다. 간단한 조사를 통해 지역 병원의 응급실 전화번호가 터미널 룸의 전화번호와 한 자리 차이난다는 사실을 알게 되었습니다. 이러한 상황이 반복되지 않도록 지역 전화 회사에 요청해 터미널 룸 전화의 번호를 변경했습니다. 이 이야기는 클러스터 컨트롤러나 터미널과 직접적으로 관련이 없지만, 예상치 못한 일이 발생할 수 있다는 점을 고려하고, 비상 상황에 대비해 여유 시간을 확보하는 것이 중요하다는 사실을 보여줍니다.

 

 앞서 언급했듯이, 프론트 엔드 프로세서나 통신 컨트롤러에 연결된 클러스터 컨트롤러의 사용은 메인프레임 컴퓨터의 아키텍처가 바이트를 이동시키고 계산을 수행하는 데 더 적합하게 설계될 수 있도록 했습니다. 이는 메인프레임이 비즈니스 및 과학 응용 프로그램을 더 효율적으로 처리할 수 있게 해주었고, 통신 컨트롤러는 비트를 더 효율적으로 처리하도록 설계되었기 때문에, 병렬로 형성된 문자를 하나씩 직렬로 전송하거나 직렬 데이터 스트림을 하나씩 병렬로 변환하는 데 필요한 주요 작업을 수행할 수 있었습니다.

 

 

그림 1.2는 메인프레임 컴퓨터 기반 네트워크의 계층적 구조를 보여줍니다.

 

 터미널 작업자를 클라이언트로, 메인프레임을 서버로 생각하면, 터미널-메인프레임 연결은 현대의 서버와 유사하게 프로그램에 접근할 수 있으므로 초기 형태의 클라이언트-서버 컴퓨팅이라고 할 수 있습니다.

 

 터미널-메인프레임 환경에서 터미널은 특정 서비스를 요청하는 클라이언트 역할을 합니다. 메인프레임은 서비스를 제공하는 서버 역할을 합니다. 초기 세대의 터미널 장치는 지능이 제한적이었기 때문에, 1970년대 후반에 등장한 2세대 및 3세대 터미널이 등장하기 전까지는 제한적인 기능을 수행했습니다. 이 터미널은 당시에는 하드웨어적으로 고정된 전자 장치였으나, 오늘날 우리가 말하는 펌웨어의 초기 형태로 간주될 수 있었습니다. 이 전자 장치는 일련의 작업을 수행했으며, 이는 프로그램의 초기 버전으로 간주될 수 있습니다. 따라서 후속 세대의 터미널 장치는 초기 세대의 단순히 데이터를 표시하고 제한된 데이터 입력 기능을 제공하는 장치보다 클라이언트-서버 컴퓨팅에 더 가깝다고 할 수 있습니다.

 

 메인프레임 환경의 주요 한계 중 하나는 본래 계층적 구조였습니다. 즉, 두 명의 터미널 작업자가 나란히 앉아 정보를 전자적으로 교환하고자 하더라도 모든 통신이 메인프레임을 통해 이루어져야 했습니다. 이는 특히 동부 해안의 도시와 서부에 위치한 컴퓨터 사이에서 작업이 이루어질 때 큰 지연을 초래할 수 있었습니다. 1970년대 동안 고속 통신 회선이 초당 4800 또는 9600bps의 데이터 전송 속도를 제공했을 때는 특히 더 그랬습니다. IBM은 1990년대에 Advanced Peer-to-Peer Networking (APPN) 하드웨어와 소프트웨어를 도입하여 메인프레임의 계층적 아키텍처를 변경하려 했지만, 그때는 이미 로컬 영역 네트워크가 지배적이었고, 현대의 클라이언트-서버 통신이 주류였습니다.

 

1.2.1.2 Modern Client-Server Operations 이전에는 터미널과 메인프레임 간의 관계가 클라이언트-서버 컴퓨팅의 초기 형태를 나타낼 수 있다고 언급했지만, 1980년대 초 개인용 컴퓨터(PC)의 도입 이후에야 이 용어가 본격적으로 받아들여졌습니다. 개인용 컴퓨터의 프로그래밍 가능성은 웹 기반 애플리케이션을 포함한 현대 클라이언트-서버 컴퓨팅의 발전의 기초가 되었으며, 콘텐츠 전송 네트워크(CDN)를 사용함으로써 이러한 운영이 더욱 개선되었습니다.

 

현대 클라이언트-서버 컴퓨팅 환경에서는 클라이언트가 통신 네트워크를 통해 서버 프로세스(프로그램)로 메시지를 전송하는 프로세스(프로그램)를 의미합니다. 클라이언트 프로세스는 서버에게 특정 작업이나 서비스를 수행해 달라고 요청합니다. 클라이언트는 일반적으로 서버 프로그램의 사용자 인터페이스 부분을 관리하는 프로그램을 운영하지만, 다른 기능도 수행할 수 있습니다. 웹 환경에서는 PC가 클라이언트가 받고자 하는 정보의 주소를 나타내는 URL(Uniform Resource Locator)을 전송합니다. 서버는 페이지 정보가 어떻게 표시되어야 하는지 정의하는 코드를 포함한 웹 페이지를 응답으로 보냅니다. 클라이언트 프로그램(현대의 브라우저)이 이 내장 코드를 해석하여 클라이언트 화면에 웹 페이지를 생성합니다.

그림 1.3 URL 쿼리, HTML 코드 응답, 및 요청된 웹 페이지의 클라이언트 디스플레이 간의 관계

 

 그림 1.3은 웹 환경에서 현대 클라이언트-서버 컴퓨팅의 여러 측면 간의 관계를 보여줍니다. Microsoft Internet Explorer 브라우저 프로그램의 메인 창 우측 상단에서, https://www.yahoo.com 주소를 볼 수 있습니다. 이 주소는 저자의 클라이언트 PC에서 야후 서버로 전송된 URL을 나타냅니다. 이 쿼리에 응답하여, 야후 서버는 해당 URL 주소와 일치하는 홈페이지를 전송했습니다. 실제로 클라이언트 PC는 HTML(하이퍼텍스트 마크업 언어) 및 JAVA 또는 VBScript 명령문 시퀀스를 수신하게 되며, 그 중 일부는 그림 1.3의 왼쪽 상단에 있는 창에 예시로 표시되어 있습니다. 브라우저의 '보기' 메뉴에서 '소스'를 선택하면, 브라우저를 운영하는 PC가 해석한 소스 명령문이 메모장 창에 표시됩니다. 따라서 이 단일 화면에서는 서버로 전송된 URL 형태의 클라이언트 요청과, 클라이언트에서 운영 중인 브라우저가 해석하여 웹 페이지를 생성한 서버 응답을 볼 수 있습니다. 2장에서 우리는 Java 및 VBScript로 코딩된 내장 프로그램을 포함하여 HTML에 대해 자세히 설명하고 논의할 것입니다. (Chrome Dev Tools)

 

 인터넷과 그 다양한 시설(예: 웹 서버)은 클라이언트-서버 컴퓨팅 역사에 비교적 최근에 추가되었기 때문에, 서버는 웹 페이지를 생성하는 것 외에도 다른 기능을 수행한다는 점에 유의해야 합니다. 일부 서버는 데이터베이스 검색 및 업데이트 작업을 수행합니다. 다른 서버는 프린터에 대한 액세스를 제공하며, 서버 기반 프로세스는 네트워크 사용자가 공유 파일에 접근할 수 있게 하는 장치에서 작동하여 파일 서버라고 불리는 장치가 될 수 있습니다. 수년에 걸쳐 다양한 애플리케이션을 지원하기 위해 여러 종류의 서버가 개발되었습니다. 데이터베이스 서버는 일반적인 서버 유형 중 하나이며, 데이터베이스가 예약 시스템에 통합되면 특정 유형의 예약 시스템 서버, 예를 들어 차량 렌탈, 호텔 또는 항공 예약 시스템 서버가 됩니다. 최근 등장한 또 다른 인기 있는 서버 유형은 비디오 서버입니다.

 

그림 1.4  일반적인 정보 전달 시스템

 

 그림 1.4는 네트워크가 인터넷, 기업 인트라넷 또는 다른 네트워크와 연결되지 않은 단순한 로컬 영역 네트워크(LAN)가 될 수 있는 일반적인 정보 전달 시스템을 보여줍니다.

 

1.2.2 Use of Video Servers

 

 비디오 서버는 이름에서 알 수 있듯이 비디오 콘텐츠를 저장하는 데 사용됩니다. 비디오 서버의 저장 용량이 매우 중요한 이유를 설명하기 위해, 한 조직이 수도꼭지 수리, 전등 스위치 설치와 같은 프로젝트를 다루는 "How To" 비디오를 저장한다고 가정해 봅시다. 비디오가 30fps(초당 프레임) 프레임 속도이며 640 x 480 픽셀의 해상도에 24비트 색상 깊이를 사용한다고 가정하면, 1초의 디스플레이에는 30 × 640 × 480 × 24, 즉 약 2억 2100만 비트가 필요하며, 이는 거의 2800만 바이트에 해당합니다. 따라서 1분짜리 비디오는 약 1.68GB의 데이터 저장 및 전송이 필요합니다. 웹과 같은 현대 비디오 환경에서는 비디오 데이터의 저장 및 전송을 줄이기 위한 여러 방법이 있습니다. 비디오 파일의 크기를 줄이는 주요 방법에는 비디오 길이를 줄이거나 해상도, 프레임 속도, 색상 깊이를 조정하는 것, 그리고 압축 기술을 사용하는 것이 포함됩니다.

 

1.2.2.1 Video Length 당연히 비디오가 길어질수록 더 많은 저장 공간과 전송 시간이 필요합니다. 따라서 비디오의 데이터 저장 및 전송 요구를 줄이는 한 가지 방법은 비디오 길이를 줄이는 것입니다. 빠르게 변화하는 세상에서 온라인 뉴스 비디오가 일반적으로 몇 분 정도의 길이만 갖는 이유가 바로 이것입니다.

 

1.2.2.2 Video Resolution 풀 해상도 비디오는 640 * 480 픽셀의 해상도를 갖는 VGA 모니터로부터 시작되었습니다. 이 해상도는 가로 640픽셀, 세로 480픽셀을 의미합니다. VGA 표준이 개발된 이후 어댑터 카드와 모니터의 해상도 기능이 크게 향상되었지만, 풀 해상도 비디오는 오늘날에도 흔히 사용됩니다. 그 외에 자주 사용되는 해상도로는 320 x 240 해상도가 있으며, 가로와 세로가 각각 절반으로 줄어들어 데이터 저장 용량이 1/4로 감소합니다. 또 다른 해상도는 160 x 120으로, 이는 1/4 해상도로 불리며, 데이터 총량을 1/16로 줄입니다.

 

1.2.2.3 Frame Rate 영화관에서 필름의 프레임 속도는 일반적으로 초당 24프레임입니다. TV에서는 재생 속도로 인해 이미지가 초당 30프레임 속도로 표시됩니다. 더 낮은 프레임 속도는 이미지가 튀는 듯한 느낌을 줄 수 있습니다. 컴퓨터로 이미지를 전송할 때 초기 비디오는 데이터 요구 사항을 절반 또는 1/3로 줄이기 위해 15fps 또는 심지어 10fps의 낮은 프레임 속도로 사용되었습니다. 이는 10년 전에는 거의 필수적이었지만, 데이터 저장 용량의 발전과 케이블 및 DSL 통신의 데이터 속도 발전 덕분에 이제는 30fps 속도를 사용할 수 있습니다.

 

1.2.2.4 Color Depth 색상 깊이는 표시되는 각 픽셀의 색상을 표현하는 데 사용되는 비트 수를 의미합니다. 흑백 화면에는 픽셀당 1비트가 필요하며, "트루 컬러"와 "풀 컬러"라고 불리는 것은 빨간색, 파란색, 녹색 데이터를 각각 8비트씩 사용하여 픽셀당 24비트를 필요로 합니다. 이는 인간의 눈이 구별할 수 있는 최대 색상 양을 나타냅니다. 그다음으로 작은 감소는 16비트를 사용하여 수천 가지 색상을 나타낼 수 있으며, 데이터 양을 1/3 줄입니다. 비디오는 일반적으로 24비트 색상 깊이 장치를 사용하므로, 색상 깊이를 24비트에서 16비트로 줄이는 것은(이를 양자화라고 부름) 프레임 내 전환을 왜곡할 수 있습니다.

 

1.2.2.5 Data Compression 앞서 언급한 모든 기술 중에서 데이터 압축은 비디오를 표현하는 데 사용되는 데이터 양을 가장 많이 줄이는 방법입니다. 풀 모션 비디오에서는 여러 데이터 압축 방법이 사용됩니다. 그중 몇 가지는 Microsoft가 MPEG-4, Part 2를 구현한 Windows Media Video(WMV)와, Adobe의 Flash Video가 있습니다. Flash Video는 버전 6과 7에서 Sorenson Spark라는 FLV 파일용 코덱(인코더-디코더)을 사용했으며, Flash Player 8 이후의 버전에서는 ON2 Technologies VP 압축 및 다양한 버전의 MPEG을 지원합니다. 각 버전의 데이터 압축은 저비트, 중비트 및 고비트 전송 지원과 압축 효율성 측면에서 다르게 작동하지만, 공통적으로 모두 데이터 저장 요구 사항을 크게 줄이고 데이터 전송 시간을 단축합니다. 그러나 비디오를 효과적으로 시청하려면 클라이언트가 호환 가능한 브라우저나 브라우저에 호환 가능한 플러그인을 설치해야 하며, 이 두 가지 주제는 이 책의 후반에서 자세히 논의할 것입니다.

1.2.3 Server Network Architecture

 네트워크 아키텍처가 데이터 흐름을 촉진하기 위해 개발된 것과 마찬가지로, 서버 사용은 처리 작업을 용이하게 하기 위한 아키텍처 개발을 촉진했습니다. 초기 PC 네트워크는 클라이언트가 파일에 접근하고 공유할 수 있는 파일 서버를 기반으로 했습니다. 파일 서버는 클라이언트 요청에 대해 전체 파일을 다운로드하는 방식으로 응답했기 때문에, 동시에 많은 사용자를 지원하는 서버의 능력에는 한계가 있었습니다. 이러한 한계는 오늘날 웹 서버에서도 여전히 존재하며, 서비스 거부(DOS) 공격을 통해 악용되기도 했습니다. DOS 공격은 전송 제어 프로토콜(TCP)과 그 3방향 핸드셰이크의 특성을 이용해 발생할 수 있습니다. 잠재적인 공격에 노출되는 것 외에도, 많은 파일 전송으로 인해 발생하는 네트워크 트래픽은 통신에 큰 영향을 미칠 수 있습니다.

 

 파일 공유와 관련된 한계는 데이터베이스 서버 사용으로 이어졌습니다. 관계형 데이터베이스 관리 시스템(DBMS)을 사용하는 데이터베이스 서버는 클라이언트 쿼리에 직접 응답하여, 전체 파일 전송이 일어날 때의 네트워크 트래픽과 비교했을 때 네트워크 트래픽을 크게 줄였습니다. 따라서 많은 조직에서 현대적인 클라이언트-서버 아키텍처는 파일 서버 대신 데이터베이스 서버를 사용하는 방식으로 전환되었습니다.

 

 데이터 흐름을 촉진하기 위해 고려해야 할 두 가지 서버 아키텍처가 있습니다. 이러한 아키텍처 유형은 서버 내부와 외부로 나뉩니다. 내부 서버 아키텍처에 대해 논의할 때, 우리는 주로 서버 내의 구성 요소, 즉 프로세서, 프로세서 성능, 메모리, 디스크 채널, 디스크 용량, 디스크 입출력(I/O) 데이터 전송 속도의 배열과 사양을 참조합니다. 외부 서버 아키텍처에 대해 논의할 때는 주로 한 서버가 다른 서버의 전처리기로서 기능을 분담하는 방식을 참조합니다. 이러한 서버 간 관계는 네트워크를 통해 발생하는 경우가 많기 때문에, 이러한 아키텍처를 서버 기반 네트워크 아키텍처라고 부르는 것이 일반적입니다. 이 섹션에서는 외부 또는 서버 네트워크 아키텍처에 중점을 둘 것입니다. 가장 일반적인 서버 아키텍처 형태는 2계층(two-tier)과 3계층(three-tier) 아키텍처입니다.

 

그림 1.5  2계층과 3계층 아키텍처

 

 

1.2.3.1 Two-Tier Architecture 2계층 아키텍처는 클라이언트와 서버 간의 직접 통신을 나타내며, 중간 서버가 필요하지 않습니다. 여기서 클라이언트는 한 계층을, 서버는 두 번째 계층을 나타냅니다. 이 아키텍처는 보통 최대 100명 정도의 사용자를 지원해야 하는 중소규모 조직에서 자주 사용됩니다. 사용자 수준을 논의할 때, 잠재적인 사용자 수가 아닌 동시 사용자 수를 의미한다는 점에 유의해야 합니다. 잠재적인 사용자는 일반적으로 훨씬 더 많습니다.

 

1.2.3.2 Three-Tier Architecture 3계층 서버 아키텍처에서는 클라이언트와 서버 사이에 서버 또는 일련의 서버가 에이전트로 기능하여, 클라이언트가 요구하는 데이터나 애플리케이션이 있는 서버와의 중간 역할을 합니다. 이 에이전트는 원래 서버가 수행해야 할 처리 작업을 대신 수행함으로써 여러 가지 기능을 제공합니다. 예를 들어, 에이전트는 클라이언트 쿼리를 데이터베이스 서버에서 실행할 수 있는 데이터베이스 검색 언어로 변환하는 번역 서비스를 제공할 수 있습니다. 다른 가능한 에이전트 기능으로는 동시에 허용되는 요청 수를 제한하는 계측 장치로서 작동하거나, 특정 기준에 따라 요청을 다른 서버에 분배하는 전처리 매핑 에이전트로서 작동하는 등의 다양한 역할이 있을 수 있습니다. 또한 중간 계층 장치가 수행할 수 있는 기능의 다른 예로는 요청 대기열 관리, 요청 필터링, 상상할 수 있는 다양한 애플리케이션 전처리가 포함될 수 있습니다.

 

 그림 1.5는 설명의 간소화를 위해 동일한 네트워크에서 2계층과 3계층 아키텍처를 보여줍니다. 2계층 아키텍처에서는 클라이언트-서버 통신이 장치 간에 직접 이루어집니다. 반면, 3계층 아키텍처에서는 데이터 흐름이 두 번 발생하는데, 처음에는 클라이언트에서 에이전트로, 그다음에는 에이전트에서 서버로 데이터가 전달됩니다. 따라서 로컬 영역 네트워크 환경에서는 추가적인 네트워크 사용량을 서버에서의 처리 기능 분산과 비교해야 합니다. 예를 들어, 데이터 흐름이 초당 평균 6000개의 패킷을 발생시키고, 각 패킷의 데이터 크기가 평균 1200바이트라고 가정해봅시다. 그러면 2계층 아키텍처는 72Mbps의 데이터 흐름을 가지며, 3계층 서버 아키텍처에서는 데이터 흐름이 두 배로 증가해 144Mbps의 데이터 속도를 초래하게 됩니다. 기가비트 이더넷 네트워크가 설치되어 있다면 이는 중요하지 않지만, 최대 100Mbps의 데이터 전송 기능을 가진 패스트 이더넷이 사용된다면, 데이터 흐름을 처리할 수 없는 과도하게 사용된 네트워크로 변하게 됩니다. 에이전트가 데이터에 대한 전처리를 수행할 수 있으므로, 서버로의 데이터 흐름이 줄어들 가능성도 있지만, 전처리가 추가적인 트래픽을 발생시킬 수도 있습니다. 에이전트의 동작과 상관없이 3계층 네트워크에서는 2계층 네트워크보다 트래픽이 더 많아지며, 네트워크 구조를 설계할 때 이를 고려해야 합니다.

 

 이제 클라이언트-서버 아키텍처의 기본 개념을 이해했으므로, 콘텐츠 전송의 발전에 대한 논의로 돌아가 푸시(push) 기술에 중점을 두겠습니다.