Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Netflix

Нетфликс и искусственный интеллект

09.10.2020 12:10:51 | Автор: admin
На одной из презентаций технического отдела Netflix представительница компании показала публике вот такой экран по ее утверждению, это инструмент для продюсеров, который призван помогать тем принимать правильные решения на этапе предпроизводства. Вложить ли деньги в известных актеров, поменять ли стилистическую направленность и тут же узнать, как и с какой вероятностью это скажется на сборах.



Любой, кто имеет хотя бы отдаленное представление о производстве кино, уже сейчас может смеяться. После череды скандалов под флагом #metoo, в ходе которых продолжает вскрываться глубоко коррумпированное устройство Голливуда и прилегающих пространств, сложно принять всерьез рассказы в духе Стар Трека о переливающихся инструментах для бюджетирования. Рассказы эти, к тому же, напрочь лишены конкретики Нетфликс известен своим нежеланием раскрывать реальные рейтинги своих продуктов, поэтому подсказывать художественные решения их производителям с таким же успехом может шестигранный кубик. Что, конечно, не означает, что работа в этом направлении не ведется. Более того, не только Нетфликс и другие гиганты, но и небольшие компании пытаются выстраивать свою бизнес-модель на машинных предсказаниях.



В общих чертах процесс устроен следующим образом специально нанятые люди просматривают большое количество популярных и случайных фильмов и сериалов, отмечая их многочисленные особенности снят женщиной, длится 98 минут, физического насилия нет, звезд нет, бюджет такой-то, сборы такие-то, действие происходит в Нью-Йорке (и далее насколько позволяет фантазия непосредственных исполнителей и их менеджеров). Параллельно с этим анализируются всевозможные открытые источники структурированной информации вроде IMDB и в целом интернет на предмет зрительских отзывов, ключевых слов и других связей с внешним миром. Дальше в дело вступают алгоритмы, специфичные для конкретных задач, но, если упрощать, то современное машинное обучение в этой области все больше сводится к решению задачи продолжения последовательности. Что нужно сделать, когда уже сделано одно, другое и третье. Самым очевидным примером такой задачи можно считать генерацию текста, а самым перспективным на данный момент решением модель GPT-3, способную учитывать более 170 миллиардов параметров. Последняя цифра, конечно, звучит слегка комично математический контекст и современные модели человеческого мозга накладывают свои стандарты, но речь в числе прочего идет о том, чтобы кто-то на потеху публике поскользнулся на банановой кожуре. В теории это, конечно, способ писать сценарии автоматически, а также автоматически их снимать (и смотреть). На практике кино по-прежнему пишут и снимают люди, но, если говорить о Нетфликсе, часть традиционно человеческих художественных задач машины все же решают. По утверждениям сотрудников компании, искусственный интеллект используется для создания трейлеров, постеров, а также на некоторых стадиях монтажа. Если возвращаться к вопросам предпроизводства и думам продюсеров, то Нетфликс утверждает, что в их распоряжении есть инструменты для поиска локаций для съемок, а также формирования съемочных групп, исходя из графиков занятости тех или иных людей. Стоит, впрочем, учитывать, что продюсер контента для Нетфликса, если он сумел таковым стать, и без специальных инструментов имеет огромное количество привилегий расписания актеров и осветителей хоть и серьезная вещь, но все же способная подстроиться под нужды людей с деньгами и выходом на большую аудиторию.



И все же главная гордость Нетфликса как технологической компании сегодня это система рекомендаций. Есть сообщения о том, что благодаря тому, как фильмы и сериалы соединяются с потенциальной аудиторией, процент коммерчески успешных проектов Нетфликса составляет 80% то есть, 4 из 5 снятых благодаря компании фильмов и сериалов отбивают затраты. оставим подробности о том, как и возможно ли вообще доказать это при оплате за подписку на весь каталог, интереснее тут другое. А именно, как эти рекомендации устроены. В общем и целом, новизны относительно деятельности, скажем, палатки с видеокассетами из 90-х, тут быть не может. Вопрос лишь в том, как глубоко мы готовы погружаться. Не нужно много ума и машинной мощи, чтобы поместить на главную страницу сериал Друзья, но ни одна компания, когда-либо транслировавшая Друзей до Нетфликса не оценивалась в 26 миллиардов долларов. Шутка ли, в марте компания была вынуждена снизить пропускную способность своих европейских каналов на 25%, чтобы интернет не сломался. При всем возможном скепсисе к тому, на чем компания строит свой публичный образ, сложно отрицать очевидное огромное количество людей не просто смотрит сериалы, а смотрит конкретно Нетфликс.



Ключевая концепция для Нетфликса (и, конечно, многих других) в смысле организации бизнеса поведение пользователя. Если немного подумать о том, что такое поведение человека, который смотрит интернет-телевидение, в воображении всплывает довольно простой набор действий зайти на сайт, пролистать главную страницу, куда-то щелкнуть, вернуться назад, что-то выбрать, что-то посмотреть, когда-то остановиться, продлить или отменить подписку и так далее. Конечно, все эти и многие другие действия отслеживаются и анализируются. А будучи наложенными на вкратце описанный выше массив всевозможных тегов, которыми размечены фильмы и сериалы, они превращаются в беспрецедентную по масштабам коллекцию данных о том, кто и как смотрит продукцию Нетфликса. И на основе этой базы круглосуточно происходит изобретение следующих действий компании. Все, от лицензирования контента до того, как он показывается на телефоне зрителя так или иначе связано с этими данными. Поскольку данных становится все больше, а алгоритмы обращения с ними совершенствуются, сценарий, при котором даже на нашем веку задача производства фильма может быть полностью возложена на мир роботов, не кажется недостижимым. И именно эта, пусть и условная (что это вообще будут за фильмы?) реалистичность и обеспечивает непрерывный рост всех показателей Нетфликса как бизнеса. Однако есть и бесчисленное множество сдерживающих факторов, из которых мне бы хотелось подробно остановиться на одном сопротивлении материала.

В последние годы ни один разговор о судьбе видео в интернете не может обойтись без упоминания социальной сети TikTok. Короткие видео со всего света крутятся на невероятных скоростях и невероятном количестве смартфонов (речь чуть ли о миллиарде) по велению, казалось бы, все тех же алгоритмов. Но Тикток (а в этом смысле можно говорить и о YouTube) это не только миллиард пользователей, но и примерно столько же видео. Причем видео настолько коротких, что впору говорить о попытках за их счет даже не захватить внимание, а непосредственно включать конкретные нейроны в мозге зрителя. Но поскольку зритель в данном случае почти равно создатель, то есть продюсер, гораздо более прозрачны в его случае аналитические инструменты, а по факту их эфемерность. Да, теги, да, количество просмотров и подобные цифры вкупе с демографическими данными о зрителях все это можно применять и строить свою тикток-империю, но по большому счету тикток остается слишком быстро крутящейся каруселью образов, чтобы о каком-то бизнес-подходе было интересно рассуждать. Тикток таким образом оказывается в первую очередь доказательством возможности простроить связи между миллионами людей, попутно их развлекая или оповещая о чем-то важном. И по сути это ничем не отличается от того, чем занимается тот же Нетфликс. Кроме одного Нетфликс показывает кино и сериалы, а это вещи слишком глубоко укорененные в драматических структурах и скоростях прошлого. Пока Аль Пачино пройдет от столика в ресторане до туалета, можно посмотреть 4 тиктока.



Те несколько тысяч фильмов и сериалов, имеющихся в каждый момент на Нетфликсе, не могут обеспечить такую же модель потребления, как Тикток или даже Youtube. Во-первых, сериалы, даже самые короткие все-таки не продукт определенной платформы, закрепленной за брендом. В то же время короткие видео, производимые и загружаемые обычными пользователями все равно что шахматные партии или, чаще, отдельные ходы в них то есть, случаи в особом мире, пусть даже этот мир уравнивает в правах спящих котов и спорящих друг с другом политиков. Тикток, конечно, не появился бы без долгих лет съемки видео на мобильные телефоны, но то, чем сегодня заполнена эта соцсеть это в первую очередь продукты желания создать видео для Тиктока, лишь при специальном угле зрения способные перерасти изначальный контекст. С Нетфликсом все иначе. Сериал Черное зеркало не может быть равен Крестному отцу не потому что одно произведение лучше другого, а потому что они банально слишком длинны, чтобы не растерять формальной связи друг с другом к финальным титрам. Нетфликс, безусловно, метит в статус удобства в бытовом смысле: в доме есть горячая вода и Нетфликс. Но горячая вода, будем честны, вещь несколько более простая. Десятки и сотни актеров, декораций, проездов камеры, перекличек с окружающей действительностью и хотя бы даже возникающих про просмотре ассоциаций все это вместе не производит эффекта, сравнимого с горячей водой по однозначности. Секрет, который производители контента охраняют лучше всего звучит так если посмотреть все сериалы на свете не будет ровным счетом ничего. И да, возможно, 18 лет назад можно было по выражению лица узнать, смотрел человек вчерашнюю серию Бригады или нет, но в ситуации сверх-персонализированной матрицы интернет-услуг на утро можно надеяться лишь на способность примерно понять, сколько часов человек спал. Поэтому и возможность представить себе ситуацию существования автоматического кино можно приравнять к возможности вообще ничего не представлять да и победа машин гораздо быстрее произойдет через тикток.

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



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



Подробнее..
Категории: Блог компании ruvds.com , Работа с видео , It-компании , Кино , Netflix , Сериалы , Потоковое видео , Телешоу , Телевизор

Перевод Запуск Netflix на телевизорах и приставках. Лишние 40 миллисекунд

15.12.2020 20:09:12 | Автор: admin
Приложение Netflix работает на сотнях умных телевизоров, стиков и телевизионных приставок. Я один из инженеров, которые помогают производителям запустить наше приложение на их устройствах. В этой статье обсудим особенно сложный вопрос, который помешал выходу одной телеприставки на европейский рынок.

Таинственная проблема


В конце 2017 года меня позвали на созвон, чтобы обсудить проблему с приложением Netflix на новой телеприставке. Это было новое устройство Android TV с поддержкой 4K, на базе Android Open Source Project (AOSP) версии 5.0, Lollipop. Я уже несколько лет работал в Netflix и помог выпустить несколько девайсов, но это был моё первое устройство Android TV.

