Масштабирование клинического видео: регионы, мощности и пики нагрузки

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Платформа телемедицины, которая справляется с десятью консультациями в день, может развалиться на десяти тысячах: видео масштабируется не так, как обычное веб-приложение. Его ограничивают пропускная способность канала и то, где физически стоят серверы. Масштабирование клинического видео складывается из трёх задач: распределить нагрузку по множеству медиасерверов (горизонтальное масштабирование), поставить серверы ближе к пациентам в стране с одиннадцатью часовыми зонами (региональная маршрутизация) и иметь запас на дни, когда спрос утраивается (пиковая ёмкость). Для медицинской платформы «регионы» – это российские ЦОДы и облака: записывать и хранить персональные данные граждан РФ в зарубежных базах запрещено (ч. 5 ст. 18 152-ФЗ). Доступность здесь тоже требование, а не просто хороший сервис. Закон обязывает защищать данные от уничтожения и блокирования и уметь их восстанавливать (ст. 19), приказ ФСТЭК № 21 выделяет отдельную группу мер обеспечения доступности, а порядок 193н требует провести экстренную консультацию «врач – врач» в срок от 30 минут до 2 часов. В статье – архитектура, расчёт ёмкости и требования закона, благодаря которым «работает в демо» превращается в «работает в разгар сезона ОРВИ».

Зачем это читать

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

Что значит масштабирование для видео

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

Конкретнее. У каждой платформы реального времени есть ключевой узел. Когда в клиническом видеозвонке двое и более участников, их видео обычно идёт не напрямую, а через медиасервер – чаще всего Selective Forwarding Unit (SFU), который получает видео каждого один раз и пересылает остальным. SFU похож на телефонистку на коммутаторе: она принимает голос каждого абонента и соединяет его со всеми, кому нужно его слышать, вместо того чтобы каждый звонил каждому. Почему для клиники лучше SFU, разобрано в статье P2P, SFU и MCU для клиники. Здесь важно одно: SFU несёт нагрузку, а значит, именно его и придётся масштабировать.

Один SFU – это один компьютер. У него фиксированная вычислительная мощность и, что важнее, фиксированная сетевая ёмкость – канал, через который он отдаёт видео наружу. Когда канал забит, следующая консультация получает не «медленную страницу», а рваное видео, замершие кадры или обрыв звонка. Из-за этого жёсткого потолка масштабирование клинического видео и становится отдельной инженерной дисциплиной, а не вопросом настройки.

Первый потолок: канал одного сервера

Начнём со стоимости одной консультации, потом умножим. Клиническому видеопотоку, достаточному для разговора лицом к лицу, нужно примерно 1,5 мегабита в секунду (Мбит/с) в каждую сторону. (Что значит «достаточно» с клинической точки зрения и когда дерматологии или лечению ран нужно больше – отдельная тема статьи «Задержка, качество и клиническая планка „достаточно хорошо“».)

В консультации на двоих SFU принимает 1,5 Мбит/с от пациента и 1,5 Мбит/с от врача и пересылает каждый поток другой стороне. То есть сервер отдаёт около 3 Мбит/с на каждую идущую консультацию. Посчитаем – результат удивляет:

Отдача на консультацию = 2 участника × 1,5 Мбит/с = 3 Мбит/с
Канал сервера (пример) = 10 Гбит/с = 10 000 Мбит/с
Теоретический максимум = 10 000 ÷ 3 ≈ 3 300 консультаций
Практический максимум (~50%) ≈ 1 600 консультаций

Теоретическое число предполагает, что канал можно заполнить идеально, а это невозможно. Нужен запас на всплески трафика, повторные передачи, ограничения процессора, и есть простое правило: сервер на 95% загрузки вот-вот упадёт. Практический ориентир – половина теоретического потолка. Итак, один хорошо оснащённый медиасервер тянет порядка 1 000–1 600 одновременных консультаций на двоих, а не десять тысяч. Как только в самую загруженную минуту одного сервера не хватает, начинается горизонтальное масштабирование, и большинство растущих платформ доходят до этой черты раньше, чем ожидают.

