CDN(Contents Delivery Network)의 정의

- 대용량 또는 사용자의 잦은 요청이 있는 컨텐츠들을 Cache 서버에 분산 배치하여 컨텐츠의 전송 중 발생하는 트래픽 집중 & 병목현상 및 데이터 손실을 해결하기 위해 등장한 컨텐츠 전송 기술 ( 느린 응답속도/다운로딩 타임을 극복하기 위한 기술 )

CDN의 작동 원리

1.  웹 브라우저가 실행되는 디바이스인 PC나 모바일 기기의 사용자 에이전트가 특정 주소에 접근하여 HTML, 이미지, CSS, JavaScript 파일 등 렌더링하는 데 필요한 콘텐츠를 서버로부터 요청

2. DNS는 콘텐츠에 대한 각 요청이 발생하면 End User와 가장 가까운 위치에 최적으로 배치된 CDN 서버에 End User가 매핑되고, 해당 서버는 요청된 파일의 캐싱된(사전 저장된) 버전으로 응답(전송). 

3. 서버가 파일을 찾는 데 실패하는 경우 CDN 플랫폼의 다른 서버에서 콘텐츠를 찾은 다음 End User에게 응답을 전송. 콘텐츠를 사용할 수 없거나 콘텐츠가 오래된 경우, CDN은 오리진 서버에 대한 요청 프록시로 작동하여 향후 요청에 대해 응답할 수 있도록 Patch된 새로운 콘텐츠를 저장

CDN의 구성 요소 

- CDN 서버 : 컨텐츠 저장, 최종 사용자에게 스트리밍 서비스 

- Contents 분배 : 지정된 컨텐츠를 스케쥴에 따라 지정된 CDN 서버에 전송하여 최신 컨텐츠 버전을 유지함. 

- GLB라우터 : 지역적으로 분산되어 설치된 여러 CDN 서버를 사용자와 가장 가까운 CDN서버에서 사용자가 서비스 받을 수 있도록 하는 라우터 

- CDN관리 및 모니터링 SW : 분산되어 있는 CDN서버를 중앙에서 관리, 장애상황 대처

CDN기술요소 

- Contents Sync : CP의 웹컨텐츠 중 변경된 내용이 있다면 CDN서버와 Sync

- Caching 기술 : 자주 사용되는 파일 캐쉬 서버에 저장  

    -  Pull 모델 - ISP들의 POP지점에 Cache서버 배치 

    - Push 모델 = 캐쉬서버를 웹서버 앞에 위치 

- Load Balancing : 서버사이의 트래픽 향상

    - Product-Based 솔류션 : 기업 소유 형태

    - Service-Based 솔류션 : 아웃소싱 형태 

- Streaming 기술 : 실시간으로 사용자가 원하는 컨텐츠 전송 기술

     - Multicasting Streaming : 동시에 많은 고객

     - On-demand Streaming : 주문형 서비스

CDN 캐싱 방식의 종류

- Static Caching

– 사용자의 요청이 없어도 Origin Server에 있는 Content를 운영자가 미리 Cache Server에 복사함

– 따라서 사용자가 Cache Server에 접속하여 Content를 요청하면 무조건 그 Content는 Cache Server에 있음! (100% Cache Hit)

– 대부분의 국내 CDN에서 이 방식을 사용함 (예. Pooq 동영상 스트리밍/다운로드, NCSOFT 게임파일 다운로드 등)

Dynamic Caching

– 최초 Cache Server에는 Content가 없음

– 사용자가 Content를 요청하면 해당 Content가 있는지 확인하고, 없으면(Cache Miss) Origin Server로 부터 다운로드 받아(Cache Fill) 사용자에게 전달해 줌

– 이후 동일 Content를 요청 받으면 저장(캐싱)된 Content를 사용자에게 전달(Cache Hit)

– 각 Content는 일정 시간(TTL)이 지나면 Cache Server에서 삭제될 수 있고, 혹은 Origin Server를 통해 Content Freshness 확인 후에 계속 가지고 있을 수 있음

–  Akamai, Amazon과 같은 Global CDN 업체, 그리고 Cisco나 ALU의 통신사업자향 CDN 장비 솔루션에서 이 방식을 지원함

CDN 도입효과

- CP측면 : Web성능향상, 다양한 멀티미디어 제공, 비용절감, QoS증가

- ISP측면 : Performance 향상, 사용자 만족도 향상 

- User측면 : QoS확보된 서비스 제공, 다양한 컨텐츠 서비스

참고 

https://blog.naver.com/paninfo/10139797986

https://cdn.hosting.kr/cdn%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94/

http://brainwave.tistory.com/82

https://idchowto.com/?p=16938