На связи были все четыре стороны: крупная европейская компания платного ТВ, запускающая устройство (оператор), подрядчик, интегрирующий прошивку (интегратор), поставщик системы-на-чипе (поставщик чипов) и я (Netflix).

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

Интегратор нашёл способ воспроизвести проблему: несколько раз запустить Netflix, начать воспроизведение, а затем вернуться в UI. Они предоставили скрипт для автоматизации процесса. Иногда это занимало целых пять минут, но скрипт всегда надёжно воспроизводил баг.

Тем временем инженер из компании-поставщика чипов диагностировал основную причину: приложение Netflix для Android TV под названием Ninja не успевало доставлять аудиоданные. Лаги вызваны опустошением буфера в аппаратном звуковом конвейере. Воспроизведение останавливалось, когда декодер ждал от Ninja часть аудиопотока, а затем оно возобновлялось, когда поступали новые данные. Интегратор, поставщик чипов и оператор все думали, что проблема понятна. И все они смотрели на меня: Netflix, у вас есть ошибка в вашем приложении, и вы должны её исправить. Я слышал напряжение в голосе представителя оператора. Выпуск устройства задерживался и выходил за рамки бюджета, и они ожидали от меня результатов.

Расследование


Я был настроен скептически. Это же самое приложение Ninja работает на миллионах устройств Android TV, включая умные телевизоры и другие телевизионные приставки. Если в Ninja ошибка, то почему она происходит только на этом устройстве?

Я начал с того, что сам воспроизвёл проблему с помощью скрипта от интегратора. Я связался с коллегой из компании-производителя микросхем и спросил, видел ли он что-нибудь подобное (не видел). Затем начал изучать исходный код Ninja. Нужно было найти точный код, который отвечает за доставку аудиоданных. Я во многом разобрался, но начал теряться в коде, который отвечает за воспроизведение, и мне нужна была помощь.

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


Рис. 1. Упрощённый конвейер воспроизведения

Давайте на минутку поговорим об аудио/видеоконвейере в приложении Netflix. До буфера декодера он абсолютно одинаковый на каждой приставке и телевизоре, но перемещение данных A/V в буфер декодера устройства это процедура, специфичная для конкретного устройства. Она выполняется в собственном потоке. Задача этой процедуры состоит в том, чтобы поддерживать буфер декодера полным, вызывая следующий кадр аудио- или видеоданных через API от Netflix. В Ninja эта работа выполняется потоком Android. Существует простая машина состояний и некоторая логика для обработки различных состояний воспроизведения, но при нормальном воспроизведении поток копирует один кадр данных в API воспроизведения Android, а затем сообщает планировщику потока подождать 15 мс перед следующим вызовом обработчика. При создании потока Android можно запросить повторный запуск потока, словно цикле, но именно планировщик потоков Android вызывает обработчик, а не ваше собственное приложение.

На максимальных 60 FPS устройство должно отображать новый кадр каждые 16,66мс, поэтому проверки через 15мс хватает в любом случае. Поскольку интегратор определил, что проблема в аудиопотоке, я сосредоточился на конкретном обработчике, который доставлял аудиосэмплы в аудиослужбу Android.

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

Ага, озарение


В конце концов я сосредоточился на трёх числах: скорость передачи данных, время вызова обработчика и время передачи управления от обработчика обратно Android. Я написал скрипт для анализа выходных данных журнала и сгенерировал график ниже, на котором виден ответ.


Рис. 2. Визуализация пропускной способности аудиопотока и тайминги обработчика

Оранжевая линия это скорость перемещения данных из буфера потоковой передачи в аудиосистему Android (байт в миллисекунду). На этой диаграмме три различных сценария:

  1. Две области с высокими пиками, где скорость передачи данных достигает 500байт в миллисекунду. Эта фаза буферизация перед началом воспроизведения. Обработчик копирует данные быстро, как только может.
  2. Область посередине это нормальное воспроизведение. Аудиоданные перемещаются со скоростью около 45 байт в миллисекунду.
  3. Область лагов находится справа, когда аудиоданные перемещаются со скоростью около 10 байт в миллисекунду. Это недостаточно быстро для поддержания воспроизведения.

Неизбежный вывод: оранжевая линия подтверждает выводы инженера из компании-производителя чипов. Действительно, Ninja недостаточно быстро доставляет аудиоданные.

Чтобы понять причину, давайте внимательнее изучим жёлтые и серые линии.

Жёлтая линия показывает время, проведённое в самой процедуре обработчика, вычисленное по меткам времени, записанным в начале и по завершению процедуры. Как в нормальной, так и в лагающей области время в обработчике одинаковое: около 2мс. Всплески показывают случаи, когда время оказалось медленнее из-за выполнения других задач на устройстве.

Истинная первопричина


Серая линия время между вызовами обработчика говорит о другом. При обычном воспроизведении обработчик вызывается примерно каждые 15 мс. В случае лагов справа обработчик вызывается примерно каждые 55мс Между вызовами возникают лишние 40мс, и в такой ситуации он никак не может угнаться за воспроизведением. Но почему?

Я сообщил о своём открытии интегратору и поставщику чипов (смотрите, виноват планировщик потоков Android!), но они продолжали настаивать, что решать проблему должен Netflix. Почему бы при каждом вызове обработчика не копировать больше данных? Это была справедливая критика, но реализация такого поведения повлекла бы глубокие изменения, на которые я не хотел идти, поэтому продолжил поиски первопричины. Я нырнул в исходный код Android и узнал, что потоки Android это конструкция пользовательского пространства, а планировщик потоков для синхронизации использует системный вызов epoll(). Я знал, что производительность epoll() не гарантирована, поэтому подозревал, что нечто систематически на него влияет.

В этот момент меня спас другой инженер из компании-поставщика чипов, который обнаружил баг, уже исправленный в следующей версии Android (Marshmallow). Оказывается, планировщик потоков Android изменяет поведение потоков в зависимости от того, работает приложение на переднем плане или в фоновом режиме. Потокам в фоновом режиме назначается дополнительная задержка 40мс (40000000нс).

Ошибка глубоко в ядре Android означала, что это дополнительное значение таймера сохранялось при перемещении потока на передний план. Обычно поток обработчика звука создавался, когда приложение на переднем плане, но иногда немного раньше, когда Ninja всё ещё находилась в фоновом режиме. Если такое случалось, воспроизведение начинало лагать.

Полученные уроки


Это не последняя ошибка, которую мы исправили на платформе Android, но её было труднее всех отследить. Она находилась вне приложения Netflix и даже вне конвейера воспроизведения, а все исходные данные указывали на ошибку в самом приложении Netflix.

История иллюстрирует аспект моей работы, которую я люблю: невозможно предсказать все проблемы, которые наши партнёры сбросят на меня. И я знаю, что для их решения нужно понимать множество систем, работать с отличными коллегами и постоянно подталкивать себя к изучению нового. То, что я делаю, оказывает непосредственное влияние на реальных людей и на их удовольствие от отличного продукта. Когда люди наслаждаются просмотром Netflix в своей гостиной, я знаю, что являюсь частью команды, которая сделала это возможным.
Подробнее..
Категории: Работа с видео , Разработка под android , Компьютерное железо , Видеотехника , Netflix , Android tv , Потоки android , Android thread

Перевод Жизнь инженера Netflix дело о лишних 40 мс

16.01.2021 14:23:21 | Автор: admin
Приложение Netflix работает на сотнях смарт-телевизоров, потоковых пультах и приставках платного ТВ. Инженер-партнёр помогает производителям устройств запустить приложение Netflix на их устройствах. В этой статье я расскажу об одной особенно сложной проблеме, которая заблокировала запуск устройства в Европе.



Как начались странности


Ближе к концу 2017 года я участвовал в конференции-связи, где обсуждали проблему с приложением Netflix на новой ТВ-приставке. Эта приставка была новым устройством Android с воспроизведением 4K на базе Android Open Source Project (AOSP) 5.0 Lollipop. В Netflix я имел дело с несколькими устройствами, но это было моё первое устройство Android TV.

В этой конференции участвовали все четыре игрока рынка: крупная европейская компания платного телевидения (оператор), эта компания запускала устройство; подрядчик, который интегрировал прошивку ТВ-приставки (интегратор); производитель микросхем; я представлял Netflix.

Интегратор и Netflix уже закончили строгую сертификацию Netflix, но во время внутреннего испытания оператора телеканалов один из руководителей компании рассказал о серьёзной проблеме: воспроизведение Netflix на его устройстве прерывалось, то есть видео проигрывалось совсем недолго, затем останавливалось, проигрывалось и снова прерывалось. Случалось это не всегда, но, как правило, спустя несколько дней после включения устройства. На представленной видеозаписи баг выглядел ужасно.

Интегратор нашёл способ воспроизвести проблему: нужно было несколько раз запустить Netflix, начать воспроизведение, затем вернуться в пользовательский интерфейс устройства. Нам дали сценарий, чтобы повторять ситуацию автоматически. Иногда воспроизведение ситуации с помощью скрипта занимало пять минут, но баг проявлялся всегда.

Тем временем полевой инженер производителя микросхем диагностировал причину проблемы: приложение Netflix, Ninja для Android-TV, медленно подавало аудиоданные. Видео останавливалось из-за истощения буфера в конвейере аудиоустройства. Ролик замирал, пока декодер ждал данных от Ninja. Когда новые данные поступали, проигрыватель оживал.

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

Расследование


Я был настроен скептически. То же самое приложение Ninja работает на миллионах устройств Android TV, включая смарт-ТВ и другие приставки. Если ошибка в Ninja, то почему она проявляется только на Android 5.0?

С помощью скрипта от интегратора я воспроизвёл проблему сам. Связался со своим коллегой у продавца микросхем, спросил, видел ли он что-то подобное раньше (он не видел). Затем я начал читать исходный код Ninja, потому что хотел найти фрагмент, который передавал данные. Я многое разузнал, но запутался в коде воспроизведения и нуждался в помощи.

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


Рисунок 1 Упрощённый конвейер воспроизведения

