#NetflixAndChill: масштабирование Netflix с помощью Node.js и контейнеров
Не так давно Netflix была просто компанией по производству DVD. Когда Ким Тротт, директор по разработке платформы пользовательского интерфейса в Netflix, начал работать в компании около девяти лет назад, компания только начинала транслировать видео и имела каталог всего из 50 наименований. Теперь компания транслирует контент по всему миру и выпускает собственные оригинальные программы.
По мере того, как компания продолжает расширяться, команда UI Platform сосредоточена на создании приложения Netflix, чтобы убедиться, что оно максимально эффективно и результативно до начала производства. Учитывая масштабность Netflix, они придумали новые способы добиться этого.
В этом корпоративном интервью (полное видео вы можете найти здесь) Майкал Роджерс, менеджер сообщества в Node.js Foundation, беседует с Юнонг Сяо, архитектором платформы в Netflix, и Ким Тротт о том, как Netflix продвигается с их контейнеризацией своих границ. уровень обслуживания (который позволяет команде Netflix получать доступ к данным со всеми сотнями внутренних микросервисов, которые существуют в Netflix), другие проекты Node.js в Netflix и то, как Netflix возвращает технологии через рабочие группы.
Майкл: Привет, добро пожаловать в корпоративные обсуждения с Фондом Node.js. Я Майкл Роджерс, менеджер сообщества. Сегодня с нами Ким Тротт и Юнонг Сяо из Netflix. Скажи привет.
Ким: Привет.
Юнун: Всем привет.
Майкал: Почему бы вам не рассказать нам немного о себе, своих ролях и команде, а также о том, чем вы все занимаетесь в Netflix?
Ким: Команда, которой я управляю в Netflix, называется командой UI Platform. Мы находимся внутри организации, занимающейся разработкой пользовательского интерфейса. Задача нашей команды состоит в том, чтобы помочь всем командам, занятым созданием приложения Netflix, просто сделать их более продуктивными и эффективными. Это может охватывать широкий круг вопросов. Это может быть создание библиотек, совместно используемых всеми командами, которые упрощают доступ к данным или ведение журнала на стороне клиента. Мы пишем эти библиотеки на JavaScript, Objective-C и Java, на любых целевых платформах, которые есть у нас в командах. Затем мы также работаем над платформой Node.js здесь, в Netflix, и создаем вещи, чтобы упростить запуск приложений Node.js и производство для команд, ориентированных на пользовательский интерфейс.
Юнонг: В общем, моя роль в Netflix заключается в том, чтобы работать над платформой Node.js. Я помогаю запускать Node в масштабе здесь. Прямо сейчас мы находимся в середине большой проблемы реструктуризации, о которой мы поговорим позже, о доступе к данным и Netflix. Моя основная роль здесь состоит в том, чтобы развернуть и запустить Node.js в нужном масштабе, а также убедиться, что он работает, поддается отладке и хорошо работает для нас.
Ким: Мы также консультируем, помогая командам справляться с различными проблемами, придумывая решения этих проблем, помогая им интегрировать новые технологии, которые мы внедряем. Например, когда мы работаем над новой проблемой локализации, мы помогаем всем командам внедрить эту новую услугу, как если бы это было управление строками. Мы хотели бы, чтобы группа помощи приняла это и проложила бы им путь к тому, чтобы убедиться, что это работает бесперебойно, прежде чем команда, ориентированная на продукт, примет это.
Майкл: Как давно вы работаете в Netflix?
Ким: Я работаю в Netflix 9 лет в июле. Когда я начинал, это было действительно правильно, когда мы запустили первую потоковую передачу, поэтому вы могли смотреть только в проигрывателе Windows Media на машине с Windows. Я думаю, что в каталоге было около 50 наименований, так что это было очень, очень рано. В то время мы были в основном производителем DVD, поэтому я видел, как Netflix перешла от DVD к потоковой передаче и теперь стала нашим собственным производителем контента.
Юнонг: Я здесь почти 2 года. Когда я начинал, у нас только что была вечеринка на 50 миллионов, которую я просто пропустил, но скоро мы приближаемся к 100 миллионам подписчиков, так что у нас будет более крупная вечеринка.
Ким: Надеюсь.
Юнонг: Раньше я несколько лет работал в Joyent, работая над Node.js и распределенными системами, а до этого я работал в AWS, также работая над распределенными системами.
Майкл: Круто, очень здорово. Вы выступили с докладом на Node.js Interactive (Ким), который был очень хорошо принят. Я думаю, что на самом деле это наше видео номер один. В разговоре вы упомянули, что выполняете некоторую контейнеризацию пограничных сервисов в Netflix. Не могли бы вы рассказать нам, как это продвигается?
Ким: Да, с тех пор, как мы выступили в Node Interactive, мы добились значительного прогресса в этом проекте, и на самом деле мы собираемся запустить системное тестирование и теневой трафик, поэтому мы собираемся чтобы начать с теневого трафика, а затем запустить полное тестирование системы, где мы фактически пропускаем клиентский трафик (реальный производственный трафик) через новый уровень контейнера узла, чтобы проверить весь стек и устранить любые проблемы, связанные с масштабированием или памятью. Это действительно интересно. За последние несколько месяцев было проделано много тяжелой работы, чтобы добраться до этого момента, поэтому команда очень взволнована. Юнонг может поделиться некоторыми интересными технологическими инновациями или идеями, которые мы вложили в этот проект, который нам очень нравится.
Юнонг: Я просто расскажу вам немного об этом проекте. Сегодня, когда какое-либо устройство или клиент пытается получить доступ к Netflix, они должны использовать так называемые Edge Services, которые представляют собой набор сценариев конечных точек, написанных на Groovy, которые они записывают в монолитную систему на основе JVM, которая позволяет им получать доступ к данным со всеми сотнями серверные микросервисы, существующие в Netflix. У нас это очень хорошо работает, но мы сталкиваемся с некоторыми проблемами вертикального масштабирования. Мы подумали: «Эй, это отличная возможность использовать Node, который использует JavaScript». Многие наши клиентские инженеры действительно хорошо разбираются в этом, и большинство наших пользовательских интерфейсов написаны на JavaScript и Docker, чтобы иметь возможность горизонтально масштабировать все эти сценарии доступа к данным.
Это был действительно интересный проект. Одна из вещей, которые, как мне кажется, мы делаем и используем довольно уникальный подход, - это способ маршрутизации всех этих скриптов доступа к данным. Традиционно сегодня все происходит внутри одной модели, а маршрутизация не полностью внутри JVM. Итак, мы разбиваем все эти сотни различных скриптов доступа к данным на отдельные приложения Node.js, а это значит, что мы должны иметь возможность управлять ими более незаметно.
Один из принятых нами подходов - это использование semver как способа маршрутизации к каждому из этих отдельных приложений. Теперь мы обновляем каждое приложение с помощью семантического управления версиями, а затем можем выполнять маршрутизацию на основе этой версии. Отдельный клиент может запросить дополнительную версию, версию патча или основную версию, и так же, как это работает с пакетами NPM, мы можем направить этот запрос на последнюю вспомогательную версию или последнюю основную версию, в частности на Node. приложение внутри контейнера. Это действительно новинка, потому что это помогает нам легко обновлять все на нашем сервере, точно так же, как NPM работает с пакетами Node, но помогает нам поддерживать тех же клиентов во внешнем интерфейсе. Многие наши клиенты используют модель магазина приложений, что означает, что они существуют в течение очень долгого времени и никогда не обновляются, но мы по-прежнему хотим гибкости, чтобы иметь возможность обновлять все наши приложения для доступа к данным. запуск Node внутри контейнеров. Это одна из новинок, которую мы сделали и над чем работаем прямо сейчас.
Я выступал в Container Camp с более подробной информацией об этой реализации, но мы думаем, что это действительно новинка. Наряду с этим, очевидно, что мы также создаем реестр, как и реестр NPM, который является индексом для всех этих приложений, чтобы мы могли выяснить, какая версия semver какого приложения указывает на какую версию Docker. Netflix реализует очень большой сквозной проект, в котором участвует не только наша команда, но и множество команд. Это включает в себя команду Edge Services, команду инструментов ... У нас есть команда, которая также работает над всей инфраструктурой на основе контейнеров Docker. Это действительно захватывающее время для работы в Netflix.
Ким: Я думаю, что это действительно поможет нам отслеживать версии, запущенные в производственной среде, и когда возникает необходимость, скажем, в исправлении безопасности или каком-либо критическом обновлении, чтобы иметь возможность использовать семантику семантики версии исправления. чтобы нацелиться на это и получить это исправление без необходимости изменять какой-либо клиентский код, что важно для нас, потому что каждый раз, когда мы запускаем нового клиента, это может вызвать отток с точки зрения производительности и других аспектов, и иногда приходится уходить через процесс сертификации для модели магазина приложений. Мы можем двигаться намного быстрее, просто обновляя на стороне сервера, без необходимости влиять на клиентскую сторону.
Майкл: Великолепно. Как это повлияло на производительность разработчиков в Netflix? Вы упомянули, что это позволяет вам двигаться намного быстрее и вам не нужно проходить весь процесс в магазине приложений. Вы также немного упомянули об этом в своем выступлении, я думаю, тоже.
Ким: Да, мы еще не находимся на стадии широкого внедрения этого. Как я уже упоминал, сейчас мы собираемся запустить на следующей неделе теневой трафик, который, по сути, забирает проходящий клиентский трафик, а затем затеняет его по сравнению с новым стеком приложений Node и обеспечивает его масштабирование. Я думаю, что мы еще не осознали некоторые преимущества производительности разработчиков, но у нас есть люди, которые используют его на ранних этапах для создания системного теста, который мы проводим, и пока я думаю, что отзывы об этом были действительно положительными. .
На самом деле продуктивность разработчиков достигается за счет разбиения монолита на более мелкие части, которые теперь гораздо проще запускать локально на вашем компьютере. С помощью контейнеризации мы действительно можем гарантировать, что то, что вы выполняете локально, будет очень точно отражать то, что вы запускаете в производственной среде. Это действительно полезно. Из-за того, как работает Node, мы можем атаковать отладчики, устанавливать точки останова и прочее через код.
Раньше, если вы хотели отлаживать эти сценарии Groovy, вы вносили некоторые изменения в код, загружали его на уровень Edge, запускали его, видели, что он ломается, вносили еще несколько изменений, загружали его. Был REPL, но было сложно вытащить код из сценария и запустить его в REPL. Это действительно сложный рабочий процесс для разработчиков. Множество заявлений на печать и тому подобных ужасных вещей.
Я думаю, переместив его так, чтобы его было очень легко запускать локально, это будет огромным преимуществом для производительности разработчиков, так как вы можете выполнять итерацию намного быстрее, потому что вам не нужно ничего развертывать в облаке, чтобы увидеть свои изменения и протестировать вещи. из.
Юнонг: Да, то, что раньше занимало у вас, скажем, десятки минут на тестирование, теперь вы буквально работаете локально. Я думаю, что настоящим свидетельством этого проекта является то, что все наши инженеры, работающие над всеми клиентами, спрашивают нас: «Когда мы сможем использовать это вместо текущих устаревших стеков?» Это действительно хорошее свидетельство того, к чему, по нашему мнению, приведет нас этот проект.
Ким: Да, поэтому мы надеемся начать с первого внедрения действительно больших масштабов и производства в третьем квартале, поэтому, используя второй квартал, чтобы стабилизировать и укрепить все, и доказать это через теневой трафик и запустить некоторые системные тесты, при которых мы действительно запускаем его достаточно долго, чтобы получить некоторое обучение. Затем команды начнут внедрять его в третьем квартале.
Есть люди, которые регулярно стучат в нашу дверь и говорят: «Когда это будет? Это не может произойти достаточно скоро. Я думаю, что есть большой спрос и ажиотаж. Мы стараемся действовать как можно быстрее, но, очевидно, у нас много заказчиков, на которых мы не хотим оказывать негативное влияние, поэтому нам также нужно действовать осторожно.
Майкл: Есть ли что-нибудь еще в будущей дорожной карте Netflix с Node.js, кроме запуска теневого трафика и завершения всего этого?
Ким: Впереди еще много всего интересного. Я думаю, что одна из вещей, которые нас действительно волнуют, - это после того, как мы отказались от создания этого стека, чтобы начать работать над некоторыми инструментами и инструментами, связанными с производительностью, поэтому лучшие инструменты для посмертной отладки - это то, чем мы действительно увлечены и действительно хотим участвовать в рабочих группах и помогать вносить свой вклад в сообщество, чтобы мы могли создавать лучшие инструменты, которые каждый может использовать.
Юнонг: Мы тоже вроде как работаем ... Опять же, я думаю, что одна из причин, почему Node.js так популярен, на самом деле заключается в том, что у него есть действительно надежный набор инструментов, которые позволят вам отлаживать, когда ваш процесс выходит из строя, и поэтому мы активно над этим работаем и вносим свой вклад. Как и сказала Ким, мы участвуем во многих этих рабочих группах, и мы хотели бы, чтобы эти инструменты стали лучше и совершенствовались в следующие несколько месяцев, а также внести вклад в некоторые из этих инструментов в свое время.
Другие вещи, над которыми мы работаем, которые, как я полагаю, являются частью контейнера проекта Edge Services, есть нечто, называемое ReactiveSocket, который представляет собой новый мультиплексный, дуплексный протокол, версию которого мы создали в JavaScript и на Node, и это то, что сегодня является открытым исходным кодом, и мы используем его в рамках реорганизации нашей Edge. Это то, над чем мы также очень рады работать, поскольку в нем значительно улучшена производительность уже существующего HTTP-стека. Это некоторые из вещей, над которыми мы работаем.
Ким: Да, и я думаю, что с ReactiveSocket он открывает для нас несколько новых вариантов использования. Поскольку мы берем ту модель, в которой скрипты выполняются на том же уровне, что и уровень службы API, поэтому эта агрегация сотен микросервисов в Netflix, поскольку мы разделяем это, теперь мы выполняем удаленные вызовы Edge уровень (мы теперь называем его уровнем удаленного обслуживания), чтобы вернуть все эти агрегированные метаданные обратно на уровень узла, где мы выполняем агрегирование перевода и логику, специфичную для пользовательского интерфейса и клиента. Разбивая это на части, было небольшое беспокойство по поводу того, что мы вводим еще один прыжок в общий процесс, и каковы будут последствия этого? Это повлияет на производительность? У нас будут более высокие тарифы, задержки или проблемы с этим?
Итак, одна из интересных вещей, которые мы можем использовать с ReactiveSocket, - это новый интерактивный канал с использованием каналов, в котором мы можем держать соединение открытым и начинать отправку данных туда и обратно. Если мы перейдем к Edge за некоторыми данными, а затем мы поймем, что при обработке этих данных нам нужно получить больше данных, мы можем сделать это очень эффективно, потому что мы можем оставить это соединение открытым, а затем на стороне Edge они могут даже сохранить вокруг некоторых из их кешей в памяти, чтобы мы могли сделать эти коммуникации действительно эффективными, даже если мы разделяем эти уровни. Это действительно захватывающий аспект ReactiveSocket, который мы еще не полностью использовали.
Майкаль: Ух ты, круто. Это все, что у меня есть для вас сегодня. Было здорово поговорить с вами, и я очень ценю, что вы нашли время поговорить с Фондом.