Горизонтальное масштабирование: много серверов, один маршрутизатор сессий

Горизонтальное масштабирование – это много SFU, и каждая новая консультация отправляется на тот, где есть место. Почти все задачи здесь решаются двумя шаблонами.

Простой и самый частый шаблон держит каждую консультацию целиком на одном SFU. Пациент и врач заходят на один сервер, другая консультация попадает на другой. Компонент под названием маршрутизатор сессий (часть сигнального сервиса) в момент старта звонка выбирает SFU со свободной ёмкостью и назначает звонок туда. Консультация на двоих или в малой группе спокойно помещается на одной машине, поэтому для телемедицины «один на один» почти никогда не нужно ничего сложнее. Вы масштабируетесь, добавляя серверы, а маршрутизатор распределяет между ними звонки. Это базовая архитектура, и её достаточно для подавляющего большинства клинических нагрузок.

Второй шаблон, каскадирование SFU, связывает несколько SFU, чтобы обслужить одну очень большую сессию. Первый сервер принимает видео докладчика и пересылает его другим SFU, каждый из которых раздаёт его своей группе зрителей [14]. Каскад нужен, чтобы провести клинический разбор на тысячу человек или общее собрание сети клиник, где одному серверу-источнику не хватило бы исходящего канала на всех. Для групповых встреч ориентир другой: один SFU тянет примерно 50–200 одновременных комнат в зависимости от числа участников в каждой, и за этим пределом или при нескольких сотнях зрителей в одной комнате переходят на каскад. Большинству платформ телемедицины каскад нужен только для редких крупных образовательных событий, а не для рутинных консультаций. Механика описана в статье WebRTC в масштабе из раздела о видеостриминге. Здесь важно понять, какой шаблон реально нужен вашей нагрузке, чтобы не платить за каскад, которым вы почти не воспользуетесь.

Нажмите, чтобы увеличить

Второй потолок: расстояние и скорость света

Сервер со свободным каналом, но в неправильном месте всё равно даёт плохую консультацию. Разговор в реальном времени зависит от задержки – времени в миллисекундах (мс) между событием перед одной камерой и его появлением на другом экране. Выше определённого порога люди начинают перебивать друг друга, естественный ритм опроса ломается, а невролог при дистанционной оценке инсульта не может надёжно оценить реакцию пациента. По широко используемой рекомендации ITU-T G.114 для интерактивного разговора приемлема односторонняя задержка примерно до 150 мс [11].

Это физический предел, и в России он особенно ощутим. Свет в оптоволокне идёт со скоростью около 200 000 км/с, то есть каждая 1 000 км пути добавляет примерно 5 мс в одну сторону. От Москвы до Владивостока по прямой около 6 400 км, а страна растянута на одиннадцать часовых зон – от Калининграда (МСК−1) до Камчатки (МСК+9). Посчитаем худший, но частый случай: и пациент, и врач во Владивостоке, а единственный медиасервер платформы стоит в Москве. Медиа идёт туда и обратно:

Путь через Москву     = 2 × 6 400 км ≈ 12 800 км (по прямой)
Реальная трасса       ≈ 12 800 × 1,4 ≈ 18 000 км (допущение: кабель длиннее прямой)
Распространение       ≈ 18 000 × 5 мс / 1 000 км ≈ 90 мс
+ захват, кодирование, SFU, декодирование, буфер ≈ 70–80 мс
Итого в одну сторону  ≈ 160–170 мс – за бюджетом 150 мс

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

Где брать регионы – практический вопрос. У Selectel облачные пулы есть в Москве, Санкт-Петербурге и Новосибирске, причём аттестованные сегменты указаны только для Москвы и Санкт-Петербурга [12]; российский регион Yandex Cloud – ru-central1 с несколькими зонами доступности [13]. Зоны доступности одного региона спасают от отказа дата-центра, но не приближают сервер к Хабаровску. Для Дальнего Востока и Сибири проверяйте, у кого из провайдеров есть площадка ближе к вашим пациентам, а где её нет – рассматривайте аренду серверов в региональном ЦОДе. И сразу задавайте второй вопрос: покрывает ли эту площадку нужный вам аттестат.

