목차
2.6 비디오 스트리밍과 콘텐츠 분배 네트워크 131
2.6.1 인터넷비디오 131
2.6.2 HTTP 스트리밍 및 DASH 132
2.6.3 콘텐츠 분배 네트워크(CDN) 133
2.6.4 사례연구: 넷플릭스. 유튜브 137
📟 2.6 비디오 스트리밍과 콘텐츠 분배 네트워크
💻 2.6.1 인터넷 비디오
- 스트리밍 비디오 애플리케이션
- 미리 녹화된 비디오(영화，TV 프로그램，스포츠 경기, 유튜브 영상(UCC 비디오))을 대상
- 녹화된 비디오는 서버에 저장되어 사용자가 비디오 시청을 서버에게 온디맨드로 요청
- 온디맨드 : 사용자가 원하면 줘!
- 넷플릭스，유튜브(구글)，아마존，틱톡(TikTok) 등 인터넷 비디오 스트리밍 회사
- 비디오 : 이미지의 연속
- 일반적으로 초당 24개 또는 30개의 이미지로 일정한 속도로 표시됨.
- 디지털 인코딩 이미지는 픽셀 단위로 구성
- 각 픽셀은 여러 비트(휘도,색상)들로 인코딩
- 압축 가능
- trading off : 비디오 품질과 비트 전송률은 서로 반비례
- 비디오를 여러 버전의 품질로 생성(사용자는 맞는 버전 선택)
- 높은 비트 전송률
- 압축된 인터넷 비디오는 일반적으로 고화질 동영상을 스트리밍하기 위해 100 kbps에서 4 Mbps 이상으로 구성
- 4K 스트리밍은 l0Mbps 이상의 비트 전송률
- = 하이엔드(hightnd) 동영상의 경우 트래픽과 스토리지 용량이 엄청나게 필요함
- 평균 종단 간 처리량
- 연속 재생을 위한 중요한 성능 척도
- 압축된 비디오 전송률 <= 스트리밍 애플리케이션에 대한 평균 처리량을 네트워크는 제공내가 이해한 바로는 서버가 각 클라이언트의 전송속도의 평균이 평균 종단 간 처리량을 의미하는 듯.
그래서 이 평균이 어느정도 되어야 대부분 클라이언트에서 영상이 끊기지 않고 전송되기 위해 중요한 척도이다~인 듯
🎿 2.6.2 HTTP 스트리밍 및 DASH
HTTP 스트리밍에서의 비디오 : HTTP 서버 내의 특정 URL을 갖는 일반적인 파일로 저장- 동작 과정
- 사용자가 비디오 시청을 원하면 클라이언트는 서버에게 TCP 연결을 설립
- 해당 URL에 대한 HTTP GET 요청
- 서버가 HTTP 응답 메시지 내에서 비디오 파일을 전송
(기본 네트워크 프로코콜 및 트래픽 조건이 허용되는 대로) - 클라이언트 쪽에서는 애플리케이션 버퍼에 전송된 바이트가 저장됨.
- 버퍼의 바이트 수가 미리 정해진 임곗값(threshold)을 초과하면 클라이언트 애플리케이션이 재생 시작
- 비디오 스트리밍 애플리케이션: 클라이언트 애플리케이션 버퍼에서 주기적으로 비디오 프레임을 가져옴 -> 프레임을 압축해제 -> 사용자의 화면에 표시
=> 비디오의 후반 부분에 해당하는 프레임을 수신하고 버퍼링할 때 비디오를 표시내 생각은 일단 영상이 끊기지 않아야하니까 어느정도 버퍼에 저장해두고, 좀 거의 준비댔다 싶으면 이제 화면에 표시해주고 나머지를 계속 받아오는 것을 말하는 듯
- 문제점
- 클라이언트 별 가용 대역폭은 차이를 가짐 -> but 똑같이 인코딩된 비디오를 전송받음
- ㄴ 동일한 클라이언트에서도 시간에 따른 차이가 발생
DASH(Dynamic Adaptive Streaming over HTTP)
- 위 문제점 해결한 HTTP 기반 스트리밍
- 비디오는 여러 가지 버전으로 인코딩 -> 클라이언트가 서로 다른 인코딩률을 같는 비디오를 선택
- 각 버전은 비트율과 품질 수준이 서로 다르다.
- 클라이언트는 동적으로 여러 버전의 비디오를
Chunk단위로 선택 후 요청
(가용 대역폭에 따라 맞는 비트율 요청)
- 이동 중에 접속하는 기지국의 상황에 따라 가용 대역폭이 자주 변화하기 때문에 클라이언트에게 중요
- 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다.
- HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는
매니패스트(manifest)파일을 가지고 있다. - 동작 과정
- 클라이언트는 먼저 매니페스트 파일을 요청하여 서버에서 제공되는 다양한 버전을 안다.
- 클라이언트는 매번 원하는 버전의 비디오 조각 단위 데이터를 선택하고,
HTTP GET 요청 메시지에 URL과 byte-range를 지정하여 요청한다. - 클라이언트는 비디오 조각 단위 데이터를 다운로드한다.
- 그 동안 측정된 수신 대역폭과 비트을 결정 알고리즘을 이용해 다음에 선택할 비디오 조각 단위 데이터의 버전을 결정한다.
🎰 2.6.3 콘텐츠 분배 네트워크(CDN)
스트리밍 서비스 문제점 : 많은 시청자 -> 큰 스트리밍 트래픽을 전세계에 끊김 없이 제공해야함.
해결책
1. 거대 데이터 센터 하나에서 직접 전송 = 거대 서버 하나
- 서버가 터지면 전체가 터짐
- 클라이언트가 데이터 센터로부터 지역적으로 멀리 있다면 딜레이 발생
- 많은 다양한 통신링크와 ISP 거침 -> 링크 중 하나라도 비디오 소비율보다 낮은 전송용량을 가지면 처리율↘ -> 화면 정지
- 인기 있는 비디오 = 같은 통신 링크로 여러번 전송 됨
- 대역폭 낭비 + ISP에게 동일한 바이트 전송에 대한 중복 비용 지불
콘텐츠 분배 네트워크(CDN,contents distribution network)
- 다수의 지점에 분산된 서버들을 운영
- 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 이들 분산 서버에 저장한다.
- 사용자는 최선의 서비스와 사용자 경험을 제공할 수 있는 지점의 CDN 서버로 연결
- 콘텐츠 제공자가 소유한 사설 CDN(ex 유튜브-구글) or 제 3자가 운영하는 CDN
- 서버 위치 설정 방법
enter deep: 서버 클러스터를 세겨 곳곳의 접속 네트워크에 구축- ISP의 접속 네트워크 안쪽에 CDN 서버를 놓음
- 서버를 최대한 사용자 가까이에 위치
- 장점
- 사용자와 CDN 서버 사이의 링크 및 라우터 수↘
- 사용자가 경험하는 지연 시간 및 처리율↗
- 단점
- 고도의 분산 설계 -> 서버 클러스터 유지 관리 비용↗
bring home: 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축- ISP의 접속 네트워크 바깥에 CDN 서버를 놓아 Home으로 가져오는 개념
- 접속 ISP에 직접 연결X -> CDN 서버를 인터넷 교환 지점(IXP)에 배치(간접)
- 장점
- 개수↘ = 클러스터 유지 및 관리 비용↘
- 더 넓은 지역 커버 가능
- 단점
- 사용자가 느끼는 지연 시간↘, 처리율↘
- ISP의 접속 네트워크 바깥에 CDN 서버를 놓아 Home으로 가져오는 개념
- 서버 클러스터의 위치가 정해지면 여기에 콘텐츠 복사본 저장
- 이때 모든 비디오의 복사본을 전부 유지 X
- 국가별 성향 차이
- 클러스터에 대해 pull 방식을 사용
- 사용자가 지역 클러스터에 없는 비디오를 요청하면，해당 비디오를 중앙 서버나 다른 클러스터로부터 전송받아 사용자에게 서비스하는 동시에 복사본을 만들어 저장
- 캐시와 같이 클러스터의 저장 공간이 가득 차면 자주 사용되지않는 비디오 데이터는 삭제
CDN 동작
간단 설명
1. 사용자 호스트의 웹 브라우저가 URL을 지정함으로써 특정 비디오의 재생을 요청
2. CDN은 그 요청을 가로챔 -> DNS 활용
(1) 그 시점에서 클라이언트에게 가장 적당한 CDN 클러스터를 선택
(2) 클라이언트의 요청을 해당 클러스터의 서버로 연결
1. 사용자가 NetCinema의 웹페이지를 방문
2. 사용자가 http://video.netcinema.com/6Y7B23V 링크를 클릭하면,
사용자의 호스트 -> 지역 DNS 서버 with video.netcinema.com에 대한 DNS query(질의)
3. 지역 DNS서버(LDNS): 호스트이름(url)의 "video"문자열을 감지 -> Netcinema의 책임 DNS 서버 with query
- 3-1. Netcinema 책임 DNS 서버 -> 지역 DNS서버(LDNS) with KingCDN의 호스트 이름(a1105.kingcdn.com) 응답 (해당 DNS 질의를 KingCDN으로 연결하기 위해)
4. 지역 DNS서버(LDNS) -> KingCDN 책임 DNS with a1105.kingcdn.com에 대한 query
- 4-2. KingCDN 책임 DNS -> 지역 DNS서버(LDNS) with KingCDN 콘텐츠 서버의 IP 주소 응답
- 이때 클라이언트가 콘텐츠를 전송받게 될 서버가 결정됨
5. 지역 DNS서버(LDNS) -> 사용자 호스트 with 콘텐츠를 제공할 CDN 서버의 IP주소 응답
6. 클라이언트는 해당 IP주소로 직접 TCP연결을 설정, 비디오에 대한 HTTP Get 요청
- 만약 DASH가 사용된다면
- 서버 : 서로 다른 버전의 비디오에 대한 URL 목록을 포함하는 manifest 파일을 클라이언트에게 전송
- 클라이언트 : 동적으로 서로 다른 버전의 비디오 조각 단위 데이터를 선택 가능
클러스터 선택 정책
- 지리적으로 가장 가까운 클러스터(TLD(kr,fr)랑 같은거래유) 할당
- 상용 지리정보 데이터베이스를 이용하면 LDNS의 IP 주소는 지리적으로 매핑oo
- 간단하고 대부분 잘 작동 but 일부는 안됨
- 지리적으로는 가깝지만, 네트워크 경로의 길이 홉(hop)의 수에 따라 달라질 수 있기 때문
- 일부 사용자는 상당히 멀리 있는 DNS 서버를 LDNS로 사용하도록 설정했을 수도 있음
- 이는 경로 지연, 대역폭 변화 등 무시 -> 항상 같은 클러스터를 클라이언트에게 할당하게 됨.
- 주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 실시간 측정 수행
- 현재의 네트워크 트래픽 상황을 반영한 최선의 클러스터를 선택
- ex) CDN은 각 클러스터가 ping이나 DNS 질의 같은 프로브 메시지를 주기적으로 U5NS들에게 전송 가능
- but 많은 LDNS가 이와 같은 메시지에 응답하지 않도록 설정되어 있다..
🔎 2.6.4 사례연구: 넷플릭스，유튜브
넷플릭스
- 비디오 배포 : 아마존 클라우드와 자체 CDN 인프라
- 아마존 클라우드의 기능
- 콘텐츠 수집：영화의 수집과 처리
- 영화의 스튜디오 마스터 버전을 받아서 아마존 클라우드 시스템의 호스트에 업로드
- 콘텐츠 처리：각 영화의 여러 가지 형식의 비디오를 생성
- 고객들의 다양한 플레이어 기기의 사양이 적합하도록
- DASH를 이용한 HTTP 적응적 스트리밍 서비스를 위해 각 형식별로 다양한 비트율의 여러 가지 버전을 생성
- CDN으로 버전 업로드: 아마존 클라우드 시스템 호스트는 영화의 다양한 버전을 CDN으로 업로드
- 콘텐츠 수집：영화의 수집과 처리
- 적응적 스트리밍과 CDN을 포함하여 이 절의 전반부에서 논의한 여러 가지 기술을 사용
(동작과정은 거의 위 기술과 유사) - 그러나 넷플릭스는 비디오(웹 페이지 제외)만 배포하는 자체 CDN을 사용하고 있기 때문에 CDN 디자인을 단순화하고 조정 가능
- 특정 클라이언트를 CDN 서버에 연결하기 위해 위 CDN동작 과정처럼 DNS 리다이렉션을 사용X
- 대신 아마존 클라우드에서 실행되는 것처럼 넷플릭스 소프트웨어는 클라이언트에게 특정 CDN 서버를 사용하도록 알려줌.
- 넷플릭스 CDN은 본래 사용하는 풀 캐싱(pullcaching)보다 푸시 캐싱(push-caching)을 사용
- 콘텐츠는 캐시 미스(cache miss) 중에 동적으로 사용되는 것이 아니라 사용량이 적은 시간 중 예약된 시간에 서버에 푸시한다.
유튜브
- 거대한 데이터 센터에서 직접 동영상을 배포
- CDN 적극 활용.
- 구글은 자체 비공개 CDN을 사용하여 유류브 동영상을 배포하고 수백 가지의 IXP 및 ISP 위치에 서버 클러스터를 설치
- CDN 동작 과정과 똑같이 사용자를 특정 서버 클러스터와 연결하는 데 DNS를 사용
- 구글의 클러스터 선택 정책 : 클라이언트와 클러스터 간의 RTT가장 적은 곳을 연결
- 때로는 클러스터들 간의 균형 있는 작업 부하를 위해 클라이언트가 DNS를 통해 좀 더 멀리 있는 클러스터에 연결되기도 한다.
- HTTP 스트리밍을 채용
- 보유한 비디오에 대해 각기 다른 비트율과 품질을 갖는 여러 단계의 버전을 생성, 제공
- DASH 같은 적응적 스트리밍 대신에 사용자가 스스로 버전을 선택
- 재생 위치 조정과 조기 종료로 인한 대역폭과 서버 자원의 낭비를 줄이기 위해 유튜브는 HTTP byte-range 헤더를 이용해 목표한 분량의 선인출 데이터 이후에 추가로 전송되는 데이터
흐름을 제한
- HTTP 스트리밍 사용 : 서버 -> 클라이언트로의 비디오 전송 + 사용자 -> 서버로의 비디오 업로드
- 업로드된 각각의 비디오를 자신들의 형식으로 변환하고 여러개의 버전으로 생성
- 이러한 과정은 전적으로 구글 데이터 센터 내에서 이루어짐
인생 살자.
개발자로서 성장하는 데 큰 도움이 된 글이었습니다. 감사합니다.