Давайте поговорим об аудио/видеоконвейере. Всё, вплоть до буфера декодера, одинаково на всех телевизионных приставках и смарт-ТВ, но перемещение аудио- и видеоданных в буфер декодера это процедура, которая зависит от устройства и работает в собственном потоке. Задача процедуры перемещения поддерживать заполненность буфера декодера через вызов API Netflix, этот вызов предоставляет следующий кадр аудио- или видеоданных.

В Ninja эта работа выполнялась с помощью Android Thread. Есть простой конечный автомат и логика для обработки разных состояний воспроизведения, но при нормальном воспроизведении поток копирует один кадр данных в API воспроизведения Android, а затем сообщает планировщику потоков, что он должен подождать 15 мс и снова вызвать обработчика. Когда вы создаёте поток Android, можно запросить, чтобы поток запускался повторно, как если бы в цикле; но это планировщик потоков Android и он вызывает обработчика, а не ваше собственное приложение.

Чтобы воспроизвести видео со скоростью 60 кадров в секунду (наивысшей чистотой кадров в Netflix), устройство должно отображать новый кадр каждые 16,66 мс, поэтому наличие нового сэмпла проверяется каждые 15 мс. Этого времени достаточно, чтобы опережать любой видеопоток Netflix.

Интегратор определил, что проблема кроется в аудиопотоке, поэтому я сосредоточился на конкретном обработчике потока, который доставлял аудиосэмплы в аудиосервис Android. Где же лишние миллисекунды?

Я предположил, что виновата какая-то вызванная обработчиком функция, поэтому прописал логирование по всему обработчику, предполагая, что код-виновник станет очевиден. Вскоре стало ясно, что в обработчике не было ничего плохого: даже когда воспроизведение прерывалось, он отрабатывал за несколько миллисекунд.

Прозрение


В конце концов я обратил внимание на три цифры: скорость передачи данных, время вызова обработчика и время, когда он передаёт управление обратно в Android. Я написал сценарий, чтобы проанализировать вывод логирования, и построил график, который ответил на мой вопрос.


Рисунок 2 Визуализация пропускной способности аудио и синхронизации обработчика потоков

Оранжевая линия показывает, как быстро данные перемещаются из буфера потоковой передачи в аудиосистему Android, в байтах за миллисекунду. На этой диаграмме можно увидеть три варианта поведения:

  1. Две высокие шипованные части, где скорость передачи данных достигает 500 байт/мс. Эта фаза буферизации, перед началом воспроизведения. Обработчик копирует данные так быстро, как только может.
  2. Область посередине это нормальное воспроизведение. Аудиоданные перемещаются со скоростью около 45 байт/мс.
  3. Область заикания находится справа, где аудиоданные движутся со скоростью ближе 10 байт/мс. Это недостаточно быстро, чтобы воспроизведение продолжалось.

Неизбежный вывод оранжевая линия подтверждает то, что рассказал инженер производителя микросхем: Ninja медленно передаёт данные. Чтобы понять причину, давайте посмотрим, о чём свидетельствуют жёлтые и серые линии. Жёлтая линия показывает время, проведённое в самой подпрограмме обработчика, это время рассчитывалось по записанным вверху и внизу обработчика отметкам.
И при нормальном воспроизведении, и при воспроизведении с заиканием время в обработчике было одинаковым: около 2 мс. Пики показывают случаи, когда выполнение замедлялось из-за затрат на другие задачи устройства.

Корень проблемы


Серая линия, время между вызовами обработчика, свидетельствует о другом. Когда видео проигрывается нормально, видно, что обработчик вызывается каждые 15 мс. Когда видео прерывается (справа), обработчик вызывается примерно каждые 55 мс. Между вызовами есть лишние 40 мс, а значит, успеть за воспроизведением невозможно. Но почему?

Я рассказал о своём открытии интегратору и производителю микросхем (посмотрите, виноват планировщик потоков Android!). Но они продолжали сопротивляться: почему бы вам просто не копировать новые данные, когда вызывается обработчик? Критика была справедливой, но, если переписать код таким образом, это повлечёт за собой больше изменений, чем я был готов внести, поэтому я решил продолжить поиск первопричины.

Я погрузился в исходный код Android и узнал, что потоки Android это конструкция пользовательского пространства, а планировщик потоков, чтобы определять время, использует системный вызов epoll(). Производительность epoll() не гарантируется, поэтому я подозревал, что на эту функцию влияет что-то системное.
И здесь меня спас другой инженер поставщика микросхем, который обнаружил ошибку; эту ошибку исправили в следующей версии Android Marshmallow. Планировщик потоков Android изменяет поведение потоков в зависимости от того, работает ли приложение в фоновом режиме или на переднем плане. Потокам в фоновом режиме задается дополнительное время ожидания в 40000000 нс. Ошибка в глубине самой Android означала, что дополнительное время возникает, когда поток перемещается на передний план.

Обычно поток обработчика звука создавался, когда приложение выполнялось на переднем плане, но иногда поток создавался немного раньше. Такое случалось, когда приложение Ninja работало в фоновом режиме и тогда проигрыватель останавливался.

Извлеченные уроки


Это была не последняя исправленная на этой платформе ошибка, но именно её было труднее всего отследить. Баг скрывался за пределами Netflix, не в конвейере воспроизведения; вместе с тем все исходные данные указывали на ошибку в приложении Netflix.

Эта история показывает одну из сторон моей любимой работы: я не могу предугадать все проблемы, которые наши партнёры перебросят мне, кроме того, я знаю, что для разрешения проблем мне нужно разбираться в нескольких системах, работать с замечательными коллегами и постоянно заставлять себя узнавать что-то новое. Моя работа прямо влияет на людей, на их удовольствие от отличного продукта. Я понимаю, что, когда люди наслаждаются Netflix в своей гостиной, именно я тот человек в команде, который делает это возможным.



Другие профессии и курсы
ПРОФЕССИИ



КУРС


Подробнее..
Категории: Работа с видео , Разработка под android , Лайфхаки для гиков , Блог компании skillfactory , Netflix , Стриминг , Стриминговые сервисы , Дебаггинг , Skillfactory

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 1

21.06.2020 00:16:48 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Около 15 лет назад моя мачеха, назовем ее Фрэнсис, стала чувствовать боль и слабость во всем теле, ей стало трудно стоять, и когда врачи в больнице немного привели ее в себя, у нее обнаружился паралич рук и ног. Это было ужасное испытание для нее и для нас, как оказалось, диагнозом стал синдром Гийона-Барре. Мне просто любопытно, кто-нибудь из вас слышал о такой болезни? О, довольно много людей! Надеюсь, вы получили эту информацию не из первых рук. Это аутоиммунное заболевание, острый полирадикулоневрит, при котором иммунная система человека поражает собственные периферические нервы.



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

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

Вы можете спросить: Какое отношение этот рассказ имеет к теме микросервисов? Так вот, трафик в архитектуре микросервисов являет собой такой же подвиг, как и человеческое дыхание. У вас могут возникать всплески трафика, иметь место враждебная DDoS атака, хакер может внести изменения в вашу рабочую среду, отрезав клиентам доступ. Вот почему сегодня мы собираемся поговорить об архитектуре микросервисов, об их огромных преимуществах, проблема и решениях, которые Netflix обнаружил в течение последних 7 лет борьбы с большим количеством сбоев разного рода.

Я начну со вступления, в котором вам представлюсь, затем займу немного времени объяснением базовых основ микросервисов. Большую часть доклада я посвящу проблемам и их решениям, которые предлагает Netflix. В завершении я расскажу о зависимостях организации процессов и соответствующей им архитектуры.

Я Джош Эванс, который начал работу в Netflix в 1999 году, перед этим сделав карьеру в схожей области. Я пришел в проект за месяц до запуска DVD-сервиса, работал инженером, менеджером и был участником интеграции коммерческого продукта и стриминга в существующий DVD-бизнес. В 2009 я попал прямо в сердце потокового мультимедиа, возглавив команду Playback Service службу, которая занимается доставкой DRM, манифестов и записью телеметрии, возвращающейся из устройств пользователей. Я также управлял этой командой во время международного внедрения Netflix, когда наш сервис заработал практически на всех устройствах, воспроизводящих потоковое видео, и участвовал в переносе проекта с дата-центров в облачный сервис. Можно сказать, что последние 3 года были самыми захватывающими. Я возглавлял команду инженеров Operations Engineering, которая фокусируется на высокопрофессиональных операциях контроля скорости, мониторинге и предупреждении сбоев, доставке потокового мультимедиа и широком спектре функций, поиогающих инженерам Netflix успешно эксплуатировать свои собственные облачные сервисы.

Примерно месяц назад я ушел из Netflix и сегодня наверстываю упущенное с книгой Арианны Хаффингтон The Sleep Revolution: Transforming Your Life, One Night at a Time. Впервые за довольно долгое время я взял отпуск и провожу его с семьей, пытаясь выяснить, как создать баланс между работой и личной жизнью.

Как известно, Netflix является лидером в области абонентского интернет-телевидения, предоставляющим пользователям голливудскую кинопродукцию, инди, локальные передачи, растущий пласт оригинального контента. У нас 86 млн. пользователей в 190 странах, стриминг на 10 языках и поддержка более 1000 типов устройств. Все это работает на основе микросервисов AWS.



Давайте поговорим о микросервисах с абстрактной точки зрения. Начнем с того, какими они не должны быть. Дата-центр Netflix DVD образца 2000 года имел достаточно простую инфраструктуру: аппаратный балансировщик нагрузки, кстати, достаточно дорогой, хост Linux стандартной конфигурации с Apache Reverse Proxy и Tomcat, и всего одно приложение, названное нами Javaweb.



Хост напрямую соединялся через JDBC с базой данных Oracle, которая, в свою очередь, соединялась с другой, биллинговой базой данных Oracle через DB link. Первой проблемой данной архитектуры была монолитность кодовой базы Javaweb, то есть все вкладывалось в одну единственную программную базу, обновляемую еженедельно или раз в 2 недели. Любое внеочередное изменение становилось проблемой, которую было достаточно трудно диагностировать. Например, мы потратили почти неделю, разбираясь с медленной памятью. Мы вытягивали куски кода, запускали его, смотрели, что при этом происходит и так далее, поэтому внесение любых изменений занимало много времени. База данных представляла собой еще более строгий монолит это был один сегмент оборудования, работающй с одной большой базой данных Oracle, которую мы называли Базой данных магазина. Если она выходила из строя, то из строя выходило абсолютно все. Каждый год с началом периода отпусков мы наращивали аппаратные мощности, чтобы вертикально масштабировать наше приложение.

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