Нажмите, чтобы увеличить

Регионы и закон: локализация данных

Выбирая, где стоят серверы, вы выбираете и юрисдикцию данных. Видео и аудио консультации – персональные данные о здоровье, то есть специальная категория по ст. 10 152-ФЗ и врачебная тайна по ст. 13 323-ФЗ. Отсюда правило, которое для медицинской платформы закрывает вопрос «а не поставить ли регион за границей».

Хранить – только в России. С 1 июля 2025 года запись, систематизация, накопление и хранение персональных данных граждан РФ с использованием баз данных за рубежом прямо запрещены (ч. 5 ст. 18 152-ФЗ в редакции 23-ФЗ) [1][2]. Штраф для юрлица – до 6 млн ₽, за повторное нарушение – до 18 млн ₽ (ч. 8 и 9 ст. 13.11 КоАП) [2]. Записи консультаций, расшифровки, журналы, бэкапы – всё это должно лежать в российских базах.

Передавать за рубеж – отдельная процедура. Живое медиа, которое идёт через медиасервер или TURN-релей за границей, – это передача данных иностранному получателю. С 1 марта 2023 года до начала трансграничной передачи оператор уведомляет Роскомнадзор и оценивает получателя, а Роскомнадзор вправе передачу запретить или ограничить (ст. 12 152-ФЗ) [1]. Медплатформе проще и безопаснее вообще не открывать этот вопрос: все SFU и TURN – в России, и пациент, который временно находится за границей, подключается к российскому серверу.

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

«Типичная ошибка: «Поднимем TURN-релеи у зарубежного провайдера – там дешевле трафик, перенесём потом». Медиа консультаций уходит за границу без уведомления Роскомнадзора, а если на тех же серверах окажутся логи или записи, это уже прямое нарушение ч. 5 ст. 18. Определитесь с картой регионов до того, как подключите первого пациента: ошибка локализации грозит проверкой, а не просто рефакторингом.»

Третий потолок: пик нагрузки

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

Предсказуемый профиль задают часы работы клиник, и в России он растянут часовыми поясами. Восемь утра во Владивостоке – час ночи по Москве. Если основная аудитория федерального сервиса живёт в европейской части страны, дневной пик совпадает с московским днём, а утренний пик Дальнего Востока приходится на московскую ночь – ровно на то время, когда команда привыкла выкатывать обновления и обслуживать базы. Окно техработ у федеральной платформы – не «ночь по Москве», а узкий промежуток, который выбирают по графику нагрузки всех регионов.

Непредсказуемый профиль – это всплески: тяжёлый сезонный подъём ОРВИ и гриппа или региональная вспышка, из-за которой спрос неделями резко растёт. Именно в такие периоды пациенты чаще выбирают телемедицину вместо поликлиники. Платформа, рассчитанная на обычный вторник, в худший январский понедельник начнёт обрывать звонки.

Посчитаем на примере.

Целевой объём           = 10 000 консультаций в день
Окно работы             = 8 часов = 480 минут
Средняя консультация    = 15 минут
Одновременность (сред.) = (10 000 × 15) ÷ 480 ≈ 312 консультаций сразу
Отдача                  = 312 × 3 Мбит/с ≈ 936 Мбит/с (~1 Гбит/с в среднюю минуту)

Уже среднее требует серьёзной ёмкости, но ориентироваться на него – ловушка. Реальный трафик клиники неравномерен: дневной пик может быть в два-три раза выше среднего за сутки. Применим пик-фактор 2,5×:

Пиковая одновременность = 312 × 2,5 ≈ 780 консультаций сразу
Пиковая отдача          = 780 × 3 Мбит/с ≈ 2 340 Мбит/с (~2,3 Гбит/с)

