Обработка медиаданных в Netflix Stratum: автоматическая оптимизация размеров контейнеров25.09.2026 19:01

[не удалось получить полный текст]

Авторы: Виолетта Пидволоцка и Навин Маредди

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

Инженеры разрабатывают функции Stratum, упаковывая код приложений и зависимости ОС в образы OCI. Затем Stratum планирует запуск этих контейнеров как пакетных заданий на вычислительной платформе Netflix Titus, а вышестоящие сервисы запускают выполнение функций.

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

Чтобы запросить ресурсы для этих функций, владельцы указывают лимиты CPU, памяти, диска и сети в конфигурации YAML, как показано ниже:

functionName: VideoEncoder.encodeV1
resources:
  numCpus: 8
  memoryInMB: 18000
  diskSizeInMB: 50000
  networkInMbps: 1000

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

В этой статье мы расскажем, как создали Stratum Resource Tuner (SRT) — автоматизированную систему, которая безопасно подбирает оптимальные размеры работающих в production контейнеров без участия человека. Мы рассмотрим примеры из реальной практики, архитектуру безопасности и выводы, которые сделали после неудачного автоматического изменения.

Проблема: избыточное выделение ресурсов

Создавая новую функцию Stratum, инженеры обычно копируют YAML-конфигурацию ресурсов существующей функции или рассчитывают её на самый неблагоприятный сценарий. После запуска в production инженеры редко возвращаются к этим настройкам, пока не произойдёт сбой, — и тогда из предосторожности выделяют ещё больше ресурсов, чем нужно.

Настраивать ресурсы вручную нецелесообразно по следующим причинам:

• Большие операционные затраты: Чтобы уменьшить выделенные ресурсы, приходится несколько дней вручную отслеживать метрики и методом проб и ошибок проводить тесты. Это отнимает драгоценное время инженеров, которое можно было бы посвятить другим важным задачам. Если сократить ресурсы слишком сильно, возникают инциденты в production, поэтому ручная настройка сопряжена с высоким риском и приносит мало пользы.
• Постоянное развитие инфраструктуры и кодеков: Облачные провайдеры регулярно обновляют оборудование. Распределение ресурсов, оптимальное для аппаратного поколения постарше, может незаметно стать неэффективным на более новом оборудовании. Одновременно Netflix постоянно совершенствует стандарты медиаконтента и алгоритмы кодирования, например AV1, AV2 и пространственное аудио. Распределение ресурсов, подобранное для одного кодека, может оказаться не оптимальным после выхода усовершенствованного алгоритма.
• Изменение характера нагрузок: По мере выхода Netflix на новые типы медиаконтента — например, потоковые видеоподкасты, спортивные трансляции, интерактивные рекламные форматы с адаптацией на основе ИИ и интеграции с крупными вещательными компаниями, такими как TF1 во Франции, — объём ресурсов, необходимых для обработки медиаконтента, может непредсказуемо меняться, и статические лимиты ресурсов контейнеров перестают быть точными.
• Рост стоимости оборудования в отрасли: Из-за огромного мирового спроса на инфраструктуру ИИ цены на серверное оборудование и DRAM продолжают расти, поэтому особенно дорого обходится простаивающая память контейнеров.
• Увеличение масштаба платформы: В масштабах Netflix даже небольшое избыточное выделение ресурсов многократно повторяется при сотнях тысяч ежедневных запусков контейнеров, приводя к накоплению неиспользуемых мощностей на всей платформе Stratum.

Чтобы оценить масштаб проблемы, мы проанализировали историю использования ресурсов в нагрузках Stratum. Данные телеметрии подтвердили нашу гипотезу: избыточное выделение ресурсов встречалось часто, потери вычислительных мощностей накапливались, а устойчивое решение требовало полностью пересмотреть подход к управлению конфигурациями ресурсов.

Знакомьтесь: Stratum Resource Tuner

Чтобы решить перечисленные проблемы, мы создали Stratum Resource Tuner (SRT), автоматически подбирающий оптимальные размеры контейнеров Stratum. Наша главная цель — избавить пользователей от необходимости вручную указывать конфигурации ресурсов. Мы начали с нескольких нагрузок с высокой пропускной способностью и невысокими требованиями к задержке. На них приходится большая часть — 70–80% — использования ресурсов.

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

