Комплексный системный анализ архитектуры микросервисов в Netflix для поддержки глобальных сервисов потокового видео
1. Введение
Netflix уже много лет является одним из лучших онлайн-сервисов потокового видео на основе подписки в мире ([12]), на него приходится более 15% мировой пропускной способности Интернета. В 2019 году Netflix уже приобрел более 167 миллионов подписчиков, причем каждый квартал добавляется более 5 миллионов новых подписчиков, и работает более чем в 200 странах. В частности, подписчики Netflix тратят более 165 миллионов часов на просмотр более 4 000 фильмов и 47 000 серий в день. Эти впечатляющие статистические данные показывают, что с инженерной точки зрения технические группы Netflix разработали такую потрясающую систему потокового видео с очень высокой доступностью и масштабируемостью, чтобы обслуживать своих клиентов по всему миру.
Однако техническим командам потребовалось более 8 лет, чтобы их ИТ-системы были такими, как сейчас ([1]). Фактически, преобразование инфраструктуры Netflix началось в августе 2008 года после того, как в его собственных центрах обработки данных отключили все услуги по аренде DVD на три дня. Netflix понял, что ему нужна более надежная инфраструктура без единой точки отказа. Поэтому было принято два важных решения: миграция ИТ-инфраструктуры из центров обработки данных в общедоступное облако и замена монолитных программ небольшими управляемыми программными компонентами архитектурой микросервисов. Оба решения напрямую повлияли на успех Netflix сегодня.
Netflix выбрала облако AWS ([4]) для миграции своей ИТ-инфраструктуры, поскольку AWS может предложить высоконадежные базы данных, крупномасштабное облачное хранилище и несколько центров обработки данных по всему миру. Используя облачную инфраструктуру, созданную и обслуживаемую AWS, Netflix не выполнил тяжелую недифференцированную работу по созданию центров обработки данных, а больше сосредоточился на своей основной деятельности - предоставлении пользователям высококачественного потокового видео. Несмотря на то, что ему необходимо перестроить всю технологию, чтобы обеспечить ее бесперебойную работу в облаке AWS, улучшение масштабируемости Netflix и доступность услуг значительно выиграли в свою очередь.
Netflix также является одним из первых основных драйверов архитектуры микросервисов. Микросервисы нацелены на решение проблем монолитного проектирования программного обеспечения, поощряя разделение задач ([11]), при котором большие программы разбиваются на более мелкие программные компоненты посредством модульности с инкапсуляцией данных самой по себе. Микросервисы также помогают повысить масштабируемость за счет горизонтального масштабирования и разделения рабочей нагрузки. Внедряя микросервисы, инженеры Netflix легко меняют любые сервисы, что приводит к более быстрому развертыванию. Что еще более важно, они могут отслеживать производительность каждой службы и быстро изолировать ее проблемы от других работающих служб.
В этом исследовании я заинтересован в понимании облачной архитектуры Netflix и ее производительности при различных рабочих нагрузках и сетевых ограничениях. В частности, я хочу проанализировать структуру системы с точки зрения доступности, задержки, масштабируемости и устойчивости к сбоям сети или сбоям системы. Это исследование организовано следующим образом. В разделе 2 будет описана возможная архитектура системы Netflix, полученная из различных онлайн-источников. Затем в разделе 3 будут рассмотрены более подробные компоненты системы. В разделах 4, 5, 6, 7 я проанализирую систему в отношении вышеуказанных целей проектирования. Наконец, я делаю вывод о том, что было извлечено из этого анализа, и о возможных следующих шагах, которые необходимо предпринять для улучшения.
2. Архитектура
Netflix работает на основе сервисов облачных вычислений Amazon (AWS) и Open Connect, собственной сети доставки контента ([1]). Обе системы должны работать вместе, чтобы предоставлять высококачественные услуги потокового видео по всему миру. С точки зрения архитектуры программного обеспечения Netflix состоит из трех основных частей: клиента, серверной части и сети доставки контента (CDN).
Клиент - это любой поддерживаемый браузер на ноутбуке или настольном компьютере или приложение Netflix на смартфонах или смарт-телевизорах. Netflix разрабатывает собственные приложения для iOS и Android, чтобы обеспечить наилучшие впечатления от просмотра для каждого клиента и устройства. Управляя своими приложениями и другими устройствами с помощью своего SDK, Netflix может прозрачно адаптировать свои потоковые сервисы при определенных обстоятельствах, таких как медленные сети или перегруженные серверы.
Backend включает сервисы, базы данных и хранилища, полностью работающие в облаке AWS. Backend в основном обрабатывает все, кроме потокового видео. Некоторые компоненты Backend с соответствующими сервисами AWS перечислены ниже:
Масштабируемые вычислительные инстансы (AWS EC2)
Масштабируемое хранилище (AWS S3)
Микросервисы бизнес-логики (специализированные фреймворки Netflix)
Масштабируемые распределенные базы данных (AWS DynamoDB, Cassandra)
Обработка больших данных и аналитика (AWS EMR, Hadoop, Spark, Flink, Kafka и другие специализированные инструменты Netflix)
Обработка и перекодирование видео (специализированные инструменты Netflix)
Open Connect CDN - это сеть серверов под названием Open Connect Appliances (OCAs), оптимизированная для хранения и потоковой передачи больших видео. Эти серверы OCAs размещаются внутри сетей интернет-провайдеров (ISP) и точек обмена интернет-трафиком (IXP) по всему миру. OCAs несут ответственность за потоковую передачу видео непосредственно клиентам.
В следующих разделах я опишу справочную облачную архитектуру Netflix, состоящую из этих трех частей. В разделе 2.1 общая архитектура способна передавать потоковое видео, называемая архитектурой воспроизведения, после того, как подписчик нажимает кнопку «Воспроизвести» в своих приложениях. Затем в разделе 2.2 будет описана более подробная архитектура микросервисов Backend, чтобы продемонстрировать, как Netflix обеспечивает доступность и масштабируемость в глобальном масштабе.
2.1 Архитектура воспроизведения
Когда подписчики нажимают кнопку «Воспроизвести» в своих приложениях или устройствах, клиент будет общаться как с серверной частью на AWS, так и с OCAs на Netflix CDN для потоковой передачи видео ([7]). На следующей диаграмме показано, как работает процесс воспроизведения:
Fig 1. Playback architecture for streaming videos
OCAs постоянно отправляет отчеты о состоянии своей рабочей нагрузки, возможности маршрутизации и доступных видео в службу Cache Control, работающую в AWS EC2, чтобы приложения для воспроизведения могли обновлять клиентам последние исправные OCAs. Запрос воспроизведения отправляется с клиентского устройства в сервис Netflix Playback Apps, работающий на AWS EC2, чтобы получить URL-адреса для потоковой передачи видео.
Служба Playback Apps должна определить, что запрос воспроизведения будет действителен для просмотра конкретного видео. Такие проверки будут проверять план подписчика, лицензирование видео в разных странах и т. Д.
Сервис Playback Apps обращается к сервису Steering, также работающему в AWS EC2, чтобы получить список соответствующих серверов OCAs для запрошенного видео. Служба управления использует IP-адрес клиента и информацию об интернет-провайдерах, чтобы определить набор подходящих OCAs, которые лучше всего подходят для этого клиента.
Из списка 10 различных серверов OCAs, возвращаемых службой Playback Apps, клиент проверяет качество сетевых подключений к этим OCAs и выбирает самый быстрый и надежный OCAs для запроса видеофайлов для потоковой передачи.
Выбранный сервер OCAs принимает запросы от клиента и запускает потоковую передачу видео.
На приведенной выше диаграмме служба Playback Apps, служба управления и служба управления кешем полностью работают в облаке AWS на основе архитектуры микросервисов. В следующем разделе я опишу эталонную архитектуру микросервисов Netflix Backend, которая увеличивает доступность и масштабируемость запущенных сервисов.
2.2 Бэкэнд-архитектура
Как я описывал в предыдущих разделах, Backend обрабатывает практически все, начиная от регистрации, входа в систему, выставления счетов и заканчивая более сложными задачами обработки, такими как перекодирование видео и персональные рекомендации. Чтобы поддерживать как легкие, так и тяжелые рабочие нагрузки, выполняемые в одной и той же базовой инфраструктуре, Netflix выбрала архитектуру микросервисов для своей облачной системы. Диаграмма на рисунке 2 представляет возможную архитектуру микросервисов в Netflix, которую я извлек из нескольких онлайн-источников ([11, 13, 14]):
Fig 2. A reference of Backend architecture based on various sources
Клиент отправляет запрос воспроизведения в серверную часть, работающую на AWS. Этот запрос обрабатывается балансировщиком нагрузки AWS (ELB).
AWS ELB перенаправит этот запрос в службу шлюза API, работающую на экземплярах AWS EC2. Этот компонент, названный Zuul, создан командой Netflix для обеспечения динамической маршрутизации, мониторинга трафика и обеспечения безопасности, а также устойчивости к сбоям на границе развертывания облака. Запрос будет применен к некоторым предопределенным фильтрам, соответствующим бизнес-логике, а затем направлен в API приложения для дальнейшей обработки.
Компонент API приложения - это основная бизнес-логика операций Netflix. Существует несколько типов API, соответствующих различным действиям пользователя, например API регистрации, API рекомендаций для получения рекомендаций по видео. В этом сценарии перенаправленный запрос от службы шлюза API обрабатывается Play API.
Play API вызовет микросервис или последовательность микросервисов для выполнения запроса. Службу Playback Apps, службу управления и службу управления кешем на рис. 1 можно рассматривать как микросервис на этой схеме.
Микросервисы - это в основном небольшие программы без сохранения состояния, которые также могут вызывать друг друга. Чтобы контролировать каскадный сбой и обеспечить отказоустойчивость, каждый микросервис изолируется от вызывающих процессов с помощью Hystrix. Его результат после выполнения можно кэшировать в кэше памяти, чтобы обеспечить более быстрый доступ для этих критически важных запросов с низкой задержкой.
Микросервисы могут сохранять или получать данные из хранилища данных во время его обработки.
Микросервисы могут отправлять события для отслеживания действий пользователей или другие данные в конвейер потоковой обработки для обработки персонализированных рекомендаций в реальном времени или пакетной обработки задач бизнес-аналитики.
Данные, поступающие из конвейера потоковой обработки, могут быть постоянными для других хранилищ данных, таких как AWS S3, Hadoop HDFS, Cassandra и т. Д.
Описанные архитектуры помогают нам получить общее представление о том, как различные части организуются и работают вместе для потоковой передачи видео. Однако, чтобы проанализировать доступность и масштабируемость архитектур, нам нужно более подробно изучить каждый важный компонент, чтобы увидеть, как он работает при различных рабочих нагрузках. Это будет рассмотрено в следующем разделе.
3. Компоненты
В этом разделе я хочу изучить компоненты, определенные в разделе 2, чтобы проанализировать их доступность и масштабируемость. При описании каждого компонента я также хотел бы указать, как он отвечает этим целям дизайна. Более подробный анализ проекта будет упомянут в следующих разделах в отношении всей системы.
3.1 Клиент
Технические группы Netflix приложили немало усилий для разработки более быстрых и интеллектуальных клиентских приложений, работающих на ноутбуках, настольных компьютерах или мобильных устройствах. Даже на некоторых смарт-телевизорах, в которых Netflix не имеет специализированного клиента, Netflix по-прежнему контролирует его производительность с помощью предоставленного SDK. Фактически, любая среда устройства должна установить платформу Netflix Ready Device Platform (NRDP), чтобы обеспечить наилучшее качество просмотра Netflix. Типичный структурный компонент клиента ([11]) показан на рисунке 3.
Fig 3. Client App Component
Клиентские приложения разделяют 2 типа подключений к Backend для обнаружения и воспроизведения контента. Клиент использует протокол NTBA ([15]) для запросов на воспроизведение, чтобы обеспечить большую безопасность на своих серверах OCAs и устранить задержку, вызванную квитированием SSL / TLS для новых подключений.
При потоковой передаче видео клиентское приложение интеллектуально снижает качество видео или переключается на другие серверы OCAs ([1]), если сетевые соединения перегружены или имеют ошибки. Даже если подключенный OCAs перегружен или вышел из строя, клиентское приложение может легко переключиться на другой сервер OCAs для лучшего просмотра. Все это может быть достигнуто благодаря тому, что SDK платформы Netflix на клиенте отслеживает последние исправные OCAs, полученные из службы Playback Apps (рисунок 1).
3.2 Бэкэнд
3.2.1 Служба шлюза API
Fig 4. Zuul Gateway Service Component
Входящие фильтры могут использоваться для аутентификации, маршрутизации и оформления запроса.
Фильтр конечных точек можно использовать для возврата статических ресурсов или направления запроса соответствующему источнику или API-интерфейсу приложения для дальнейшей обработки.
Исходящие фильтры можно использовать для отслеживания метрик, украшения ответа пользователю или добавления настраиваемых заголовков.
Zuul может открывать для себя новый API приложений путем интеграции с Service Discovery Eureka
Zuul широко используется для маршрутизации трафика для различных целей, таких как адаптация API нового приложения, нагрузочные тесты, маршрутизация к различным конечным точкам службы при огромных рабочих нагрузках.
3.2.2 API приложения
API приложения играет роль уровня оркестрации ([18]) для микросервисов Netflix. API обеспечивает логику составления вызовов базовых микросервисов в необходимом порядке с дополнительными данными из других хранилищ данных для создания соответствующих ответов. Команда Netflix потратила много времени на разработку компонента Application API, поскольку он соответствует основным бизнес-функциям Netflix. Он также должен быть масштабируемым, высокодоступным при большом объеме запросов. В настоящее время API приложений определены в трех категориях: API регистрации для запросов, не являющихся участниками, таких как регистрация, выставление счетов, бесплатная пробная версия и т. Д., API обнаружения для поиска, запросы рекомендаций и API воспроизведения для потоковой передачи, просмотр запросов на лицензирование. Подробная структурная схема компонентов Application API представлена на рисунке 5.
Fig 5. Separation of Play and Discovery Application API
В недавнем обновлении реализации Play API сетевой протокол между Play API и микросервисами - это gRPC / HTTP2, который «позволяет определять методы и объекты RPC через буферы протокола, а клиентские библиотеки / SDK автоматически генерируются на различных языках» ([ 13]). Это изменение позволяет Application API надлежащим образом интегрироваться с автоматически сгенерированными клиентами посредством двунаправленной связи и «минимизировать повторное использование кода через границы сервисов».
API приложения также предоставляет общий устойчивый механизм, основанный на командах Hystrix, для защиты лежащих в его основе микросервисов.
Поскольку Application API должен обрабатывать огромные объемы запросов и создавать соответствующие ответы, его внутренняя обработка должна выполняться параллельно. Команда Netflix обнаружила, что сочетание синхронного выполнения и асинхронного ввода-вывода ([13]) является правильным подходом.
Fig 6. Synchronous Execution & Asynchronous I/O of Application API
Каждый запрос от службы шлюза API будет помещен в цикл сетевых событий API приложения для обработки.
Каждый запрос будет заблокирован выделенным обработчиком потока, который помещает команды Hystrix, такие как getCustomerInfo, getDeviceInfo и т. Д., В цикл исходящих событий. Этот цикл исходящих событий настраивается для каждого клиента и работает с неблокирующим вводом-выводом. После завершения или истечения тайм-аута вызывающих микросервисов выделенный поток будет создавать соответствующие ответы.
3.2.3 Микросервисы
Согласно определению Мартина Фаулера, «микросервисы - это набор небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с легковесными механизмами…». Эти небольшие программы можно независимо развертывать или обновлять по сравнению с другими, и они имеют свои собственные инкапсулированные данные.
Реализация компонента микросервисов в Netflix ([11]) показана на рисунке 7.
Fig 7. Structural component of a microservice
Микросервис может работать сам по себе или вызывать другие микросервисы через REST или gRPC.
Реализация микросервиса может быть аналогична реализации API приложения, как показано на рисунке 6, на котором запросы будут помещены в цикл сетевых событий, а результаты от других вызываемых микрослужб помещаются в очередь результатов при асинхронном неблокирующем вводе-выводе.
Каждая микрослужба может иметь собственное хранилище данных и несколько кеш-хранилищ последних результатов в памяти. EVCache - это основной выбор для кэширования микросервисов в Netflix.
3.2.4 Хранилища данных
При миграции своей инфраструктуры в облако AWS Netflix использовала разные хранилища данных (рис. 8), как SQL, так и NoSQL, для разных целей ([6]).
Fig 8. Netflix Data Stores deployed on AWS
Базы данных MySQL используются для управления названиями фильмов и транзакций / выставления счетов.
Hadoop используется для обработки больших данных на основе пользовательских журналов.
ElasticSearch обеспечил поиск заголовков для приложений Netflix
Cassandra - это распределенное хранилище данных NoSQL на основе столбцов для обработки большого количества запросов на чтение без единой точки отказа. Чтобы оптимизировать задержку при выполнении больших запросов на запись, используется Cassandra из-за ее в конечном итоге согласованной способности.
3.2.5 Трубопровод обработки потока
Конвейер потоковой обработки данных ([14, 3]) стал основой данных Netflix для бизнес-аналитики и задач персонализированных рекомендаций. Он отвечает за создание, сбор, обработку, агрегирование и передачу всех событий микросервисов другим обработчикам данных почти в реальном времени. На рисунке 9 показаны различные части платформы.
Fig 9. Keystone Stream Processing Platform at Netflix
Платформа потоковой обработки обрабатывала триллионы событий и петабайты данных в день. Он также будет автоматически масштабироваться по мере увеличения количества подписчиков.
Модуль Router обеспечивает маршрутизацию к различным приемникам данных или приложениям, в то время как Kafka отвечает за маршрутизацию сообщений, а также за буферизацию для нисходящих систем.
Потоковая обработка как услуга (SPaaS) позволяет инженерам по обработке данных создавать и контролировать свои настраиваемые приложения управляемой потоковой обработки, в то время как платформа позаботится о масштабируемости и операциях.
3.3 Открыть Connect
Open Connect - это глобальная сеть доставки контента (CDN), отвечающая за хранение и доставку телешоу и фильмов Netflix своим подписчикам по всему миру. Netflix разработала и эффективно использовала Open Connect, перенеся контент, который люди хотят смотреть, как можно ближе к тому месту, где они хотят его смотреть. Чтобы локализовать трафик просмотра видео Netflix в сети клиентов, Netflix в партнерстве с поставщиками интернет-услуг (ISP) и точками обмена интернет-трафиком (IX или IXP) по всему миру развертывает специализированные устройства, называемые Open Connect Appliances (OCAs). внутри их сети ([7]).
Fig 10. Deployment of OCAs to IXs or ISPs sites
OCAs - это серверы, оптимизированные для хранения и потоковой передачи больших видеофайлов с сайтов IX или ISP непосредственно в дома подписчиков. Эти серверы периодически сообщают об оптимальных маршрутах с метриками работоспособности, которые они узнали из сетей IXP / ISP, и о том, какие видеоролики они хранят на своих SSD-дисках, в сервисы Open Connect Control Plane на AWS. В свою очередь, службы уровня управления будут принимать такие данные, чтобы автоматически направлять клиентские устройства к наиболее оптимальным OCAs, учитывая доступность файлов, состояние сервера и близость сети к клиентам.
Службы уровня управления также управляют поведением заполнения при добавлении новых файлов или обновлении файлов в OCAs каждую ночь. Поведение при заполнении ([8,9]) показано на рисунке 11.
Когда новые видеофайлы были успешно перекодированы и сохранены на AWS S3, сервисы уровня управления на AWS передадут эти файлы на серверы OCAs на сайтах IXP. Эти серверы OCAs будут применять заполнение кеша для передачи этих файлов на серверы OCAs на сайтах интернет-провайдеров в их подсетях.
Когда сервер OCAs успешно сохранил видеофайлы, он сможет запустить одноранговое заполнение, чтобы скопировать эти файлы на другие серверы OCAs на том же сайте, если это необходимо.
Между двумя разными сайтами, которые могут видеть IP-адреса друг друга, OCAs могут применять процесс заполнения уровней вместо обычного заполнения кеша.
Fig 11. Fill patterns among OCAs
4. Цели дизайна
В предыдущих разделах я подробно описал облачную архитектуру и ее компоненты, лежащие в основе бизнеса Netflix в области потокового видео. В этом и последующих разделах я хотел бы глубже проанализировать эту архитектуру дизайна. Я начинаю со следующего списка наиболее важных целей дизайна:
Обеспечьте высокую доступность потоковых сервисов в глобальном масштабе.
Устойчивость к сбоям в сети и сбоям системы.
Минимизируйте задержку потоковой передачи для каждого поддерживаемого устройства в различных сетевых условиях.
Поддержка масштабируемости при большом объеме запросов.
В подразделах я собираюсь проанализировать доступность потоковой службы и соответствующую оптимальную задержку. В разделе 6 рассматривается более глубокий анализ механизмов устойчивости, таких как Chaos Engineering, а в разделе 7 рассматривается масштабируемость потоковых сервисов.
4.1 Высокая доступность
По определению доступность системы измеряется с точки зрения того, сколько раз будет выполнен ответ на запрос в течение определенного периода времени, без гарантии того, что он содержит самую последнюю версию информации. В нашей конструкции системы доступность потоковых сервисов зависит как от доступности серверных сервисов, так и от серверов OCAs, на которых хранятся потоковые видеофайлы.
Цель серверных служб - получить список наиболее здоровых OCAs, близких к конкретному клиенту, либо из кеша, либо путем выполнения некоторых микросервисов. Следовательно, его доступность зависит от различных компонентов, включающих запрос воспроизведения: балансировщики нагрузки (AWS ELB), прокси-серверы (API Gateway Service), Play API, выполнение микросервисов, хранилища кешей (EVCache) и хранилища данных (Cassandra):
Балансировщики нагрузки могут улучшить доступность, направляя трафик на разные прокси-серверы, чтобы предотвратить перегрузку рабочих нагрузок.
Play API контролирует выполнение микросервисов с тайм-аутом с помощью команд Hystrix, которые могут помочь предотвратить каскадные сбои для других сервисов.
Микросервисы могут отвечать на Play AI данными в кеше, если вызов внешних служб или хранилищ данных занимает больше времени, чем ожидалось.
Кэш реплицируется для более быстрого доступа.
Получая список серверов OCAs от Backend, клиент проверяет сеть на эти OCAs и выбирает лучшие OCAs для подключения. Если этот OCAs перегружен или не работает во время процесса потоковой передачи, то клиент переключается на другой исправный, или Platform SDK запросит другие OCAs. Следовательно, его доступность сильно коррелирует с доступностью всех OCAs, доступных в его ISP или IXP.
Высокая доступность потоковых сервисов Netflix достигается за счет сложных многорегиональных операций и сервисов AWS, а также избыточности серверов OCAs.
4.2 Низкая задержка
Задержка потоковых сервисов в основном зависит от того, насколько быстро Play API может разрешить список исправных OCAs и насколько хорошо соединение клиента с выбранным сервером OCAs.
Как я описал в разделе «Компонент API приложения», Play API не ожидает выполнения микросервиса вечно, поскольку он использует команды Hystrix для управления временем ожидания результата, прежде чем он получит устаревшие данные из кеш. Это может контролировать допустимую задержку, а также остановить каскадные отказы для других служб.
Клиент немедленно переключится на другие близлежащие серверы OCAs с наиболее надежным сетевым подключением, если произойдет сбой сети на текущем выбранном сервере OCAs или этот сервер будет перегружен. Он также может снизить качество видео, чтобы оно соответствовало качеству сети, в случае обнаружения ухудшения сетевого подключения.
5. Компромиссы
В описанной выше конструкции системы были тщательно реализованы два важных компромисса:
Низкая задержка по сравнению с согласованностью
Высокая доступность важнее согласованности
Компромисс между задержкой и согласованностью встроен в архитектуру серверных служб. Play API может получать устаревшие данные из хранилищ EVCache или из, в конечном итоге, согласованных хранилищ данных, таких как Cassandra.
Точно так же компромисс между доступностью и согласованностью предпочел бы построение ответов с приемлемой задержкой, не требуя выполнения микросервисов для последних данных в хранилищах данных, таких как Cassandra.
Также существует не совсем актуальный компромисс между масштабируемостью и производительностью ([21]). В этом компромиссе улучшение масштабируемости за счет увеличения числа экземпляров для обработки большего количества рабочих нагрузок может привести к тому, что система будет работать с ожидаемым увеличением производительности. Это может быть проблемой для тех архитектур проектирования, в которых нагрузка не сбалансирована между доступными рабочими. Однако Netflix решил этот компромисс с автоматическим масштабированием AWS. Мы вернемся к этому решению более подробно в Разделе 7.
6. Устойчивость
Разработка облачной системы, способной к самовосстановлению после сбоев или отключений, была долгой целью Netflix с самого начала миграции в облако AWS. Некоторые распространенные сбои системы были устранены следующим образом:
Сбой в разрешении зависимостей службы.
Сбой при выполнении микросервиса может вызвать каскадные отказы других сервисов.
Ошибка подключения к API из-за перегрузки.
Сбой подключения к экземплярам или серверам, таким как OCAs.
Для обнаружения и устранения этих сбоев служба шлюза API Zuul ([20]) имеет встроенные функции, такие как адаптивные повторные попытки, ограничивающие одновременные вызовы API приложений. В свою очередь, API приложения использует команды Hystrix для тайм-аута вызовов микросервисов, чтобы остановить каскадные сбои и изолировать точки сбоев от других.
Технические команды Netflix также известны своей практикой хаоса в области инженерии. Идея состоит в том, чтобы вводить псевдослучайные ошибки в производственные среды и создавать решения для автоматического обнаружения, изоляции и восстановления после таких сбоев. Ошибки могут добавлять задержки к ответам при выполнении микросервисов, отключать службы, останавливать серверы или экземпляры и даже приводить к отключению всей инфраструктуры региона ([5]). Целенаправленно вводя реалистичные производственные сбои в контролируемую среду с помощью инструментов для обнаружения и устранения таких сбоев, Netflix может быстро обнаруживать такие слабые места, прежде чем они вызовут более серьезные проблемы.
7. Масштабируемость
В этом разделе я проанализирую масштабируемость потоковых сервисов Netflix, охватывая горизонтальное масштабирование, параллельное выполнение и разделение базы данных. Другие части, такие как кеширование и балансировка нагрузки, также помогают повысить масштабируемость, были упомянуты в разделе 4.
Во-первых, горизонтальное масштабирование инстансов EC2 в Netflix обеспечивается сервисом AWS Auto Scaling Service. Этот сервис AWS автоматически запускает больше эластичных экземпляров, если объем запросов увеличивается, и отключает неиспользуемые. В частности, поверх тысяч таких экземпляров Netflix построил Titus ([17]), платформу управления контейнерами с открытым исходным кодом, которая позволяет запускать около 3 миллионов контейнеров в неделю. Кроме того, любой компонент нашей архитектуры, показанной на рисунке 2, можно развернуть внутри контейнера. Более того, Titus позволяет контейнерам работать в нескольких регионах на разных континентах по всему миру.
Во-вторых, реализация прикладного API или микросервиса в разделе 3.2.2 также увеличивает масштабируемость, позволяя параллельное выполнение задач в цикле сетевых событий и асинхронном цикле исходящих событий.
Наконец, хранилища с широкими столбцами, такие как Cassandra, и хранилища объектов типа "ключ-значение", такие как ElasticSearch, также обеспечивают высокую доступность и масштабируемость без единой точки отказа.
8. Заключение
Перевод статьи с сайта https://medium.com/
1. Введение
Netflix уже много лет является одним из лучших онлайн-сервисов потокового видео на основе подписки в мире ([12]), на него приходится более 15% мировой пропускной способности Интернета. В 2019 году Netflix уже приобрел более 167 миллионов подписчиков, причем каждый квартал добавляется более 5 миллионов новых подписчиков, и работает более чем в 200 странах. В частности, подписчики Netflix тратят более 165 миллионов часов на просмотр более 4 000 фильмов и 47 000 серий в день. Эти впечатляющие статистические данные показывают, что с инженерной точки зрения технические группы Netflix разработали такую потрясающую систему потокового видео с очень высокой доступностью и масштабируемостью, чтобы обслуживать своих клиентов по всему миру.
Однако техническим командам потребовалось более 8 лет, чтобы их ИТ-системы были такими, как сейчас ([1]). Фактически, преобразование инфраструктуры Netflix началось в августе 2008 года после того, как в его собственных центрах обработки данных отключили все услуги по аренде DVD на три дня. Netflix понял, что ему нужна более надежная инфраструктура без единой точки отказа. Поэтому было принято два важных решения: миграция ИТ-инфраструктуры из центров обработки данных в общедоступное облако и замена монолитных программ небольшими управляемыми программными компонентами архитектурой микросервисов. Оба решения напрямую повлияли на успех Netflix сегодня.
Netflix выбрала облако AWS ([4]) для миграции своей ИТ-инфраструктуры, поскольку AWS может предложить высоконадежные базы данных, крупномасштабное облачное хранилище и несколько центров обработки данных по всему миру. Используя облачную инфраструктуру, созданную и обслуживаемую AWS, Netflix не выполнил тяжелую недифференцированную работу по созданию центров обработки данных, а больше сосредоточился на своей основной деятельности - предоставлении пользователям высококачественного потокового видео. Несмотря на то, что ему необходимо перестроить всю технологию, чтобы обеспечить ее бесперебойную работу в облаке AWS, улучшение масштабируемости Netflix и доступность услуг значительно выиграли в свою очередь.
Netflix также является одним из первых основных драйверов архитектуры микросервисов. Микросервисы нацелены на решение проблем монолитного проектирования программного обеспечения, поощряя разделение задач ([11]), при котором большие программы разбиваются на более мелкие программные компоненты посредством модульности с инкапсуляцией данных самой по себе. Микросервисы также помогают повысить масштабируемость за счет горизонтального масштабирования и разделения рабочей нагрузки. Внедряя микросервисы, инженеры Netflix легко меняют любые сервисы, что приводит к более быстрому развертыванию. Что еще более важно, они могут отслеживать производительность каждой службы и быстро изолировать ее проблемы от других работающих служб.
В этом исследовании я заинтересован в понимании облачной архитектуры Netflix и ее производительности при различных рабочих нагрузках и сетевых ограничениях. В частности, я хочу проанализировать структуру системы с точки зрения доступности, задержки, масштабируемости и устойчивости к сбоям сети или сбоям системы. Это исследование организовано следующим образом. В разделе 2 будет описана возможная архитектура системы Netflix, полученная из различных онлайн-источников. Затем в разделе 3 будут рассмотрены более подробные компоненты системы. В разделах 4, 5, 6, 7 я проанализирую систему в отношении вышеуказанных целей проектирования. Наконец, я делаю вывод о том, что было извлечено из этого анализа, и о возможных следующих шагах, которые необходимо предпринять для улучшения.
2. Архитектура
Netflix работает на основе сервисов облачных вычислений Amazon (AWS) и Open Connect, собственной сети доставки контента ([1]). Обе системы должны работать вместе, чтобы предоставлять высококачественные услуги потокового видео по всему миру. С точки зрения архитектуры программного обеспечения Netflix состоит из трех основных частей: клиента, серверной части и сети доставки контента (CDN).
Клиент - это любой поддерживаемый браузер на ноутбуке или настольном компьютере или приложение Netflix на смартфонах или смарт-телевизорах. Netflix разрабатывает собственные приложения для iOS и Android, чтобы обеспечить наилучшие впечатления от просмотра для каждого клиента и устройства. Управляя своими приложениями и другими устройствами с помощью своего SDK, Netflix может прозрачно адаптировать свои потоковые сервисы при определенных обстоятельствах, таких как медленные сети или перегруженные серверы.
Backend включает сервисы, базы данных и хранилища, полностью работающие в облаке AWS. Backend в основном обрабатывает все, кроме потокового видео. Некоторые компоненты Backend с соответствующими сервисами AWS перечислены ниже:
Масштабируемые вычислительные инстансы (AWS EC2)
Масштабируемое хранилище (AWS S3)
Микросервисы бизнес-логики (специализированные фреймворки Netflix)
Масштабируемые распределенные базы данных (AWS DynamoDB, Cassandra)
Обработка больших данных и аналитика (AWS EMR, Hadoop, Spark, Flink, Kafka и другие специализированные инструменты Netflix)
Обработка и перекодирование видео (специализированные инструменты Netflix)
Open Connect CDN - это сеть серверов под названием Open Connect Appliances (OCAs), оптимизированная для хранения и потоковой передачи больших видео. Эти серверы OCAs размещаются внутри сетей интернет-провайдеров (ISP) и точек обмена интернет-трафиком (IXP) по всему миру. OCAs несут ответственность за потоковую передачу видео непосредственно клиентам.
В следующих разделах я опишу справочную облачную архитектуру Netflix, состоящую из этих трех частей. В разделе 2.1 общая архитектура способна передавать потоковое видео, называемая архитектурой воспроизведения, после того, как подписчик нажимает кнопку «Воспроизвести» в своих приложениях. Затем в разделе 2.2 будет описана более подробная архитектура микросервисов Backend, чтобы продемонстрировать, как Netflix обеспечивает доступность и масштабируемость в глобальном масштабе.
2.1 Архитектура воспроизведения
Когда подписчики нажимают кнопку «Воспроизвести» в своих приложениях или устройствах, клиент будет общаться как с серверной частью на AWS, так и с OCAs на Netflix CDN для потоковой передачи видео ([7]). На следующей диаграмме показано, как работает процесс воспроизведения:
Fig 1. Playback architecture for streaming videos
OCAs постоянно отправляет отчеты о состоянии своей рабочей нагрузки, возможности маршрутизации и доступных видео в службу Cache Control, работающую в AWS EC2, чтобы приложения для воспроизведения могли обновлять клиентам последние исправные OCAs. Запрос воспроизведения отправляется с клиентского устройства в сервис Netflix Playback Apps, работающий на AWS EC2, чтобы получить URL-адреса для потоковой передачи видео.
Служба Playback Apps должна определить, что запрос воспроизведения будет действителен для просмотра конкретного видео. Такие проверки будут проверять план подписчика, лицензирование видео в разных странах и т. Д.
Сервис Playback Apps обращается к сервису Steering, также работающему в AWS EC2, чтобы получить список соответствующих серверов OCAs для запрошенного видео. Служба управления использует IP-адрес клиента и информацию об интернет-провайдерах, чтобы определить набор подходящих OCAs, которые лучше всего подходят для этого клиента.
Из списка 10 различных серверов OCAs, возвращаемых службой Playback Apps, клиент проверяет качество сетевых подключений к этим OCAs и выбирает самый быстрый и надежный OCAs для запроса видеофайлов для потоковой передачи.
Выбранный сервер OCAs принимает запросы от клиента и запускает потоковую передачу видео.
На приведенной выше диаграмме служба Playback Apps, служба управления и служба управления кешем полностью работают в облаке AWS на основе архитектуры микросервисов. В следующем разделе я опишу эталонную архитектуру микросервисов Netflix Backend, которая увеличивает доступность и масштабируемость запущенных сервисов.
2.2 Бэкэнд-архитектура
Как я описывал в предыдущих разделах, Backend обрабатывает практически все, начиная от регистрации, входа в систему, выставления счетов и заканчивая более сложными задачами обработки, такими как перекодирование видео и персональные рекомендации. Чтобы поддерживать как легкие, так и тяжелые рабочие нагрузки, выполняемые в одной и той же базовой инфраструктуре, Netflix выбрала архитектуру микросервисов для своей облачной системы. Диаграмма на рисунке 2 представляет возможную архитектуру микросервисов в Netflix, которую я извлек из нескольких онлайн-источников ([11, 13, 14]):
Fig 2. A reference of Backend architecture based on various sources
Клиент отправляет запрос воспроизведения в серверную часть, работающую на AWS. Этот запрос обрабатывается балансировщиком нагрузки AWS (ELB).
AWS ELB перенаправит этот запрос в службу шлюза API, работающую на экземплярах AWS EC2. Этот компонент, названный Zuul, создан командой Netflix для обеспечения динамической маршрутизации, мониторинга трафика и обеспечения безопасности, а также устойчивости к сбоям на границе развертывания облака. Запрос будет применен к некоторым предопределенным фильтрам, соответствующим бизнес-логике, а затем направлен в API приложения для дальнейшей обработки.
Компонент API приложения - это основная бизнес-логика операций Netflix. Существует несколько типов API, соответствующих различным действиям пользователя, например API регистрации, API рекомендаций для получения рекомендаций по видео. В этом сценарии перенаправленный запрос от службы шлюза API обрабатывается Play API.
Play API вызовет микросервис или последовательность микросервисов для выполнения запроса. Службу Playback Apps, службу управления и службу управления кешем на рис. 1 можно рассматривать как микросервис на этой схеме.
Микросервисы - это в основном небольшие программы без сохранения состояния, которые также могут вызывать друг друга. Чтобы контролировать каскадный сбой и обеспечить отказоустойчивость, каждый микросервис изолируется от вызывающих процессов с помощью Hystrix. Его результат после выполнения можно кэшировать в кэше памяти, чтобы обеспечить более быстрый доступ для этих критически важных запросов с низкой задержкой.
Микросервисы могут сохранять или получать данные из хранилища данных во время его обработки.
Микросервисы могут отправлять события для отслеживания действий пользователей или другие данные в конвейер потоковой обработки для обработки персонализированных рекомендаций в реальном времени или пакетной обработки задач бизнес-аналитики.
Данные, поступающие из конвейера потоковой обработки, могут быть постоянными для других хранилищ данных, таких как AWS S3, Hadoop HDFS, Cassandra и т. Д.
Описанные архитектуры помогают нам получить общее представление о том, как различные части организуются и работают вместе для потоковой передачи видео. Однако, чтобы проанализировать доступность и масштабируемость архитектур, нам нужно более подробно изучить каждый важный компонент, чтобы увидеть, как он работает при различных рабочих нагрузках. Это будет рассмотрено в следующем разделе.
3. Компоненты
В этом разделе я хочу изучить компоненты, определенные в разделе 2, чтобы проанализировать их доступность и масштабируемость. При описании каждого компонента я также хотел бы указать, как он отвечает этим целям дизайна. Более подробный анализ проекта будет упомянут в следующих разделах в отношении всей системы.
3.1 Клиент
Технические группы Netflix приложили немало усилий для разработки более быстрых и интеллектуальных клиентских приложений, работающих на ноутбуках, настольных компьютерах или мобильных устройствах. Даже на некоторых смарт-телевизорах, в которых Netflix не имеет специализированного клиента, Netflix по-прежнему контролирует его производительность с помощью предоставленного SDK. Фактически, любая среда устройства должна установить платформу Netflix Ready Device Platform (NRDP), чтобы обеспечить наилучшее качество просмотра Netflix. Типичный структурный компонент клиента ([11]) показан на рисунке 3.
Fig 3. Client App Component
Клиентские приложения разделяют 2 типа подключений к Backend для обнаружения и воспроизведения контента. Клиент использует протокол NTBA ([15]) для запросов на воспроизведение, чтобы обеспечить большую безопасность на своих серверах OCAs и устранить задержку, вызванную квитированием SSL / TLS для новых подключений.
При потоковой передаче видео клиентское приложение интеллектуально снижает качество видео или переключается на другие серверы OCAs ([1]), если сетевые соединения перегружены или имеют ошибки. Даже если подключенный OCAs перегружен или вышел из строя, клиентское приложение может легко переключиться на другой сервер OCAs для лучшего просмотра. Все это может быть достигнуто благодаря тому, что SDK платформы Netflix на клиенте отслеживает последние исправные OCAs, полученные из службы Playback Apps (рисунок 1).
3.2 Бэкэнд
3.2.1 Служба шлюза API
Fig 4. Zuul Gateway Service Component
Входящие фильтры могут использоваться для аутентификации, маршрутизации и оформления запроса.
Фильтр конечных точек можно использовать для возврата статических ресурсов или направления запроса соответствующему источнику или API-интерфейсу приложения для дальнейшей обработки.
Исходящие фильтры можно использовать для отслеживания метрик, украшения ответа пользователю или добавления настраиваемых заголовков.
Zuul может открывать для себя новый API приложений путем интеграции с Service Discovery Eureka
Zuul широко используется для маршрутизации трафика для различных целей, таких как адаптация API нового приложения, нагрузочные тесты, маршрутизация к различным конечным точкам службы при огромных рабочих нагрузках.
3.2.2 API приложения
API приложения играет роль уровня оркестрации ([18]) для микросервисов Netflix. API обеспечивает логику составления вызовов базовых микросервисов в необходимом порядке с дополнительными данными из других хранилищ данных для создания соответствующих ответов. Команда Netflix потратила много времени на разработку компонента Application API, поскольку он соответствует основным бизнес-функциям Netflix. Он также должен быть масштабируемым, высокодоступным при большом объеме запросов. В настоящее время API приложений определены в трех категориях: API регистрации для запросов, не являющихся участниками, таких как регистрация, выставление счетов, бесплатная пробная версия и т. Д., API обнаружения для поиска, запросы рекомендаций и API воспроизведения для потоковой передачи, просмотр запросов на лицензирование. Подробная структурная схема компонентов Application API представлена на рисунке 5.
Fig 5. Separation of Play and Discovery Application API
В недавнем обновлении реализации Play API сетевой протокол между Play API и микросервисами - это gRPC / HTTP2, который «позволяет определять методы и объекты RPC через буферы протокола, а клиентские библиотеки / SDK автоматически генерируются на различных языках» ([ 13]). Это изменение позволяет Application API надлежащим образом интегрироваться с автоматически сгенерированными клиентами посредством двунаправленной связи и «минимизировать повторное использование кода через границы сервисов».
API приложения также предоставляет общий устойчивый механизм, основанный на командах Hystrix, для защиты лежащих в его основе микросервисов.
Поскольку Application API должен обрабатывать огромные объемы запросов и создавать соответствующие ответы, его внутренняя обработка должна выполняться параллельно. Команда Netflix обнаружила, что сочетание синхронного выполнения и асинхронного ввода-вывода ([13]) является правильным подходом.
Fig 6. Synchronous Execution & Asynchronous I/O of Application API
Каждый запрос от службы шлюза API будет помещен в цикл сетевых событий API приложения для обработки.
Каждый запрос будет заблокирован выделенным обработчиком потока, который помещает команды Hystrix, такие как getCustomerInfo, getDeviceInfo и т. Д., В цикл исходящих событий. Этот цикл исходящих событий настраивается для каждого клиента и работает с неблокирующим вводом-выводом. После завершения или истечения тайм-аута вызывающих микросервисов выделенный поток будет создавать соответствующие ответы.
3.2.3 Микросервисы
Согласно определению Мартина Фаулера, «микросервисы - это набор небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с легковесными механизмами…». Эти небольшие программы можно независимо развертывать или обновлять по сравнению с другими, и они имеют свои собственные инкапсулированные данные.
Реализация компонента микросервисов в Netflix ([11]) показана на рисунке 7.
Fig 7. Structural component of a microservice
Микросервис может работать сам по себе или вызывать другие микросервисы через REST или gRPC.
Реализация микросервиса может быть аналогична реализации API приложения, как показано на рисунке 6, на котором запросы будут помещены в цикл сетевых событий, а результаты от других вызываемых микрослужб помещаются в очередь результатов при асинхронном неблокирующем вводе-выводе.
Каждая микрослужба может иметь собственное хранилище данных и несколько кеш-хранилищ последних результатов в памяти. EVCache - это основной выбор для кэширования микросервисов в Netflix.
3.2.4 Хранилища данных
При миграции своей инфраструктуры в облако AWS Netflix использовала разные хранилища данных (рис. 8), как SQL, так и NoSQL, для разных целей ([6]).
Fig 8. Netflix Data Stores deployed on AWS
Базы данных MySQL используются для управления названиями фильмов и транзакций / выставления счетов.
Hadoop используется для обработки больших данных на основе пользовательских журналов.
ElasticSearch обеспечил поиск заголовков для приложений Netflix
Cassandra - это распределенное хранилище данных NoSQL на основе столбцов для обработки большого количества запросов на чтение без единой точки отказа. Чтобы оптимизировать задержку при выполнении больших запросов на запись, используется Cassandra из-за ее в конечном итоге согласованной способности.
3.2.5 Трубопровод обработки потока
Конвейер потоковой обработки данных ([14, 3]) стал основой данных Netflix для бизнес-аналитики и задач персонализированных рекомендаций. Он отвечает за создание, сбор, обработку, агрегирование и передачу всех событий микросервисов другим обработчикам данных почти в реальном времени. На рисунке 9 показаны различные части платформы.
Fig 9. Keystone Stream Processing Platform at Netflix
Платформа потоковой обработки обрабатывала триллионы событий и петабайты данных в день. Он также будет автоматически масштабироваться по мере увеличения количества подписчиков.
Модуль Router обеспечивает маршрутизацию к различным приемникам данных или приложениям, в то время как Kafka отвечает за маршрутизацию сообщений, а также за буферизацию для нисходящих систем.
Потоковая обработка как услуга (SPaaS) позволяет инженерам по обработке данных создавать и контролировать свои настраиваемые приложения управляемой потоковой обработки, в то время как платформа позаботится о масштабируемости и операциях.
3.3 Открыть Connect
Open Connect - это глобальная сеть доставки контента (CDN), отвечающая за хранение и доставку телешоу и фильмов Netflix своим подписчикам по всему миру. Netflix разработала и эффективно использовала Open Connect, перенеся контент, который люди хотят смотреть, как можно ближе к тому месту, где они хотят его смотреть. Чтобы локализовать трафик просмотра видео Netflix в сети клиентов, Netflix в партнерстве с поставщиками интернет-услуг (ISP) и точками обмена интернет-трафиком (IX или IXP) по всему миру развертывает специализированные устройства, называемые Open Connect Appliances (OCAs). внутри их сети ([7]).
Fig 10. Deployment of OCAs to IXs or ISPs sites
OCAs - это серверы, оптимизированные для хранения и потоковой передачи больших видеофайлов с сайтов IX или ISP непосредственно в дома подписчиков. Эти серверы периодически сообщают об оптимальных маршрутах с метриками работоспособности, которые они узнали из сетей IXP / ISP, и о том, какие видеоролики они хранят на своих SSD-дисках, в сервисы Open Connect Control Plane на AWS. В свою очередь, службы уровня управления будут принимать такие данные, чтобы автоматически направлять клиентские устройства к наиболее оптимальным OCAs, учитывая доступность файлов, состояние сервера и близость сети к клиентам.
Службы уровня управления также управляют поведением заполнения при добавлении новых файлов или обновлении файлов в OCAs каждую ночь. Поведение при заполнении ([8,9]) показано на рисунке 11.
Когда новые видеофайлы были успешно перекодированы и сохранены на AWS S3, сервисы уровня управления на AWS передадут эти файлы на серверы OCAs на сайтах IXP. Эти серверы OCAs будут применять заполнение кеша для передачи этих файлов на серверы OCAs на сайтах интернет-провайдеров в их подсетях.
Когда сервер OCAs успешно сохранил видеофайлы, он сможет запустить одноранговое заполнение, чтобы скопировать эти файлы на другие серверы OCAs на том же сайте, если это необходимо.
Между двумя разными сайтами, которые могут видеть IP-адреса друг друга, OCAs могут применять процесс заполнения уровней вместо обычного заполнения кеша.
Fig 11. Fill patterns among OCAs
4. Цели дизайна
В предыдущих разделах я подробно описал облачную архитектуру и ее компоненты, лежащие в основе бизнеса Netflix в области потокового видео. В этом и последующих разделах я хотел бы глубже проанализировать эту архитектуру дизайна. Я начинаю со следующего списка наиболее важных целей дизайна:
Обеспечьте высокую доступность потоковых сервисов в глобальном масштабе.
Устойчивость к сбоям в сети и сбоям системы.
Минимизируйте задержку потоковой передачи для каждого поддерживаемого устройства в различных сетевых условиях.
Поддержка масштабируемости при большом объеме запросов.
В подразделах я собираюсь проанализировать доступность потоковой службы и соответствующую оптимальную задержку. В разделе 6 рассматривается более глубокий анализ механизмов устойчивости, таких как Chaos Engineering, а в разделе 7 рассматривается масштабируемость потоковых сервисов.
4.1 Высокая доступность
По определению доступность системы измеряется с точки зрения того, сколько раз будет выполнен ответ на запрос в течение определенного периода времени, без гарантии того, что он содержит самую последнюю версию информации. В нашей конструкции системы доступность потоковых сервисов зависит как от доступности серверных сервисов, так и от серверов OCAs, на которых хранятся потоковые видеофайлы.
Цель серверных служб - получить список наиболее здоровых OCAs, близких к конкретному клиенту, либо из кеша, либо путем выполнения некоторых микросервисов. Следовательно, его доступность зависит от различных компонентов, включающих запрос воспроизведения: балансировщики нагрузки (AWS ELB), прокси-серверы (API Gateway Service), Play API, выполнение микросервисов, хранилища кешей (EVCache) и хранилища данных (Cassandra):
Балансировщики нагрузки могут улучшить доступность, направляя трафик на разные прокси-серверы, чтобы предотвратить перегрузку рабочих нагрузок.
Play API контролирует выполнение микросервисов с тайм-аутом с помощью команд Hystrix, которые могут помочь предотвратить каскадные сбои для других сервисов.
Микросервисы могут отвечать на Play AI данными в кеше, если вызов внешних служб или хранилищ данных занимает больше времени, чем ожидалось.
Кэш реплицируется для более быстрого доступа.
Получая список серверов OCAs от Backend, клиент проверяет сеть на эти OCAs и выбирает лучшие OCAs для подключения. Если этот OCAs перегружен или не работает во время процесса потоковой передачи, то клиент переключается на другой исправный, или Platform SDK запросит другие OCAs. Следовательно, его доступность сильно коррелирует с доступностью всех OCAs, доступных в его ISP или IXP.
Высокая доступность потоковых сервисов Netflix достигается за счет сложных многорегиональных операций и сервисов AWS, а также избыточности серверов OCAs.
4.2 Низкая задержка
Задержка потоковых сервисов в основном зависит от того, насколько быстро Play API может разрешить список исправных OCAs и насколько хорошо соединение клиента с выбранным сервером OCAs.
Как я описал в разделе «Компонент API приложения», Play API не ожидает выполнения микросервиса вечно, поскольку он использует команды Hystrix для управления временем ожидания результата, прежде чем он получит устаревшие данные из кеш. Это может контролировать допустимую задержку, а также остановить каскадные отказы для других служб.
Клиент немедленно переключится на другие близлежащие серверы OCAs с наиболее надежным сетевым подключением, если произойдет сбой сети на текущем выбранном сервере OCAs или этот сервер будет перегружен. Он также может снизить качество видео, чтобы оно соответствовало качеству сети, в случае обнаружения ухудшения сетевого подключения.
5. Компромиссы
В описанной выше конструкции системы были тщательно реализованы два важных компромисса:
Низкая задержка по сравнению с согласованностью
Высокая доступность важнее согласованности
Компромисс между задержкой и согласованностью встроен в архитектуру серверных служб. Play API может получать устаревшие данные из хранилищ EVCache или из, в конечном итоге, согласованных хранилищ данных, таких как Cassandra.
Точно так же компромисс между доступностью и согласованностью предпочел бы построение ответов с приемлемой задержкой, не требуя выполнения микросервисов для последних данных в хранилищах данных, таких как Cassandra.
Также существует не совсем актуальный компромисс между масштабируемостью и производительностью ([21]). В этом компромиссе улучшение масштабируемости за счет увеличения числа экземпляров для обработки большего количества рабочих нагрузок может привести к тому, что система будет работать с ожидаемым увеличением производительности. Это может быть проблемой для тех архитектур проектирования, в которых нагрузка не сбалансирована между доступными рабочими. Однако Netflix решил этот компромисс с автоматическим масштабированием AWS. Мы вернемся к этому решению более подробно в Разделе 7.
6. Устойчивость
Разработка облачной системы, способной к самовосстановлению после сбоев или отключений, была долгой целью Netflix с самого начала миграции в облако AWS. Некоторые распространенные сбои системы были устранены следующим образом:
Сбой в разрешении зависимостей службы.
Сбой при выполнении микросервиса может вызвать каскадные отказы других сервисов.
Ошибка подключения к API из-за перегрузки.
Сбой подключения к экземплярам или серверам, таким как OCAs.
Для обнаружения и устранения этих сбоев служба шлюза API Zuul ([20]) имеет встроенные функции, такие как адаптивные повторные попытки, ограничивающие одновременные вызовы API приложений. В свою очередь, API приложения использует команды Hystrix для тайм-аута вызовов микросервисов, чтобы остановить каскадные сбои и изолировать точки сбоев от других.
Технические команды Netflix также известны своей практикой хаоса в области инженерии. Идея состоит в том, чтобы вводить псевдослучайные ошибки в производственные среды и создавать решения для автоматического обнаружения, изоляции и восстановления после таких сбоев. Ошибки могут добавлять задержки к ответам при выполнении микросервисов, отключать службы, останавливать серверы или экземпляры и даже приводить к отключению всей инфраструктуры региона ([5]). Целенаправленно вводя реалистичные производственные сбои в контролируемую среду с помощью инструментов для обнаружения и устранения таких сбоев, Netflix может быстро обнаруживать такие слабые места, прежде чем они вызовут более серьезные проблемы.
7. Масштабируемость
В этом разделе я проанализирую масштабируемость потоковых сервисов Netflix, охватывая горизонтальное масштабирование, параллельное выполнение и разделение базы данных. Другие части, такие как кеширование и балансировка нагрузки, также помогают повысить масштабируемость, были упомянуты в разделе 4.
Во-первых, горизонтальное масштабирование инстансов EC2 в Netflix обеспечивается сервисом AWS Auto Scaling Service. Этот сервис AWS автоматически запускает больше эластичных экземпляров, если объем запросов увеличивается, и отключает неиспользуемые. В частности, поверх тысяч таких экземпляров Netflix построил Titus ([17]), платформу управления контейнерами с открытым исходным кодом, которая позволяет запускать около 3 миллионов контейнеров в неделю. Кроме того, любой компонент нашей архитектуры, показанной на рисунке 2, можно развернуть внутри контейнера. Более того, Titus позволяет контейнерам работать в нескольких регионах на разных континентах по всему миру.
Во-вторых, реализация прикладного API или микросервиса в разделе 3.2.2 также увеличивает масштабируемость, позволяя параллельное выполнение задач в цикле сетевых событий и асинхронном цикле исходящих событий.
Наконец, хранилища с широкими столбцами, такие как Cassandra, и хранилища объектов типа "ключ-значение", такие как ElasticSearch, также обеспечивают высокую доступность и масштабируемость без единой точки отказа.
8. Заключение
References
- Netflix: What Happens When You Press Play? By Todd Hoff on Dec 11, 2017. Link
- High Quality Video Encoding at Scale. By Anne Aaron and David Ronca on HighScalability. Dec 9, 2015. Link
- Building and Scaling Data Lineage at Netflix to Improve Data Infrastructure Reliability, and Efficiency. By Di Lin, Girish Lingappa, Jitender Aswani on The Netflix Tech Blog. Mar 25, 2019. Link
- Ten years on: How Netflix completed a historic cloud migration with AWS. By Tom Macaulay on Computerworld. Sep 10, 2018. Link
- The Netflix Simian Army. By Yury Izrailevsky and Ariel Tseitlin on The Netflix Tech Blog. Link
- Globally Cloud Distributed Applications at Netflix. By Adrian Cockcroft. Oct 2012. Link
- Open Connect Overview. By Netflix. Link
- Open Connect Deployment Guide. By Netflix. Link
- Netflix and Fill. By Michael Costello and Ellen Livengood. Aug 11, 2016. Link
- Automating Operations of a Global CDN. By Robert Fernandes at Strange Loop. Sep 14, 2019. Link
- Mastering Chaos — A Netflix Guide to Microservices. By Josh Evans at QCon. Dec 07, 2016. Link
- Netflix Revenue and Usage Statistics. By Mansoor Iqbal on BusinessofApps. March 6, 2020. Link
- Netflix Play API — Why we build an Evolutionary Architecture. By Suudhan Rangarajan at QCon 2018. Dec 12, 2018. Link
- Keystone Real-time Stream Processing Platform. By Zhenzhong Xu on The Netflix Tech Blog. Sep 10, 2018. Link
- Netflix Releases Open Source Message Security Layer. By Chris Swan on InfoQ. Nov 24th, 2014. Link
- Netflix Open Source. Link
- Titus, the Netflix container management platform, is now open source. By Amit Joshi and others. Link
- Engineering Trade-Offs and The Netflix API Re-Architecture. By Katharina Probst and Justin Becker on The Netflix Tech Blog. Aug 23, 2016. Link
- Kafka Inside Keystone Pipeline. By Real-Time Data Infrastructure Team. April 27, 2016. Link
- Open Sourcing Zuul 2. By Arthur Gonigberg and others on The Netflix Tech Blog. May 21, 2018. Link
- Performance Vs Scalability. By Beekums. Aug 19, 2017. Link
Перевод статьи с сайта https://medium.com/