Netflix — Open Connect가 비디오를 전달하는 방식

애니메이션이 보여주는 것

밤에서 시작한다 — 신작이 per-title encoding으로 타이틀별 비트레이트 사다리가 되어 S3에 쌓이고, OCA들이 fill window에 manifest와의 delta를 peer fill → tier fill → cache fill 서열로 내려받는다. 그 다음 낮의 재생 경로: 클라이언트가 Playback Apps에서 인증·라이선싱을 받고, CODA가 CCS의 health·BGP·보유 파일 데이터로 순위 매긴 OCA URL 목록을 돌려주면, 이후 비디오 바이트는 AWS를 전혀 거치지 않고 OCA에서 직접 흐른다.

장애 국면이 이 설계의 백미다 — 서빙 중인 OCA가 죽어도 클라이언트는 AWS에 다시 묻지 않고, 이미 손에 든 목록의 다음 URL로 전환한다. 폴백 경로를 재생 시작 시점에 미리 배포해 둔 것이다.

왜 요청 시 캐싱이 아니라 밤에 미리 채우는가

일반 CDN은 카탈로그가 무한(전체 웹)이라 요청이 와야 무엇을 캐시할지 안다. Netflix는 반대 조건이다 — 카탈로그가 유한하고, 무엇이 언제 어디서 인기 있을지 시청 데이터로 꽤 정확히 예측된다. 그래서 트래픽이 한산한 밤에 미리 채워, 피크 시간대에 원본까지 거슬러 올라가는 상류 대역폭 수요를 자릿수 단위로 줄인다.

fill 서열(peer → tier → cache)도 같은 논리다. 같은 manifest cluster의 이웃 OCA에서 먼저 받고, 없으면 더 먼 OCA, 최후에만 S3로 간다 — 비싼 회선일수록 나중에 쓴다.

• peer fill: 같은 manifest cluster(같은 서브넷)의 이웃 OCA에서
• tier fill: 그 밖의 더 먼 OCA에서
• cache fill: 최후의 수단으로 S3(오리진)에서 직접

AWS가 다운되면 시청이 멈추나

재생 중인 스트림은 계속된다. 비디오는 OCA가 직접 서빙하고 있고, 클라이언트는 폴백용 OCA URL 목록까지 이미 갖고 있기 때문이다. 영향을 받는 건 '새 재생 시작' — 인증과 스티어링은 control plane의 일이라서다. 결정과 전달을 갈라 둔 분리가 장애 반경도 갈라 놓는다.

한 대의 OCA가 전체 카탈로그를 갖고 있지도 않다. storage appliance가 최대 약 120TB, global appliance는 최대 약 60TB라 인기 콘텐츠만 가까이 두고, 비인기 타이틀은 캐시 미스로 처리해 IXP의 더 큰 OCA 등 상위 계층에서 서빙한다. 어느 경로든 비디오는 100% Open Connect이며, 전 세계 Netflix 트래픽의 약 95%가 Open Connect와 ISP의 직접 연결로 흐른다.