Системный дизайн: клипы с пандами

Шаг 4 из 33

Функциональные требования

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

Функциональное требование описывает действие системы, и у каждого действия есть вызывающий. Поэтому в таблице отдельная колонка: кто нажимает.

Нейронки в таблице нет. Она — способ выполнить FR-2, а не требование: с точки зрения загружающего система «находит панду», а чем именно, он не видит. Так же нет очереди, GPU и CDN: это решения, и они появятся на схеме, когда их оправдают числа. И «клип» в таблице — то, что зритель смотрит и тегирует; файл это или таймкоды, решится на расчёте.

Отдельно стоит FR-8 — удалить клип, где панды нет. Он выглядит мелким, но это единственный способ исправить ошибку детектора без человека с нашей стороны, и на шаге про детекцию он ещё понадобится.

Шаг 5 из 33

Что вне рамок

Список того, чего система не делает, записывают так же явно, как список функций. Через полгода кто-нибудь спросит, почему нет рекомендаций, и ответ должен быть в документе.

• Модерация. Кто-то загрузит видео без панды и с чем-то, чего в галерее быть не должно. Это отдельный контур с людьми, правилами и жалобами.
• Рекомендации. Лента первой версии — по времени и по тегу. «Подобрать по вкусу» — отдельный продукт со своими данными.
• Другие животные. Детектор один и ищет панду. Модель на каждое животное — другой пайплайн и другой бюджет.
• Ручной монтаж. Подвинуть границу клипа на секунду. Если клип — таймкоды, это дёшево: два числа в строке. В первой версии всё равно не делаем, но дверь не закрыта — в отличие от схемы с нарезкой.
• Прямые трансляции. Обработка потока, а не файла, — другая система.

Справа десять утверждений из того же разговора. Разложи их по видам: часть свойств на слух похожа на функции, и на ревью спорят как раз о них.

Шаг 6 из 33

Нефункциональные требования

Второй раздел — свойства. Нефункциональное требование не добавляет системе действий, оно задаёт гарантию для тех, что уже есть.

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

Видео загружается, не проходя через наш API. Часовой ролик — это гигабайты. Запрос такого размера упирается в лимит тела, таймаут балансировщика и память сервиса, который его принимает. Байты должны идти в хранилище напрямую.

Клип начинает играть быстро из любой страны. Зритель не ждёт; и байты клипа тоже не должны идти через наш сервис.

Один загружающий не занимает весь пул. Зоопарк зальёт архив за десять лет, и турист с одним роликом будет ждать за ним сутки.

Колонка «Цель» пока пустая. Числа — на следующем шаге.

Шаг 7 из 33

Числа, к которым привязываемся

Свойство без числа нельзя проверить. SLO задаёт долю, порог и окно.

• Приём загрузок — 99,9% за 30 дней. Старт и complete отвечают, даже когда GPU-пул лежит. Это 43 минуты в месяц, когда загрузить нельзя.
• 99% видео доходят до конечного состояния за сутки без человека. Конечные — «готово», «панд нет» и «не вышло». Видео, которое навсегда осталось «в обработке», хуже упавшего.
• 95% видео до десяти минут получают клипы в течение 15 минут. Это обещание про очередь и пул. Оно нарушается, когда загрузок больше, чем успевает разобрать GPU.
• Первый кадр за две секунды в 95 случаях из 100, из любой страны. Считаем верхнюю границу, а не среднее, и не только из своего города.
• Поиск за 300 мс в 99 случаях из 100, свежий тег виден за пять секунд. Второе число важнее первого: поиск, который не находит тег, поставленный минуту назад, выглядит сломанным.

Цели ложатся в колонку рядом с теми строками, что уже в таблице. По этим числам потом принимают решения: нарушено третье — расширяем пул, нарушено четвёртое — смотрим на CDN и на то, где в файле лежит индекс.

Шаг 8 из 33

Расчёт: сколько GPU

Калькулятор справа. Пять тысяч видео в сутки — это 0,06 видео в секунду в среднем и 0,23 на пике, если пик вчетверо выше среднего. Для сравнения: у сервиса скрейпинг-джоб было 28 джоб в секунду. Поток здесь в сто раз меньше, и очередь на таком потоке — не вопрос. Вопрос — что происходит с каждым видео.

