Автоматично масштабована архітектура потокового передавання RTSP з подвійними оркестраторами та нульовою втратою пакетів
Платформа спостереження потребувала динамічного масштабування своєї інфраструктури потокового відео — обробляючи від 10 до 200+ IP-камер із сотнями одночасних глядачів та AI-воркерів для обробки — гарантуючи нульову втрату пакетів під час операцій масштабування та підтримуючи стабільні URL-адреси потоків, які ніколи не змінюються.
Обговоріть Ваш Проєкт
Виклик
Фіксована інфраструктура потокового передавання не могла впоратися зі змінними вимогами зростаючої платформи спостереження:
- Змінність масштабу — Кількість камер і попит глядачів різко змінювалися протягом дня (співвідношення піку до мінімуму 10x)
- Витрати на надмірне резервування — Резервування для пікового навантаження означало 70%+ простоюючих ресурсів у непікові години
- Втрата пакетів під час масштабування — Додавання або видалення потокових серверів спричиняло переривання потоку, втрачаючи кадри для AI-воркерів для обробки
- Нестабільність URL-адрес — Камери та глядачі, налаштовані на певні IP-адреси серверів, потребували переналаштування при зміні інфраструктури
- Різні потреби в масштабуванні — Прийом камер і розподіл для глядачів мали принципово різні схеми навантаження, що вимагало незалежного масштабування
- Переривання роботи AI-воркерів — Конвеєри обробки AI виходили з ладу, коли їхній вихідний потоковий сервер зменшував масштаб
Наше Рішення
Ми розробили автоматично масштабовану архітектуру потокового передавання з подвійними оркестраторами з окремими кластерами прийому (ingestion) та розподілу (distribution), 5-фазне плавне вимкнення для нульової втрати пакетів, стабільні URL-адреси на основі DNS та автоматичне перепідключення AI-воркерів.
Архітектура
- Сервер потокового передавання: MediaMTX для підтримки протоколів RTSP/WebRTC/HLS
- Кластер прийому: 1-10 серверів, що приймають RTSP-потоки з камер
- Кластер розподілу: 2-20 серверів, що обслуговують глядачів (WebRTC/HLS) та AI-воркерів (RTSP)
- Подвійні оркестратори: Незалежні контролери масштабування для прийому та розподілу
- Балансувальники навантаження: Окремі балансувальники навантаження для кожного кластера з алгоритмами, відповідними протоколу
- Реєстр сервісів: Redis для статусу серверів, відображень потоків та координації
- Моніторинг працездатності: Активні перевірки працездатності з автоматичним відновленням
- Рівень DNS: Стабільні доменні імена, що вказують на балансувальники навантаження (URL-адреси ніколи не змінюються)
Дизайн подвійного оркестратора
Чому два оркестратори
Прийом і розподіл мають принципово різні характеристики масштабування:
- Прийом масштабується відповідно до кількості камер та вхідної пропускної здатності (передбачувано, зростає стабільно)
- Розподіл масштабується відповідно до кількості глядачів та попиту AI-воркерів (періодичний, непередбачуваний)
Окремі оркестратори дозволяють кожному масштабуватися незалежно зі спеціалізованими політиками, метриками та порогами — без того, щоб рішення щодо масштабування одного кластера впливали на інший.
Оркестратор прийому
- Основна метрика: Підключення камер на сервер
- Допоміжна метрика: Використання вхідної пропускної здатності
- Масштабування вгору: Коли CPU перевищує поріг або кількість камер на сервер перевищує місткість
- Масштабування вниз: Коли використання падає нижче порогу протягом тривалого періоду стабілізації
- Діапазон серверів: від 1 до 10 серверів
Оркестратор розподілу
- Основна метрика: Підключення глядачів + AI-воркерів на сервер
- Допоміжна метрика: Використання вихідної пропускної здатності
- Масштабування вгору: Коли CPU перевищує поріг або кількість підключень на сервер перевищує місткість
- Масштабування вниз: Коли використання падає нижче порогу протягом тривалого періоду (довша стабілізація, ніж для прийому)
- Діапазон серверів: від 2 до 20 серверів (мінімум 2 для високої доступності)
Нульова втрата пакетів: 5-фазне плавне вимкнення
Коли сервер розподілу заплановано до видалення, 5-фазний процес забезпечує відсутність втрати кадрів:
Фаза 1: Попереднє сповіщенняСервер позначається як "DRAINING" (осушується) у реєстрі сервісів. Вага балансувальника навантаження зменшується, щоб нові підключення прямували до інших місць. Redis pub/sub сповіщення та вебхуки попереджають AI-воркерів про підготовку до міграції.
Фаза 2: Оновлення балансувальника навантаженняСервер видаляється з пулу бекендів балансувальника навантаження. Нові підключення не можуть дістатися до сервера, що осушується. Існуючі підключення продовжуються без перерви.
Фаза 3: Міграція AI-воркерівAI-воркери відключаються від сервера, що осушується, і перепідключаються до справних серверів розподілу. Збереження стану на основі контрольних точок забезпечує відновлення обробки з точного кадру, на якому вона зупинилася. Загальна затримка: приблизно 3 секунди з нульовою втратою кадрів.
Фаза 4: Осушення глядачівЗалишкові підключення глядачів природним чином осушуються протягом настроюваного періоду. Сучасні відеоплеєри автоматично перепідключаються до тієї ж стабільної URL-адреси, яка перенаправляє на справні сервери. Більшість глядачів не відчувають перерв.
Фаза 5: ОчищенняПеревірити, що всі підключення закрито. Видалити сервер з реєстру сервісів. Знищити хмарний екземпляр. Записати метрики масштабування.
Стабільні URL-адреси
Архітектура URL-адрес гарантує, що камери та клієнти ніколи не потребуватимуть переналаштування:
- Ціль публікації камери: Стабільне доменне ім'я для прийому
- Ціль доступу для глядачів/AI: Стабільне доменне ім'я для розподілу
- DNS-записи вказують на IP-адреси балансувальників навантаження (які є постійними)
- Балансувальники навантаження прозоро обробляють маршрутизацію до бекенд-серверів
- Бекенд-сервери можуть бути додані, видалені або замінені без зміни URL-адрес
Реєстр сервісів (Redis)
Централізований екземпляр Redis координує всю систему:
- Відстеження стану сервера (активний, осушується, офлайн)
- Відображення потоку до сервера (яка камера на якому сервері прийому)
- Стан AI-воркера та дані контрольних точок
- Метрики навантаження на сервер для прийняття рішень щодо масштабування
- Pub/sub канали для подій координації в реальному часі
Перепідключення AI-клієнта
Бібліотека AI-клієнта забезпечує безшовне перепідключення:
- Слухає сповіщення про видалення сервера через Redis pub/sub
- Автоматичне збереження контрольних точок кадрів через регулярні інтервали
- Перепідключення до справного сервера розподілу за сповіщенням
- Відновлення обробки з контрольної точки з мінімальною затримкою
- Звітування метрик про події перепідключення
Моніторинг працездатності
- Активні перевірки працездатності на кожному сервері через регулярні інтервали
- Автоматичні оновлення балансувальника навантаження при відмовах серверів
- Тригери автоматичного відновлення для невідповідних серверів
- Відстеження часу безперебійної роботи та звітність про доступність
Ключові особливості
- Подвійні оркестратори — Незалежне масштабування для кластерів прийому та розподілу
- Нульова втрата пакетів — 5-фазне плавне вимкнення з міграцією AI-воркерів
- Стабільні URL-адреси — Маршрутизація на основі DNS гарантує, що URL-адреси ніколи не змінюються під час масштабування
- Перепідключення AI-воркерів — Міграція на основі контрольних точок з розривом ~3 секунди та нульовою втратою кадрів
- Незалежне масштабування — Прийом та розподіл масштабуються на основі власних метрик
- Реєстр сервісів — Координація на основі Redis для статусу сервера та відображень потоків
- Моніторинг працездатності — Активні перевірки з автоматичним відновленням
- Оптимізація витрат — Автоматичне зменшення масштабу в періоди низького попиту
Результати
Технологічний Стек
caseStudyDetail.more Кейси
Ознайомтесь з іншими нашими технічними впровадженнями
Обробка рахунків-фактур за допомогою AI, OCR та інтеграції з QuickBooks
Середній бізнес, який щомісяця обробляє сотні рахунків-фактур від постачальників, потребував усунення ручного введення даних шляхом автоматичного вилучення даних рахунків-фактур за допомогою AI/OCR та їх прямої синхронізації з QuickBooks для ведення бухгалтерського обліку та відстеження платежів.
Вставка реклами на стороні клієнта (CSAI) з парсингом маркерів SCTE-35 та інтеграцією багатоплатформного плеєра
Платформа потокового відео потребувала впровадження вставки реклами на стороні клієнта (CSAI) для веб-, мобільних програм та програм для підключених телевізорів — що забезпечує персоналізований рекламний досвід на рівні пристрою з повною підтримкою взаємодії з рекламою (натискні оверлеї, супутні банери, кнопки пропуску), який не може забезпечити вставка на стороні сервера.
Готові Трансформувати Свій Бізнес?
Давайте обговоримо, як ми можемо застосувати подібні рішення для ваших завдань.