Постановка проблемы:

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

Этот механизм обмена мыслями в потоковом режиме сопряжен с множеством проблем, одна из которых — создание системы, способной обрабатывать переменную нагрузку в больших масштабах. Одним из примеров такой ситуации в реальном времени является спортивное мероприятие в прямом эфире, такое как финал ЧМТ в ИНДИИ/НОВОЙ ЗЕЛАНДИИ. Этот матч посмотрели около 25 миллионов человек, что на сегодняшний день является самым высоким показателем среди всех прямых трансляций. В целом нагрузка не будет такой высокой, но она может быть для таких событий, поэтому система должна быть построена для обработки таких непредвиденных ситуаций.

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

Некоторые из общих требований:

  1. Все пользователи должны иметь возможность комментировать, как и когда они хотят.
  2. Комментарии должны доставляться всей аудитории этого потока в режиме реального времени.
  3. Система должна быть отделена от потока видеопотока в реальном времени, так как он не находится на критическом пути.
  4. Сообщения доставляются в режиме реального времени, поэтому, если пользователь присоединится после времени T1, он увидит комментарии только после этой метки времени.
  5. Сообщения должны доставляться через разные типы устройств.
  6. Сообщения должны быть доставлены всем зрителям независимо от их регионов.
  7. Система должна быть высокодоступной и масштабируемой.

Давайте начнем..

На высоком уровне система должна выглядеть следующим образом:

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

Предположения

  1. Здесь мы уделяем больше внимания службе обмена сообщениями, поэтому мы предполагаем, что такие вопросы безопасности, как аутентификация, ssl, ограничение скорости и т. д., уже существуют.
  2. Управление информацией о пользователях уже реализовано.
  3. Также мы не фокусируемся на пользовательском интерфейсе, который будет использоваться для просмотра сообщений.
  4. Один пользователь может быть частью только одного потока в каждый момент времени.

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

Описание компонентов

Служба обмена сообщениями

  1. Это серверы API, которые будут получать комментарий/лайк от пользователя для определенного потока.
  2. Как только запрос получен от службы обмена сообщениями пользователя, он выполнит некоторые базовые проверки, а затем отправит запрос ближайшему диспетчеру, который будет находиться в том же регионе, в котором работает этот компонент.

Диспетчер:

Диспетчер прочитает сообщения из очереди и выполнит следующие действия:

  1. Прочитайте имя потока из запроса и узнайте всех супервизоров, которые имеют активные соединения для этого потока.
  2. Отправьте сообщение всем супервайзерам, которые были рассчитаны на шаге 1.
  3. Поскольку супервизоры потока могут находиться в разных регионах, диспетчер также будет разветвлять полученные им сообщения в очереди диспетчеров во всех регионах.
  4. Здесь по мере увеличения нагрузки на SQS количество диспетчеров также можно масштабировать на основе количества непрочитанных сообщений в SQS. Таким образом достигается независимое масштабирование.

Начальник

Supervisor прочитает сообщения от SQS и выполнит следующие действия:

  1. Найдите всех пользователей, которые слушают прямую трансляцию, для которой предназначено сообщение.
  2. Отправьте сообщение всем пользователям, вычисленным на шаге 1.
  3. Количество супервизоров можно масштабировать, если количество одновременных подключений увеличивается.
  4. Когда пользователь начинает потоковую передачу видео, с супервизором устанавливается соединение через веб-сокет. Соединение через веб-сокет привязано к серверу, поэтому существует ограничение на количество одновременных подключений, которые может обрабатывать один сервер. Таким образом, для масштабирования супервизоры будут находиться за балансировщиками нагрузки.

Ход событий

  1. Алиса и Боб оба смотрят stream1.
  2. Когда пользователь начинает потоковую передачу видео, также будет открыто длинное соединение для опроса с супервизором.
  3. Supervisor будет хранить данные (ассоциацию идентификатора потока и идентификатора пользователя) в своем кэше.
  4. Каждый пользователь также будет продолжать отправлять контрольный сигнал супервизору, чтобы сообщить ему, что соединение все еще активно. Если пульс не будет получен в течение определенного периода времени, соединение будет считаться устаревшим и будет удалено из кэша супервизора.
  5. После установления соединения с супервизором он позвонит диспетчеру, чтобы зарегистрировать поток, который он начал прослушивать.
  6. Dispatcher сохранит эти данные (идентификатор потока и идентификатор супервизора) в своем кеше.
  7. Теперь Алиса, которая была подключена к потоку 1, отправит лайк или комментарий для этого потока через API-вызов службы сообщений.
  8. Служба сообщений отправит это событие ближайшему диспетчеру.
  9. Диспетчер проверит свой кэш, чтобы найти все узлы супервизора, у которых есть пользователи, которые прослушивают поток 1, и отправит сообщение на соответствующие узлы супервизора.
  10. Узел супервизора после получения сообщения проверит свой кеш, чтобы найти всех пользователей, которые прослушивают поток 1, и отправит это сообщение через соединение через веб-сокет всем слушателям потока 1.

Ведение журнала и мониторинг:

  1. Все журналы приложений и событий будут помещены в стек ELK.
  2. Метрики могут быть сведены к единице, если система APM, такая как Hyper-Trace, Data-Dog и т. д.

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

Автомасштабирование:

В приведенных выше системах все компоненты слабо связаны и могут легко масштабироваться независимо друг от друга.

  1. Если количество вызовов API увеличивается, экземпляры службы обмена сообщениями можно масштабировать для обработки нагрузки.
  2. Если количество сообщений в SQS диспетчера увеличивается, количество узлов диспетчера можно масштабировать для обработки большего количества сообщений и, таким образом, поддержания качества обслуживания.
  3. Если количество одновременных пользовательских подключений увеличивается, узлы супервизора можно масштабировать для обработки большего количества подключений.

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

Эффективное управление долгоживущими подключениями

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

Причины большого количества подключений:

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

Стратегии управления большим количеством одновременных долгоживущих соединений:

  1. Используйте асинхронный ввод-вывод для управления подключениями, чтобы можно было увеличить количество подключений, управляемых одним сервером. Это позволит оптимизировать использование ресурсов сервера, но увеличит сложность кода.
  2. Назначьте TTL для каждого соединения. Каждому соединению назначается случайный TTL, чтобы оно прерывалось по истечении заданного времени, и при необходимости клиент мог снова установить соединение. ПРИМЕЧАНИЕ. При назначении TTL время должно быть выбрано случайным образом, чтобы мы не застряли в проблеме громового стада.
  3. Обычно сервер не закрывает соединения со своей стороны, поэтому периодически сервер может отправлять клиенту сигнал уничтожения, чтобы клиент мог его прослушать, закрыть текущее соединение и установить новое соединение только в том случае, если оно необходимо.

Характеристики услуги

  1. Логирование и мониторинг с помощью Kibana.
  2. Поскольку потоки используются между различными компонентами, регулирование нагрузки может выполняться в разных точках.
  3. Поскольку сервис развернут в облаке с использованием EKS, можно выполнить горизонтальное масштабирование. Кроме того, поскольку существуют различные слабо связанные компоненты, каждый компонент можно масштабировать независимо от любого другого компонента. Критерии масштабирования: пропускная способность, использование ЦП, использование памяти.

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

Предоставьте любые отзывы, разъяснения или улучшения в разделе комментариев. Если вы хотите обсудить какую-либо тему дизайна, добавьте ее в раздел комментариев.

Удачного обучения…

Использованная литература:

https://www.youtube.com/watch?v=yqc3PPmHvrA