На каждое видео детектор тратит GPU. Не на каждый кадр: модель смотрит два кадра в секунду, и пятиминутный ролик обрабатывается примерно за минуту — 0,2 секунды GPU на секунду видео. Это 83 GPU-часа в сутки. Больше обработка ничего не делает: ни резать, ни перекодировать не нужно, клип — это таймкоды.

Сколько GPU держать, считает закон Литтла: поток на пике, умноженный на время одной обработки. 0,23 видео в секунду по 60 секунд — 14 видео в работе одновременно. Видео на GPU обрабатывается по одному, так что это же число — размер пула на пике. В среднем хватит четырёх: пул растёт и сжимается по глубине очереди.

Ожидание в очереди — ползунок, а не результат: закон Литтла не говорит, каким оно будет, но переводит его в видео. Пять минут ожидания — это 69 роликов в очереди на пике и шесть минут от загрузки до клипов; NFR-4 выполняется с запасом. Подвинь ожидание к получасу — обещание нарушено.

Подвинь коэффициент GPU к единице — модель смотрит каждый кадр, — и пул вырастает до семидесяти. Один ползунок детектора стоит дороже всего остального в этой схеме, и это первый аргумент за то, чтобы сэмплировать кадры, а не прогонять все.

Шаг 9 из 33

Расчёт: сколько байтов на диске

Теперь про размер — то, ради чего задача такая, какая есть.

Пятиминутное видео с телефона при 10 Мбит/с весит 358 МБ. Пять тысяч таких в сутки — 1,7 ТБ загрузок в день. Через наш API столько не проходит; это уже требование NFR-2, и на схеме оно станет первым решением.

Клип — таймкоды, поэтому оригинал остаётся: он и есть то, что смотрят. 1,7 ТБ в день — это 622 ТБ за год, и хранилище растёт с этой скоростью, пока живут видео. Горячими — в классе для частого чтения — держим первые тридцать дней, пока видео смотрят; дальше оно уходит в класс с редким доступом по правилу хранилища. На цифрах это 51 ТБ горячих и 571 ТБ холодных через год.

Калькулятор считает и альтернативу. Если бы клипы резали в отдельные файлы и хранили только их — панда в кадре пятую часть ролика, клип кодирован в 3 Мбит/с, — это было бы 37 ТБ в год, в 17 раз меньше. Вот цена решения «таймкоды вместо нарезки», и её надо назвать вслух.

Что за неё куплено. Нет нарезки и перекодирования — ни CPU на каждое видео, ни файлов, которые могут разойтись со строками в базе. Границу клипа можно подвинуть двумя числами. Пропущенную панду можно найти повторным прогоном, а новую модель — применить к архиву. При нарезке ничего из этого нельзя: оригинала нет.

Подвинь длину видео к часу или битрейт к 50 Мбит/с — и счёт за хранилище становится главным в системе. Тогда нарезка возвращается на стол, и это честный ответ калькулятора. В таблицу уходит строка про бюджет хранилища; число к ней — на шаге про хранение.

Шаг 10 из 33

Расчёт: сколько смотрят

Третий калькулятор — про зрителей. Если каждое загруженное видео собирает сто просмотров клипов, это 500 тысяч просмотров в сутки и 23 в секунду на пике. Каждый просмотр — 20 секунд оригинала по 10 Мбит/с, 25 мегабайт: клип не перекодирован, смотрят в том битрейте, в котором снял телефон. Итого 11 ТБ в сутки и 341 ТБ в месяц.

Это трафик, который нельзя пропускать через наш сервис: его отдаёт CDN, а наш API — только адрес и два таймкода. В таблицу уходит строка NFR-12, число к ней появится на кадре про раздачу.

Битрейт при просмотре — ползунок. Подвинь его к трём мегабитам: трафик падает втрое, до 102 ТБ в месяц. Это то, что дала бы разовая перекодировка при загрузке — один файл на видео в битрейте раздачи, нарезки по-прежнему нет. В первой версии её не делаем: это CPU на каждое видео и вторая копия. Когда счёт за трафик станет больше счёта за хранение, ползунок покажет, сколько она сэкономит.

Вторая половина калькулятора — метаданные. Каждый просмотр — одно чтение страницы клипа из базы, каждый пятый зритель ещё и ищет. На пике это 28 чтений в секунду против 0,7 записей клипов: сорок чтений на одну запись. Система читающая, как и обещала аналогия с YouTube, но 28 чтений в секунду — это ничто для одной базы с индексом. Кэш и отдельная читающая сторона здесь не нужны; они понадобятся, если просмотров станет в сто раз больше, и тогда дорога известна — глава про CQRS.