Так что же такое микросервис? Кто-нибудь хочет дать ему определение? Мне нравится, что вы сказали: привязка к контексту и владение данными. Я приведу вам определение Мартина Фаулера: Архитектурный стиль микросервисов представляет собой подход к разработке одного приложения как совокупности мелких сервисов, каждый из которых имеет собственный рабочий процесс и осуществляет коммуникацию с помощью легких механизмов, преимущественно в виде API на основе HTTP-ресурсов.

Думаю, мы все это знаем. Это несколько абстрактное, технически правильное определение, но оно не дает возможности почувствовать дух микросервисов. Я считаю, что микросервисы это эволюционная реакция на опыт применения монолитных структур. Разделение компонентов одна из самых важных вещей, обеспечиваемая модульностью и способностью к инкапсуляции структур данных, причем вам не придется иметь дело с организацией координации их взаимодействия.

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

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

Давайте рассмотрим архитектуру Netflix и то, как она мапируется.

Слева вы видите клиентский сервис конечный уровень ELB-прокси под названием Zuul, который осуществляет динамическую маршрутизацию. Здесь же расположен NCCP (Netflix Content Control Plane), который поддерживает предыдущие поколения наших устройств и обеспечивает воспроизводящую способность контента. API-шлюз, являющийся ядром нашей современной архитектуры, обращается ко всем другим сервисам для выполнения запросов клиентов.



Справа расположена подсистема среднего уровня Middle Tier и платформа сервиса. Это среда, состоящая из множества компонентов, таких как A/B тестирование, сообщающее результаты пользовательских проверок. Абонентский сервис Subscriber предоставляет развернутую информацию о клиентах, система рекомендаций Recommendations обеспечивает информацию, необходимую для создания списка фильмов, которые будут представлены каждому клиенту.

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

Эти виды объектов формируют экосистему Netflix. Хочу подчеркнуть, что так как микросервисы являются абстракцией, мы склонны думать о них очень упрощенно. На этом слайде показан мой любимый горизонтально масштабируемый микросервис. Прекрасно, что микросервисы кажутся простыми, однако в реальности почти никогда таковыми не являются. В какой-то момент вам потребуются данные, которые нужно вытянуть из базы данных. Это может быть абонентская информация Subscriber или рекомендации Recommendations. Обычно эти данные находятся на уровне хранения Persistence. На схеме показан обычный подход к получению пользовательских данных, который использует не только сервис Netflix.

Service Client начинает предоставлять клиентские библиотеки на основе Java, которые обеспечивают доступ к базовым данным. Наступает момент, когда вам потребуется масштабировать сервис, привлекая к этому EVCashe Client, потому что сервис с разросшейся базой данных недостаточно хорошо справляется с клиентской нагрузкой. EVCache это распределенное решение для кэширования в памяти, основанное на memcached & spymemcached, интегрированное с инфраструктурой Netflix OSS и AWS EC2. После подключения клиента EVCashe вы должны будете заняться оркестровкой, чтобы, если это хранилище выйдет из строя, вы смогли бы обратиться к Service Client, который вызовет базу данных и вернет ответ обратно. При этом вы должны убедиться в том, что произошло наполнение EVCashe так, что при следующем обращении к нему спустя несколько миллисекунд все будет в порядке.



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

Выделим четыре области, которые нужно исследовать: зависимости, масштабирование, различия, зависящие от вашей архитектуры, и то, как следует вносить изменения. Начнем с зависимостей и разобьем их на 4 случая использования.



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



Этот риск вызван задержками сети, перегрузкой, отказами аппаратной части. Вызываемый сервис может иметь логические ошибки или неполадки масштабирования. Он может работать очень медленно и выдавать при вызове ошибку таймаута. Самый ужасный сценарий, который реализовывался чаще, чем хотелось, это когда сбой всего одного сервиса при развертывании приводил к отказу всей системы, из-за чего клиент утрачивал с ней всякую связь. И упаси вас боже развернуть эти ошибочные изменения на несколько регионов при использовании мультирегиональной стратегии, потому что вам просто некуда будет отступить, чтобы восстановить и отремонтировать систему.

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..
Категории: It-инфраструктура , Анализ и проектирование систем , Блог компании ua-hosting.company , Конференции , Микросервисы , Oracle , Netflix , Javaweb

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 2

22.06.2020 00:17:16 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1

Для защиты приложений от неполадок такого рода мы разработали HYSTRIX имплементацию корпоративного шаблона Circuit Breaker, предохранитель, который контролирует задержки и ошибки при сетевых вызовах.



HYSTRIX представляет собой библиотеку отказоустойчивости, которая будет терпеть сбои до порогового значения, оставляя цепь открытой. Это означает, что HYSTRIX будет перенаправлять все последующие вызовы в резерв, чтобы предотвратить будущие сбои, и создаст временной буфер для соответствующего сервиса, который можно будет восстановить после сбоя. Это что-то вроде запасного варианта: если сервис А не может вызвать сервис В, он все равно отправит клиенту резервный ответ, который позволит ему продолжить использование сервиса вместо того, чтобы просто получить сообщение об ошибке.

Таким образом, преимущество HYSTRIX это изолированные пулы потоков и понятие цепи. Если несколько вызовов сервиса В безуспешны, сервис А перестанет их совершать и будет ждать восстановления. В свое время HYSTRIX был инновационным решением, но при его использовании возникал вопрос: у меня есть вся история настроек, я уверен, что все сделано правильно, но как узнать, что он действительно работает?

Лучший способ узнать это (вспомним наши биологические аналогии) вакцинация, когда вы берете мертвый вирус и вводите его в организм, чтобы стимулировать борьбу антител с живым вирусом. В продакшене роль прививки играет фреймворк Fault Injection Testing (FIT) тестирование, которое позволяет находить проблемы микросервисов путем создания искусственных сбоев. С его помощью выполняются синтетические транзакции на уровне устройств или аккаунтов, либо увеличивается объем живого трафика вплоть до 100%. Таким образом проверяется надежность микросервисов под стрессовой нагрузкой.



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

Это хорошо, если рассматривать соединения точка-точка. Но представьте, что ваша система состоит из сотни микросервисов, и каждый из них зависит от других. Как проверить такую систему, не проводя миллионов тестов, во время которых сервисы вызывают друг друга?
Допустим, у вас имеется 10 сервисов в цельной структуре микросервиса, и каждый из них обладает 99,99% доступностью. Это означает, что на протяжение года каждый сервис может быть не доступным 53 минуты.



Если бы сервисы работали независимо, в этом не было бы ничего критичного, но когда они зависят друг от друга, суммарное время отказа всего микросервиса может достигать 8-9 часов в год, а это уже большая разница.

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



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

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

Представьте, что у меня есть общая логика и общие шаблоны доступа для вызова моего сервиса и есть 20 или 30 разных зависимостей. Действительно ли я захочу, чтобы каждая отдельная команда разработчиков писала один и тот же или немного отличающийся код снова и снова, или же захочу объединить все в общую бизнес-логику и общие шаблоны доступа? Это было настолько очевидно, что мы внедрили именно такое решение.

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

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



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

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



У нас не было желания оставить один голый металл, мы хотели использовать простую логику с общими шаблонами. В результате был найден баланс между крайне простой каркасной моделью REST API и максимально упрощенными клиентскими библиотеками.

Давайте поговорим о Persistence живучести системы. Мы выбрали верный путь, взяв за основу теорему CAP. Вижу, что с ней незнакомы всего несколько присутствующих. Эта теорема говорит о том, что при наличии сетевых партиций приходится выбирать между согласованностью и доступностью. Согласованность означает, что каждое чтение дает самую последнюю запись, а доступность что каждый работающий узел всегда успешно выполняет запросы на чтение и запись. Это касается сценариев, в которых одна конкретная база данных в зоне доступности может быть недоступна, в то время как другие базы будут доступны.

На слайде показан сетевой сервис А, который записывает в 3 базы данных копии одинаковых данных. Каждая из баз работает с одной из 3 сетей, обеспечивая доступность. Вопрос в том, что делать, если вы потеряете связь с одной из БД у вас возникнет сбой и сообщение об ошибке, либо вы продолжите работу с двумя остальными БД, пока неполадка не будет устранена.



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



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

Теперь поговорим об инфраструктуре, потому что это отдельная важная тема. Когда-нибудь ваша инфраструктура, будь то AWS, Google или ваша собственная разработка, может отказать, потому что отказать может все что угодно. Вы видите заголовок статьи Forbes о том, что Amazon AWS обвалил Netflix в канун Рождества 2012 года.



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



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



Ранее в этом году я уже выступал на QСon London с докладом о глобальной архитектуре Netflix, так что вы можете просмотреть это выступление, если хотите вникнуть в тему достаточно глубоко.
Перейдем к масштабированию и рассмотрим три его составляющих: stateless-сервисы, stateful-сервисы и гибридные сервисы. Что же такое stateless-сервис? Кто-нибудь из присутствующих может дать определение? Начну с того, что это не кеш или база данных, где вы храните массивный объем информации. Вместо этого у вас есть часто используемые метаданные, кэшируемые в энергонезависимой памяти.

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

26:30 мин

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..
Категории: It-инфраструктура , Анализ и проектирование систем , Блог компании ua-hosting.company , Конференции , Микросервисы , Oracle , Netflix , Javaweb

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 3

24.06.2020 00:13:58 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2

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



