동영상 스트리밍 설계 면접 퀴즈

동영상 서비스를 설계합니다. 올리는 문제는 파일 업로드에서 다뤘으므로, 여기서는 올라온 영상을 어떻게 보게 하는지를 봅니다.

만드는 값과 내려주는 값이 다르다

업로드는 하루 5만 개 (평균 10분)이고 시청은 하루 3억 회 (평균 8분 시청)입니다. 영상 하나를 만드는 값은 한 번만 내고, 내려주는 값은 볼 때마다 냅니다.

그래서 만들 때 일을 더 해서 내려줄 때를 값싸게 만드는 쪽으로 기웁니다. 여러 화질을 미리 만들어 두는 것도, 조각으로 잘라 두는 것도 그 판단입니다.

다만 무한정 그럴 수는 없습니다. 조회가 상위 1퍼센트 영상이 조회의 90퍼센트로 몰려 있어서, 거의 안 보는 영상에 만드는 값을 다 내면 그 값이 그대로 낭비가 됩니다. 이 상충이 뒤에서 한 절을 차지합니다.

통째로 내려주면 안 되는 이유

파일 하나를 그대로 주는 방식은 세 가지가 걸립니다.

첫 번째가 요구사항과 정면으로 부딪힙니다. 2초 안에 첫 화면을 보여줘야 하는데, 10분 영상을 다 받는 데 그보다 훨씬 오래 걸립니다.

그래서 영상을 조각으로 잘라 필요한 만큼만 받게 합니다. 이것이 이 아키타입의 골격입니다.

두 요구가 서로를 밀어낸다

2초 시작과 버퍼링 재생 시간의 1퍼센트 미만은 함께 두면 상충합니다.

시작을 빠르게 하려면 조금만 받고 재생을 시작해야 한다
끊기지 않으려면 넉넉히 받아 두어야 한다

이 둘을 어떻게 함께 지키는지가 뒤의 한 절입니다. 요구사항을 읽을 때 서로 밀어내는 쌍을 찾아 두면 어느 절이 어려울지 미리 알 수 있습니다.

다루지 않는 것

세 번째를 빼는 것이 중요합니다. 저장된 영상은 미리 만들어 둘 시간이 있고 실시간 방송은 없습니다. 이 차이가 인코딩과 전송의 모든 결정을 바꾸므로, 하나를 먼저 끝냅니다.

앞 절에서 조각으로 잘라 필요한 만큼만 받게 하기로 했습니다. 그 조각을 얼마로 자르고 어떻게 찾게 하는지가 이 절입니다.

조각과 목록 파일

영상을 몇 초 단위로 자릅니다. 그리고 어떤 조각이 어디 있는지 적은 목록 파일을 함께 둡니다. 재생하는 쪽은 목록을 먼저 받고 필요한 조각을 순서대로 받습니다.

목록에는 이런 것이 들어갑니다.

목록 파일이 있어야 탐색이 가능합니다. 사용자가 5분 지점으로 건너뛰면, 조각 길이로 나눠 몇 번째 조각인지 계산해 그것만 받습니다. 통째 파일에서는 이 계산을 할 수 없습니다.

조각 길이를 얼마로 하나

짧게 자를수록 유리한 것과 불리한 것이 갈립니다.

요청 수를 계산해 봐야 합니다. 8분을 2초로 자르면 조각이 240개이고, 시청 하루 3억 회 (평균 8분 시청)에 곱하면 하루 수백억 건의 조각 요청입니다. 조각을 짧게 하는 결정은 요청 수를 그만큼 늘리는 결정입니다.

그래서 흔히 중간을 고릅니다. 시작 부분만 짧은 조각으로 두고 뒤는 길게 두는 방법도 있습니다. 시작이 급한 것은 앞부분뿐입니다.

조각은 스스로 재생 가능해야 한다

영상 압축은 앞 화면과의 차이만 기록하는 방식을 씁니다. 그래서 아무 지점에서 잘라 버리면 그 조각만으로는 화면을 만들 수 없습니다.

조각의 첫 화면은 앞을 참조하지 않는 완전한 화면이어야 한다

이 제약이 두 가지를 강제합니다. 첫째, 조각 경계를 아무 데나 둘 수 없습니다. 둘째, 완전한 화면을 자주 넣어야 하므로 조각을 짧게 하면 파일 크기가 커집니다. 조각 길이 결정에 압축 효율이 걸리는 이유입니다.

목록을 어떻게 내려주나

목록 파일은 작고 모든 시청자에게 같습니다. 조각도 같습니다. 둘 다 사람마다 다르게 만들지 않는 것이 중요합니다.

주소가 사람마다 다르면 엣지가 같은 조각을 사람 수만큼 따로 저장합니다. 적중률이 무너지고, 그것이 곧 비용입니다. 접근 제어는 주소가 아닌 다른 방법으로 하며 뒤에서 다룹니다.

화질 5단계를 미리 만들어 둡니다. 그러면 시청자에게 어느 것을 줄지 정해야 하는데, 그 결정을 서버가 하면 안 됩니다.

판단은 받는 쪽이 한다

서버는 시청자의 네트워크 상태를 모릅니다. 알 수 있는 것은 조금 전에 보낸 것이 얼마나 빨리 갔는지인데, 그것도 서버 쪽에서 보는 값입니다.

받는 쪽은 자기가 실제로 얼마나 빨리 받았는지와 버퍼가 얼마나 남았는지를 압니다. 그래서 다음 조각의 화질을 받는 쪽이 고릅니다.

서버가 무상태가 됩니다. 조각 요청은 그냥 파일 요청이고, 누가 어떤 화질을 보고 있는지 기억할 필요가 없습니다. 이것이 엣지에서 그대로 캐시될 수 있는 이유이기도 합니다.

무엇을 보고 고르나

두 신호를 함께 봅니다.

속도만 보면 잘못 판단합니다. 속도가 좋아 보여도 버퍼가 거의 비었으면 높은 화질을 시도할 여유가 없습니다. 반대로 버퍼가 넉넉하면 조금 무리해도 됩니다.

그리고 올릴 때와 내릴 때가 대칭이 아닙니다.

내릴 때는 빠르게 내린다. 끊기는 것을 막아야 한다
올릴 때는 천천히 올린다. 올렸다가 다시 내리면 더 나쁘다

화질이 계속 오르내리면 더 나쁘다

전환 판단을 민감하게 만들면 화질이 자주 바뀝니다. 시청자에게는 한 단계 낮은 화질로 안정된 것보다 나쁩니다. 화면이 계속 흐려지고 선명해지는 것은 눈에 띕니다.

그래서 전환에 여유를 둡니다. 올릴 기준과 내릴 기준을 다르게 두어, 경계 근처에서 왕복하지 않게 합니다. 한 번 바꾼 뒤에는 잠시 유지합니다.

화질 목록에 무엇을 넣나

5단계를 어떻게 벌려 놓을지도 결정입니다.

그리고 가장 낮은 화질은 아주 느린 네트워크에서도 끊기지 않을 만큼 낮아야 합니다. 그것이 마지막 방어선입니다. 가장 낮은 것으로도 못 받으면 재생이 멈춥니다.