Site icon AppTractor

Как Netflix справляется с 260 миллионами одновременных потоков без буферизации

Несколько недель назад у меня Wi-Fi просел прямо посреди серии. Картинка стала мыльной примерно на десять секунд, а затем тихо снова стала чёткой. Без индикатора загрузки. Без остановки.

Этот маленький момент находится в конце длинной цепочки, и почти ни одна её часть не запускается в тот момент, когда вы нажимаете Play. В начале 2024 года Netflix превысил отметку в 260 миллионов домохозяйств с подпиской, а с тех пор вырос уже более чем до 300 миллионов. В один вечер ноября 2024 года 65 миллионов потоков одновременно смотрели один боксёрский матч.

То, как Netflix справляется с такой нагрузкой в 2026 году, в основном решается за часы до того, как запрос вообще покидает ваш дом. В этом вся суть, и это изменило мой взгляд на кэширование. Давайте разберёмся.

Почему очевидная архитектура разваливается

Архитектура, которую большинство из нас набросало бы первой, выглядит разумно: хранить видеофайлы в нескольких крупных дата-центрах, поставить перед ними коммерческую CDN и позволить кэшам наполняться по мере просмотра.

Но стоит посчитать — и всё быстро ломается.

65 миллионов потоков со средней скоростью около 5 Мбит/с дают более 300 Тбит/с. Ни один кластер централизованных серверов не протолкнёт такой объём через публичный интернет. Одни только расходы на транзит утопили бы проект, а пиринговые каналы захлебнулись бы задолго до того, как серверы достигли бы предела. Sandvine, компания, которая измеряет такие вещи, неоднократно показывала, что на Netflix приходится двузначная доля всего нисходящего интернет-трафика.

У кэша по запросу есть и более тихая проблема. Представьте премьеру. В полночь выходит новый сезон, а pull-through CDN ещё ничего о нём не хранит. Миллионы запросов приходят в одну и ту же минуту, каждый из них — промах кэша, и все они одновременно идут обратно к источнику.

То есть наивная архитектура сильнее всего буферизуется ровно в тот момент, когда смотрит больше всего людей. Netflix обошёл это, дважды перевернув задачу.

Первый механизм: фильм уже лежит у вас рядом

Netflix построил собственную CDN и назвал её Open Connect. Необычна здесь физическая часть. Компания бесплатно поставляет реальные серверы — Open Connect Appliances — в дата-центры интернет-провайдеров и точки обмена трафиком для тех провайдеров, которые соответствуют требованиям. По собственным опубликованным данным Netflix, к 2021 году эта инфраструктура превысила 17 000 серверов в 158 странах.

Провайдеры принимают эти серверы, потому что каждый байт, отданный внутри их собственной сети, — это байт, который им не нужно вести через платные транзитные каналы. Экономят обе стороны, поэтому такая схема и существует так долго.

Каждое устройство хранит ту часть каталога, которую с наибольшей вероятностью будут смотреть в конкретном регионе. И эти серверы заполняются заранее. Каждую ночь, в период низкой нагрузки, Netflix прогнозирует региональный спрос на следующий день и копирует нужные тайтлы на нужные устройства. Пятничная премьера уже лежит на сервере внутри здания вашего провайдера в четверг вечером.

Теперь представьте схему. Из вашей гостиной выходят две стрелки. Тонкая идёт далеко — в AWS, где Netflix запускает всё, кроме самого видео. Вход в аккаунт, просмотр каталога, рекомендации, DRM и сервис маршрутизации, который выбирает подходящее устройство, — всё это находится там. В ответ приходит небольшой манифест с URL.

Толстая стрелка — это видео. И оно проходит в лучшем случае несколько километров: от устройства, стоящего внутри сети вашего интернет-провайдера. По словам самого Netflix, фактически весь его видеотрафик идёт через Open Connect. Фильм не приходит из облака.

Это разделение сделано намеренно. Netflix завершил перенос всего в AWS ещё в 2016 году, но самую тяжёлую нагрузку решил оставить вне облака — на оборудовании, которое проектирует сам. Управляющая плоскость живёт там, где гибкость стоит дёшево. Плоскость данных живёт там, где находятся байты.

А что с наплывом зрителей на премьере? Он распределяется по тысячам уже прогретых кэшей, каждый из которых обслуживает свой район. Единого источника, который можно перегрузить, больше нет.

Второй механизм: телевизор пересогласовывает качество прямо во время просмотра

Предварительное размещение решает проблему интернета. Но оно ничего не делает с вашим домом. Перегруженный Wi-Fi, микроволновка, брат или сестра в рейтинговом матче — весь этот хаос остаётся на стороне клиента.

Каждый тайтл заранее кодируется в лестницу уровней качества: примерно от 235 Кбит/с внизу до около 15 Мбит/с для 4K. После работ Netflix над кодированием под конкретный тайтл такая лестница строится отдельно для каждого контента. Мультфильм с плоскими цветами требует гораздо меньше битов, чем зернистый экшен с ручной камерой, поэтому каждый получает собственную лестницу.

Видео режется на фрагменты длиной в несколько секунд. Плеер загружает фрагмент, измеряет реальную пропускную способность и смотрит, сколько секунд видео уже лежит в буфере. Затем он выбирает битрейт для следующего фрагмента. Исследование Netflix совместно со Stanford, опубликованное на SIGCOMM 2014, показало, что учёт буфера, а не только прогнозирование пропускной способности, резко снижает повторную буферизацию.

Поэтому воспроизведение начинается осторожно, за несколько секунд поднимает качество и снижает его до того, как буфер опустеет при просадке канала. Вы видите на мгновение более мягкую картинку вместо индикатора загрузки. Именно это и произошло с моим Wi-Fi в начале статьи. Система работала ровно так, как была спроектирована.

Есть и третий, менее заметный рычаг. Netflix уже много лет внедряет кодек AV1 на разных устройствах, потому что более эффективный кодек означает, что каждая ступень лестницы требует меньше битов. Та же картинка выживает на худшем соединении.

Если сложить два механизма вместе, общая форма становится понятной. Open Connect делает путь от сервера до вашего роутера коротким и незагруженным. Адаптивный плеер сглаживает всё, что остаётся на последних метрах. Один механизм убирает вариативность. Другой поглощает её остатки.

Запрос — это последний шаг, а не первый

Мы привыкли считать запрос началом работы. Приходит запрос — система отвечает.

Архитектура Netflix говорит обратное. К тому моменту, когда вы нажимаете Play, файл был выбран прошлой ночью, закодирован в собственную лестницу качества месяцы назад и скопирован на сервер рядом с вами ещё до того, как вы вернулись домой. Нажатие Play почти ничего не запускает: небольшой вызов программного интерфейса, манифест и короткая локальная передача.

Большая часть задачи потокового видео решается до того, как первый байт достигает вашей домашней сети. В таком масштабе реагировать на спрос уже слишком поздно.

Как это выглядит в масштабе в тысячу раз меньше

Вам не нужны 17 000 серверов, чтобы позаимствовать этот принцип. Перенесите работу на момент до запроса.

Шаблон каждый раз один и тот же: предскажите, заранее разместите, а затем позвольте клиенту адаптироваться к оставшемуся хаосу.

Размещайте контент ближе к краю сети до того, как появится спрос. Если вы реагируете на спрос, вы уже опоздали.

Источник

Exit mobile version