У вас есть минимум и максимум, есть метрики, которыми вы пользуетесь, когда увеличиваете свою группу. Если нужен новый экземпляр, вы просто вытягиваете и раскручиваете любой образ из S3. В этом есть ряд преимуществ. Во-первых, это эффективное использование компьютерных мощностей, поскольку вы изменяете их по требованию. Вышедшие из строя узлы легко замещаются новыми. Но самое важное то, что при всплесках трафика, например, во время DDoS-атак или вследствие ошибок производительности, автомасштабирование позволяет сохранять работоспособность системы в то время как вы разбираетесь с причинами и устраняете неполадки. Я настоятельно рекомендую использовать это масштабирование, потому что оно неоднократно спасало нас от серьезных сбоев.

И конечно же, вы хотите убедиться в его постоянной работе с помощью Chaos. Обезьянка Хаоса Chaos Monkey это наш инструмент, который случайным образом уничтожает экземпляры AWS или процессы на серверах, которые обслуживают сервис Netflix. Этот инструмент подтверждает, что если один из узлов узел умирает, то все остальное продолжает работать без проблем. После внедрения Chaos Monkey мы получили возможность круглосуточно убеждаться в том, что все ноды имеют избыточное дублирование, падение одного узла не приводит ни к каким последствиям, а каждая неполадка документируется для того, чтобы впоследствии для ее устранения можно было применить готовое решение.



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

Существует два различных подхода к кэшированию. Как я уже говорил, в наш коллектив влились бывшие сотрудники Yahoo, имевшие большой опыт работы с кэшами ha-proxy. Они использовали шаблон из выделенных серверов для пользователей. То есть пользователь всегда попадал на один и тот же узел, где располагался кеш с единственной копией данных. Проблема заключалась в том, что при поломке этого узла пользователь терял доступ ко всему сервису. На ранней стадии существования сервиса, еще до внедрения HYSTRIX, возникали ситуации, когда выход из строя одного узла обрушивал весь сервис Netflix. Устранение неполадки занимало 3,5 часа, в течение которых мы ждали, пока кеш сам себя наполнит, чтобы можно было выполнить запрос.

На следующем слайде показана схема выделенных сегментов Dedicated Shards, представляющая собой отказ от использования шаблона пользовательского dedicated-сервера.



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

Основной технологией в этом сценарии является совместное использование записи в EVCache. Данные записываются не только на несколько узлов, но и в несколько зон доступности. Чтение из них происходит локально, но опять же приложение может читать из нескольких зон, если это необходимо.



Это очень успешная модель, которую использует практически каждый виртуальный сервис Netflix.
Давайте поговорим о гибридных сервисах, представляющих собой комбинацию stateless и stateful сервисов. В данном случае очень легко использовать EVCache как наиболее подходящую технологию обеспечения отказоустойчивости.



Она позволяет обрабатывать 30 миллионов запросов в секунду, это 2 триллиона запросов в день. В EVCache могут храниться сотни миллиардов объектов и десятки тысяч экземпляров класса memcashed. Огромным преимуществом этой архитектуры является линейная масштабируемость, благодаря чему запросы возвращаются в течение нескольких миллисекунд независимо от нагрузки. Конечно, вам необходимо создать достаточно узлов, но сам процесс масштабирования чрезвычайно прост.



Несколько лет назад мы использовали сценарий, когда наш сервис Subscribers полагался на EVCache в несколько большей степени, чем это было необходимо, то есть имелся антипаттерн, о котором мы уже говорили. К Subscribers обращались практически все остальные сервисы. Я имею ввиду, что все хотели о нем знать, всем нужен был ID клиента, то, как получить доступ к аккаунтам и другая информация. Все оффлайн и онлайн вызовы поступали в один и тот же кластер.

Во многих случаях имели место многократные вызовы одного и того же приложения, получалось, что вы могли вызывать EVCache так часто, как вам хотелось, и на пике активности мы наблюдали от 800 тысяч до миллиона запросов в секунду. Fallback был бы логичным, если думать о нем в сиюминутном аспекте: если кеш дал сбой, дайте мне возможность вызвать сервис. Однако и с Fallback существовала проблема: когда весь уровень EVCache давал сбой, то все запросы поступали к сервису и базе данных и возникал антипаттерн сервис с базой данных не мог справиться с той нагрузкой, которую принимал на себя EVCache. Получалось, что вроде бы правильный подход тоже приводил к неудаче сбой EVCache вызывал отказ всего сервиса Subscribers.



Решение этой проблемы носит комплексный характер:

  • прекратить долбежку одного и того же кластера системы оффлайн-запросами и вызовами в режиме реального времени, разделив рабочую нагрузку на онлайн и оффлайн сегменты;
  • организовать Request-level cashing, то есть всегда привязывать жизненный цикл записи к текущей области запроса, чтобы стало невозможно вызывать один и тот же сервис снова и снова;
  • встраивание в устройства пользователей токенов безопасности Fallback.

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



Рассмотрим вариации различные варианты архитектуры сервиса. Чем больше таких вариантов, тем больше можно решить проблем, возникающих при увеличении масштаба системы, операционных отклонениях Operational drift, при которых эксплуатационные показатели отличаются от базовых показателей работы сервиса, или при внедрении новых языков или контейнеров.

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

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

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



В течение нескольких лет мы аккумулировали лучшие практики и сформулировали общие принципы, которые назвали Production Ready, или Готовый продукт. Это чеклист, или программа действий Netflix. Каждый из принципов основан на автоматизации и постоянном улучшении модели взаимодействия с сервисом:

  • Оповещения Alerts
  • Apache & Tomcat
  • Автоматический canary-анализ
  • Автоматическое масштабирование
  • Модель хаоса
  • Согласованные, непротиворечивые наименования
  • ELB config
  • Проверка работоспособности Healthchek
  • Неизменяемые образы машин
  • Squeeze тестирование. Оно состоит в запуске определенных тестов или бенчмарков для того, чтобы увидеть изменения в производительности и вычислить критическую точку приложения. Затем проверяется, было ли это последнее изменение неэффективным, или же оно определяет рекомендуемые параметры автоматического масштабирования перед развертыванием.
  • Red/Black развертывания, заключающиеся в релизе, который сокращает время простоя и риски за счет запуска двух идентичных производственных сред, Red и Black. В любой момент времени только одна из сред является живой, причем она обслуживает весь трафик.
  • Тайм-ауты, повторные попытки, fallback.


Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..
Категории: It-инфраструктура , Анализ и проектирование систем , Блог компании ua-hosting.company , Конференции , Микросервисы , Oracle , Netflix , Javaweb

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 4

26.06.2020 00:04:47 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 3

В отличии от operational drift, внедрение новых языков для интернационализации сервиса и новых технологий, таких как контейнеры, это сознательные решения добавить новую сложность в окружающую среду. Моя группа операционистов стандартизировала асфальтированную дорогу лучших технологий для Netflix, которые запекались в заранее определенных наилучших практиках, основанных на Java и EC2, однако по мере развития бизнеса разработчики стали добавлять новые компоненты, такие как Python, Ruby, Node-JS и Docker.



Я очень горжусь тем, что мы первыми сами выступали за то, чтобы наш продукт отлично работал, не дожидаясь жалоб клиентов. Все начиналось достаточно просто у нас были операционные программы на Python и несколько бэк-офисных приложений на Ruby, но все стало намного интересней, когда наши веб-разработчики заявили, что намерены отказаться от JVM и собираются перевести веб-приложение на программную платформу Node.js. После внедрения Docker вещи стали намного сложнее. Мы руководствовались логикой, и придуманные нами технологии стали реальностью, когда мы внедрили их для клиентов, потому что они имели большой смысл. Расскажу вам, почему это так.

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

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

Логично было взять эти endpoints и вытянуть их из API-сервиса. Для этого мы создали компоненты Node.js, которые запускались как небольшие приложения в контейнерах Docker. Это позволило изолировать любые неполадки и сбои, вызванные этими node-приложениями.

Стоимость этих изменений достаточно велика и складывается из следующих факторов:

  • Инструменты повышения производительности. Управление новыми технологиями требовало новых инструментов, потому что UI-команда, использующая очень удачные скрипты для создания эффективной модели, не должна была тратить много времени на управление инфраструктурой, она должна была заниматься только написанием скриптов и проверкой их работоспособности.
    Инсайт и сортировка возможностей ключевым примером являются новые инструменты, необходимые для выявления информации о факторах производительности. Нужно было знать, на сколько % занят процессор, как используется память, и сбор этой информации требовал разных инструментов.
  • Фрагментация базовых образов простая базовая AMI стала более фрагментированной и специализированной.
  • Управление узлами. Не существует доступной готовой архитектуры или технологий, которые позволяют управлять узлами в облаке, поэтому мы создали Titus платформу управления контейнерами, которая обеспечивает масштабируемое и надежное развертывание контейнеров и облачную интеграцию с Amazon AWS.
  • Дублирование библиотеки или платформы. Предоставление новым технологиям одних и тех же основных функций платформы потребовало ее дублирования в облачные инструменты разработчиков Node.js.
  • Кривая обучения и производственный опыт. Внедрение новых технологий неизбежно создает новые проблемы, которые необходимо преодолеть и извлечь из них уроки.

Таким образом, мы не могли ограничиться одной асфальтированной дорогой и должны были постоянно строить новые пути для продвижения своих технологий. Для снижения стоимости мы ограничивали централизованную поддержку и фокусировались на JVM, новых узлах и Docker. Мы расставляли приоритеты по степени эффективного воздействия, информировали команды о стоимости принятых ими решений и стимулировали их искать возможность многократного использования уже разработанных эффективных решений. Мы использовали этот подход при переводе сервиса на иностранные языки для доставки продукта интернациональным клиентам. Примерам могут служить относительно простые клиентские библиотеки, которые могут генерироваться автоматически, так что достаточно легко создавать Python-версию, Ruby-версию, Java-версию и т.д.

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

Давайте поговорим о последнем элементе изменениях, или вариациях. Посмотрите, как неравномерно меняется потребление нашего продукта по дням недели и по часам на протяжение суток. Можно сказать, что в 9 утра для Netflix наступает время тяжелых испытаний, когда нагрузка на систему достигает максимума.



Как можно достичь высокой скорости внедрения программных инноваций, то есть постоянно вносить новые изменения в систему, не вызывая перерывов в доставке сервиса и не создавая неудобств нашим клиентам? Netflix добились этого благодаря использованию Spinnaker новой глобальной облачной платформы управления и непрерывной доставки (СD).