Теперь добавим сезонный пик, который поднимает спрос ещё на 50%:

Сезонный пик        = 780 × 1,5 ≈ 1 170 консультаций сразу
Отдача на пике      = 1 170 × 3 Мбит/с ≈ 3 510 Мбит/с (~3,5 Гбит/с)

Восьмичасовое окно здесь – допущение для сети клиник в одном часовом поясе. Федеральная платформа растягивает тот же объём на более длинный день, и средняя одновременность у неё ниже, но пик по-прежнему определяет самый загруженный регион в самый загруженный час. В самую загруженную реальную минуту нашему примеру нужно примерно 3,5 Гбит/с исходящей ёмкости и больше тысячи одновременных консультаций – более чем втрое выше комфортного среднего. Подготовиться к этому можно двумя честными способами и одним нечестным.

Нечестный – заложиться под среднее и надеяться на лучшее. Он экономит деньги в спокойные дни и подводит пациентов в худший день, когда вы нужнее всего.

Первый честный способ – статический запас: держать постоянно запущенными столько серверов, чтобы покрыть пик. Это просто и всегда готово, но бóльшую часть года вы платите за простаивающую ёмкость.

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

Нажмите, чтобы увеличить

Доступность – требование к защите данных и к срокам, а не только SLA

Здесь масштабирование из операционной задачи превращается в вопрос соответствия требованиям. Защиту медданных часто сводят к тому, чтобы посторонние ничего не увидели. Но 152-ФЗ требует защищать персональные данные не только от неправомерного доступа и копирования, но и от уничтожения и блокирования (ч. 1 ст. 19), а среди мер прямо называет восстановление данных, модифицированных или уничтоженных вследствие несанкционированного доступа (п. 7 ч. 2) [3]. Доступность, то есть наличие данных в тот момент, когда они нужны врачу, стоит в одном ряду с конфиденциальностью.

Конкретику дают подзаконные акты. ПП 1119 задаёт уровень защищённости системы, а приказ ФСТЭК № 21 – набор мер под него, среди которых отдельные группы «обеспечение целостности» и «обеспечение доступности персональных данных»: отказоустойчивость, резервирование, резервное копирование и восстановление [4][5]. Для медицины добавляется срок: экстренная консультация «врач – врач» по 193н проводится в срок от 30 минут до 2 часов с момента запроса, неотложная – от 3 до 24 часов (п. 19) [7]. Платформа, которая падает на пике или теряет площадку без переключения, нарушает не только свой SLA: она срывает срок, установленный порядком.

Есть и третий слой – критическая информационная инфраструктура. Здравоохранение – сфера КИИ, и с 2026 года информационные системы медорганизаций включены в перечень типовых отраслевых объектов (распоряжение Правительства № 360-р) [9]. Об инциденте на значимом объекте КИИ сообщают в НКЦКИ не позднее 3 часов с момента обнаружения, на иных объектах – в течение 24 часов (приказ ФСБ № 547) [10]. Если ваш продукт работает внутри такой системы, отказ региона – вопрос уже не только доступности, но и отчётности.

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

За изменениями в регулировании стоит следить. В июле 2026 года ФСТЭК опубликовала проект приказа на замену № 21: оценка защищённости до начала обработки, раз в три года и после каждого инцидента, отдельные меры для контейнеров и API, требования к обработчикам [6]. На сентябрь 2026 года проект не подписан – относитесь к нему как к ориентиру, а не к закону, и проверяйте статус, прежде чем ссылаться на сроки. Подробнее – в статье о требованиях к защите ПДн в 2026 году.

Плавная деградация: предохранительный клапан масштабирования

