1. Video Streaming과 CDNs 개요
스트리밍 비디오 트래픽은 인터넷 대역폭의 주요 소비자임
(ex. Netflix, YouTube 등)
Video Streaming에서 마주할 문제점
- 규모 문제 : 수십억명 커버 가능 해야함
(서버 하나에 모든 요청 몰리면 과부하 터짐) - 이질성 (Heterogeneity) 문제
사용자 환경이 다 다르기에, 모든 사람에게 같은 품질로 비디오 제공 불가능
(네트워크 상황에 맞춘 적응형 스트리밍 필요)
해결책 : CDNs (Content Distribution Networks)
분산 구조를 사용해서, 여러 서버와 위치에 콘텐츠를 미리 배포
가까운 서버에서 사용자에게 스트리밍 하도록 함
2. Video Coding
- Video는 이미지 프레임들의 연속
(ex. 24fps : 1초에 24장의 이미지) - 이미지는 픽셀배열로 구성
- 픽셀은 bit로 표현
(ex. RGB 컬러 픽셀이면 각각 8비트씩, 총 24비트 사용)
Video Coding 방식
비디오는 파일 크기가 너무 크기에 압축을 하기 위해 coding 필요함
- 압축의 핵심: 중복(redundancy) 제거
공간적 코딩 (spatial coding)
이미지 내 중복 제거
(ex. 같은 색이 100번 반복되는 경우, 보라색 100번으로 표현)
시간적 코딩 (temporal coding)
이미지 사이 중복성 제거하는 방식으로, 연속된 프레임 사이의 차이만 전송
(ex. frame i 와 frame i+1 이 거의 같다면,
i+1 전체를 보내는 대신, i와 다른 부분만 전송)
3. Video Encoding (압축)
CBR (Constant Bit Rate)
항상 일정한 비트 전송율로 영상 전송
(복잡한 장면이든, 단순한 장면이든 상관없이)
- 네트워크 대역폭 예측 쉬움
- 복잡한 장면에서 품질 떨어질 수있음 (bit 부족)
VBR (Variable Bit Rate)
장면의 복잡도에 따라 비트 전송율 다름
(장면 복잡하면 더 많은 비트 사용)
- 전체 파일 용량 최적화되고, 품질 좋아짐
- 순간마다 필요한 대역폭이 변동해서, 네트워크 관리 어려움
Video Encoding (압축) 방식 Example
- MPEG-1: 1.5 Mbps (옛날 CD-ROM 영상)
- MPEG-2: 3~6 Mbps (DVD 품질)
- MPEG-4: 64Kbps ~ 12Mbps (인터넷 스트리밍에 많이 사용)
4. Streaming Stored Video
저장된 비디오 스트리밍의 고려사항
- bandwidth가 시간에 따라 변동
일정한 속도로 비디오를 받는데 어려움 생김
(네트워크 혼잡도가 집 내부, 비디오 서버 쪽 등등 다양한 곳에서 발생 가능) - packet loss와 delay 발생
비디오 재생이 지연되거나, 영상 품질이 떨어질 수 있음
동작 과정 (이상적인)
Playout Buffering (플레이아웃 버퍼링)
클라이언트가 재생하면, 원래 비디오의 타이밍을 그대로 맞춰야함
- jitter (지터)
네트워크 지연(Network delay) 은 항상 일정 X
해결 방법
네트워크 변동(jitter)이 있어도, 끊기지 않고 부드럽게 재생
- 빨간색 선: 서버에서 일정한 비율로 비디오를 전송 -
- 파란색 선: 클라이언트가 실제로 데이터를 받는 양
(네트워크 변동 때문에 오락가락함) - 검은색 선: 클라이언트가 일정한 속도로 비디오를 재생하는 모습
클라이언트가 버퍼(client-side buffer) 를 사용해서
버퍼를 먼저 채우고, 일정량 채워지면 재생 시작
Streaming Multimedia: DASH
DASH = Dynamic, Adaptive Streaming over HTTP
Server 역할
- 비디오 파일을 여러 청크(chunk) 로 나누기
- 여러 가지 인코딩 속도(ex. 400kbps, 800kbps)로 각각 저장
- manifest 파일 제공
(각각 청크의 URL 정보가 들어 있음)
Client 역할
주기적으로 네트워크 속도 측정
(최대 코딩 속도 청크를 선택해서 다운로드 받기 위해)
- manifest 파일을 받아서, 청크들의 URL 정보 확인
- 현재 측정된 네트워크 속도에 맞춰 적당한 청크 품질을 선택해서 가져옴
client가 고려해야되는 것
- When : 언제 청크를 요청할 지
(버퍼가 비거나, 넘치지 않도록) - what encoding rate : 어떤 인코딩 비율(화질)을 요청할지 결정
- where : 어디(어떤 서버)에서 청크를 받을지 결정
(가까운 서버, 또는 덜 혼잡한 서버 선택해서 빠르게 다운로드)
Streaming Stored Video Summary
= Encoding + DASH + Playout Buffering
1) 인코딩 방식 필요
2) DASH 사용해서 청크를 현명하게 가지고 오기
3) 클라이언트 쪽에서 충분한 버퍼 쌓아두기
5. Content Distribution Networks (CDNs)
Content를 분배하는 Network
(CDNs을 사용해야되는 이유 1. 개요에서 설명함)
Mega Server의 한계
현실적으로 불가능함 (사용자 감당 x)
- Single Point of Failure
서버 하나가 고장나면 전체 서비스 중단 - Network Congestion
서버 주변 네트워크에 트래픽 몰려서 혼잡 발생 - Long Path to Clients
멀리 있는 사용자까지 데이터 전송하느라 지연(latency) 증가 - Multiple Copies
같은 영상을 여러 사람에게 전송 → 네트워크 대역폭 낭비
해결책
여러 지역 서버에 콘텐츠 복사본을 저장하고, 사용자에게 가까운 서버가 제공
CDNs 배포 방식
enter deep (깊숙이 들어가기)
많은 access network 안쪽에 CDN 서버를 설치
(사용자가 최대한 가깝게)
- 많은 CDN server 사용 (적은 규모)
bring home (집 근처에 배치)
비교적 적은 수의 대규모 서버를 access network 바깥쪽에 설치
- 적은 CDN server 사용 (큰 규모)
CDNs 동작 과정
사용자가 'MadMen'을 보고 싶다고 요청하는 경우
1) 요청 발생
사용자가 CDN 네트워크에 "MadMen" 요청
2) 위치 찾기
"MadMen" 복사본이 있는 서버를 찾음 (manifest file 참고)
3) 연결 및 다운로드
가장 가까운 서버로 연결하여 콘텐츠를 스트리밍 시작
4) (혼잡 시) 경로 변경
만약 연결 경로가 혼잡하면, 복사본을 가진 다른 서버로 요청 전환 가능
OTT 환경
OTT (Over The Top) 서비스는 인터넷을 통해 직접 콘텐츠를 제공
- 통신사/ISP에 의존하지 않고, 자체적으로 콘텐츠를 제공 (인터넷망만 빌림)
(ex. 넷플릭스, 유튜브)
OTT 환경의 고려사항
- 어떤 CDN 노드에서 콘텐츠를 가져올까?
(가장 빠른 경로, 덜 혼잡한 서버 선택) - 혼잡 시 사용자 행동은 어떻게 될까?
(끊기거나 느려지면 시청자가 이탈) - 어떤 콘텐츠를 어떤 CDN 노드에 저장할까?
(인기도를 예측해서 인기 콘텐츠를 가까운 노드에 미리 배치)
6. CDN content access Example
Example 1.
Bob이 http://video.netcinema.com/6Y7B23V URL을 요청하는 경우
(실제 비디오는 KingCDN이라는 CDN 서버에 저장)
1) Bob이 URL 입력
2) URL을 로컬 DNS 서버로 질의
video.netcinema.com의 IP 주소를 찾기 위해
3) 로컬 DNS가 netcinema.com의 권한 DNS 서버로 문의
video.netcinema.com의 IP가 어디 있는지 모를 때
4) 권한 DNS가 KingCDN 서버를 추천
"video는 KingCDN이 관리해!"
(도메인에 대한 책임이 있어서, 정보를 넘기는 것)
5) Bob은 KingCDN의 콘텐츠 서버를 찾아 비디오 요청
실제 HTTP 요청을 보냄
6) KingCDN 서버가 비디오 스트리밍 시작
Bob에게 비디오 데이터 전송
Example 2.
Case study : Netflix
1) Bob이 넷플릭스 로그인 및 계정 관리
2) Bob이 넷플릭스에서 보고 싶은 비디오를 탐색
3) 원하는 비디오 선택 시, manifest file(다양한 버전들의 URL 리스트)을 받음
4) Bob이 manifest를 보고 최적의 CDN 서버를 선택 → 비디오 스트리밍 시작