Автоматический подбор оптимальных ресурсов по умолчанию отключён. Владельцы функций должны вручную включить его отдельно для каждого типа ресурса (например, CPU, памяти, сети или диска). После включения SRT выполняет работу без участия человека в пять этапов:

Рисунок 1. Общая схема работы SRT

1. Сбор метрик использования ресурсов для всех запусков функции.
2. Формирование рекомендации для каждого типа ресурсов (например, CPU или памяти).
3. Проверка рекомендации с помощью экспериментов.
4. Применение или отклонение рекомендации в зависимости от результатов экспериментов.
5. Мониторинг после применения метрик и поиск аномалий после внедрения рекомендации.

«Рекомендация» — ключевое понятие в SRT и основная единица работы. По мере выполнения этапов SRT рекомендация проходит несколько состояний:

Рисунок 2. Машина состояний рекомендации

• CREATED: рекомендация создана по расписанию.
• EVALUATING: выполняется проверка рекомендации, SRT анализирует результаты.
• APPLIED: все эксперименты пройдены, и SRT автоматически внедрил рекомендованную конфигурацию.
• REJECTED: как минимум один эксперимент завершился неудачно, поэтому конфигурация функции осталась без изменений.
• MONITORED: SRT отслеживает рекомендацию в течение периода наблюдения после внедрения, чтобы убедиться в стабильности.

В следующих разделах мы подробно рассмотрим каждый этап. Чтобы наглядно показать этот процесс, проследим за полным жизненным циклом функции VideoEncoder.encodeV1 — функции кодирования видео с высокой пропускной способностью, ресурсы памяти и CPU которой удалось успешно оптимизировать.

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

Сбор метрик

Для формирования таких рекомендаций необходим надёжный механизм сбора метрик. Каждый контейнер Stratum с точностью до минуты сообщает метаданные о выполнении функции, параметры инфраструктуры и данные об использовании ресурсов (CPU, памяти, диска и сети).

Эти метрики проходят через Keystone, платформу Netflix для потоковой обработки событий в реальном времени, и поступают в два отдельных хранилища данных:

Рисунок 3. Сбор метрик

• Хранилище сводных данных о выполнении: хранит сводные метрики на уровне запусков, индексированные в Elasticsearch для быстрого поиска по отдельным значениям. Оно служит краткосрочным хранилищем, в котором можно запрашивать и анализировать отдельные запуски.
• Долгосрочное хранилище данных с высоким разрешением: хранит исходные метрики использования ресурсов с высоким временным разрешением в таблицах Iceberg. Запросы к нему выполняются медленнее, зато оно служит долгосрочным хранилищем, где сохраняется история за несколько месяцев для анализа тенденций использования ресурсов.

Для каждого выполнения записывается одна запись, представленная в виде span. Вот как выглядят эти записи для одного span функции VideoEncoder.encodeV1.

В Elasticsearch запись содержит сводную информацию о завершённом span, идентифицируемом по tags.stratum.spanId:

{
  "tags.stratum.spanId": "38536313f65f060a",
  "tags.functionName": "VideoEncoder.encodeV1",
  "tags.stratum.phase": "run",
  "tags.stratum.success": true,
  "tags.stratum.retriedWithMoreResources": false,
  "tags.stratum.function.execDurationSecs": 26,
  "tags.cpuCount": 8,
  "tags.memoryInMB": 18000,
  "tags.diskInMB": 50000,
  "tags.networkInMbps": 1000,
  "tags.titusTaskId": "06e1a7c0-2502-4a54-905f-b13a1e786107",
  "tags.instanceType": "r7a.24xlarge",
  "tags.nf.region": "us-east-1",
  "ts": 1780743028000
}

В Iceberg запись содержит те же метаданные, но дополнительно включает временной ряд использования ресурсов с точностью до минуты, отслеживаемый в течение этого span:

{
  "span_id": "38536313f65f060a",
  "function_name": "VideoEncoder.encodeV1",
  "phase": "run",
  "success": true,
  "start_epoch_secs": 1780743002,
  "end_epoch_secs": 1780743028,
  "runtime_secs": 26,
  "cpu_requested": 8,
  "memory_mb_requested": 18000,
  "disk_mb_requested": 50000,
  "network_mbps_requested": 1000,
  "titusTaskId": "06e1a7c0-2502-4a54-905f-b13a1e786107",
  "instance_type": "r7a.24xlarge",
  "tags.stratum.retriedWithMoreResources": false,
  "env": "prod",
  "resource_usage": [ 
   { "cpu_usage": 1.13, "memory_mb": 3701.37, "disk_mb": 20120.4, "net_in_mb": 221.09, "net_out_mb": 0.12 },
   { "cpu_usage": 2.25, "memory_mb": 3584.09, "disk_mb": 25410.1, "net_in_mb": 0.02, "net_out_mb": 0.05 },
   { "cpu_usage": 4.16, "memory_mb": 6750.79, "disk_mb": 30400.5, "net_in_mb": 165.90, "net_out_mb": 0.38 },
   ... 
  ]
}

Формирование рекомендаций

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

Каждая рекомендация сохраняется в хранилище рекомендаций, что позволяет по мере необходимости запрашивать и фильтровать рекомендации по функции, типу ресурса или статусу.

Рисунок 4. Последовательность формирования рекомендаций

Для каждой функции и каждого типа ресурсов рабочий процесс применяет следующую логику:

• Фильтрация по типу нагрузки: мы настраиваем только нагрузки с высокой пропускной способностью. Так мы сосредоточиваем усилия на тех функциях, оптимизация которых даст наиболее значимую экономию для всего парка.
• Агрессивная настройка CPU и сети: мы ориентируемся на p99 без дополнительного запаса. CPU и сеть — ресурсы, которые можно сжать: если контейнер время от времени достигает этих лимитов, функция может выполняться немного медленнее.
• Консервативная настройка памяти и диска: мы ориентируемся на p99,9 и закладываем запас безопасности. Физическая память или дисковое пространство могут закончиться, что приведёт к критическим сбоям — например, аварийному завершению из-за нехватки памяти (OOM) или дискового пространства (OOD). Поэтому необходим защитный запас.
• Ограничения на изменения: мы отбрасываем рекомендации, если абсолютное сокращение слишком мало, чтобы оправдать операционные затраты. Для памяти и диска максимальное сокращение за один цикл ограничено 15% — этот предел безопасности мы ввели после первых запусков в production.

Рабочий процесс создаёт новые рекомендации в состоянии CREATED. Если для данной функции и типа ресурса уже есть рекомендация в этом состоянии, SRT перезаписывает её, используя обновлённые расчёты. После перехода рекомендации из состояния CREATED поля recommended_value и stats становятся неизменяемыми. При следующих ежедневных запусках создаётся новая рекомендация с уникальным идентификатором, а существующая запись не изменяется.

Вот как выглядят рекомендации по разным типам ресурсов в исходном состоянии CREATED для функции VideoEncoder.encodeV1:

• Рекомендация по CPU

{

  "function_name": "VideoEncoder.encodeV1",
  "env": "prod", "resource_type": "CPU",
  "current_value": 8, "recommended_value": 4,
  "status": "CREATED",
  "resource_cost_usd_per_hour": ***,
  "stats": {
    "usage": { "p99": 4.16, "p999": 4.57 },
    "execution": {
      "total_fn_executions": 748762182,
      "success_fn_executions_pct": 99.75,
      "total_fn_exec_runtime_hr": 88102723
    },
    "window": { "start": "2026-05-05T00:00:00Z", "end": "2026-06-05T00:00:00Z" }
  },
  "experiment_inputs": null,
  "experiment_workflow_execution_id": null,
  "outcome_message": null,
  "finalized_at": null
}

• Рекомендация по памяти (сокращение на 15% за один шаг)

{
  "id": "2edb734a-6184-4f5e-8ffa-23004bd665d7",
  "function_name": "VideoEncoder.encodeV1",
  "env": "prod", "resource_type": "MEMORY_MB",
  "current_value": 18000, "recommended_value": 15300,
  "status": "CREATED",
  "resource_cost_usd_per_hour": ***,

  "stats": {
    "usage": { "avg": 5296.43, "p99": 6750.8, "p999": 7820.3 },
    "execution": {
      "total_fn_executions": 748762182,
      "success_fn_executions_pct": 99.75,
      "total_fn_exec_runtime_hr": 88102723
    },
    "window": { "start": "2026-05-05T00:00:00Z", "end": "2026-06-05T00:00:00Z" }
  },
  "experiment_inputs": null,
  "experiment_workflow_execution_id": null,
  "outcome_message": null,
  "finalized_at": null
}

По мере прохождения жизненного цикла рекомендации SRT заполняет остальные параметры.

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

После завершения проверочных запусков статус меняется на APPLIED или REJECTED, а в записи сохраняются результаты и время завершения для последующего анализа.

Повторный запуск с увеличенными ресурсами

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

Для обработки таких неожиданных всплесков мы разработали отказоустойчивый механизм. Процесс-наблюдатель, запущенный в каждом настроенном контейнере, отслеживает использование памяти и диска во время выполнения функции. Если контейнер превышает заранее заданные пороговые значения — 85% для памяти без учёта кэша или 95% для диска, — наблюдатель помечает выполнение как рискованное, отменяет его и ставит задачу в очередь для повторного запуска в контейнере большего размера:

new_container_size = original_container_size * 1.5

Множитель 1,5 применяется только к параметрам памяти и диска.

Рисунок 5. Повторный запуск с увеличенными ресурсами

Этот механизм «повторного запуска с увеличенными ресурсами» служит страховкой: более крупные конфигурации контейнеров применяются только при повторном запуске задач для автоматического восстановления после нестандартных ситуаций. Хотя такие редкие повторные запуски увеличивают расходы на вычисления и задержки, благодаря им мы можем оптимизировать повседневные конфигурации и не закладывать ресурсы на редкие и дорогостоящие исключения заранее.

Если во время тяжёлого запуска функции VideoEncoder.encodeV1 использование памяти превысит порог в 85% (15 300 МБ) при текущем размере контейнера 18 000 МБ, система прервёт выполнение и перезапустит его в контейнере на 27 000 МБ.

Мы предпочли бы запускать повторные попытки после фактических событий OOM или OOD, а не при достижении заранее заданных порогов, однако технические ограничения текущей архитектуры затрудняют надёжное обнаружение таких событий. Пока мы разрабатываем более совершенные возможности обнаружения, заранее заданные пороги служат надёжным временным решением.

SRT автоматически включает механизм повторного запуска для всех функций, для которых активирована оптимизация памяти или диска. Каждый контейнер Stratum сообщает о повторных запусках; эти данные поступают в Elasticsearch и Iceberg вместе со стандартной телеметрией производительности.

Проверка рекомендаций

Перед внедрением каждая рекомендация должна пройти двухэтапную проверку, управляемую рабочим процессом Conductor. На этапе EVALUATING SRT проводит два отдельных типа экспериментов:

1. Синтетический эксперимент: недорогой тест с низким уровнем риска, позволяющий выявить очевидные ухудшения до внедрения в production.
2. Эксперимент в production: проверка на реальном трафике, позволяющая оценить изменения на разнообразных производственных нагрузках и повысить уверенность в результате.

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

Рисунок 6. Этап оценки

Синтетический эксперимент:

• Проводится в тестовой среде, изолированной от производственного трафика.
• Создаются два кластера: один для текущей конфигурации, другой — для рекомендованной.
• Одинаковые наборы запросов одновременно воспроизводятся в обоих кластерах, без разделения трафика: обе конфигурации получают 100% тестовых запросов.
• Обычно длится 1–2 часа.
• Выполняется до конца, без досрочных проверок на предмет сбоев.

Рисунок 7. Схема синтетического эксперимента

Эксперимент в production:

• Проводится в production на реальном пользовательском трафике, распределённом между тремя кластерами:
  ◦ около 90% остаётся в основном кластере (текущая производственная конфигурация).
  ◦ около 5% направляется в базовый кластер (текущая производственная конфигурация).
  ◦ около 5% направляется в экспериментальный кластер (рекомендованная конфигурация).
• Рекомендации проверяются на кластере базовой конфигурации сопоставимого размера, а не на основном кластере, чтобы сохранить сходные профили трафика.
• Обычно длится от одного дня до одной недели в зависимости от объёма трафика.
• Быстро прекращается при проблемах: эксперимент отменяется досрочно, если обнаружено ухудшение показателей.

Рисунок 8. Схема эксперимента в production

Платформа Stratum проводит и другие эксперименты одновременно с экспериментами SRT. Чтобы не дробить трафик чрезмерно, эксперименты SRT получают более низкий приоритет и уступают ресурсы активным экспериментам с более высоким приоритетом.

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

Вернёмся к рекомендации по памяти для VideoEncoder.encodeV1 (18 000 МБ → 15 300 МБ). Проверка запускается со следующими параметрами:

{
  "recommendationId": "2edb734a-6184-4f5e-8ffa-23004bd665d7",
  "syntheticExperiment": { "numberOfExecutions": 3000 },
  "productionExperiment": {
    "enabled": true,
    "maxContainers": 20, // max containers shift to baseline & experimental clusters
    "upGateTimeoutMinutes": 10080, // time to wait for traffic to start flowing
    "maxRunDurationMinutes": 1240, // max time to run the experiment once traffic starts
    "minSamples": 500 // min executions needed on both clusters before evaluating
  }
}

На обоих этапах проверки рекомендации проходят две последовательные проверки; при неудаче любой из них эксперимент немедленно прекращается:

• Повторные запуски с увеличенными ресурсами: в ходе эксперимента сокращение памяти и диска ограничено порогом повторных запусков не более 1%.
• Время выполнения: сравнивается медианное время выполнения, чтобы исключить искажение результата выбросами. В зависимости от нагрузки допускается замедление на 10–15% относительно базового значения; предел можно настроить отдельно для каждой функции.

Если рекомендация проходит оба этапа проверки, SRT меняет её статус на APPLIED и внедряет конфигурацию в основной производственный кластер. Если на любом этапе не пройдена проверка, SRT помечает рекомендацию как REJECTED и сохраняет существующую конфигурацию. Оба результата сопровождаются уведомлениями от SRT.

Функция VideoEncoder.encodeV1 успешно прошла оба этапа:

{
  "outcome": "APPLIED",
  "syntheticExperiment": {
    "result": "SUCCESS",
    "samples": { "baseline": 3000, "experimental": 3000 },
    "medianExecutionSecs": { "baseline": 59.0, "experimental": 59.0 },
    "slownessIncreasePct": 0.0,
    "retryRatePct": { "baseline": 0.0, "experimental": 0.0 }
  },
  "productionExperiment": {
    "result": "SUCCESS",
    "samples": { "baseline": 50361, "experimental": 49790 },
    "medianExecutionSecs": { "baseline": 196.0, "experimental": 198.0 },
    "slownessIncreasePct": 1.0,
    "retryRatePct": { "baseline": 0.0, "experimental": 0.0 }
  }
}

Рекомендация перешла в состояние APPLIED, и объём памяти, выделяемой функции VideoEncoder.encodeV1, был окончательно установлен на уровне 15 300 МБ. Рекомендация по CPU также прошла проверку без проблем: выделение CPU сократилось с 8 ядер до 4.

Мониторинг после внедрения

Успешное прохождение экспериментов не означает завершения жизненного цикла рекомендации. Обновление кода функции, изменение входных параметров или перемены в вычислительной среде (Titus/EC2) со временем могут повлиять на работу в production. Чтобы обеспечить безопасность конфигурации и стимулировать внедрение новых возможностей, мы наладили непрерывный мониторинг изменений после их применения.

Мы отслеживаем метрики в течение 90 дней, используя два скользящих временных окна: быстрое — 30 минут и медленное — 24 часа. Для каждого окна заданы собственные пороговые значения оповещения: автоматическое уведомление отправляется, если доля повторных запусков превышает 3% за 30 минут или 2% за 24 часа.

При стабильной работе доля повторных запусков обычно составляет около 0,1%; значения до 2–3% остаются в пределах приемлемых операционных колебаний. Большинство внедрённых рекомендаций сохраняли стабильность в течение последних трёх месяцев.

Функция VideoEncoder.encodeV1 уже несколько месяцев работает с оптимизированной конфигурацией, не превышая пороговых значений. Однако функция VideoEncoder.encodeV2 выявила сложный нестандартный случай: сокращение объёма памяти на 50% прошло все проверки, и функция стабильно работала две недели, но затем неожиданный сдвиг трафика поднял долю повторных запусков выше 60%.