Критически важно, что Spinnaker был разработан для интеграции наших лучших практик так, чтобы по мере развертывания компонентов в продакшн мы можем интегрировать их результат непосредственно в технологию доставки медиаконтента.



Нам удалось использовать в конвейере доставки две технологии, которые мы высоко ценим: автоматизированный canary-анализ и поэтапное развертывание. Canary-анализ означает, что мы направляем ручеек трафика в новую версию кода, а остальной продакшн-трафик пропускаем через старую версию. Затем мы проверяем, как справляется с задачей новый код лучше или хуже существующего.

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



В конце выступления я коротко расскажу об организации и архитектуре Netflix. В самом начале у нас была схема под названием Electronic Delivery электронная доставка, представлявшая собой первую версию потоковой передачи медиаконтента NRDP 1.x. Здесь можно использовать термин обратный поток, потому что изначально пользователь мог только скачивать контент для последующего воспроизведения на устройстве. Самая первая платформа электронной доставки Netflix образца 2009 года выглядела примерно так.



Пользовательское устройство содержало в себе приложение Netflix, которое состояло из интерфейса UI, модулей безопасности, активации сервиса и воспроизведения, базирующихся на платформе NRDP Netflix Ready Device Platform.

В то время пользовательский интерфейс был очень прост. Он содержал так называемый Queque Reader, и пользователь заходил на сайт, чтобы добавить что-то в Queque, а затем просматривал добавленный контент на своем устройстве. Положительным было то, что клиентская команда и серверная команда принадлежали одной организации Electronic Delivery и имели тесные рабочие взаимоотношения. Полезная нагрузка была создана на основе XML. Параллельно был создан API Netflix для DVD бизнеса, который стимулировал сторонние приложения направлять трафик в наш сервис.

Однако Netflix API был хорошо подготовлен к тому, чтобы помочь нам с инновационным пользовательским интерфейсом, в нем содержались метаданные всего контента, сведения о том, какие фильмы доступны, что создавало возможность генерировать списки просмотра. У него был общий REST API, базирующийся на схеме JSON, HTTP Response Code, такой же, что используется в современной архитектуре, и модель безопасности OAuth то, что требовалось в то время для внешнего приложения. Это позволило перейти от публичной модели доставки потокового контента к приватной.



Проблема перехода заключалась во фрагментации, так как теперь в нашей системе функционировали два сервиса, основанные на совершенно разных принципах работы один на Rest, JSON и OAuth, другой на RPC, XML и механизме безопасности пользователей на основе системы токенов NTBA. Это была первая гибридная архитектура.

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



В связи с этим у меня был разговор с одним из старших инженеров компании, которому я задал вопрос: Что должна представлять собой правильная долгосрочная архитектура?, и он задал встречный вопрос: Вероятно, тебя больше волнуют организационные последствия что произойдет, если мы интегрируем эти вещи, а они сломают то, что мы хорошо научились делать?. Этот подход очень актуален для закона Конвея: Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации. Это очень абстрактное определение, поэтому я предпочитаю более конкретное: Любая часть программного обеспечения отражает организационную структуру, которая его создала. Приведу вам мое любимое высказывание, принадлежащее Эрику Реймонду: Если над компилятором работают четыре команды разработчиков, то в итоге вы получите четырехпроходный компилятор. Что же, Netflix имеет четырехпроходный компилятор, и это то, как мы работаем.

Можно сказать, что в этом случае хвост машет собакой. У нас на первом месте не решение, а организация, именно она является драйвером архитектуры, которую мы имеем. Постепенно от мешанины сервисов мы перешли к архитектуре, которую назвали Blade Runner Бегущий по лезвию, потому что здесь речь идет о граничных сервисах и возможностях NCCP разделяться и интегрироваться напрямую в Zuul-прокси, API-шлюз, причем соответствующие функциональные куски были превращены в новые микросервисы с более продвинутыми функциями безопасности, воспроизведения, сортировки данных и т.д.

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


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..
Категории: It-инфраструктура , Анализ и проектирование систем , Блог компании ua-hosting.company , Конференции , Микросервисы , Oracle , Netflix , Javaweb

Одно неловкое движение, и сразу целый вал ненужных рекомендаций за что критикуют видеохостинги

10.01.2021 14:07:00 | Автор: admin

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

Осада related-блоков и персонализацияглавной будет продолжается неделями, пока вы снова не зацепитесь за очередную теорию заговора или новостные сводки. В умеренных объемах они безвредны смысл и содержание всех этих роликов забывается через час после просмотра.

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

Фотография: Kevin Grieve. Источник: Unsplash.comФотография: Kevin Grieve. Источник: Unsplash.com

Метрики вместо развития

Универсальный характер проблемы достаточно точно описал Даниел Канеман, известный психолог и лауреат многочисленных премий по экономике. Он констатировал, что основная масса соцсетей вовсе не стремятся вооружить нас инструментами для саморазвития и поиска качественного контента среди сотен тысяч и миллионов ежедневных публикаций. Их задача максимизировать уровень вовлеченности пользователей, чем и заняты соответствующие алгоритмы и рекомендательные движки, в том числе и популярных видеохостингов. С их помощью мы незаметно для себя день за днем строим персональный инфококон, из которого потом придется выбираться: Воззрения, которыми вы обладали несколько лет назад, становятся все более экстремальными за счет влияния соцсетей, замечает Канеман.

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

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

Фотография: Christopher Ott. Источник: Unsplash.comФотография: Christopher Ott. Источник: Unsplash.com

Даже разработчик, поучаствовавший в проектировании рекомендательного алгоритма YouTube, убежден, что задачи для него можно было бы сформулировать несколько иначе. За этим последовала бы совсем другая реализация и эффект в масштабе пользовательской базы сервиса.

Сегодня вопрос заключается в том, какую долю от семи с лишним сотен миллионов часов, затрачиваемых на просмотр роликов, люди расходуют на достаточно посредственные видео. Если одной из ключевых метрик для включения того или иного сюжета в топы и related-подборки остается суммарный объем времени, потраченного на него пользователями, то такие рекомендации будут соответствующего качества.

Слабые рекомендации

Сегодня все чаще можно встретить критику алгоритмов YouTube. Вот так на эту тему высказываются на Hacker News: Болею, целую неделю сижу дома. Фактически обновляю главную каждые пятнадцать минут, но видео, которые я пропускаю уже сотый раз, остаются на месте. Снова и снова нужно скроллить, чтобы найти что-то другое. Базовая рекомендация в таких ситуациях самостоятельно редактировать, чистить или замораживать историю просмотров. Если избавиться от пары записей с роликами об условных теориях заговора, алгоритм пессимизирует это тематическое направление и не будет рекомендовать подобный контент. Более радикальный подход режим приватного просмотра [инкогнито или private browsing], если возникает спонтанное желание провалиться в черную дыру с кучей сомнительных сюжетов. Так можно будет и не тратить время на чистку watch history.

Резиденты HN отмечают и другие особенности рекомендательного движка этой площадки: Помню, как в далеком 2009-м искал электронную музыку и в related к трекам с условной тысячью просмотров были аналогичные по популярности композиции. Их мало кто слушал, поэтому и я всего за несколько часов открыл для себя кучу новых исполнителей. Сегодня все иначе алгоритм выдает похожие видео, но это почти всегда стотысячники.

Фотография: Glenn Carstens-Peters. Источник: Unsplash.comФотография: Glenn Carstens-Peters. Источник: Unsplash.com

Стоит признать, что встречаются и мнения в защиту YouTube, хотя по большей части ключевую роль в примерах играют не алгоритмы, а пользовательский опыт: На моем ноуте слушал музыку чуть ли не весь дом, но ситуацию спас хороший вкус окружающих теперь сервис радует меня шикарными рекомендациями. Они круче, чем у Spotify. На HN говорят и о других видеохостингах вроде Netflix, но даже в случае этой стриминговой площадки пользователи сожалеют о низком качестве действующих алгоритмов фильтрации контента по сравнению с временами, когда компания работала с DVD-дисками и предлагала качественные рекомендации.

Отсутствие точечных настроек

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

Еще один лайфхак пригодится тем, кто не успевает изучать ролики, отложенные для последующего просмотра. Часть из них рано или поздно пропадают с площадки либо за нарушения правил, либо по желанию авторов, решивших обновить канал. В таком случае стоит заранее воспользоваться youtube-dl одним из наиболее популярных менеджеров загрузок [более 87 тыс. звезд на GitHub на момент публикации]. Либо выбрать более доступный вариант закинуть ссылку на видео в Wayback Machine. Однако в этом случае гарантированной архивации ждать не стоит снэпшот могут и не сделать по единственному запросу [хотя общее число захватываемых сервисом роликов еще в 2018-м оно доходило до 800 тыс. в неделю].

Фотография: Dodi Achmad. Источник: Unsplash.comФотография: Dodi Achmad. Источник: Unsplash.com

По мнению резидентов HN, чтобы не отвлекаться на рекомендации, иногда стоит полностью скрывать related-секции с помощью адблокеров. Или настроить автоматический редирект с главной к ленте тех каналов, на которые вы подписаны. Вообще говоря, среди аудитории площадки уже давно сформировался запрос на подобный функционал и точечные возможности вроде белых и черных списков, которые позволили бы прятать из выдачи ролики с определенными ключевыми словами, тегами и параметрами. Однако зрители вынуждены делать все это с помощью сторонних сервисов например, RSS-ридеров. Хотя и эту возможность, кажется, уже ограничили, так что довольствоваться остается лишь расширениями для браузеров.

Что будет происходить дальше

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

Следует признать, что перекос в строну исключения человеческого фактора из рекомендательного процесса пока не принес выдающихся результатов, поэтому маятник уже начал движение в обратную сторону. Мы продолжим рассказывать о том, как развиваются альтернативные способы поиска интересных видеороликов и музыки здесь и в нашем Мире Hi-Fi, а пока предлагаем несколько материалов для дополнительного чтения по теме:

Подробнее..
Категории: Блог компании аудиомания , Аудиомания , Облачные сервисы , Netflix , Youtube , Рекомендательные системы , Видеохостинги