Подвинь просмотры к тысяче на видео: байты вырастают до петабайтов в месяц, а чтений в базу всё ещё меньше трёхсот в секунду. Байты растут быстрее запросов, и это главная пропорция задачи.

Шаг 11 из 33

C1: система и всё, что с ней разговаривает

Теперь можно рисовать. Первый кадр — C1: система одним блоком.

Слева пользователь: он и загружает, и смотрит, и тегирует. Справа CDN — чужая сеть кэшей, через которую зритель получает байты клипа. Мы её не эксплуатируем, а только настраиваем, и её доступность в наш SLO не входит — но NFR-5 без неё не выполнить.

Две линии от пользователя — легенда цвета на всех следующих кадрах: запись уходит в сервис, чтение приходит с CDN. То, что оба пути байтов идут мимо наших сервисов, станет видно на C2.

Шаг 12 из 33

Вход: байты мимо API

Первые элементы внутри границы — api-gateway, video-api, база clips-pg и хранилище видео videos-s3.

Загрузка идёт в три хода. POST /videos создаёт строку видео в состоянии uploading и возвращает подписанные ссылки на части. Телефон льёт части прямо в videos-s3: по частям, с докачкой оборванной части, без лимита тела запроса на нашей стороне. POST /videos/{id}/complete говорит, что всё долито, и переводит видео в uploaded.

Через video-api при этом проходят два маленьких запроса, а 358 МБ видео — ни одного байта. Это NFR-2 на схеме. Сервис, который проксировал бы терабайты в сутки, пришлось бы масштабировать по трафику, а не по запросам, и он ничего не делал бы с этими байтами, кроме как перекладывал.

Файл, который сюда лёг, — единственная копия видео на всю его жизнь. Из него детектор возьмёт кадры, из него же зритель будет смотреть клипы.

• Новое на схемеapi-gatewayТочка входа: проверяет, кто пришёл, держит лимиты и раздаёт запрос внутрь. Про видео не знает ничего.
• Новое на схемеvideo-apiЕдинственный сервис с ручками: заводит загрузку, принимает complete, пишет теги, отдаёт галерею и поиск. Байты видео через него не идут.
• Новое на схемеclips-pgpostgresВидео, клипы, теги. Строка видео — она же задача обработки; строка клипа — два таймкода.
• Новое на схемеvideos-s3s3Видео как загружено — единственная копия. Сюда пользователь льёт байты сам, отсюда их берёт детектор, отсюда их тянет CDN.

Шаг 13 из 33

Очередь — это таблица

После complete видео нужно обработать, и привычный ход — поставить брокер: video-api публикует «видео загружено», воркер читает. Здесь брокера нет, и это решение, а не упущение.

Строка videos и есть задача. У неё статус uploaded, номер попытки, срок аренды и время следующего запуска. Сервис clip-pipeline раз в секунду спрашивает базу: SELECT … WHERE status = 'uploaded' AND next_run_at <= now() ORDER BY … FOR UPDATE SKIP LOCKED LIMIT 1, — ставит processing и аренду и идёт работать. Несколько воркеров берут задачи из одной таблицы и не мешают друг другу: захваченные строки пропускаются.

Чем это лучше брокера именно здесь. Поток — 0,23 видео в секунду на пике; четырнадцать воркеров по запросу в секунду — четырнадцать запросов к индексу. Состояние видео и задача — одна строка, значит, нет двойной записи «база плюс брокер», ради которой у скрейпера появился outbox. И очередь видна одним SQL-запросом: сколько ждёт, сколько в работе, какая задача самая старая.

Брокер нужен там, где тысячи сообщений в секунду, много разных потребителей или события, которые должны разойтись по сервисам. Ничего из этого в задаче нет: потребитель один, и он тяжёлый. Сама таблица и запросы к ней — на следующем шаге.

• Новое на схемеclip-pipelineШедулер с обработкой внутри: берёт следующее видео из таблицы под аренду, качает оригинал, ищет панду и записывает таймкоды клипов. Ничего не режет.

Шаг 16 из 33

От оригинала до таймкодов

Пайплайн взял задачу. Дальше три действия, и ни одно из них не создаёт нового видео.

Оригинал скачивается из videos-s3 один раз, на локальный диск воркера. Детектор сэмплирует из него кадры, прогоняет через модель и склеивает попадания в отрезки: начало и конец в миллисекундах, уверенность. Из кадра с самой уверенной пандой делается превью и кладётся в videos-s3 рядом с видео.

Потом одна транзакция в clips-pg: строки клипов с таймкодами и статус видео ready. Пока она не закоммичена, для всей системы видео ещё в обработке, и клипов у него нет.

Байты клипа — это байты оригинала, который уже лежит там, куда его положил пользователь. Пайплайн ничего не режет и не перекодирует: ffmpeg здесь только достаёт кадры.

Шаг 17 из 33

Воркер умер с видео в руках

Обработка длится минуту, иногда десять. За это время воркер может умереть: модель упала по памяти на 4K-кадре, облако забрало спотовую машину, кто-то выкатил релиз. Видео остаётся processing, и дашборд его не покажет, потому что формально оно обрабатывается.

Поэтому у задачи аренда. Взяв видео, воркер ставит lease_until на десять минут вперёд и продлевает его каждую минуту, пока работает. Тот же clip-pipeline раз в минуту ищет строки processing с истёкшей арендой и возвращает их в uploaded: попытка плюс один, next_run_at через паузу, которая растёт с каждой попыткой. После третьей — failed с текстом последней ошибки.

Повторная попытка должна быть безопасной. Клипы пишутся с ключом (video_id, start_ms), превью — с детерминированными именами: половина клипов от прошлой попытки перезапишется, а не удвоится. Это та же идемпотентность, что у приёма, только внутри пайплайна. Оригинал повтор не трогает вовсе — он только читается.

Постоянные ошибки — битый файл, не видео вовсе — повторять незачем: такие сразу в failed. Граница проходит не по коду ошибки, а по тому, может ли повтор дать другой результат.

Шаг 18 из 33

Чтение: галерея, страница, поиск

Читающая сторона — тот же video-api. У скрейпера чтение и запись были разведены по сервисам; здесь 28 чтений в секунду на пике не оправдывают второй сервис, и разделение откладывается до тех пор, пока числа не изменятся.

Три запроса. Галерея — клипы по времени, страницами по курсору. Страница видео — клипы одного video_id плюс стадия и попытки, если видео ещё в обработке: это и есть FR-2 и половина NFR-14. Поиск — клипы по тегам, о нём отдельный шаг.

Что отдаёт API в каждом из них: метаданные, адрес оригинала и два таймкода. Ни одного байта видео в ответах нет. Где эти байты — на следующем кадре.

Шаг 19 из 33

Просмотр: диапазон оригинала с CDN

GET /clips/{id} возвращает video_url, start_ms и end_ms. Адрес ведёт не в наш сервис, а на CDN, за которым стоит videos-s3. Плеер открывает оригинал с нужной секунды: запросом с заголовком Range он просит у CDN только байты клипа, а не файл целиком. На промахе узел CDN тянет этот диапазон из хранилища и держит у себя.

Одна деталь делает это возможным. Телефон часто пишет индекс кадров — атом moov — в конец MP4, и плеер не может начать с середины, не дочитав файл до конца. Разовая перестановка индекса в начало при загрузке решает это без перекодирования: байты копируются как есть.

Зачем CDN, если есть S3? Хранилище умеет отдавать диапазоны и само, по ссылке, и при небольшом трафике это правильный ответ — калькулятор раздачи так и говорит. CDN перед ним нужен ради трёх вещей.

• Расстояние. Бакет живёт в одном регионе, а зритель из другого полушария ходил бы через океан за каждым куском. Узел CDN стоит рядом со зрителем.
• Повторы. Удачный клип смотрят сто тысяч раз. Без CDN это сто тысяч чтений из бакета; с CDN бакет отдаёт диапазон по разу на каждый узел, остальное идёт из кэша на краю.
• Деньги. Трафик из хранилища наружу тарифицируется дороже, чем трафик с CDN, и каждый запрос к бакету тоже платный.

Так закрываются два требования сразу. NFR-12: 11 ТБ в сутки не проходят ни через video-api, ни через api-gateway. NFR-5: первый кадр приходит с ближайшего края, а не из одного региона. У клипа есть превью, которое показывается, пока грузится первый кусок.

Клипы публичные, как на YouTube, поэтому ссылки обычные. Если продукт захочет приватные видео, на этом же месте появятся подписанные ссылки CDN — и это единственное место, которое изменится.

Шаг 23 из 33

C3: внутри clip-pipeline

Спускаемся на уровень ниже. C3 показывает модули одного сервиса. clip-pipeline на C2 был одной коробкой, внутри у него три.

• task-poller — берёт следующую задачу под аренду, продлевает аренду, возвращает истёкшие. Всё, что относится к очереди, живёт здесь.
• panda-detector — декодирует оригинал по два кадра в секунду, прогоняет кадры через детектор пачками и склеивает попадания в отрезки: с порогом уверенности, минимальной длиной и запасом по краям. Из лучшего кадра делает превью и кладёт его рядом с видео.
• videos-repository — единственный модуль, который ходит в базу: таймкоды и статус одной транзакцией.

Если когда-нибудь понадобится разовая перекодировка оригинала в битрейт раздачи, она встанет отдельным модулем на CPU, а не на GPU, — и сделает один файл на видео, а не на клип.

• Новое на схемеtask-pollerОчередь целиком: следующая задача под аренду, продление, возврат истёкших.
• Новое на схемеpanda-detectorКадры через нейронку, попадания — в отрезки с порогом, минимальной длиной и запасом по краям; превью из лучшего кадра.
• Новое на схемеvideos-repositoryЕдинственный модуль, который ходит в clips-pg: таймкоды и статус одной транзакцией.

Шаг 25 из 33

Контракт: расписка и адреса

Контракт карточками. Три из них — про загрузку, и байты видео есть только в одной, которая не наша.

POST /videos отвечает 201 с идентификатором и подписанными ссылками на части. PUT по такой ссылке — это S3, не мы: ключ подписи ограничивает срок и объект, и клиент докачивает оборванную часть сам. complete — 202 Accepted: клипов ещё нет, есть расписка и адрес, где следить.

Переход в uploaded — условный UPDATE … WHERE status = 'uploading'. Повторный complete после потерянного ответа ничего не меняет и получает тот же 202: обработка стартует один раз. Это NFR-8, и ключ идемпотентности здесь — сам идентификатор видео.

Остальные карточки — чтение и теги. GET /clips/{id} отдаёт video_url на CDN и пару start_ms, end_ms: плеер сам просит нужный диапазон. DELETE /clips/{id} закрывает FR-8: уходит строка и превью, а оригинал — только вместе с видео.

• POST/videos201 Created

  Завести видео. В ответе идентификатор и подписанные ссылки на части: байты пойдут по ним, мимо API.

  запрос

  Idempotency-Keysizecontent_type

  ответ

  idstatus: uploadingupload.part_urls[]upload.expires_at

• PUT{upload.part_url}200 OK

  Часть видео — прямо в хранилище. Не наша ручка: это S3, мы её только подписали.

  запрос

  part bytes

  ответ

  ETag

• POST/videos/{id}/complete202 Accepted

  Загрузка закончена. Повтор с тем же id получает тот же ответ: обработка стартует один раз.

  запрос

  parts[].etag

  ответ

  status: uploadedlinks.self

• GET/videos/{id}200 OK

  Что с видео: стадия, попытки, готовые клипы.

  ответ

  statusstageattemptsclips[]

• GET/clips?tag=&cursor=200 OK

  Клипы по тегу, страницами по курсору.

  ответ

  items[]next_cursor

• GET/clips/{id}200 OK

  Страница клипа: описание, теги, адрес оригинала на CDN и два таймкода. Плеер сам просит нужный диапазон.

  ответ

  titledescriptiontags[]video_urlstart_msend_msthumbnail_url

• POST/clips/{id}/tags201 Created

  Поставить тег. Слово нормализуется; второй раз тот же тег не добавляется.

  запрос

  tag

  ответ

  tags[]

• DELETE/clips/{id}204 No Content

  Убрать клип: ложное срабатывание или своё видео. Удаляется строка и превью; оригинал — только вместе с видео.

Шаг 26 из 33

Жизненный цикл видео

Состояний у видео шесть, и три из них конечные.

uploading → uploaded → processing → ready. Рядом два других конца: empty, когда детектор ничего не нашёл, и failed, когда попытки кончились или загрузка так и не завершилась за сутки.

