--- title: Алекс Сюй, «System Design. Подготовка к сложному интервью» (Vol. 1, рус. изд.) — глава 14: Проектирование YouTube source: materials/System Design. Подготовка к сложному интервью.pdf, стр. 244–272 конспект: TASK-45.38, извлечено pymupdf 2026-09-17; ниже полный «грязный» текст главы + выжимка статус: выжимка и перенос в knowledge-base.md / methodology.md / classic-designs.md — см. _map.md --- # Глава 14. Проектирование YouTube ## Выжимка Стриминг: загрузка и воспроизведение; всё, кроме видео-потока, — через API-серверы; **видео из CDN**, метаданные в БД/кэше отдельно от файлов. Оценки (5 млн DAU): 150 ТБ/день новых видео; CDN $0.02/ГБ → **$150k/день** — главный операционный расход. **Загрузка (две параллельные ветки)**: (А) файл → хранилище исходников (BLOB) → транскодеры → версии (разрешения/кодеки) → хранилище + CDN; событие «перекодирование завершено» → очередь завершения → обработчик завершения → обновление БД/кэша метаданных → «готово к просмотру». (Б) метаданные (название, размер, формат) — обычный API-вызов. **Стриминг**: потоковые протоколы (MPEG-DASH, Apple HLS, Smooth Streaming) — стандартизированные способы отдачи; разные кодеки и плееры. Контейнер (видео+звук+метаданные) + кодеки (H.264, VP9, HEVC). Знать названия не обязательно, понимать суть — да. **Транскодирование как DAG-пайплайн** (модель Facebook): препроцессор (разбивка на **GOP** — независимо воспроизводимые блоки кадров; генерация DAG из конфигов; кэш сегментов во временное хранилище для ретраев) → планировщик DAG (этапы, параллельные ветки: видео/звук/миниатюра/водяной знак) → диспетчер ресурсов (очередь заданий + очередь воркеров + очередь выполнения + планировщик) → специализированные воркеры → временное хранилище (после обработки удаляется) → закодированное видео. **Оптимизации**: загрузка GOP-блоками параллельно (быстрее + resume), центры загрузки рядом с пользователем (CDN в обе стороны), **очереди между этапами** пайплайна (распараллеливание, слабая связанность). **Отказоустойчивость**: resumable upload, докачка, ретраи этапов. **Безопасность**: pre-signed URL для загрузки, валидация, шифрование. **Снижение расходов**: популярное — в CDN, long tail — из хранилища; региональные CDN. Перенос: classic-designs §4 (сверка), KB §14.9 (DAG-пайплайн, GOP, CDN-стоимость). ## Полный текст (грязная выгрузка) 14 ПРОЕКТИРОВАНИЕ YOUTUBE В этой главе вам предложено спроектировать YouTube. У этой задачи есть и другие разновидности, например: «Спроектируйте платформу для об­ мена видео, такую как Netflix или Hulu», но ко всем им можно применить одно и то же решение. На рис. 14.1 показана главная страница YouTube. Рис. 14.1 YouTube выглядит просто: автор контента загружает видеофайлы, а зрите­ ли их воспроизводят одним щелчком мыши. Но эта простота обманчива. За ней скрывается множество сложных технологий. Ниже перечислена интересная статистика и неочевидные факты о YouTube в 2020 году [1] [2]. Общее количество активных пользователей в месяц: 2 миллиарда. Количество видеороликов, просматриваемых ежедневно: 5 мил­ лиардов. 73 % взрослых людей в США используют YouTube. Проектирование YouTube      245 На YouTube насчитывается 50 миллионов авторов. За полный 2019 год доход от рекламы на YouTube составил 15,1 мил­ лиарда долларов, что на 36 % больше, чем в 2018 году. На YouTube приходится 37 % всего мобильного трафика в интер­ нете. Веб-сайт YouTube доступен на 80 языках. Судя по этим цифрам, YouTube — огромная глобальная система, которая приносит много денег. ШАГ 1: ПОНЯТЬ ЗАДАЧУ И ОПРЕДЕЛИТЬ МАСШТАБ РЕШЕНИЯ Как видно на рис. 14.1, помимо просмотра видео YouTube поддерживает много других функций. Например, под видео можно оставить коммента­ рий, им можно поделиться с друзьями или поставить ему лайк; вы также можете сохранить его в список воспроизведения, подписаться на канал и т. д. Все это невозможно спроектировать за 45- или 60-минутное ин­ тервью. Поэтому важно определиться с тем, что именно от вас требуется. Кандидат: «Какие возможности самые важные?» Интервьюер: «Возможность загружать и просматривать видео». Кандидат: «Какие клиенты должны поддерживаться?» Интервьюер: «Мобильные приложения, веб-браузеры и Smart TV». Кандидат: «Сколько у нас ежедневных активных пользователей?» Интервьюер: «5 миллионов». Кандидат: «Сколько времени в среднем уходит на использование этого продукта в день?» Интервьюер: «30 минут». Кандидат: «Нужно ли нам поддерживать пользователей из других стран?» Интервьюер: «Да, существенная часть аудитории находится за ру­ бежом». Кандидат: «Какие разрешения видео должны поддерживаться?» 246      ГЛАВА 14 Интервьюер: «Система совместима с большинством разрешений и видеоформатов». Кандидат: «Требуется ли шифрование?» Интервьюер: «Да». Кандидат: «Есть ли какие-либо требования к размеру видео?» Интервьюер: «Наша платформа нацелена на видео небольшого и сред­ него размера. Максимальный размер видеофайла составляет 1 Гб». Кандидат: «Можем ли мы пользоваться существующей облачной инфраструктурой, которую предоставляют Amazon, Google или Microsoft?» Интервьюер: «Это очень хороший вопрос. Для большинства компа­ ний создание всего с нуля было бы нереалистичным. Рекомендуется задействовать некоторые из существующих облачных сервисов». В этой главе мы сосредоточимся на проектировании сервиса стриминго­ вого видео со следующими возможностями: быстрая загрузка видеофайлов; бесперебойное вещание; возможность изменять качество видео; недорогая инфраструктура; высокие доступность, масштабируемость и надежность; поддерживаемые клиенты: мобильные приложения, веб-браузер и Smart TV. Приблизительные оценки Следующие оценки основаны на множестве предположений, поэтому вы должны убедиться в том, что вы с интервьюером поняли друг друга. Предположим, что у продукта 5 миллионов активных пользовате­ лей в день (DAU). Пользователи ежедневно просматривают по 5 видеороликов. 10 % пользователей загружают по 1 ролику в день. Проектирование YouTube      247 Пусть средний размер видео составляет 300 Мб. Общий объем данных, которые нужно сохранять ежедневно: 5 мил­ лионов * 10 % * 300 Мб = 150 Тб. Стоимость CDN: Š Š когда облачная сеть CDN раздает видео, вы платите за трафик, исходящий из CDN; Š Š для оценки расходов возьмем CDN CloudFront от Amazon (рис. 14.2) [2]. Предположим, что весь трафик раздается из США. Средняя цена за гигабайт составляет 0,02 доллара. Для простоты будем учитывать только стоимость видеовещания; Š Š 5 миллионов * 5 видео * 0,3 Гб * 0,02 доллара = 150 000 долларов в день. Исходя из этих приблизительных оценок, раздача видео из CDN будет стоить довольно дорого. Даже несмотря на то что облачные провайдеры с готовностью делают скидки для крупных клиентов, расходы будут значительными. О том, как их снизить, мы поговорим в разделе, посвя­ щенном подробному проектированию. Рис. 14.2 ШАГ 2: ПРЕДЛОЖИТЬ ОБЩЕЕ РЕШЕНИЕ И ПОЛУЧИТЬ СОГЛАСИЕ Как уже обсуждалось, интервьюер посоветовал использовать существу­ ющие облачные сервисы вместо того, чтобы разрабатывать все с нуля. Так что мы задействуем CDN и хранилище больших двоичных объектов 248      ГЛАВА 14 (binary large objects, BLOBs). Некоторые читатели могут задуматься, почему мы не будем создавать все это самостоятельно. Причины таковы: Интервью по проектированию ИТ-систем не посвящены созданию всего с нуля. Выбрать подходящие технологии за отведенный пе­ риод времени важнее, чем объяснить, как они работают. Например, на интервью достаточно упомянуть, что для хранения исходных видеофайлов будет использоваться хранилище BLOB-объектов. Подробное обсуждение того, как это хранилище устроено, было бы излишним. Разработка масштабируемого хранилища BLOB-объектов или CDN чрезвычайно сложная и дорогая. Даже такие крупные компании, как Netflix или Facebook, не разрабатывают все сами. Netflix ис­ пользует облачные сервисы Amazon [4], а Facebook применяет CDN от Akamai [5]. В целом наша система состоит из трех компонентов (рис. 14.3). Серверы API все остальное CDN Клиент стриминг видео Рис. 14.3 Клиент. Вы можете смотреть YouTube на своем компьютере, мо­ бильном телефоне или Smart TV. CDN. Видеоролики хранятся в CDN. Когда вы нажимаете кнопку «Смотреть», CDN возвращает стрим. Проектирование YouTube      249 Серверы API. Все, что не относится к стримингу, проходит через серверы API. Это касается ленты рекомендаций, генерации URL- адреса для загруженного видео, обновления БД кэша с метаданны­ ми, регистрации пользователей и т. д. Во время нашего диалога интервьюер проявил интерес к следующим двум процессам: загрузка видео; стриминг видео. Мы обсудим общие аспекты каждого из них. Процесс загрузки видео На рис. 14.4 показана общая схема загрузки видео. Он состоит из следующих компонентов. Пользователь. Смотрит YouTube на таких устройствах, как компью­ тер, мобильный телефон или Smart TV. Балансировщик нагрузки. Равномерно распределяет запросы между серверами API. Серверы API. Все пользовательские запросы, за исключением по­ токовой передачи видео, проходят через серверы API. БД метаданных. Метаданные видеофайлов хранятся в отдельной разделяемой БД. Она реплицируется, чтобы отвечать требованиям к производительности и высокой доступности. Кэш метаданных. Для улучшения производительности метаданные видеофайлов и пользовательских объектов кэшируются. Хранилище исходного видео. Оригинальные видеофайлы разме­ щаются в системе хранения BLOB-объектов. Вот что говорится в статье о хранилище BLOB-объектов в Википедии: «Двоичный большой объект (Binary Large Object, BLOB) — это набор двоичных данных, которые хранятся в СУБД как единое целое» [6]. Серверы перекодирования. Перекодирование видео — это процесс преобразования видеофайла из одного формата в другой (MPEG, 250      ГЛАВА 14 HLS и т. д.) с целью предоставления оптимальных видеопотоков для разных устройств и типов сетевых соединений. Хранилище перекодированного видео. Это хранилище BLOB- объектов для перекодированных видеофайлов. Балансировщик нагрузки Пользователь Хранилище исходного видео Хранилище перекодирован- ного видео CDN Кэш мета- данных Серверы перекодирования Серверы API Очередь завершения перекодирование завершено Обработчик завершения БД мета- данных КЭШ КЭШ КЭШ Рис. 14.4 Проектирование YouTube      251 CDN. Видеофайлы кэшируются в CDN. Когда вы нажимаете кноп­ ку «Смотреть», CDN возвращает видеопоток. Очередь завершения. Это очередь сообщений, хранящая информа­ цию о завершении перекодирования видео. Обработчик завершения. Этот компонент состоит из списка ра­ бочих узлов, которые извлекают события из очереди завершения и обновляют кэш и БД с метаданными. Итак, мы разобрали каждый отдельный компонент. Теперь давайте по­ смотрим, как работает процесс загрузки видео. Он состоит из двух про­ цедур, которые выполняются параллельно. А.  Загрузка видеофайла. Б.  Обновление метаданных видеофайла. Метаданные содержат сведе­ ния о URL-адресе, размере, разрешении и формате видео, а также информацию о пользователе и т. д. Процедура А: загрузка видео На рис. 14.5 показано, как загружается видеофайл. Ниже представлено описание этого процесса: 1. Видеофайлы загружаются в хранилище исходного видео. 2. Серверы перекодирования извлекают видеофайлы из хранилища исходного видео и начинают их перекодировать. 3. По завершении перекодирования следующие два задания выпол­ няются параллельно: 3а. Перекодированные видеофайлы записываются в хранилище перекодированного видео. 3б. События о завершении перекодирования записываются в оче­ редь завершения. 3a.1. Перекодированное видео передается в CDN. 3б.1. Обработчик завершения содержит группу рабочих узлов, которые непрерывно достают события из очереди. 3б.1.a. и 3б.1.б. По окончании перекодирования видео обработчик завершения обновляет БД и кэш метаданных. 252      ГЛАВА 14 Балансировщик нагрузки Хранилище исходного видео Хранилище перекодирован- ного видео CDN Кэш метаданных Серверы перекодирования Серверы API Очередь завершения перекодирование завершено Обработчик завершения 1 3б.1б 3б.1a 4 3б.1 3a.1 3a 2 3б БД метаданных Пользователь КЭШ КЭШ КЭШ Рис. 14.5 4. Серверы API сообщают клиенту о том, что видео успешно загру­ жено и готово для стриминга. Процедура Б: обновление метаданных Пока файл загружается в хранилище исходного видео, клиент отправляет запрос на обновление его метаданных, как показано на рис. 14.6. Этот запрос содержит такие сведения, как название видеофайла, его размер, формат и т. д. Серверы API обновляют кэш и БД метаданных. Проектирование YouTube      253 Балансировщик нагрузки Обновление метаданных Серверы API Кэш метаданных БД метаданных Пользователь КЭШ КЭШ КЭШ Рис. 14.6 Стриминг видео Обычно, когда вы открываете видео на YouTube, оно сразу же начинает воспроизводиться, и вам не нужно ждать окончания его загрузки. Загруз­ ка — это когда весь видеофайл копируется на ваше устройство, а стриминг подразумевает, что ваше устройство получает непрерывный видеопоток из удаленного источника. При просмотре потокового видео ваш клиент загружает данные постепенно, чтобы воспроизведение начиналось сразу и продолжалось беспрерывно. Прежде чем обсуждать процесс стриминга видео, давайте рассмотрим такое важное понятие, как протокол стриминга. Это стандартизирован­ ный способ управления стримингом видеоданных. Существуют такие популярные протоколы: 254      ГЛАВА 14 MPEG–DASH. MPEG расшифровывается как Moving Picture Experts Group («экспертная группа по движущимся изображе­ ниям»), а DASH — как Dynamic Adaptive Streaming over HTTP («динамический адаптивный стриминг по HTTP»). Apple HLS. HLS расшифровывается как HTTP Live Streaming («стриминг по HTTP в реальном времени»). Microsoft Smooth Streaming. Adobe HTTP Dynamic Streaming (HDS). Вам не нужно досконально разбираться в этих протоколах или даже помнить их названия, так как это низкоуровневые детали, требующие знания определенной предметной области. Но важно понимать, что разные стриминговые протоколы поддерживают разные форматы коди­ рования видео и доступны в разных видеоплеерах. При проектировании сервиса видеовещания необходимо выбрать протокол, подходящий для наших задач. Больше о протоколах потоковой передачи можно узнать в замечательной статье [7]. Видеопоток поступает напрямую из CDN. Его доставляет ближайший к вам пограничный сервер. Благодаря этому латентность получается очень низкой. На рис. 14.7 показана общая схема стриминга видео. CDN стриминг видео Клиент Рис. 14.7 Проектирование YouTube      255 ШАГ 3: ПОДРОБНОЕ ПРОЕКТИРОВАНИЕ При описании общей архитектуры мы разбили систему на две части: про­ цесс загрузки видео и процесс его стриминга. В этом разделе мы улучшим оба эти процесса с помощью важных оптимизаций и добавим механизм обработки ошибок. Перекодирование видео Когда вы записываете видео, ваше устройство (обычно телефон или каме­ ра) сохраняет видеофайл в определенном формате. Если вы хотите, чтобы видео как следует воспроизводилось на других устройствах, его битрейт и формат должны быть совместимы. Битрейт — это скорость, с которой обрабатываются биты; обычно чем он выше, тем лучше качество видео. Потоки с высоким битрейтом требуют больше вычислительных ресурсов и более быстрое интернет-соединение. Перекодирование видео имеет большое значение по следующим при­ чинам. Необработанное видео имеет большой размер. Часовое видео вы­ сокого разрешения с частотой 60 кадров в секунду может занимать до нескольких сотен гигабайт. Многие устройства и браузеры поддерживают только определен­ ные форматы видео. Поэтому видео должно быть перекодировано в разные форматы. Чтобы обеспечить высокое качество и плавность воспроизведения, выбор разрешения видео следует делать с учетом скорости сетевого соединения пользователя. Качество сетевого соединения может меняться, особенно на мо­ бильных устройствах. Чтобы обеспечить непрерывное воспроизве­ дение видео, следует автоматически или вручную переключаться на поток с подходящим битрейтом в зависимости от пропускной способности сети. Это крайне важно для качественного взаимодей­ ствия с пользователем. Существует множество форматов кодирования, но большинство из них состоят из двух частей. 256      ГЛАВА 14 Контейнер. Содержит видеофайл, звуковую дорожку и метадан­ ные. Кодеки. Это алгоритмы сжатия и распаковки, предназначенные для уменьшения размера видео с сохранением его качества. Са­ мыми распространенными видеокодеками являются H.264, VP9 и HEVC. Модель направленного ациклического графа На перекодирование видео уходит много ресурсов и времени. К тому же требования к перекодированию могут зависеть от автора видео. Напри­ мер, некоторым авторам нужно, чтобы поверх видео выводились водяные знаки, прочие сами предоставляют миниатюрные изображения; одни загружают видео в высоком разрешении, а другие нет. Для поддержки разных процедур обработки и обеспечения высокой сте­ пени распараллеливания необходимо добавить некий слой абстракции и позволить разработчикам клиентов самим выбирать, какие задания должны выполняться. Например, система потокового вещания видео в Facebook использует модель программирования на основе направленно­ го ациклического графа (directed acyclic graph, DAG), которая разбивает задания на этапы с возможностью последовательного или параллельного выполнения [8]. В нашей архитектуре применяется похожая модель, по­ зволяющая добиться гибкости и распараллелить вычисления. На рис. 14.8 показан DAG для перекодирования видео. На рис. 14.8 исходный видеофайл разделяется на видео, звук и метадан­ ные. Вот некоторые задания, которые можно применить к видеофайлу. Анализ. Следует убедиться в том, что видео не повреждено и имеет хорошее качество. Кодирование видео. Это делается для поддержки разных раз­ решений, кодеков, битрейтов и пр. На рис. 14.9 показан пример закодированных файлов. Миниатюрное изображение. Миниатюры могут быть загружены пользователем или автоматически сгенерированы системой. Водяной знак. Изображение, наносимое поверх видео и содержащее информацию, которая его идентифицирует. Проектирование YouTube      257 Исходное видео Звук Метаданные Видео Кодирование звука Сборка Миниатюрное изображение Водяной знак ... Задания Перекодирование видео Анализ Рис. 14.8 Кодирование видео 360p.mp4 480p.mp4 720p.mp4 4k.mp4 1080p.mp4 Рис. 14.9 258      ГЛАВА 14 Архитектура перекодирования видео На рис. 14.10 показана предложенная нами архитектура перекодирования видео, которая использует облачные сервисы. Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.10 Представленная архитектура состоит из шести основных элементов: пре­ процессора, планировщика DAG, диспетчера ресурсов, рабочих узлов, временного хранилища и закодированного видео в качестве вывода. Давайте подробно рассмотрим каждый из них. Препроцессор Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.11 На препроцессор возложено четыре обязанности: 1. Разделение видео. Видеопоток делится на части или более мелкие группы кадров (Group of Pictures, GOP). GOP — это группа или Проектирование YouTube      259 блок кадров, размещенных в определенном порядке. Каждый блок является независимо воспроизводимой единицей, обычно длиной в несколько секунд. 2. Некоторые старые мобильные устройства и браузеры могут не поддерживать разделение видео на части. Специально для них препроцессор делит видеофайл на GOP. 3. Генерация DAG. Препроцессор генерирует DAG на основе конфи­ гурационных файлов, предоставленных разработчиками клиента. На рис. 14.12 изображено упрощенное представление DAG с двумя узлами и одним ребром: Загрузка Перекодирование Рис. 14.12 Это представление DAG сгенерировано из двух конфигурационных файлов, показанных на рис. 14.13. Рис. 14.13 (источник: [9]) 4. Кэширование данных. Препроцессор служит кэшем для сегменти­ рованных видеофайлов. Для повышения надежности он записывает GOP и метаданные во временное хранилище. Если кодирование завершится неудачно, система сможет воспользоваться сохранен­ ными данными для повторного выполнения операций. 260      ГЛАВА 14 Планировщик DAG Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.14 Планировщик DAG делит задания в графе на этапы и записывает их в очередь заданий, принадлежащую диспетчеру ресурсов. На рис. 14.15 показан пример того, как работает планировщик DAG. Планировщик DAG Кодирование звука Исходное видео Звук Видео Метаданные Миниатюрное изображение Кодирование видео Этап 1 Этап 2 Рис. 14.15 Как видно на рис. 14.15, исходный видеофайл проходит три этапа об­ работки. На этапе 1 он делится на видео, звук и метаданные. На этапе 2 выполняется два процесса: кодирование видео и генерация миниатюры. В рамках этого этапа также происходит кодирование аудиофайла. Проектирование YouTube      261 Диспетчер ресурсов Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.16 Диспетчер ресурсов следит за тем, чтобы ресурсы выделялись эффектив­ но. Как показано на рис. 14.17, он содержит три очереди и планировщик заданий. Очередь заданий. Это приоритетная очередь заданий, которые нужно выполнить. Очередь рабочих узлов. Это приоритетная очередь, содержащая информацию о загруженности рабочих узлов. Очередь выполнения. Содержит информацию о заданиях, вы­ полняющихся в настоящий момент, и рабочих узлах, которые их выполняют. Планировщик заданий. Он выбирает оптимальный рабочий узел и поручает ему выполнить подходящее задание. Кодиров- щик Водяной знак Слияние Миниа- тюра Рабочие узлы ... Очередь рабочих узлов Очередь выполнения Диспетчер ресурсов Планировщик заданий получение задания с наивысшим приоритетом выбор оптимального рабочего узла Очередь заданий выполнение задания помещение задания и рабочего узла в очередь Рис. 14.17 262      ГЛАВА 14 Диспетчер ресурсов работает следующим образом: получает задание с наивысшим приоритетом из соответствующей очереди; выбирает из очереди оптимальный рабочий узел для выполнения полученного задания; поручает выбранному рабочему узлу выполнить задание; связывает между собой информацию о задании и рабочем узле и записывает ее в очередь выполнения; удаляет задание из очереди выполнения, как только оно завершилось. Рабочие узлы Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.18 Рабочие узлы выполняют задания, перечисленные в DAG. Разные узлы могут быть предназначены для разных заданий (рис. 14.19). Кодировщик Водяной знак Слияние Миниатюра Рабочие узлы ... Рис. 14.19 Проектирование YouTube      263 Временное хранилище Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.20 Здесь используется несколько систем хранения данных. Выбор той или иной системы зависит от таких факторов, как тип, размер и время жизни данных, частота доступа к ним и т. д. Например, метаданные часто нужны рабочим узлам и обычно имеют небольшой размер, по­ этому их целесообразно кэшировать в памяти. Видео- и аудиоданные за­писываются в хранилище BLOB-объектов. После завершения об­ работки видео соответствующие данные удаляются из временного хранилища. Закодированное видео Препроцессор Закодированное видео Планиров- щик DAG Диспетчер ресурсов Рабочие узлы Временное хранилище Рис. 14.21 Закодированное видео является конечным результатом процесса коди­ рования. Оно может иметь вид файла с именем наподобие funny_720p.mp4. 264      ГЛАВА 14 Оптимизация системы На этом этапе у вас уже должно быть четкое представление о процессах загрузки, стриминга и перекодирования видео. Теперь мы оптимизируем некоторые аспекты системы, включая ее скорость, безопасность и стои­ мость обслуживания. Оптимизация скорости: распараллеливание загрузки видео Загружать видео как единое целое неэффективно. Мы можем разделить его на мелкие блоки, выровненные по GOP, как показано на рис. 14.22. GOP 1 Исходное видео разделение с выравниванием по GOP GOP 2 GOP N ... Рис. 14.22 Это сделает процесс загрузки быстрым и позволит его возобновить, если что-то пойдет не так. Разделение видеофайла на GOP можно выполнить на стороне клиента, чтобы ускорить загрузку (рис. 14.23). Клиент Хранилище исходного видео GOP2 GOP1 GOP3 Рис. 14.23 Оптимизация скорости: размещение центров загрузки поблизости от пользователя Загрузку также можно ускорить за счет нескольких центров обработки данных, разбросанных по всему миру (рис. 14.24). Жители США могут загружать видео в североамериканский ЦОД, а жители Китая — в азиат­ ский. Для этого в качестве центров загрузки мы будем использовать CDN. Оптимизация скорости: повсеместное распараллеливание Обеспечить низкую латентность непросто. Еще один способ оптимиза­ ции состоит в разработке слабосвязанной системы с высокой степенью параллелизма. Проектирование YouTube      265 Североамериканский центр загрузки Азиатский центр загрузки Южноамериканский центр загрузки Европейский центр загрузки Рис. 14.24 Чтобы как следует распараллелить нашу архитектуру, в нее необходимо внести некоторые изменения. Давайте взглянем на то, как данные пере­ даются из хранилища исходного видео в CDN. Этот процесс показан на рис. 14.25. Как видите, его результат зависит от ввода на предыдущем этапе. Эта зависимость затрудняет распараллеливание. Хранилище исходного видео скачивание исход- ного сегментиро- ванного видео исходное сегмен- тированное видео закодированное видео Модуль скачивания Модуль кодиро- вания Хранилище закодирован- ного видео CDN загрузка закоди- рованного видео загрузка закоди- рованного видео Модуль загрузки закодированное видео Рис. 14.25 266      ГЛАВА 14 Для ослабления связанности системы мы добавили очереди сообщений, как показано на рис. 14.26. Чтобы объяснить, как очереди сообщений ослабляют связанность системы, рассмотрим пример. Когда очереди сообщений не было, модулю кодирования приходи­ лось ждать возвращения вывода от модуля скачивания. После добавления очереди сообщений модулю кодирования больше не нужно ждать, пока модуль скачивания вернет вывод. Если в оче­ реди сообщения находятся события, модуль кодирования может выполнить соответствующие задания параллельно. Хранилище исходного видео Хранилище закодированного видео CDN Модуль скачивания Модуль загрузки загрузка закоди- рованного видео Очередь сообщений Модуль кодирования Очередь сообщений Очередь сообщений Очередь сообщений Рис. 14.26 Оптимизация безопасности: предварительно подписанный URL-адрес загрузки Безопасность — один из важнейших аспектов любого продукта. Чтобы гарантировать, что видео загружается туда, куда нужно, и теми, кому это позволено, мы вводим понятие предварительно подписанного URL- адреса, как показано на рис. 14.27. Проектирование YouTube      267 Серверы API 1. POST /upload 3. Загрузка видео Хранилище исходного видео Пользователь 2. Предварительно подписанный URL-адрес Рис. 14.27 Обновленный процесс загрузки выглядит так: 1. Клиент отправляет HTTP-запрос серверам API, чтобы получить предварительно подписанный URL-адрес, который дает доступ к соответствующему объекту. Термин «предварительно подписан­ ный URL-адрес» встречается при загрузке файлов в Amazon S3. Другие облачные провайдеры могут называть этот механизм ина­ че. Например, хранилище BLOB-объектов в Microsoft Azure под­ держивает ту же возможность, но называет ее подписью общего доступа [10]. 2. Серверы API возвращают предварительно подписанный URL- адрес. 3. Получив ответ, клиент загружает видео с его помощью. Оптимизация безопасности: защита видеороликов Многие производители контента с неохотой публикуют свои видео в интернете, опасаясь, что их оригинальная работа будет похищена. Для защиты авторских прав можно внедрить один из следующих ме­ ханизмов. 268      ГЛАВА 14 Технические средства защиты авторских прав (digital rights management, DRM). Три крупнейшие системы DRM — Apple FairPlay, Google Widevine и Microsoft PlayReady. Шифрование AES. Вы можете зашифровать видео и настроить политику авторизации. Зашифрованные видео будут расшифро­ вываться во время воспроизведения. Это гарантирует, что их будут просматривать только авторизованные пользователи. Водяные знаки. Это изображение, которое наносится поверх видео и содержит информацию, позволяющую его идентифицировать. Это может быть логотип или название компании. Оптимизация стоимости обслуживания Сеть CDN — неотъемлемый компонент нашей системы. Она обеспечивает быструю доставку видео в глобальных масштабах. Но, как показывают наши приблизительные оценки, CDN стоит дорого, особенно если данных много. Как можно снизить расходы? Согласно проведенному ранее исследованию, видеопотоки в YouTube распределяются по принципу «длинного хвоста» [11] [12]. Это означает, что большое количество просмотров приходится на горстку популярных видеороликов, тогда как многие другие видео просматриваются редко или вообще никогда не просматриваются. Исходя из этого наблюдения, можно внести несколько оптимизаций: 1. Только самые популярные видеоролики раздаются из CDN, а все остальные доступны на серверах хранения видеофайлов большой емкости (рис. 14.28). 2. Если контент не очень популярный, нам, возможно, не придется хранить множество его закодированных версий. Короткие видео­ ролики могут кодироваться по требованию. 3. Некоторые видео пользуются популярностью только в опреде­ ленных регионах. Их не нужно распространять за пределами этих регионов. 4. Можно создать собственную сеть CDN, как это сделала компания Netflix, и наладить партнерство с интернет-провайдерами. По­ строение CDN — это масштабный проект, но для крупных ком­ Проектирование YouTube      269 паний, занимающихся стримингом видео, такой вариант может подойти. Интернет-провайдеры, такие как Comcast, AT&T или Verizon, предоставляют свои услуги по всему миру и находятся близко к пользователям. Партнерство с ними может улучшить качество воспроизведения и снизить денежные расходы на се­ тевой трафик. CDN Видеосерверы самые популярные видео другие видео Пользователь Рис. 14.28 Все эти оптимизации основаны на популярности контента, его размере, на том, как к нему обращаются пользователи, и т. д. Прежде чем что-либо оптимизировать, необходимо исследовать тенденции и закономерности в сфере видео. Вот несколько интересных статей на эту тему: [12] [13]. Обработка ошибок В крупномасштабных системах ошибки неизбежны. Чтобы обеспечить высокий уровень отказоустойчивости, ошибки должны обрабатываться контролируемым образом и работа после них должна быстро возобнов­ ляться. Есть два вида ошибок. 270      ГЛАВА 14 Некритические. В качестве примера можно привести неудачное кодирование сегмента видео. В таких случаях обычно делается не­ сколько повторных попыток выполнить операцию. Если проблема продолжает возникать и системе не удается ее исправить, клиенту возвращается код соответствующей ошибки. Критические. Примером может служить некорректный формат видео. В таких случаях система останавливает задание, относя­ щееся к этому видео, и возвращает клиенту код соответствующей ошибки. Ниже перечислены типичные ошибки, возникающие в каждом компо­ ненте нашей системы. Ошибка загрузки: повторить попытку несколько раз. Ошибка разделения видео: если клиенты более старых версий не могут разделить видео с выравниванием по GOP, видеофайл за­ гружается на сервер целиком и процесс разделения выполняется на стороне сервера. Ошибка перекодирования: повторить попытку. Ошибка препроцессора: заново сгенерировать диаграмму DAG. Ошибка планировщика DAG: запланировать задание заново. Отказ очереди диспетчера ресурсов: использовать реплику. Отказ рабочего узла: повторить выполнение задания на другом узле. Отказ сервера API: серверы API не хранят свое состояние, поэтому запрос перенаправляется к другому серверу API. Отказ сервера для кэширования метаданных: данные реплициру­ ются несколько раз. Если один сервер выходит из строя, вы можете обратиться за данными к другим серверам. Мы можем заменить отказавший кэширующий сервер новым. Отказ сервера БД для кэширования метаданных: Š Š отказ ведущего сервера: сделать ведущим один из ведомых серверов; Š Š отказ ведомого сервера: для чтения можно использовать дру­ гой ведомый сервер. Сервер базы данных, вышедший из строя, можно заменить новым. Проектирование YouTube      271 ШАГ 4: ПОДВЕДЕНИЕ ИТОГОВ В этой главе мы представили архитектуру для сервисов стриминга видео наподобие YouTube. Если в конце интервью еще остается время, можно обсудить несколько дополнительных аспектов. Масштабирование уровня API. Поскольку серверы API не хранят свое состояние, их легко масштабировать горизонтально. Масштабирование базы данных. Можно упомянуть о репликации и сегментировании базы данных. Прямая трансляция. Это процесс записи и трансляции видео в ре­ альном времени. Изначально наша система не рассчитана на такое вещание, но эта функция имеет некоторые сходства со стримингом обычного видео: оба процесса требуют загрузки, кодирования и по­ токовой передачи. Есть и заметные отличия: Š Š у прямой трансляции повышенные требования к латентности, поэтому для нее может понадобиться другой протокол потоко­ вой передачи; Š Š у прямой трансляции не настолько высокие требования к парал­ лельной обработке, поскольку небольшие блоки данных и так обрабатываются в реальном времени; Š Š прямая трансляция требует другого подхода к обработке оши­ бок. Любой механизм, обрабатывающий ошибки слишком долго, не подходит. Запрет доступа к видео. Видеоролики, нарушающие авторские права, содержащие порнографию или нарушающие закон каким-то другим образом, должны удаляться. Некоторые из них могут быть обнаружены в процессе загрузки, о других могут сообщать сами пользователи. Поздравляем, вы проделали длинный путь и можете гордиться собой. Отличная работа! 272      ГЛАВА 14 СПРАВОЧНЫЕ МАТЕРИАЛЫ [1]  YouTube by the numbers: https://www.omnicoreagency.com/youtube-statistics/ [2]  2019 YouTube Demographics: https://blog.hubspot.com/marketing/youtube- demographics [3]  Цены на Amazon CloudFront: https://aws.amazon.com/ru/cloudfront/pricing/ [4]  Netflix на AWS: https://aws.amazon.com/solutions/case-studies/netflix/ [5]  Официальный веб-сайт Akamai: https://www.akamai.com/ [6]  Двоичные большие объекты: https://ru.wikipedia.org/wiki/BLOB [7]  Here’s What You Need to Know About Streaming Protocols: https://www. dacast.com/blog/streaming-protocols/ [8]  SVE: Distributed Video Processing at Facebook Scale: https://www. cs.princeton.edu/~wlloyd/papers/sve-sosp17.pdf [9]  Архитектура обработки видео в Weibo (на китайском языке): https://www. upyun.com/opentalk/399.html [10]  Делегат доступа с общей подписью доступа: https://docs.microsoft.com/ ru-ru/rest/api/storageservices/delegate-access-with-shared-access-signature [11]  YouTube scalability talk by early YouTube employee: https://www.youtube. com/watch?v=w5WVu624fY8 [12]  Understanding the characteristics of internet short video sharing: A youtube- based measurement study. https://arxiv.org/pdf/0707.3670.pdf [13]  Content Popularity for Open Connect: https://netflixtechblog.com/content- popularity-for-open-connect-b86d56f613b