Ingest
스트리머의 비디오 영상이 트위치 데이터 센터로 가는 것
Transcode
비디오 형식을 바꾸는 것
Replication
복사. 안정성을 위해
Edge
CDN이라고도 부름
스트리머 -> Ingest -> Transcode -> Replication -> Edge -> 시청자
위와 같은 순서로 동작한다.
-빨간 스마일 = 스트리머
-Origin = 데이터 센터
스트리머가 데이터 센터로 직접 연결하는게 아니라 조그만 데이터 센터(pop)로 연결
(pop은 세계 곳곳에 있으며, 스트리머는 자신과 가장 가까운 pop에 연결)
스트리머는 PoP과만 통신하고, PoP은 트위치의 인프라스트럭처 네트워크('Backbone'이라고 부름)를 통해 데이터 센터와 통신
PoP에서 데이터 센터로 스트리머 영상 보내주면 아래와 같은 동작을 함
-파란 스마일 = 시청자들
트위치가 처음 시작했을 때는 데이터 센터(Origin) 하나로 시작
스케일하면서 데이터센터가 여러개로 됨
(위 그림에서 Origin이 여러개 있다고 보면됨)
-> 각각의 PoP이 어떤 데이터센터(Origin)과 통신해야하는지 정해줘야하는 복잡성이 생겼음
처음에는 HAProxy라는걸 사용 : PoP에서 Origin으로 연결
-> static하게 설정되어있음 : ex) PoP-A는 항상 특정 데이터 센터 Origin-1으로만 연결
데이터 센터가 많아지면서 생기는 문제들
-> 시간에 따라 특정 데이터 센터만 Resource Utilization이 올라감
-유저들이 액티브하게 트위치를 사용하는 시간은 그 나라 시간에따라 영향을 많이 받음
-각 데이터 센터가 로드를 나눠가져야 데이터 센터 하나 하나의 크기를 줄이는데, 하나의 Utilization이 올라가고 딴건 놀고있으면 각각의 데이터센터 모두 사이즈를 크게 해줘야하는 문제가있다. ❓
-> 데이터 센터가 다운됐을 때 다른 데이터 센터로 연결을 못 함
< 의문 >
1. Origin-1이 PoP-A, PoP-B와 통신, Origin-2가 PoP-C, PoP-D와 통신한다고 static하게 설정해두면, 특정 시간대따라 어느 Origin놀고 어느 Origin은 로드가 몰리고 그런거 상관없이 최대 크기는 항상 정해져있지않나??
4가지 Component가 있음
Intelligest media proxy (in PoP)
: HAProxy를 대체
Intelligest Reouting Service (in AWS)
: HAProxy보다 똑똑하게 하고싶으니까, Intelligest media proxy이 필요한 정보를 계산
Capacitor (in AWS) - CPU utilization monitoring
: Intelligest Reouting Service가 계산하기 위해 필요한 정보를 줌
The Well (in AWS) - Network utilization monitoring
: Intelligest Reouting Service가 계산하기 위해 필요한 정보를 줌
Intelligest Reouting Service는 어떤 데이터 센터랑 연결해야하는지 결정을 어떻게 내릴까?
Capacitor, The Well을 통해 결정을 내림
이제는 모든 PoP이 모든 데이터 센터와 통신할 수 있는 상태가 된다.
RTMP 형식을 HLS형식으로 바꿔줌
HTTP Live Streaming의 줄임말
인터넷 상태에 따라서 화질을 바꾸는 기술
HLS 프로토콜은 2가지 종류의 파일들을 만듦
-> Playlist
-> Video Chunk
자, 다시 Transcode로 와서!
PoP에서 RTMP로 들어오는데, RTMP는 한 가지의 화질 영상이 계속 들어오는 것이다.
즉 스트리머들이 찍어서 보내고 있는 비디오 스트림이다.
그럼 Transcode가 그걸 받아서 여러가지 화질로 바꿔준다.
바꿔줄때 어떻게 바꿔줄까?
1080p 화질의 시작부터 첫 2초까지 영상을 잘라서 파일을 하나 만들고, 2~4초 영상을 잘라서 파일을 하나 만들고..(반복)
이걸 각각 해상도마다 만듦
시청자가 들어오고, Playlist를 다운받음
(각 파일들을 어디서 다운받을 수 있는지 Playlist에 다 있음)
클라이언트의 비디오 플레이어가 지금 인터넷 상태를 확인함
상태가 안좋으면 시작은 360p로하며, 2초까지 영상이 어디에있는지 확인해서 해당 파일을 달라고 리퀘스트를 보냄.
해당 파일을 다운받아 플레이함
플레이되고있을 때는, 비디오 플레이어가 플레이 되는동안 시간이 조금 있으니까 조금 더 좋은 화질을 받고.. (반복)
계속 인터넷 상황에따라 Playlist 보면서 어떤 파일을 다운받아야할지 정해서 그 파일으 다운받아 플레이 해주는 것.
시간에따라 화질이 바뀌는 경험을 한 적 있을텐데, 이런식으로 흐름이 흘러가기 때문이다.
결국 300만명 동시시청은 어떻게 처리할까?
300만명이 동시에 파일들을 다운받으려하면 데이터센터가 처리가 힘들것
HLS의 Playlist, video chunks가 캐시하기 쉽게 해준다.
video chunks를 만들어뒀는데, 이건 한 번 만들어두면 바뀔 필요가 없는것이기때문이다.
시청자가 처음에 Playlist를 다운받으려한다.
Edge한테 Playlist를 달라고 리퀘스트 보낸다. 처음에는 Edge도 Playlist가 없다.
따라서 Edge가 Origin한테 Playlist를 달라고 리퀘스트를 보낸다.
Origin이 Edge한테 Playlist를 보낸다.
Edge가 Playlist를 시청자에게 준다.
그 다음 새로운 시청자가 와서 Edge한테 Playlist를 달라고한다.
Edge는 Playlist가 이미 있으므로, 바로 시청자에게 준다.
시청자는 빨리 다운받을 수 있게 된다.
이 상황에서 좋은점은 다음과 같다.
2명의 유저를 Serve하는데 Origin과 edge와 통신은 한 번만 하면 된다.
따라서 첫 유저쪽 동네 사용자들은 전부 Edge에서 바로 Serve할 수 있다.
video chunks도 마찬가지다.
유저가 playlist를 보고 특정 video chunks를 달라고 Edge에게 리퀘스트한다.
Edge가 처음에 없으면 Origin한테 달라고 리퀘스트하며, 받아온것이 Edge에 캐시된다.
유저에게 해당 video chunk를 준다.
그 다음에 똑같은 video chunk를 달라고하면, Origin으로 갈 필요없이 바로 줄 수 있다.
이렇게하면 시청자가 300만명이 돼도, 300만명이 다 데이터 센터와 통신하는게 아니라, 동네 유저 한 명이 다운받으면 그 동네 유저들 전부가 다 바로 사용할 수 있다.
따라서 데이터센터에 오는 트래픽을 많이 절감할 수 있게 된다.
출처
트위치 시스템 디자인