http://i5on9i.blogspot.com/2014/05/cdn-proxy-server.html

https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=231&dbnum=127531&mode=detail&type=techreport

DNS란 

• www.example.com과 같이 사람이 읽을 수 있는 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 한다. 
• 인터넷의 DNS 시스템은 이름과 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능
• DNS 서버는 이름에 대한 요청을 IP 주소로 변환하여 최종 사용자가 도메인 이름을 웹 브라우저에 입력할 때 해당 사용자를 어떤 서버에 연결할 것인지를 제어한다. 이 요청을 쿼리라고 한다.

Domain 구조

• 인터넷상에서 사용되는 도메인은 전 세계적으로 고유하게 존재하는 이름
• 정해진 규칙 및 체계에 따라야 하며, 임의로 변경되거나 생성될 수 없음.
• 인터넷상의 모든 도메인은 ".(dot)" 또는 루트(root)라 불리는 도메인 아래에 그림과 같이 나무를 거꾸로 위치시킨 역트리(Inverted tree)구조로 계층적으로 구성되어 있음
• 루트 도메인 바로 아래의 단계를 1단계 도메인 또는 최상위도메인(TLD, Top Level Doamin)이라고 부르며, 그 다음 단계를 2단계 도메인(SLD, Second Level Domailn)이라고 함
• 도메인은 일반최상위도메인(gTLD: Generic Top Level Domain)과 국가최상위도메인(ccTLD: Country Code Top Level Domain)로 구분할 수 있으며 여기서 일반최상위도메인은 다시 스폰서도메인(Sponsored TLD)과 언스폰서도메인(Unsponsored TLD)으로 구분됩니다.
• 
  



• 
  

HTTP/1.1 동작 방식

• HTTP/1.1는 기본적으로 Connection당 하나의 요청을 처리 하도록 설계
• 동시 전송이 불가능하고 요청과 응답이 순차적으로 이뤄짐
• HTTP 문서 안에 포함된 다수의 리소스 (Images, CSS, Script)를 처리하려면 요청할 리소스 개수에 비례해서 Latency(대기 시간)는 길어짐

HTTP/1.1 단점

HOL (Head Of Line) Blocking - 특정 응답의 지연

• HTTP의 HOL Blocking
• TCP의 HOL Blocking

  - HTTP/1.1의 connection당 하나의 요청 처리를 개선할 수 있는 기법 중 pipelining이 존재 

- Connection을 통해서 다수개의 파일을 요청/응답 받을 수 있는 기법

예 ) 하나의 TCP연결에서 3개의 이미지( a.png, b.png, c.png )를 얻으려고 하는 경우 HTTP의 요청 순서.

| --- a.png --- |

            | --- b.png --- |

                        | --- c.png --- |

순서대로 첫번째 이미지를 요청하고 응답 받고 다음 이미지를 요청하게 되는데 만약 첫번째 이미지를 요청하고 응답이 지연되면 아래 그림과 같이 두, 세번째 이미지는 당연히 첫번째 이미지의 응답 처리가 완료되기 전까지 대기하게 되며 이와 같은 현상을 HTTP의 HOB (Head of Line Blocking) 이라 부르며 pipelining의 큰 문제점 중 하나이다.

| ------------------------------- a.png ------------------ |

                                                                                       | -b.png- |

                                                                                                 | --c.png-- |

RTT( Round Trip Time ) 증가

• 일반적으로 하나의 connection에 하나의 요청을 처리
• 그렇기 때문에 매 요청별로 connection을 만들게 되고 TCP상에서 동작하는 HTTP의 특성상 3-way Handshake 가 반복적으로 일어나고 또한 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 저하 시킴

SPDY 등장

• HTTP/1.1 단점을 근본적으로 해결되지 않음
• 구글은 더 빠른 Web을 실현하기 위해 throughput 관점이 아닌 Latency 관점에서 HTTP를 고속화한 SPDY(스피디) 라 불리는 새로운 프로토콜을 구현
• SPDY는 HTTP를 대치하는 프로토콜이 아니고 HTTP를 통한 전송을 재 정의하는 형태로 구현 

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고 이는 HTTP/2 초안의 참고 규격이 됨

HTTP/2 등장

• HTTP가 유선 상에서 표현 방법을 대치 하는 것
• 성능에 초점
• 최종 사용자가 대기 시간, 네트워크 및 서버 리소스 사용을 인식
• 하나는 브라우저에서 웹 사이트로의 단일 연결을 허용하는 것

HTTP/2 주요 특징

Multiplexed Streams

• 한 커넥션으로 동시에 여러 개의 메세지를 주고 받을 있으며, 응답은 순서에 상관없이 stream으로 주고 받음
• HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선

Stream Prioritization

클라이언트가 요청한 HTML문서 안에 CSS파일 1개와 Image파일 2개가 존재하고 이를 클라이언트가 각각 요청하고 난 후 Image파일보다 CSS파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어지는 문제가 발생하는데 HTTP/2의 경우 리소스간 의존관계(우선순위)를 설정하여 이런 문제를 해결

Server Push

• 서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 보내줄 수 있음
• 클라이언트(브라우저)가 HTML문서를 요청하고 해당 HTML에 여러 개의 리소스(CSS, Image...) 가 포함되어 있는 경우 HTTP/1.1에서 클라이언트는 요청한 HTML문서를 수신한 후  HTML문서를 해석하면서 필요한 리소스를 재 요청하는 반면 HTTP/2에서는 Server Push기법을 통해서 클라이언트가 요청하지 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화 해서 성능 향상을 이끌어 냄
• PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 않음

Header Compression

HTTP/2는 Header 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하여 처리하는데 이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리.

위 그림처럼 클라이언트가 두번의 요청을 보낸다고 가정하면 HTTP/1.x의 경우 두개의 요청 Header에 중복 값이 존재해도 그냥 중복 전송한다. 하지만 HTTP/2에선 Header에 중복값이 존재하는 경우 Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고 중복된 Header는 index값만 전송하고 중복되지 않은 Header정보의 값은  Huffman Encoding 기법으로 인코딩 처리 하여 전송한다.

참고

https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/

http://americanopeople.tistory.com/115

https://developers.google.com/web/fundamentals/performance/http2/?hl=ko

https://kemptechnologies.com/solutions/http2/

Container란 무엇인가?

사전적 의미로 컨테이너는 어떤 물체를 격리하는 공간을 뜻합니다. 클라우드에서 컨테이너는 어떤 의미를 가질까요? 컨테이너는 애플리케이션과 애플리케이션을 구동하는 환경을 격리한 공간을 뜻합니다. 컨테이너 기술은 약 10여 년 전에 리눅스에 내장된 기술로 소개되었으며, 현재는 차세대 트렌드 기술로 주목받으며 클라우드 서비스 환경에 적용되고 있습니다.

왜 Container인가?

1)   Virtual Machine과 Container의 차이점

Virtual Machine Server에서는 Hypervisor로 하드웨어를 가상화 하고, 그 위에 Guest OS가 설치된 Virtual Machine들을 구동 시켰다. 반면에 Container Server는 운영체제 레벨에서 CPU, RAM, Disk, Network 등의 자원을 격리하여 Container에 할당하기 때문에 게스트 OS가 따로 필요 없다.

2)   효율성
안정적인 운영을 위해, 1개의 가상머신(VM, Virtual Machine)에 1개의 서비스를 구동하는 것이 권장된다. 이의 경우 가상머신의 모든 자원을 사용하는 것이 아니기 때문에 성능적 오버헤드가 발생한다. 반면 컨테이너의 경우, OS 커널을 공유하기 때문에 자원을 필요한 만큼 효율적으로 사용할 수 있다.

3)   신속성
사용자의 서비스 request traffic이 증가함에 따라, 가상머신이나 컨테이너를 추가적으로 배포한다. 가상머신의 크기는 최소 몇 GB이지만, 컨테이너의 경우 Guest OS가 없어 MB단위의 크기를 가진다. 결과적으로 가상머신은 배포하는데 수 분에서 수십 분의 시간이 소요되지만, 컨테이너는 배포에 소요되는 시간이 수 초에 불과하다.

4)   라이센스 비용 절감
가상화 서버의 경우 가상머신의 개수만큼 Guest OS의 라이센스 비용이 발생한다. 반면에 컨테이너 서버의 경우 Host OS 1대의 라이센스 비용만 발생한다. 만약 서버의 수가 많아진다면 비용의 차이도 기하급수적으로 증가할 것이다.

5)   안정성
가상머신의 경우 정확히 할당된 자원 내에서 가상머신이 운영되기 때문에, 컨테이너에 비해 안정적으로 운영할 수 있다. 반면에 컨테이너들은 OS 커널을 공유하기 때문에, 하나의 컨테이너가 무리하게 자원을 사용하게 될 수 있다. 자원 할당량을 사전에 지정 시켜줄 수 있지만, 만약 이런 상황이 발생하면 컨테이너에 장애가 발생 한다. 이런 컨테이너의 문제는 뒤에 등장할 쿠버네티스 등과 같은 Container 오케스트레이션 툴로 해결할 수 있다.

https://developer.ibm.com/kr/cloud/2018/01/12/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%99%80-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%EB%A5%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/

https://www.backblaze.com/blog/vm-vs-containers/