Масштабировать систему видеонаблюдения (video management system, VMS) со 100 до 10 000 камер — это не «то же самое, только больше», это другая архитектура. В 2026 году ключевых решений пять: приём потоков, тиринг хранения, распределение вычислений между edge и облаком, стратегия транскодинга и политика автоскейлинга. Если эти пять решений приняты верно, всё остальное — наблюдаемость, соответствие требованиям, стоимость — складывается само. Ошибётесь хотя бы в одном — система ляжет в тот день, когда вы пересечёте отметку в 500 одновременных потоков.
Горизонтальная масштабируемость VMS в 2026 году означает: микросервисы, запись на edge, поддержку смешанных кодеков AV1/H.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-HLS для раздачи на публичную аудиторию, RTSP для приёма со старых камер, SRT для подачи с удалённых точек. Пропускайте все четыре через единый медиасервер (Flussonic, Wowza или собственное решение на Pion + Go), который выполняет нормализацию протоколов и переупаковку на выходе. Не пытайтесь выбрать один протокол — производители камер и зрительские приложения всё равно вынудят вас поддерживать все.
Решение 2 — Тиринг хранения
Хранение составляет 40–60 % совокупной стоимости владения VMS на больших объёмах. Самая частая ошибка, которую мы видим: всё записывают на горячее хранилище с полным битрейтом «на всякий случай» и через полгода упираются в обрыв глубины архива, когда счёт за месяц удваивается.
Откажитесь от закрытых экосистем: ONVIF + RTSP больше не обсуждаются. Vendor lock-in в 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
Повышение тира по событию
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 % по сравнению с наивным пайплайном «загружаем всё» и при этом сохраняет доступ к самой глубокой аналитике.
Подвох
Не полагайтесь на встроенный AI камер, если вам нужны обновления модели. Большинство камер выходят с замороженным чипом инференса, и переобучить их на своих данных нельзя. Чтобы получить ощутимый эффект от AI, запускайте инференс на edge-устройстве вашего контроля — Jetson или коробке с OpenVINO, — даже если у камер уже есть AI. Воспринимайте AI на стороне камеры как бесплатный бонус, а не как основной аналитический слой.
Решение 4 — Стратегия по кодекам и транскодингу
Транскодинг — это место, где VMS-системы тихо съедают неограниченные вычисления. Чтобы держать его в рамках, достаточно двух правил:
Приоритеты AI-аналитики: сначала детекция объектов, потом флаги аномалий, затем поиск по атрибутам — это срезает операционные расходы более чем на 50 %.
Правило 1 — Запишите один раз, транскодируйте по запросу
Храните оригинальный кодек камеры (как правило, H.264 или H.265) на исходном битрейте. Варианты с пониженным разрешением генерируйте только тогда, когда конкретный зритель их запросил, и кэшируйте на короткое окно. Заранее собирать полную ABR-лестницу для каждой камеры — кратчайший путь к шестизначному счёту за вычисления в месяц на масштабе.
Правило 2 — Разгружайте через аппаратные кодировщики
NVIDIA NVENC, Intel Quick Sync и Apple VideoToolbox дают пропускную способность в 10–30× выше, чем CPU x264, при приемлемом качестве. На AWS одна машина g5.2xlarge тянет 30–50 одновременных живых транскодов, для которых на CPU потребовалась бы c5.12xlarge. Закладывайте это в бюджет как первоклассную статью капитальных или операционных затрат, а не «по остаточному принципу».
AV1 готов — сначала для холодного тира
Аппаратное кодирование AV1 (NVIDIA Ada, Intel Arc Battlemage, AMD RDNA4) теперь работает в реальном времени. AV1 даёт 30–40 % экономии битрейта по сравнению с H.265 при том же качестве — огромный плюс для VMS-нагрузок, где доминирует хранение. Ход 2026 года: транскодировать клипы тёплого и холодного тира в AV1 при ротации после приёма. Горячий тир оставляйте в H.264/H.265 для совместимости декодирования со старыми клиентскими устройствами.
Решение 5 — Политика триггеров автоскейлинга
VMS-нагрузки по своей природе скачкообразны: разборы в конце смены, реакция на инциденты, плановые выгрузки из архива. Автоскейлинг по CPU здесь слишком медленный. Лучше работают два других триггера:
Триггер A — Количество потоков на медиа-узел
Когда любой медиасервер пересекает 80 % валидированной нагрузочными тестами ёмкости в потоках на узел, поднимайте новый узел и направляйте новые подключения на него. Реакция — десятки секунд, а не минуты.
Триггер B — Глубина очереди на воркерах транскодинга
Вместо CPU воркера (запаздывающий показатель) следите за бэклогом заданий транскодинга. Когда глубина очереди превышает типичное окно обработки в 5 минут, масштабируйте воркеров горизонтально. Когда она 15+ минут держится ниже спокойного порога, скейльте вниз.
Сочетайте это со spot/preemptible-инстансами для 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. Повышение по событию проброшено в UI управления делами.
- Edge/облако: 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 с ключами, которыми управляет клиент), хранилище, привязанное к региону (данные EU не покидают EU), неизменяемость аудит-логов (append-only с криптографической пломбой) и RBAC, способный гранулярно ограничивать права вплоть до камеры и временного окна по принципу минимальных привилегий.
Два архитектурных паттерна, которые стоит закладывать с первого дня: (1) пер-тенантные ключи шифрования в KMS — чтобы взлом данных одного клиента не каскадировал на остальных; (2) регионально-зависимая маршрутизация на уровне приёма — чтобы камера в европейской сети ни при каких обстоятельствах не отправляла кадры через инфраструктуру в США, независимо от того, где залогинен оператор. Дорабатывать это потом — проект на несколько месяцев; запустить в первой версии — несколько инженерных дней.
Сравнительная матрица: build, buy, гибрид или open source для масштабируемой VMS
Быстрая сетка решений по четырём типичным путям 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 on-prem?
Да, и для части регулируемых нагрузок (оборона, отдельные сегменты здравоохранения) это вообще единственный вариант. Пять решений выше остаются в силе — просто вместо 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 AI-функций
Как выглядит аналитический слой поверх архитектуры, описанной в этом гиде.
Источники
- Документация 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+ камер. Свяжитесь с нами: либо подтвердим ваш план, либо подсветим два сценария, по которым он вероятнее всего сломается на масштабе.