Ни один план ёмкости не выдержит любой всплеск. Доверие сохраняют те платформы, которые отказывают плавно, а не разом. Когда регион подходит к потолку, хорошо построенная система не обрывает звонки случайным образом, а в первую очередь жертвует наименее важной для лечения нагрузкой. Она может снизить разрешение видео прежде, чем оборвать звонок, перейти на только аудио при перегрузке сети или сервера (аудио занимает малую долю канала видео и несёт бóльшую часть клинической ценности разговора) и направить новые консультации в соседний российский регион вместо отказа. Такие механизмы надёжности – основа клинического продукта, и они напрямую связаны с надёжностью соединения и плавной деградацией. Цель простая: при перегрузке пациент теряет в качестве, но не остаётся без помощи.

Контроль затрат: главная статья – исходящий трафик

Решения о масштабировании – это и решения о деньгах, и одна строка в счёте часто перевешивает остальные: исходящий трафик, который провайдер тарифицирует по объёму или по ширине канала. Вся работа медиасервера – отдавать видео наружу, поэтому загруженный SFU генерирует огромный исходящий трафик. Возьмите пиковую отдачу из примера, 3,5 Гбит/с в час пик, и месячный объём передачи окажется настолько велик, что крупнейшей статьёй бюджета станет трафик, а не аренда серверов. Модели тарификации у российских облаков и дата-центров разные, поэтому сверяйтесь с прайсом до выбора площадки. Снизить эту статью помогают три рычага. Держите медиа в пределах региона, чтобы не гонять его через всю страну. Настройте качество видео под клиническую задачу, чтобы не передавать 1080p там, где для диагностики хватает 480p. И выбирайте между своим хостингом и управляемой видеоплатформой осознанно: поминутная цена провайдера уже включает его трафик. Выбор «строить или покупать», включая вопрос, где провайдер хранит данные и готов ли работать по поручению обработки, разобран в статье о выборе видеослоя: свой или CPaaS, а экономика всей платформы – в модели стоимости телемедицины.

Сравнение ёмкости на трёх масштабах

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

Многорегиональный пул в первый день не нужен, но маршрутизатор сессий и управление качеством стоит заложить сразу: доделывать их в разгар сезона ОРВИ – худший момент.

Где здесь Фора Софт

Фора Софт строит видео реального времени на WebRTC с 2005 года – для видеоконференций, стриминга, e-learning, видеонаблюдения и телемедицины. Принципы масштабирования везде общие, но в здравоохранении доступность – это требование к защите данных и к срокам помощи, а не только цель сервиса. Мы проектируем клиническое видео так, чтобы карта регионов укладывалась и в бюджет задержки в стране с одиннадцатью часовыми зонами, и в требования локализации. Пул SFU и маршрутизатор сессий масштабируются горизонтально, с предиктивным запасом под сезонные пики и утренние наплывы в каждом часовом поясе. При перегрузке система переходит на аудио задолго до того, как дело дойдёт до обрыва консультации. Сначала рамка соответствия – российский контур, меры доступности, сроки 193н, – а затем скорость.

Главное

• Видео масштабируют распределением потоков по множеству SFU, а не добавлением веб-серверов без состояния.
• Один медиасервер упирается примерно в 1 000–1 600 одновременных консультаций; дальше нужно горизонтальное масштабирование.
• Региональная маршрутизация удерживает задержку в пределах разговорного бюджета ~150 мс; звонок двух жителей Владивостока через Москву в него не укладывается.
• Регионы медплатформы – российские ЦОДы и облака: хранение за рубежом запрещено, передача за рубеж требует уведомления Роскомнадзора.
• Считайте под пик, а не под среднее; учитывайте утренние наплывы во всех часовых поясах; масштабируйтесь заранее и держите тёплый запас.
• Доступность – требование ст. 19 152-ФЗ и мер приказа ФСТЭК № 21, а сроки консультаций задаёт 193н; переключение между регионами – часть готовности к аварии.

Что читать дальше

• P2P, SFU или MCU: какую топологию выбрать для консультации, групповой сессии и вебинара
• Надёжность соединения: реконнект, смена сети и плавная деградация
• Эталонная архитектура телемедицинского видео: полная картина