Перевод Machine learning в анализе логов Netflix

21.09.2020 16:09:27 | Автор: admin

Представьте лог на 2,5 гигабайта после неудачной сборки. Это три миллиона строк. Вы ищете баг или регрессию, которая обнаруживается на миллионной строке. Вероятно, найти одну такую строку вручную просто невозможно. Один из вариантов diff между последней успешной и упавшей сборкой в надежде на то, что баг пишет в журналы необычные строки. Решение Netflix быстрее и точнее LogReduce под катом.

Netflix и строка в стоге лога


Стандартный md5 diff работает быстро, но выводит не меньше сотни тысяч строк-кандидатов на просмотр, поскольку показывает различия строк. Разновидность logreduce нечёткий diff с применением поиска k ближайших соседей находит около 40 000 кандидатов, но отнимает один час. Решение ниже находит 20 000 строк-кандидатов за 20 минут. Благодаря волшебству открытого ПО это всего около сотни строк кода на Python.

Решение комбинация векторных представлений слов, которые кодируют семантическую информацию слов и предложений, и хеша с учетом местоположения (LSH Local Sensitive Hash), который эффективно распределяет приблизительно близкие элементы в одни группы и далёкие элементы в другие группы. Комбинирование векторных представлений слов и LSH великолепная идея, появившаяся менее десяти лет назад.
Примечание: мы выполняли Tensorflow 2.2 на CPU и с немедленным выполнением для трансферного обучения и scikit-learn NearestNeighbor для k ближайших соседей. Существуют сложные приближенные реализации ближайших соседей, что были бы лучше для решения проблемы ближайших соседей на основе модели.

Векторное представление слов: что это и зачем?


Сборка мешка слов с k категориями (k-hot encoding, обобщение унитарного кодирования) типичная (и полезная) отправная точка дедупликации, поиска и проблем сходства неструктурированного и полуструктурированного текста. Такой тип кодирования мешка со словами выглядит как словарь с отдельными словами и их количеством. Пример с предложением log in error, check log.

{"log": 2, "in": 1, "error": 1, "check": 1}


Такое кодирование также представляется вектором, где индекс соответствует слову, а значение количеству слов. Ниже показывается фраза log in error, check log" в виде вектора, где первая запись зарезервирована для подсчета слов log, вторая для подсчета слов in и так далее:

[2, 1, 1, 1, 0, 0, 0, 0, 0, ...]

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

Посмотрим на словарь и векторные представления фразы problem authentificating. Слова, соответствующие первым пяти векторным записям, вообще не появляются в новом предложении.

{"problem": 1, "authenticating": 1}

Получается:

[0, 0, 0, 0, 1, 1, 0, 0, 0, ...]

Предложения problem authentificating и log in error, check log семантически похожи. То есть они по существу одно и то же, но лексически настолько различны, насколько это возможно. У них нет общих слов. В разрезе нечёткого diff мы могли бы сказать, что они слишком похожи, чтобы выделять их, но кодирование md5 и документ, обработанный k-hot с kNN этого не поддерживает.

Сокращение размерности использует линейную алгебру или искусственные нейронные сети для размещения семантически похожих слов, предложений или строк лога рядом друг с другом в новом векторном пространстве. Применяются векторные представления. В нашем примере log in error, check log может иметь пятимерный вектор для представления:

[0.1, 0.3, -0.5, -0.7, 0.2]

Фраза problem authentificating может быть

[0.1, 0.35, -0.5, -0.7, 0.2]


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

На самом деле вы заменили бы тысячи или более размерностей словаря всего лишь представлением в 100 размерностей, богатыми информацией (а не пятью). Современные подходы к снижению размерности включают разложение по сингулярным значениям матрицы совместной встречаемости слов (GloVe) и специализированные нейронные сети (word2vec, BERT, ELMo).

А как насчет кластеризации? Вернёмся к логу сборки


Мы шутим, что Netflix сервис производства логов, который иногда стримит видео. Логирование, стримы, обработка исключений это сотни тысяч запросов в секунду. Поэтому масштабирование необходимо, когда мы хотим применять прикладное ML в телеметрии и логировании. По этой причине мы внимательны к масштабированию дедупликации текста, к поиску семантического сходства и обнаружению текстовых выбросов. Когда проблемы бизнеса решаются в реальном времени, другого пути нет.

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

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

Вектор представления фразы log in error, check error может быть сопоставлен с двоичным числом 01. Затем 01 представляет кластер. Вектор problem authentificating с большой вероятностью также может быть отображен в 01. Так LSH обеспечивает нечёткое сравнение и решает обратную задачу нечёткое различие. Ранние приложения LSH были над многомерными векторными пространствами из набора слов. Мы не смогли придумать ни одной причины, по которой он не работал бы с пространствами векторного представления слов. Есть признаки, что другие думали так же.



Выше изображено использование LSH при размещении символов в той же группе, но в перевернутом виде.

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

Теперь этот подход работает в каждой сборке Netflix. Семантическая часть позволяет группировать кажущиеся непохожими элементы на основе их значения и отображать эти элементы в отчетах о выбросах.

Несколько примеров


Любимый пример семантического diff. 6892 строк превратились в 3.



Другой пример: эта сборка записала 6044 строки, но в отчете осталась 171. Основная проблема всплыла почти сразу на строке 4036.



Конечно, быстрее проанализировать 171 строку, чем 6044. Но как вообще мы получили такие большие логи сборок? Некоторые из тысяч задач сборки это стресс-тесты для потребительской электроники выполняются в режиме трассировки. Трудно работать с таким объёмом данных без предварительной обработки.



Коэффициент сжатия: 91366/455 = 205,3.

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

Заключение


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

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

Если у вас есть какие-либо вопросы о возможностях в Netflix, обращайтесь к авторам в LinkedIn: Stanislav Kirdey, William High

А как вы решаете проблему поиска в логах?

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:


Eще курсы


Подробнее..
Категории: Алгоритмы , Python , Машинное обучение , Machine learning , Блог компании skillfactory , Логирование , Netflix , Tensorflow , Поиск

Перевод Перерасти ПО код это современное электричество

21.06.2021 12:17:59 | Автор: admin
image

Десять лет назад Марк Андриссен написал для Wall Street Journal статью под названием "Софт пожирает мир", в которой говорит о фундаментальном сдвиге роли, которую ПО играет в экономике. В прошлом IBM, Oracle или Microsoft продавали технологии другим компаниям как инструмент. Они продавали компьютеры и ПО GE, P&G и Citibank. Теперь есть поколение компаний, которые и создают ПО, и самостоятельно используют его, чтобы войти на рынок другой отрасли, а часто и изменить его. Uber и Airbnb не продают ПО компаниям, владеющим такси или отелями, Instacart не продаёт ПО компаниям, занимающимся продуктами питания, а Transferwise не продаёт ПО банкам.

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

Но также любопытно будет взглянуть на отдельные отрасли, которые уже были подорваны программным обеспечением, и подумать над тем, что случилось дальше. Первой, очевидно, стала отрасль звукозаписей. Технологии значительно повлияли на музыкальный бизнес, но сегодня никто в сфере технологий об этом особо не задумывается. 15 или 20 лет назад музыка была способом продажи устройств и удержания людей в экосистеме, но возникновение сервисов стриминга по подписке означало, что музыка больше не является сильным стратегическим оружием ты не потеряешь свою библиотеку музыки, если перейдёшь с iPhone на Android, или даже со Spotify на Apple Music. В то же время, абсолютный размер рынка стал очень мал по сравнению с тем, чем стала сфера технологий в прошлом году общие доходы отрасли звукозаписи составили менее 20 миллиардов долларов (половина от максимума, который был в 2000 году), а доходы Apple составили 215 миллиардов. Больше никого не заботит музыка.

Нечто подобное произошло и с книгами. Amazon занимает половину рынка, электронные книги стали реальным бизнесом (хоть и остались нишевыми), а самиздат стал вертикальным, но я подозреваю, что если бы у Apple был выбор, она не стала бы снова заниматься электронными книгами. Как и в случае с музыкой, здесь нет возможности стратегического давления: общие доходы рынка книг США в прошлом году составили около 25 миллиардов, а доходы Amazon в США 260 миллиардов. Никого в сфере технологий не интересуют онлайн-продажи книг или электронные книги.

Однако в более фундаментальном смысле, с точки зрения музыки и книг, большинство споров и вопросов относятся к индустрии музыки и книг, а не к технологиям или ПО. Spotify судится с Apple по поводу правил комиссий App Store, но во всём остальном все вопросы Spotify связаны с музыкой. Почему исполнители не зарабатывают больше денег на стриминге? Спрашивайте у лейблов. Почему Интернет не убил лейблы или издателей? Спрашивайте у любителей музыки и книг.

Думаю, то же самое происходит сегодня с телевидением и кинематографом. Технологии (а теперь и локдаун) разрушили старую модель и изменили все правила, но вопросы о новых моделях это вопросы о телевидении и кино, а не о программном обеспечении. Что произойдёт с гарантированной долей Тома Круза от выручки фильма, если он стал частью пакета, используемого для продажи подписок на стриминговый сервис? Каков срок жизни шоу на Netflix, кому переходят права на спортивные трансляции, и как будут устроены периоды релизов, когда снова откроются кинотеатры? Не спрашивайте меня всё это вопросы для Лос-Анджелеса, а не для Кремниевой долины. Netflix использовал технологии в качестве рычага для попадания на телевизионный рынок, но, повторюсь, все вопросы о его будущем это вопросы о телевидении. Тем временем, фильмы и телевидение (что бы это сегодня не значило), как и музыка с книгами, имеют ограниченное стратегическое значение для крупных технологических платформ Amazon использует их как мотиватор к покупке подписок Prime, а Apple только как маркетинговый инструмент. Контент больше не главное.

Сегодня телевидение интересно технологическим компаниям не из-за контента или из-за возможности продавать устройства, а потому, что на кону 65 миллиардов долларов, потраченных в США на рекламу, и, в более широком смысле, потому, что бывшие ранее отдельными рынками для рекламы, маркетинга, розничной аренды, доставки и многого другого, теперь становятся существенным общим рынком стоимостью 7-800 миллиардов долларов. Само телевидение интересно не очень многим.