Кто переводит, видно по цвету. В uploaded — video-api по complete. В processing и дальше в ready или empty — пайплайн, и только после коммита таймкодов. Обратно в uploaded и в failed — поллер по аренде и попыткам, а не сам детектор: упавший воркер ничего не переводит, за него это делает тот, кто заметил истёкшую аренду.

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

Шаг 27 из 33

Детекция: порог, длина, ошибки

Нейронка — не чёрный ящик с ответом «да/нет», а источник уверенности на кадр. Правила, которые превращают её в клипы, задаёт продукт, и они ложатся в таблицу требований.

Порог. Кадр считается кадром с пандой при уверенности выше 0,7. Ниже — больше ложных клипов; выше — больше пропусков. Порог подбирают на размеченной выборке и меняют без деплоя.

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

Ошибки двух родов. Ложное срабатывание — клип с енотом — исправляет загружающий через FR-8, и это дёшево: уходит строка. Пропуск — панда есть, клипа нет — исправляет повторный прогон: оригинал на месте, «пройти ещё раз» — обычная задача в той же очереди, с новым порогом или новой моделью. У схемы с нарезкой этого пути нет.

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

Шаг 28 из 33

Шумный сосед на GPU

Изоляция загружающих записана одной строкой. Симулятор справа показывает, что она значит.

Три пользователя: турист и школьная экскурсия по ролику в две секунды и зоопарк, который выложил архив — четыреста видео разом. Пул из восьми GPU по четыре секунды на видео разбирает два видео в секунду. Включи общую очередь: зоопарк занимает пул на три минуты, и у туриста за это время не готов ни один клип. Система при этом права: она берёт задачи в порядке поступления.

Переключи на «поровну». Пул тот же, изменилось только правило выбора следующей задачи: у кого меньше всего в работе, тот и следующий. Турист получает клипы через секунды, зоопарк — треть пула.

В таблице это один ORDER BY в запросе поллера: сначала владельцы, у которых в работе меньше, потом по времени загрузки. То, ради чего в брокере пришлось бы заводить очередь на владельца и свой планировщик, здесь — строка SQL. Веса — платному зоопарку больше — та же строка с коэффициентом.

Шаг 30 из 33

Что хранить и сколько

Три класса данных с разной судьбой.

Оригиналы. Живут, пока живёт видео: это и есть клипы. 622 ТБ в год при нынешнем потоке — главная статья расходов, и ею управляет не код, а правило хранилища. Первые тридцать дней, пока видео смотрят, оно лежит в классе для частого чтения; потом переезжает в класс с редким доступом, где хранение дешевле, а каждое чтение дороже. Повторы чтений при этом закрывает CDN: холодный оригинал поднимается из хранилища по разу на узел. Удаление видео уносит оригинал, превью и строки клипов и чистит CDN по адресам. Заброшенные загрузки — строка без complete сутки — подбирает чистка по сроку.

Превью. Килобайты на клип, их объём в счёте не виден.

Строки в базе. Миллионы клипов в год — таблица, которую Postgres даже не замечает. Отдельного внимания требует videos: статус меняется несколько раз за жизнь строки, и мёртвые версии копятся. Автовакуум с этим справляется, но за ним нужно смотреть, потому что по этой же таблице работает очередь.

Число для NFR-10 — в таблицу: оригинал живёт, пока живёт видео, около 622 ТБ в год, через тридцать дней — класс с редким доступом.

Шаг 31 из 33

Что мерить

Метрик много, для решений достаточно пяти.

• Возраст самой старой задачи в uploaded. Важнее длины очереди: по нему растёт пул и по нему видно, что пул не справляется, раньше, чем нарушится NFR-4.
• Время от complete до ready, p95. Прямо соответствует SLO.
• Отказы по классам ошибок. «Не хватило памяти», «не декодируется», «модель не ответила» — три разных инцидента, и смешивать их в общую долю отказов нельзя.
• Доля empty. Выросла вдвое за день — порог сбился или модель деградировала, и пользователи ещё не пожаловались.
• Доля попаданий в CDN и исходящий трафик из videos-s3. Если трафик из хранилища растёт вместе с просмотрами, CDN не кэширует диапазоны, и счёт за хранилище скажет об этом позже, чем метрика.

И стадия с попытками на странице видео: дежурному не нужно лезть в базу, чтобы увидеть «попытка 2 из 3, упал на кадре 1 840».