요구사항과 재생이라는 문제

만들 때 일을 더 해서 내려줄 때를 값싸게 만드는 쪽으로 기웁니다.

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

여러 화질을 미리 만들어 두는 것도, 조각으로 잘라 두는 것도 그 판단에서 나옵니다.

흔한 실수: 이 원칙을 끝까지 밀어붙이는 것. 조회가 상위 1퍼센트 영상이 조회의 90퍼센트로 몰려 있어서 거의 안 보는 영상에 만드는 값을 다 내면 낭비가 됩니다. 원칙과 그 예외를 함께 알고 있어야 합니다.

시작이 늦고, 버린 것이 많고, 화질을 바꿀 수 없습니다.

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

흔한 실수: 파일 앞부분부터 받아 재생하면 된다고 답하는 것. 그것만으로는 화질을 바꿀 수 없고, 중간으로 건너뛸 때 어디를 요청해야 하는지도 알 수 없습니다.

어느 절이 어려울지 미리 압니다.

2초 시작과 버퍼링 재생 시간의 1퍼센트 미만이 그 쌍입니다.

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

하나를 만족하면 다른 하나가 나빠집니다. 이런 쌍은 설계에서 절충이 필요한 지점이므로 따로 다뤄야 합니다.

흔한 실수: 두 요구를 각각 만족시키려는 것. 그러면 나중에 한쪽을 고칠 때마다 다른 쪽이 나빠지는 순환에 들어갑니다. 상충을 먼저 인정하고 함께 다루는 방법을 찾아야 합니다.

미리 만들어 둘 시간이 있는지가 다르기 때문입니다.

저장된 영상은 올린 뒤 여유가 있어서 여러 화질을 미리 만들 수 있습니다. 실시간 방송은 지금 들어오는 것을 지금 내보내야 합니다.

이 차이가 인코딩과 전송의 모든 결정을 바꿉니다. 화질을 몇 개 만들지, 조각을 얼마로 자를지, 버퍼를 얼마나 둘지가 전부 달라집니다.

흔한 실수: 둘을 한 설계로 덮으려는 것. 공통 부분이 있어 보이지만 제약이 다르면 결론이 달라집니다. 하나를 끝낸 뒤 그 결정들을 다시 검토하는 편이 낫습니다.