Есть старая шутка о том, что консультанты похожи на чаек они прилетают, наводят шум и хаос, а потом улетают. Примерно то же самое технологии сделали с медиа-индустриями поменяли всё, а потом ушли. Теперь то же происходит с розницей всё то, что технологии, ПО и Интернет сделали с медиа, повторяется и с ретейлерами. Всё это довольно большой бизнес 20 триллионов долларов.

Но после того, как технологии всё изменят, вопросы снова будут касаться в основном розницы, а не технологий. Какой это продукт, как ты о нём узнал, и как его получить? Это вопросы ретейла, бренда и маркетинга. Разумеется, ретейлер, продающий через новый онлайн-канал, должен быть в этом хорош, но тогда он должен быть хорош и в физическом канале. Наличие большого онлайн-опыта это условие для входа на рынок, но благодаря инструментам наподобие Shopify и Stripe он всё больше становится просто слоем в стеке. Однако правильной реализации онлайна недостаточно если бы Netflix показывал бы заново Друзей или Скорую помощь, то дело было бы не в качестве приложения, а Hulu не так популярен, как Netflix, не из-за качества сжатия. Правильная реализация онлайна и необходима, и сложна, но ваш успех будет определяться вопросами ретейла, телевидения или музыки.

На самом деле, то же относится и к Tesla: автономность это определённо вопрос ПО, но с электроприводом не всё так очевидно. Tesla бык в том, что она программная компания, и медведь в том, что автомобильная компания.

В начале статьи я упомянул Walmart как компанию, изменившую лицо рынка ретейла, но она также изменила ретейл благодаря пониманию того, что автомобилями уже владеют массы людей. Вероятно, автомобилестроение создало больше миллионеров в ретейле и недвижимости, чем в автомобильной отрасли производство автомобилей было просто одной из отраслей, но массовое владение автомобилями изменило всё остальное. Часто я думаю, что это хорошая точка зрения на современное состояние технологий: 80% взрослого населения мира имеет сегодня смартфон, что же мы можем с этим сделать? Именно это и означает софт пожирает мир. Но можно ещё и сказать, что Walmart не был создан людьми из автомобильной отрасли, из Детройта. Он был создан ретейлерами. Сэм Уолтон родился на десять лет позже появления Model T, а сегодняшние выпускники MBA родились в год выпуска Netscape. В какой-то момент в этой обстановке будет расти каждый, и все компании будут софтверными, а важные вопросы будут связаны не с ПО.


На правах рекламы


Облачный хостинг для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Создайте собственный тарифный план в пару кликов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Подписывайтесь на наш чат в Telegram.

Подробнее..
Категории: Apple , Софт , Финансы в it , Netflix , Amazon , Ритейл , Стриминговые сервисы , Spotify , Программное обеспечение , Walmart , Блог компании vdsina.ru

Перевод Применение паттернов Netflix DevOps к Windows

11.01.2021 12:12:41 | Автор: admin

Когда говорят про DevOps обычно всегда подразумевают работу с Linux. Но есть большое количество решений под Windows. Как осуществлять сборку Windows c помощью Packer в своем блоге поделился Netflix (Джастин Фелпс и Мануэль Корреа - Applying Netflix DevOps Patterns to Windows). Предлагаю перевод статьи.

В Netflix настройка образов Windows происходило вручную, были ошибки и это был трудоемкий процесс. В этой статье мы описываем, как мы улучшили методологию, какие технологии мы использовали, и как это улучшило развертывание и согласованность сервисов.

Artisan Crafted Images

В культуре DevOps в Netflix группа, ответственная за создание сервиса, также отвечает за развертывание, тестирование, инфраструктуру и работу этой службы. Основная обязанность инженеров Netflix - выявление пробелов и болевых точек при разработке и эксплуатации сервисов. Хотя большинство наших сервисов работают на Linux Amazon Machine Images (AMI), все еще существует множество сервисов, критически важных для Netflix Playback Experience, работающих на инстансах Windows Elastic Compute Cloud (EC2).

Мы изучили наш процесс создания образов Windows AMI и обнаружили, что он подвержен ошибкам и полон утомительных усилий. Сначала инженер запускал инстанс EC2 и ждал, пока он перейдет в режим онлайн. Как только экземпляр оказывался доступен, инженер использовал инструмент удаленного администрирования, такой как RDP, для входа в экземпляр для установки программного обеспечения и настройки параметров. Затем этот образ сохранялся как AMI и использовался в Auto Scale Group для развертывания кластера инстансов. Поскольку этот процесс занимал много времени и был долгим, в наших экземплярах Windows обычно отсутствовали последние обновления безопасности от Microsoft.

В прошлом году мы решили улучшить этот процесс.

Были следующие проблемы:

  • устаревшая документация.

  • обновления ОС.

  • высокие когнитивные издержки.

  • отсутствие непрерывного тестирования.

Масштабирование создания образов.

Наш существующий инструмент создания AMI - Aminator - не поддерживает Windows, поэтому нам пришлось использовать другие инструменты.

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

Конфигурация как код

Первая часть нашего нового решения для создания образов Windows - Packer. Packer позволяет описать процесс настройки образов в виде файла JSON. Мы используем конструктор amazon-ebs Packer для запуска инстанса EC2. После подключения Packer использует WinRM для копирования файлов и выполнения сценариев PowerShell для экземпляра. Если все шаги настройки выполнены успешно, Packer сохраняет новый AMI. Файл конфигурации, сценарии, на которые имеются ссылки, и описание зависимостей артефактов находятся во внутреннем репозитории git. Теперь у нас есть конфигурация инстанса и программного обеспечения в виде кода. Это означает, что эти изменения можно отслеживать и просматривать, как и любые другие изменения кода.

Packer требуется специфическая информация для вашей среды создания образов и расширенные разрешения AWS IAM. Чтобы упростить использование Packer для наших разработчиков программного обеспечения, мы объединили специфичную для Netflix информацию о среде AWS и вспомогательные сценарии. Изначально мы сделали это с репозиторием git и файлами переменных Packer. Также был специальный экземпляр EC2, где Packer выполнялся как задания Jenkins. Эта установка была лучше, чем создание образов вручную, но у нас все же были некоторые проблемы с эргономикой. Например, стало сложно гарантировать, что пользователи Packer получают обновления.

Последняя часть нашего решения - найти способ упаковать наше программное обеспечение для установки в Windows. Это позволит повторно использовать вспомогательные сценарии и инструменты инфраструктуры, не требуя от каждого пользователя копировать это решение в свои сценарии Packer. В идеале это должно работать аналогично тому, как приложения упаковываются в процессах Animator. Мы решили эту проблему, используя Chocolatey, менеджер пакетов для Windows. Пакеты Chocolatey создаются и затем сохраняются во внутреннем репозитории артефактов. Этот репозиторий добавлен в качестве источника для команды choco install. Это означает, что мы можем создавать и повторно использовать пакеты, которые помогают интегрировать Windows в экосистему Netflix.

Использование Spinnaker для непрерывной доставки

Базовый Dockerfile позволяет обновлениям Packer, вспомогательным скриптам и конфигурациям среды распространяться через весь процесс создания образов Windows.Базовый Dockerfile позволяет обновлениям Packer, вспомогательным скриптам и конфигурациям среды распространяться через весь процесс создания образов Windows.

Чтобы сделать процесс создания образов более надежным, мы решили использовать образ Docker, содержащий Packer, конфигурацию нашей среды и вспомогательные скрипты. В дальнейшем пользователи создают свои собственные образы Docker на основе этого базового образа. Это означает, что мы можем обновить базовый образ, добавив в него новую информацию о среде и вспомогательные сценарии, и пользователи будут получать эти обновления автоматически. Со своим новым образом Docker пользователи запускают свои задания по созданию образов Packer с помощью Titus, нашей системы управления контейнерами. Задание Titus создает файл свойств как часть пайплайна Spinnaker. Полученный файл содержит AMI ID и используется на более поздних этапах пайплайна для деплоя. Создание образа в Titus сняло ограничение на использование одного экземпляра EC2, что позволило выполнять задания. Теперь каждое изменение в инфраструктуре тестируется, обрабатывается и развертывается, как и любое другое изменение кода. Этот процесс автоматизирован с помощью пайплайна Spinaker:

пример пайплайна Spinaker, показывающий этапы создания, сборки и развертывания образов.пример пайплайна Spinaker, показывающий этапы создания, сборки и развертывания образов.

На этапе сборки Kayenta используется для сравнения показателей между базовым образом (текущий AMI) и тем что собирается (новый AMI). На сборочном этапе оценка будет определяться на основе таких показателей, как CPU, threads, latency и GC pause. Если эта оценка находится в пределах допустимого порога, AMI развертывается в каждой среде. Запуск сборки для каждого изменения и тестирование AMI в производственной среде позволяет нам получить представление о влиянии обновлений Windows, изменений скриптов, настройки конфигурации веб-сервера и т. д.

Избавление от тяжелого труда(Eliminate Toil)

Автоматизация этих утомительных рабочих задач позволяет командам работать быстрее. Нашим инженерам больше не нужно вручную обновлять Windows, Java, Tomcat, IIS и другие службы. Мы можем легко протестировать изменения настройки сервера, обновления программного обеспечения и другие модификации среды выполнения. Каждое изменение кода и инфраструктуры проходит через один и тот же конвейер тестирования и развертывания.

Получение преимуществ

Изменения, которые раньше требовали нескольких часов ручной работы, теперь легко модифицировать, тестировать и развертывать. Другие группы могут быстро развернуть безопасные и воспроизводимые инстансы в автоматическом режиме. Услуги более надежны, тестируемы и документированы. Изменения в инфраструктуре теперь рассматриваются, как и любые другие изменения кода. Это снимает ненужную когнитивную нагрузку и документирует наши знания. Исключение тяжелого труда позволило команде сосредоточиться на других функциях и исправлениях ошибок. Все эти преимущества снижают риск сбоя, который может повлиять на клиента. Принятие шаблона Immutable Server для Windows с использованием Packer и Chocolatey принесло большие преимущества.

Подробнее..
Категории: Devops , Netflix , Packer , Iac

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru