Масштабировать систему видеонаблюдения (video management system, VMS) со 100 до 10 000 камер — это не просто «то же самое, только больше», а принципиально другая архитектура. В 2026 году ключевыми решениями остаются пять: приём видеопотоков, уровни хранения, распределение вычислений между edge и облаком, стратегия транскодинга и политика автоскейлинга. Если все пять приняты правильно, всё остальное — мониторинг, соответствие требованиям, стоимость — выстраивается само собой. Ошибитесь хотя бы в одном — и система не выдержит даже 500 одновременных потоков.
Горизонтальная масштабируемость VMS в 2026 году означает: микросервисы, запись на edge, поддержку смешанных кодеков AV1/Н.265 и 10 000+ камер на кластер. Milestone XProtect, Genetec Security Center 5.12+ и Eagle Eye Networks — три эталонных решения, которые предлагают такую функциональность по цене, не требующей индивидуального RFP.
Главное
- Пять инженерных решений: набор протоколов приёма, стратификация хранения (горячий/тёплый/холодный), распределение инференса между edge и облаком, подход к работе с кодеками и транскодингом, политика триггеров автоскейлинга.
- Переход с монолита на микросервисы перестаёт быть опциональным начиная с 1 000+ потоков. Независимое масштабирование сервисов приёма, хранения, аналитики и пользовательского интерфейса — минимальная жизнеспособная архитектура.
- Гибрид edge + облако — стандарт 2026 года: обработка на камере и анализ в облаке выгоднее чистого облака по трафику и глубже, чем только edge.
- Стоимость хранения удваивается каждые 18 месяцев глубины архива. Тарифное объектное хранилище класса S3 с автоматическим повышением приоритета по событиям — единственная устойчивая модель на больших объёмах.
- Наблюдаемость — до масштаба, а не после. Метрики, трейсы и синтетические проверки здоровья нужно настроить до 500 потоков — после этого вы будете отлаживать вслепую.
Почему этот гид написала Фора Софт
Компания «Фора Софт» занимается системами видеонаблюдения с 2005 года. Одной из таких систем является V. A. L. T., которая сегодня обслуживает более 650 организаций в США — полицейские департаменты, университеты, клиники поведенческой медицины — с более чем 25 000 ежедневных пользователей и тысячами одновременных видеопотоков с камер. Этот гид — итог нашего опыта внедрения V. A. L. T. и других платформ VMS при масштабировании с 0 до 1 000 камер и с 1 000 до 10 000 камер. Описанные ниже сценарии сбоев мы устраняли в три часа ночи, а не читали о них в статьях других авторов.
Облачная архитектура нужна, когда: у вас более 50 камер или несколько объектов. Гибрид edge + облако эффективнее чистого NVR.
Планируете VMS-платформу?
Мы проектируем и запускаем архитектуры VMS для продакшена, которые масштабируются от 100 до 10 000+ камер.
Расскажите о целевом масштабе, регионе требований и составе камер. Мы вернёмся с эталонной архитектурой и поэтапным планом запуска за один созвон.
Решение 1 — Набор протоколов приёма
Каждая камера и каждый поток в вашей VMS используют один из четырёх протоколов. Поддержка всех четырёх нативно — базовый минимум; правильный выбор протокола по умолчанию для новых подключений — уже инструмент влияния.
| Протокол | Задержка | Подходит для | На что обратить внимание |
|---|---|---|---|
| RTSP | ~200–500 мс | Старые IP-камеры, развёртывания в LAN | Сложности с NAT, отсутствует встроенная аутентификация |
| WebRTC | ~80–200 мс | Живой мониторинг, дашборды операторов | Сложная эксплуатация SFU на масштабе |
| LL-HLS / DASH | ~2–4 с | Раздача публичной аудитории через CDN | Не подходит для интерактивного управления |
| SRT / RTMP | ~1–3 с | Подача контента, удалённые камеры | Нет нативной поддержки в браузерах (RTMP отключён в Chrome) |
Наш дефолт 2026 года для VMS с нуля: WebRTC для живого просмотра оператором, LL-HTTP для раздачи на публичную аудиторию, RTSP для приёма со старых камер, SRT для подачи с удалённых точек. Пропускайте все четыре через единый медиасервер (Flussonic, Wowza или собственное решение на Pion + Go), который выполняет нормализацию протоколов и переупаковку на выходе. Не пытайтесь выбрать один протокол — производители камер и зрительские приложения всё равно вынудят вас поддерживать все.
Решение 2 — Тире в хранении
Хранение составляет 40–60 % общей стоимости владения VMS при больших объёмах. Самая частая ошибка — запись всего видео на горячее хранилище с максимальным битрейтом «на всякий случай». Через полгода это приводит к обрыву глубины архива, а счёт за месяц удваивается.
Откажитесь от закрытых экосистем: ONVIF + RTSP больше не обсуждаются. Зависимость от одного поставщика в 2026 году — это красный флаг при закупках.
01
Горячий тир — последние 7 дней
Объектное хранилище на SSD (S3 Standard, GCS Standard) или локальные NVMe для on-prem. Полный битрейт, индексация по событиям и времени. Задержка извлечения — до 100 мс. Здесь возможен прямой просмотр и оперативная реакция на инциденты.
02
Тёплый тир — с 8 по 90 день
S3 Infrequent Access или GCS Nearline. Перекодировка в более низкий битрейт (обычно 30–40 % от «горячего»), если регулятор не требует сохранять полное качество. Задержка извлечения — секунды, а не миллисекунды. По запросу помеченные событиями фрагменты автоматически переводятся обратно в «горячий» тир.
03
Холодный тир — старше 90 дней
S3 Glacier Instant или Glacier Flexible Retrieval. Архив уровня соответствия (HIPAA, GDPR, CJIS) без стоимости хранения в горячем тира. Извлечение — от 1 до 12 часов, оплата отдельно. На большинстве VMS-нагрузок 90 % данных после 90 дней хранятся именно здесь.
04
Повышение TIR по событию
AI-детектирование аномалий, ручные закладки и отчёты об инцидентах автоматически возвращают соответствующие временные окна в горячее хранилище. Именно это делает тиринг совместимым с расследовательскими сценариями — операторы не ждут извлечения данных из холодного тира по флагу события.
Ориентировочная математика стоимости: один поток 1080p при 2 Мбит/с потребляет около 22 ГБ в сутки. На 1 000 камер и 90 дней горячего архива это примерно 1,98 ПБ. На AWS S3 Standard по 1,72 ₽/ГБ в месяц это около 3,3 млн ₽ в месяц только за хранение. Если перевести те же данные на схему 7/83 дней — горячий/тёплый архив — при 30 % битрейта на тёплом, счёт снижается до примерно 1 млн ₽ в месяц. За год одно это решение даёт экономию около 27 млн ₽.
Решение 3 — Распределение вычислений между edge и облаком
Место, где выполняется инференс — на камере, на edge-устройстве или в облаке, — определяет главную составляющую стоимости трафика и задержки аналитики.
| Где выполняется | Задержка | Трафик | Потолок модели |
|---|---|---|---|
| На камере | <50 мс | Минимальный (только метаданные) | YOLOv8-nano, на базе MobileNet |
| Edge-устройство (локально) | 100–300 мс | Низкий (только LAN) | YOLOv8-medium, ResNet, Whisper |
| Региональное облако | 500 мс–2 с | Высокий (полная загрузка потока) | Любая — VLM, большие диффузионные модели |
Выигрывающая схема 2026 года: edge-first с эскалацией в облако. Модели на камере отсекают 99 % кадров (движение, базовый класс объектов). На edge-устройствах работают модели среднего размера для всего, что было помечено. Только клипы целиком с низкой уверенностью отправляются в облачную VLM для глубокого анализа. Это сокращает исходящий трафик на 90–95 % по сравнению с наивным подходом «загружаем всё» и при этом сохраняет доступ к самой глубокой аналитике.
Подвох
Не полагайтесь на встроенный ИИ камер, если вам нужны обновления модели. Большинство камер поставляются с «замороженным» чипом для инференса — переобучить их на своих данных невозможно. Чтобы получить реальный эффект от ИИ, запускайте инференс на edge-устройстве в вашей системе — например, на Jetson или в коробке с OpenVINO, — даже если камеры уже имеют встроенный ИИ. Воспринимайте ИИ на стороне камеры как бесплатный бонус, а не как основной аналитический слой.
Решение 4 — Стратегия по кодекам и транскодированию
Транскодинг — это место, где VMS-системы тихо съедают неограниченные вычисления. Чтобы держать его в рамках, достаточно двух правил:
Приоритеты AI-аналитики: сначала распознавание объектов, потом выявление аномалий, затем поиск по атрибутам — это снижает операционные расходы более чем на 50 %.
Правило 1 — Запишите один раз, транскодируйте по запросу
Храните оригинальный кодек камеры (обычно H.264 или H.265) в исходном битрейте. Варианты с пониженным разрешением создавайте только по запросу зрителя и кэшируйте на короткий срок. Заранее генерировать полную ABR-лестницу для каждой камеры — самый быстрый способ получить шестизначный счёт за вычисления в месяц при масштабировании.
Правило 2 — Разгружайте через аппаратные кодировщики
NVIDIA NVENC, Intel Quick Sync и Apple VideoToolbox обеспечивают пропускную способность в 10–30 раз выше, чем кодирование x264 на CPU, при сопоставимом качестве. На AWS одна машина g5.2xlarge справляется с 30–50 одновременными живыми транскодами, для которых на CPU потребовалась бы c5.12xlarge. Учитывайте это при планировании бюджета — как важную статью капитальных или операционных расходов, а не как «остаточный» пункт.
AV1 готов — сначала для холодного тира
Аппаратное кодирование AV1 (NVIDIA Ada, Intel Arc Battlemage, AMD RDNA4) теперь работает в реальном времени. AV1 обеспечивает экономию битрейта на 30–40 % по сравнению с H.265 при одинаковом качестве — это большой плюс для систем видеонаблюдения, где основное место занимает хранение. План на 2026 год: при ротации после приёма транскодировать клипы из тёплого и холодного тира в AV1. Горячий тир оставляйте в H.264/265 — так будет проще воспроизводить на старых клиентских устройствах.
Решение 5 — Политика триггеров автоскейлинга
VMS-нагрузки по своей природе скачкообразны: разборы в конце смены, реакция на инциденты, плановые выгрузки из архива. Автоскейлинг по CPU здесь слишком медленный. Лучше работают два других триггера:
Триггер A — количество потоков на медиа-узле
Когда любой медиасервер достигает 80 % от ёмкости, проверенной нагрузочными тестами, в потоках на узел, добавьте новый узел и направляйте на него новые подключения. Реакция должна занимать десятки секунд, а не минуты.
Триггер B — Глубина очереди на воркерах транскодинга
Вместо CPU воркера (запаздывающий показатель) следите за бэклогом заданий транскодинга. Когда глубина очереди превышает типичное окно обработки в 5 минут, масштабируйте воркеров горизонтально. Когда она 15+ минут держится ниже спокойного порога, скейльте вниз.
Сочетайте это со spot/прерываемыми инстансами для stateless-воркеров транскодинга (могут завершиться в любой момент — очередь автоматически возобновит работу) и зарезервированными инстансами для медиасерверов (stateful, миграция затратна). Типичная экономия: 40–60 % на вычислениях транскодинга по сравнению с полностью on-demand.
Не уверены, что это подходит вам?
Мы проверим вашу текущую или планируемую архитектуру по этим пяти решениям.
Поделитесь целевым масштабом и ограничениями. На выходе — одностраничный gap-анализ и приоритизированный список исправлений. Без обязательств.
Декомпозиция на микросервисы, которая работает
После ~500 одновременных потоков монолитная VMS превращается в риск для развёртывания — один неудачный релиз одновременно блокирует живой мониторинг, хранение и управление пользователями. Декомпозиция, которую мы запускаем чаще всего:
Частый сценарий отказа: игнорировать стратегию хранения. Умная политика глубины архива снижает расходы на хранение на 60–80 %.
| Сервис | Ответственность | Ось масштабирования |
|---|---|---|
| Приём | Принимает RTSP/WebRTC/SRT, преобразует в единый внутренний формат | Количество потоков |
| Медиа-роутер (SFU) | Маршрутизирует живые потоки операторским клиентам | Одновременные зрители |
| Writer хранилища | Нарезает на чанки, шифрует и сохраняет в объектное хранилище | ГБ/с приёма |
| Воркер транскодинга | Варианты пониженного разрешения, конверсия в AV1 для тёплого тира | Глубина очереди |
| Аналитика | Запускает AI-инференс, генерирует события | Кадров в секунду |
| Метаданные / поиск | Индексирует события, клипы и закладки, обрабатывает поисковые запросы | QPS запросов |
| Идентификация / RBAC | Аутентификация, авторизация, мультитенантная изоляция | Количество пользовательских сессий |
| Уведомления | Алёрты в реальном времени в операторские UI, на почту, в вебхуки | Событий в секунду |
У каждого сервиса — своя ось масштабирования, своя база данных (или шард БД) и свой график обновлений. Ошибка в релизе воркера транскодинга больше не ломает весь живой мониторинг. Kubernetes, service mesh (Istio, Linkerd) и событийный стриминг (Kafka или NATS JetStream) — типичная платформенная основа 2026 года.
Кейс: V.A.L.T. — архитектура из пяти решений в более чем 650 организациях
V.A.L.T. — платформа видеонаблюдения от Форсофт, которую используют более 650 организаций в США: полицейские управления, университеты, медицинские учреждения и клиники поведенческой медицины. Система применяется для записи допросов, анализа тренингов и клинического супервайзинга. Платформа обслуживает более 25 000 пользователей ежедневно и поддерживает тысячи одновременных видеопотоков с камер.
Как пять решений реализованы в V. A. L. T.:
- Набор протоколов приёма: RTSP + ONVIF для камер, WebRTC для просмотра оператором в реальном времени, SRT для удалённых комнат подачи.
- Срок хранения: 7 дней — горячий, 83 дня — тёплый, 7 лет — холодный для записей допросов в соответствии с требованиями CJIS и HIPAA. Уведомление о повышении по событию отображается в интерфейсе управления делами.
- Edge/облако: устройства на уровне комнаты обрабатывают распознавание движения и отслеживание участников; облако отвечает за распознавание речи, разделение говорящих и поиск по материалам дела.
- Транскодинг: H.264 с ускорением NVENC для прямого эфира, конвертация в AV1 при перемещении в тёплый тир — экономия места на хранении около 35 %.
- Автоскейлинг: триггеры по количеству потоков для медиа-узлов; триггеры по глубине очереди для воркеров транскодинга; смешанный парк из reserved и spot-инстансов.
Платформа обеспечивает доступность 99,95 % и задержку менее 200 мс по регионам США. Подключение новой организации — обычно с 50–500 камерами — занимает один день и не требует отдельного проекта развёртывания.
Наблюдаемость до масштабирования, а не после
Самые болезненные провалы масштабирования VMS, с которыми мы сталкивались, объединяет одно: наблюдаемость добавляли уже после того, как система начала тормозить, а не закладывали в архитектуру с самого начала. Четыре телеметрических поверхности, которые должны быть заложены ещё до достижения 500 одновременных потоков:
- Метрики здоровья по каждому потоку (принятые кадры, доставленный битрейт, потери пакетов, задержка публикации сегмента) — как временные ряды в Prometheus с лейблами по камерам.
- Сквозные trace ID, которые проходят с кадра от приёма через транскодинг до записи в хранилище. OpenTelemetry с частотой семплирования, которую можно увеличить до 100 % на время расследования.
- Синтетические проверки, которые непрерывно получают эталонный поток из каждого региона и проверяют задержку воспроизведения, разрешение и корректность декодирования. Они выявляют скрытые сбои, по которым ещё ни один оператор не создал заявку.
- Шаблоны доступа к хранилищу — какие временные диапазоны, какие камеры и какие пользователи обращаются к горячему, тёплому и холодному тиру. Эти данные позволяют ежеквартально перенастраивать политику тиринга по мере изменения нагрузки.
Соответствие требованиям — это архитектурное ограничение, а не чек-лист
HIPAA, GDPR, CJIS и отраслевые регуляторы (FERPA для образования, PCI для ритейла) влияют на архитектуру VMS, а не только на политики. Повторяющиеся требования: шифрование при передаче (TLS 1.3) и в состоянии покоя (AES-256- GCM с ключами, которыми управляет клиент), хранение данных в привязке к региону (данные из ЕС не покидают территорию ЕС), неизменяемость логов аудита (только добавление записей с криптографической пломбой) и RBAC, позволяющий точно ограничивать права — вплоть до уровня камеры и временного интервала — в соответствии с принципом минимальных привилегий.
Два архитектурных паттерна, которые стоит заложить с самого начала: (1) пер-тенантные ключи шифрования в KMS — чтобы взлом данных одного клиента не затрагивал других; (2) регионально-зависимая маршрутизация на уровне приёма — чтобы камера в европейской сети ни при каких условиях не отправляла кадры через инфраструктуру в США, независимо от того, где залогинен оператор. Дорабатывать это позже — проект на несколько месяцев; реализовать в первой версии — несколько дней работы инженеров.
Сравнительная матрица: создать, купить, гибрид или open source для масштабируемой системы управления видео
Быстрая сетка решений по четырём типичным сценариям 2026 года. Выбирайте строку, которая соответствует размеру вашей команды, регуляторной среде и целевому сроку выхода — а не ту, что звучит амбициознее.
| Подход | Подходит для | Усилия на запуск | Срок выхода | Риски |
|---|---|---|---|---|
| Готовый SaaS | Команды до 10 инженеров, типовой сценарий | Низкие (1–2 недели) | 1–2 недели | Vendor lock-in, ограничения по доработкам |
| Гибрид (SaaS + кастомный слой) | Средний рынок, смешанные сценарии | Средние (1–2 месяца) | 1–3 месяца | Интеграционный долг, две системы на поддержке |
| Разработка на заказ (современный стек) | Энтерпрайз, уникальные данные или требования соответствия | Высокие (3–6 месяцев) | 6–12 месяцев | Скорость инженерной команды, удержание сотрудников |
| Open source на собственной инфраструктуре | Чувствительные к стоимости, технически сильные команды | Высокие (2–4 месяца) | 3–6 месяцев | Эксплуатационная нагрузка, регулярные обновления безопасности |
Часто задаваемые вопросы
Сколько одновременных потоков с камер тянет один медиасервер?
Зависит от кодека, разрешения и от того, декодирует ли сервер потоки или просто ретранслирует. Один узел Wowza / Flussonic / Janus / Pion на AWS c5.4xlarge обычно справляется с 200–500 одновременных потоков 1080p H.264 в режиме ретрансляции и падает до 50–150 при декодировании для AI или транскодинге. Проверяйте свои цифры нагрузочным тестом перед тем, как закладывать их в план — бенчмарки вендоров часто оптимистичнее реальности.
Какая реальная стоимость хранения для VMS на 1 000 камер с архивом 90 дней?
При 2 Мбит/с на поток, 1 000 камер и 90 днях хранения объём данных составит около 2 ПБ. На AWS S3 Standard это обойдётся примерно в 3,3 млн ₽ в месяц. На схеме с 7 днями горячего и 83 днями тёплого хранения при снижении битрейта на тёплом уровне до 30 % стоимость падает до ~1 млн ₽ в месяц. Добавив холодный архив на год, общая стоимость хранения на одну камеру в месяц опускается ниже 1 100 ₽ — такой уровень затрат достижим и предсказуем.
Когда переходить с монолита на микросервисы?
Конкретный триггер: когда время деплоя превышает 10 минут или когда один неудачный релиз уже дважды блокировал живой мониторинг. Обычно это происходит при 300–700 одновременных потоках. Не переходите на микросервисы «просто потому что так архитектурно правильно» — эксплуатационные издержки преждевременной декомпозиции могут подорвать небольшие команды.
Нужен ли нам Kubernetes для VMS?
До 1 000 одновременных потоков и при одном регионе — нет. Docker Compose плюс systemd плюс балансировщик нагрузки проще и дешевле. Выше 1 000 потоков или при нескольких регионах Kubernetes становится оправданным: примитивы автоскейлинга, выкаток и service discovery окупают свои эксплуатационные издержки. EKS/ GKE/ AKS лучше самосборного контрольного плана, если у вас нет сильной платформенной команды.
Как сделать мультитенантную изоляцию в общем облаке VMS?
Три слоя: (1) пер-тенантные ключи шифрования в KMS, чтобы данные в объектном хранилище были криптографически изолированы; (2) row-level security в БД метаданных или отдельные схемы под тенант; (3) RBAC, который применяется на API-гейтвее, а не только в UI. Аудит-логи должны помечать каждую попытку межтенантного доступа. Не полагайтесь на код приложения как на единственный механизм изоляции — одна ошибка может привести к межтенантной утечке данных.
Можно ли отказаться от облака и хранить всю VMS локально?
Да, и для части регулируемых нагрузок (оборона, отдельные сегменты здравоохранения) это вообще единственный вариант. Пять решений выше остаются в силе — просто вместо S3 используется MinIO/ceph, вместо EKS — on-prem Kubernetes, а вместо g5-инстансов — физические NVENC-GPU. Закладывайте 2–3× инженерных усилий на первоначальный запуск платформы и её эксплуатацию; логическая архитектура остаётся той же.
Читайте далее
Функционал VMS
12 ключевых функций современной VMS в 2026 году
Какие возможности должна давать масштабируемая VMS — после того как под капотом выстроена правильная архитектура.
Мобильные SDK
Лучшие Android SDK для приложений видеонаблюдения в 2026 году
Какой мобильный SDK подключать к клиенту VMS — с той же стоимостью, задержкой и соответствием требованиям.
AI-аналитика
Тренды Android-видеонаблюдения 2026: 5 функций на основе ИИ
Как выглядит аналитический слой поверх архитектуры, описанной в этом гиде.
Источники
- Документация AWS по классам хранения и производительности S3, 2026.
- Матрица поддержки NVIDIA NVENC/NVDEC (архитектуры Ada, Blackwell).
- Эталонные материалы Alliance for Open Media по внедрению кодека AV1.
- CNCF Cloud Native Storage Landscape, выпуск 2026 года.
- Внутренние метрики продакшен-развёртывания Фора Софт V. A. L. T.
Резюмируя — пять решений, а не пять функций
Дизайн масштабируемой VMS в 2026 году — это не про выбор лучшего производителя камер или самого большого облака. Это про то, чтобы заранее принять пять архитектурных решений: приём, уровни хранения, распределение между edge и облаком, транскодинг, автоскейлинг — и заложить наблюдаемость и соответствие требованиям в основу системы, а не добавлять их потом.
Платформы, которые масштабируются до 10 000+ камер, — это не те, у кого больше всего функций. Это те, где команда основателей с самого первого дня приняла пять ключевых решений правильно, а всё остальное сложилось вокруг них.
Строите свою VMS?
Дайте нам нагрузочно проверить вашу архитектуру до выхода в продакшен.
Фора Софт запускала VMS-платформы — от пилотных проектов на 100 камер до полноценных развёртываний на 10 000+ камер. Свяжитесь с нами: либо подтвердим ваш план, либо укажем на два сценария, при которых он с большой вероятностью не сработает на больших масштабах.