Рисунок 9. Неожиданный всплеск повторных запусков

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

Теперь пороговые значения для двух окон автоматического отката выглядят так:

• Последние 30 минут: при доле повторных запусков 3% отправляется предупреждение, а при 10% запускается автоматический откат.
• Последние 24 часа: доля повторных запусков 2% приводит и к отправке уведомления, и к автоматическому откату.

При превышении порога для автоматического отката конфигурация функции немедленно возвращается к исходному состоянию до применения рекомендации.

Рисунок 10. Автоматический откат рекомендации

Мы намеренно используем простую логику отката: возвращаем последнюю известную стабильную конфигурацию, а не пытаемся динамически менять ресурсы во время инцидента.

Инцидент с VideoEncoder.encodeV2 также заставил нас пересмотреть правила формирования рекомендаций для памяти и диска. Вместо немедленного применения полного целевого сокращения SRT теперь вводит меньшие, постепенные изменения на 15% и переходит к следующему шагу, только убедившись в стабильности после предыдущего. Кроме того, мы добавили глобальный выключатель, который позволяет отключить автоматическую оптимизацию ресурсов для всех функций при возникновении неожиданных проблем или побочных эффектов.

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

Где мы сейчас

Избыточно крупные контейнеры и расхождения конфигураций не должны становиться неизбежной платой за масштабное выполнение бессерверных нагрузок. Создав Stratum Resource Tuner, мы превратили ручной, чрезмерно осторожный подбор ресурсов в автоматизированный конвейер с самовосстановлением. На реальных нагрузках и благодаря непростым урокам, вынесенным из неожиданных всплесков, мы доказали, что непрерывная оптимизация ресурсов позволяет безопасно значительно повысить эффективность инфраструктуры.

Сначала мы сосредоточились на оптимизации нагрузок по кодированию видео с высокой пропускной способностью, поставив цель сократить общие расходы Stratum на вычислительные ресурсы на 5%. Например, в функции VideoEncoder.encodeV1 удалось сократить использование CPU на 50%, а памяти — на 40%, не ухудшив производительность и не увеличив долю повторных запусков.

Однако нестандартные случаи, подобные ситуации с VideoEncoder.encodeV2, помогли нам сделать важные выводы: резкое сокращение ресурсов одним шагом может создавать скрытые риски, а ручное реагирование на инциденты замедляет восстановление. Эти выводы побудили нас ввести более строгие ограничения безопасности в Stratum Resource Tuner: ограничить сокращение памяти и диска до 15% за цикл и добавить автоматический откат при превышении пороговой доли повторных запусков. Благодаря этим мерам повторная настройка VideoEncoder.encodeV2 позволила стабильно сократить использование памяти на 20%, и с тех пор новых инцидентов не возникало.

В дальнейшем мы сосредоточимся на следующих задачах:

• Расширить применение SRT за пределами нагрузок по кодированию с высокой пропускной способностью и поддержать больше типов функций и нагрузок.
• Дополнительно оптимизировать ресурсы в регионах с ограниченной доступностью вычислительных мощностей.
• Перейти от реактивных оповещений к упреждающему автоматическому увеличению ресурсов для функций с недостаточным выделением мощностей.
• Проверить, даст ли намеренное увеличение ресурсов для чувствительных к задержкам нагрузок прирост производительности и сократит ли время выполнения функций.
• Усовершенствовать сигналы о сбоях OOM/OOD, превратив запаздывающие индикаторы в опережающие, чтобы повысить точность настройки.

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

Благодарности

Особая благодарность Олофу Йоханссону, Якубу Карчевскому, Адаму Мазуру, Итану Матьё, Розанне Ли, Амея Васани, Жану Баркхёйсену, Полу Иеромнимону и Адитье Пракашу.

Обработка медиаконтента в Netflix Stratum: автоматический подбор оптимальных размеров контейнеров — статья, впервые опубликованная в Netflix TechBlog на Medium, где читатели продолжают обсуждение, выделяя фрагменты и отвечая на них.

© Netflix Tech Blog