Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Часть затрат на инфраструктуру можно снять, разместившись в облачных сервисах, да и риск хабраэффекта резко снижается. Вот только вопрос, кто из них захочет иметь дело с видеостримингом?
Из последних примеров облачных сервисов, которые точно любят стриминг — Amazon и Rackspace. Мы плотно работаем с медиасервером Wowza, вижу по ним. Вовза очень тесно сотрудничает с обоими и не собираются останавливаться на достигнутом. С Амазоном Вовза «дружит семьями» — есть интеграция с CloudFront, прозрачный биллинг. С Рэкспейсом Вовза проводила на днях совместный семинар, о том, как правильнее сделать живую трансляцию, развернув обрабатывающие мощности в их облаке.
Что такое стриминг с точки зрения провайдера? Много трафика и, если это VOD, много дискового пространства. То есть это живые деньги для них.
Что такое стриминг с точки зрения провайдера? Много трафика и, если это VOD, много дискового пространства. То есть это живые деньги для них.
Вы так не снизите затраты, а многократно их повысите, если внезапно видео станет чуть популярнее. Снизит это затраты только если просмотров совсем мало.
А с видео дружат все облака с платным трафиком, думаю. Это ж их хлеб.
А с видео дружат все облака с платным трафиком, думаю. Это ж их хлеб.
Если вы решили заняться тем, что выкладываете видео у себя, то вы однозначно это видео как-то монетизируете. Иначе смысла нет и надо спокойно использовать Ютюб. Так что затраты вырастут, конечно, но уже вместе с прибылью. Что владельцу контента как раз и нужно.
А про затраты — речь в комментарии выше о том, что затраты можно снизить по сравнению с решениями на выделенных серверах. До какого-то предела именно так и есть — облака помогут быстро заскейлиться. Но после определённого порога проще выделенные сервера покупать.
А про затраты — речь в комментарии выше о том, что затраты можно снизить по сравнению с решениями на выделенных серверах. До какого-то предела именно так и есть — облака помогут быстро заскейлиться. Но после определённого порога проще выделенные сервера покупать.
Я к тому, что для видео на объемах чуть превышающих минимальные, намного выгоднее оплачивать сервер с безлимитным каналом, чем трафик помегабайтно. Амазон и подобыне решения больше подходят для стартапов, котрые уже получили инвестиции, но еще не набрали в команду людей, что могут качественно настроить сервера, найти правильный хостинг и т.д.
В целом да, согласен. Тут уже зависит от «экономики» конкретного проекта. У нас недавно одному клиенту для счастья хватило лимитов трафика DigitalOcean, например. Ему оказалось проще раскидать запросы на несколько мелких серверов, каждый из которых по итогу месяца не выходил за рамки своего тарифа. В итоге себестоимость была буквально копеечная. Но это скорее исключение — стример был действительно начинающий.
облачные сервисы + видео — это многократный рост расходов.
Многократный — по сравнению с чем?
Предположу, что по сравнению с коло/дедиком.
Виртуализация, конечно, даёт свои накладные расходы. Но насчёт многократного роста — хотелось бы посмотреть на конкретные бенчмарки и какие-то конечные цифры.
Плюсы виртуализации в другом — меньше порог вхождения, больше скорость развертывания, проще наращивать мощность. Накладные расходы перекрываются экономией на других направлениях.
Дедики/коло становятся выгоднее чуть позже, когда начинает сказываться разница в ценах на трафик и память. То есть при больших объёмах.
Плюсы виртуализации в другом — меньше порог вхождения, больше скорость развертывания, проще наращивать мощность. Накладные расходы перекрываются экономией на других направлениях.
Дедики/коло становятся выгоднее чуть позже, когда начинает сказываться разница в ценах на трафик и память. То есть при больших объёмах.
При чём тут виртуализация? Мы же рассматриваем готовые сервисы, с оплатой трафика и хранилища, а не создание собственного облака.
Стоимость трафика и хранения основные составляющие затрат итоговых, и они в облаках больше, чем на выделенных серверах, как только речь заходит о чём-то большем чем показ друзьям пары видео.
Стоимость трафика и хранения основные составляющие затрат итоговых, и они в облаках больше, чем на выделенных серверах, как только речь заходит о чём-то большем чем показ друзьям пары видео.
При чём тут виртуализация?
Максим erlyvideo явно написал про многократный рост всвязи с виртуализацией, про это и был мой уточняющий вопрос и далее ответ.
они в облаках больше, чем на выделенных серверах
Именно об этом я и написал в комменте выше — да, накладные расходы выше. Преимущество в том, что остальные плюсы подобного подхода до поры-до времени перевешивают эти затраты.
После определённого порога, конечно, выгоднее использовать выделенное железо и каналы. Собственно, нам, как поставщикам продуктов для стриминга, нет большой разницы, где работать — выбор за клиентом, в конечном счёте.
Нет, он написал именно об облаках. Давай все же не смешивать две разных области: техническую и экономическую. Виртуализация это чисто технический аспект, облака — чисто экономический (в данном контексте).
levgem.livejournal.com/397082.html?thread=4427546#t4427546
levgem.livejournal.com/397082.html?thread=4427546#t4427546
От автора вопроса я не услышал уточнения. Но он явно говорит о росте расходов, то есть об экономике — про неё и написал тебе в ответ.
А то, что при энкодинге выжимаются все возможности и нужно хорошее железо — тут не спорю. Вот и screaam об этом же в комментах ниже пишет.
А то, что при энкодинге выжимаются все возможности и нужно хорошее железо — тут не спорю. Вот и screaam об этом же в комментах ниже пишет.
Вопрос тут экономический.
Облако при равномерном использовании всегда дороже, чем bare metal, потому что ты платишь за _возможность_ всплеска.
Но для старта DigitalOcean — ок, годится.
Облако при равномерном использовании всегда дороже, чем bare metal, потому что ты платишь за _возможность_ всплеска.
Но для старта DigitalOcean — ок, годится.
Вопрос был, в общем-то, про «многократный». Оверхед есть, но он явно не в разы.
Платят не столько за возможность всплеска, сколько вообще за удобство развертывания и управления. Поднимая несколько виртуалок за считанные минуты, а потом в любой момент изменяя их параметры — сильно экономишь по времени.
Платят не столько за возможность всплеска, сколько вообще за удобство развертывания и управления. Поднимая несколько виртуалок за считанные минуты, а потом в любой момент изменяя их параметры — сильно экономишь по времени.
тут вопрос в возможности прогнозирования нагрузки и её равномерности.
Если она прогнозируемая и равномерная, все эти облака — это именно многократный оверхед.
Хостер в Амстердаме дает в разы лучшее качество, чем Амазон и в разы дешевле. Но он инертен, это факт.
Просто когда виртуалка, которую так удобно настраивать, стоит дороже чем выделенный сервер на котором она работает, то нафига она нужна с её удобством?
Но это уже вопрос не про стриминг, а про облака вообще.
Если она прогнозируемая и равномерная, все эти облака — это именно многократный оверхед.
Хостер в Амстердаме дает в разы лучшее качество, чем Амазон и в разы дешевле. Но он инертен, это факт.
Просто когда виртуалка, которую так удобно настраивать, стоит дороже чем выделенный сервер на котором она работает, то нафига она нужна с её удобством?
Но это уже вопрос не про стриминг, а про облака вообще.
Всё верно. Облака vs. Железо — этому спору столько же, сколько самим облакам. Стриминг как юзкейс просто обостряет противоречия между этими опциями.
Стриминг обостряет в том числе из-за своей специфики.
Например, когда надо вещать 30 гигабит, то предложение поставить балансировщик вызывает только улыбку.
Но на текстовых сайтах таких нагрузок практически никогда не бывает, поэтому балансировщик там всегда годится.
Иначе говоря: «обычные» задачи создают нагрузку на CPU и память. Видео — на сеть и иногда на диск. Отсюда постоянное стремление отказаться от облака
Например, когда надо вещать 30 гигабит, то предложение поставить балансировщик вызывает только улыбку.
Но на текстовых сайтах таких нагрузок практически никогда не бывает, поэтому балансировщик там всегда годится.
Иначе говоря: «обычные» задачи создают нагрузку на CPU и память. Видео — на сеть и иногда на диск. Отсюда постоянное стремление отказаться от облака
А что не так с идеей разбалансировать 30 гигабит? Десяток небольших эджей ставится на нескольких локациях, поближе к потребителям — и вперёд.
раскидывать клиентов между эджами или пропускать 30 гигабит через балансер.
HTTP-based протоколы (HLS, HDS, Smooth, DASH) поддерживают редирект по 302 ответу, аналогичный механизм есть и в RTMP. Балансировщику нет необходимости пропускать через себя все 30 гигабит. Соответственно можно раскидывать соединения как по раунд-робину, так и по признаку местонахождения (гео-балансинг) и по более сложным схемам типа нагрузки на конкретные сервера и т.п.
Для самых простых случаев, когда вполне подойдёт раунд робин — можно просто настроить DNS failover — балансировщик в этом случае вообще не нужен.
Для самых простых случаев, когда вполне подойдёт раунд робин — можно просто настроить DNS failover — балансировщик в этом случае вообще не нужен.
Вы успешно внедряли 302 редирект на HLS и HDS? Или вы только предполагаете?
Мы его не просто внедряли — на этом построена балансировка в нашем медиа-сервере. Она работает и используется нашими клиентами.
Проблемы есть с этим 302 у разных клиентов.
Не все пережевывают.
Не все пережевывают.
Какие ещё есть безболезненные варианты, если не брать решения на основе маршрутизации?
iframe с плеером.
Очень, кстати, неплохой вариант, учитывая, что кастомеры поголовно не в состоянии вставить плеер без ошибок.
Ещё мы экспериментировали с хитрой схемой, когда с балансировщика отдается HLS и HDS плейлисты, а в них уже ссылки на плейлисты на ориджинах.
Ну и DNS маршрутизация. Наш балансировщик отслеживает состояние разных стримов и отдаст список IP-шников, на которых есть нужный стрим. Это даже кому-то пришлось использовать, с совсем бедовыми клиентами типа приставок.
Очень, кстати, неплохой вариант, учитывая, что кастомеры поголовно не в состоянии вставить плеер без ошибок.
Ещё мы экспериментировали с хитрой схемой, когда с балансировщика отдается HLS и HDS плейлисты, а в них уже ссылки на плейлисты на ориджинах.
Ну и DNS маршрутизация. Наш балансировщик отслеживает состояние разных стримов и отдаст список IP-шников, на которых есть нужный стрим. Это даже кому-то пришлось использовать, с совсем бедовыми клиентами типа приставок.
Это всё вполне работающие варианты. Но чем хорош 302 редирект — не надо ничего придумывать ни на стороне сайта (с iframe ссылку ведь всё равно менять надо на нужный сервер), ни на стороне марштуризаторов. Дал единообразную ссылку — и дальше забота сервера, куда бросать запрос.
Чуть позже сделаем баласировку на основе обратной связи от серверов по текущей нагрузке, опять же на основе 302 ответа, как работающего «из коробки».
Если клиент хочет чего-то более интересного, вроже DNS-маршрутизации — его право.
Чуть позже сделаем баласировку на основе обратной связи от серверов по текущей нагрузке, опять же на основе 302 ответа, как работающего «из коробки».
Если клиент хочет чего-то более интересного, вроже DNS-маршрутизации — его право.
Не, iframe отдается с одного адреса, а в нём уже адреса к разным стримерам.
Мы поддерживаем много разных клиентов: не только айпады, но и андроиды, приставки, VLC и т.п. Я могу подетальнее позже попробовать вспомнить, где именно разваливается 302
Мы поддерживаем много разных клиентов: не только айпады, но и андроиды, приставки, VLC и т.п. Я могу подетальнее позже попробовать вспомнить, где именно разваливается 302
Код, который внутри iframe, всё равно надо как-то формировать, т.е. это ещё одно звено.
Если вспомните про 302 — пишите, конечно.
Если вспомните про 302 — пишите, конечно.
балансировщик с 302 — это такое же звено, как и генератор iframe.
Просто пользователь себе на страницу вставляет:
и от балансировщика получает:
Это самый безотказный способ для веб-сайтов. Но не работает с приставками. Но приставки могут и по API сходить.
Просто пользователь себе на страницу вставляет:
<iframe src="pointcdn.net/users/15/streams/ort" width=240 height=160></iframe>
и от балансировщика получает:
<html>
<body>
<video src="http://node-1654.pointcdn.net/ort/index.m3u8"></video>
Это самый безотказный способ для веб-сайтов. Но не работает с приставками. Но приставки могут и по API сходить.
Рассматривали этот же вопрос в рамках своего проекта и пришли к выводу, что создавать свой полноценный велосипед не рационально, разве что ограничиться дублированием ютюбовского плеера на тот случай, если по какой-то причине ютюб заблокирует один из роликов. Пришли к такому выводу неслучайно:
1) Нужны очень большие мощности для обработки видео — 1080р сейчас чуть ли не в каждом смартфоне
2) Сложности с софтом — что бы получить хорошее качество картинки при 0,10 бит/пиксель нужно кодирование в два прохода. CPU тут бесполезен (при кодировании 1080р большой продолжительности) и остается только использовать Cuda и видеокарты nVidia.
3) Обеспечение достаточно широкого канала в случае резкого увеличения количества просмотров — 5,5 Мбит/с на клиента при просмотре 1080р это уже не шутки, 100 человек забьют намертво полугигабитный канал.
4) Использование хорошего плеера — далеко не каждый плеер обеспечивает предпросмотр кадра при наведении курсора на ползунок, позволяет переключаться между потоками разного качества и при этом одинаково хорошо работает на всех платформах во всех браузерах.
Получается, что сделать сервис, который по качеству лучше или примерно равен ютюбу очень и очень непросто, а так же очень затратно. Не в каждую бизнес-модель это вписывается…
1) Нужны очень большие мощности для обработки видео — 1080р сейчас чуть ли не в каждом смартфоне
2) Сложности с софтом — что бы получить хорошее качество картинки при 0,10 бит/пиксель нужно кодирование в два прохода. CPU тут бесполезен (при кодировании 1080р большой продолжительности) и остается только использовать Cuda и видеокарты nVidia.
3) Обеспечение достаточно широкого канала в случае резкого увеличения количества просмотров — 5,5 Мбит/с на клиента при просмотре 1080р это уже не шутки, 100 человек забьют намертво полугигабитный канал.
4) Использование хорошего плеера — далеко не каждый плеер обеспечивает предпросмотр кадра при наведении курсора на ползунок, позволяет переключаться между потоками разного качества и при этом одинаково хорошо работает на всех платформах во всех браузерах.
Получается, что сделать сервис, который по качеству лучше или примерно равен ютюбу очень и очень непросто, а так же очень затратно. Не в каждую бизнес-модель это вписывается…
Поэтому логичен компромисс — использовать специализированные платные сервисы. Конечно, они будут стоить денег, но обойдется это гораздо дешевле, чем с нуля разворачивать свою инфраструктуру (для небольших и средних объемов). Своя инфраструктура выгодна только для крупных проектов.
Я участвовал в разработке одного такого сервиса (но владельцем не являюсь и зарплату там уже не получаю :) Тут ссылку давать не буду, чтобы не сочли рекламой, да ещё и в чужом топике. Если вдруг интересно, могу через личку.
Я участвовал в разработке одного такого сервиса (но владельцем не являюсь и зарплату там уже не получаю :) Тут ссылку давать не буду, чтобы не сочли рекламой, да ещё и в чужом топике. Если вдруг интересно, могу через личку.
Платные сервисы тоже разные бывают и за разные деньги. Там «всё не так однозначно» (с) Уходя на универсальное, казалось бы, решение, вы всё равно теряете в гибкости. Да и риски всё равно остаются, просто перекладываются на плечи другого человека. Да, подобный хостер берёт на себя огромную кучу вопросов, но чем более надёжное решение выбираете, тем дороже оно стоит. И возвращаемся всё к тому же — «Не в каждую бизнес-модель это вписывается».
Разумеется, везде есть нюансы.
Потому я и написал про компромисс — уход от жестких ограничений бесплатных сервисов (обязательная чужая реклама и блокировки за неосторожное использование фоновой музычки, которые невозможно обжаловать), но относительно малой кровью в сравнении с разработкой своего решения с нуля.
Потому я и написал про компромисс — уход от жестких ограничений бесплатных сервисов (обязательная чужая реклама и блокировки за неосторожное использование фоновой музычки, которые невозможно обжаловать), но относительно малой кровью в сравнении с разработкой своего решения с нуля.
Вот тут с вами не соглашусь. Летом буду делать сервис по облачному кодированию видео, который будет заметно дешевле всех конкурентов, в разы, я бы даже сказал.
Не совсем понял — только кодирование? А хостинг и стриминг?
во-первых, нашли чем хвастаться: «дешевле конкурентов». За счёт чего? Отсутствия поддержки или фигового выходного качества?
Это очень серьезное заявление, потому что сервисы по кодированию видео не то что бы прям 1000% маржу имеют.
Это очень серьезное заявление, потому что сервисы по кодированию видео не то что бы прям 1000% маржу имеют.
За счет того, что я, во-первых, буду распараллеливать кодирование даже одного файла на несколько серверов, а во-вторых за счет того, что я нашел место, где можно взять в аренду мощные компьютеры за крайне низкую стоимость.
Предполагается делать 2 варианта оплаты: либо за машинное время, либо фиксированная стоимость в месяц. В первом случае, используется пул доступных для кодирования машин, и оплачивается машинное время. Предполагается, что стоимость машинного часа будет в районе $1.2. Предположим, вам нужно кодировать видеофайл, который идет 1 час, с пресетом veryfast, и получается, что видео кодируется в 3 раза быстрее, чем воспроизводится. Вы заплатите за 20 минут кодирования, т.е. $0.4. А если кодировать нужно с пресетом veryslow, и видео кодируется в 2 раза медленнее, то вы заплатите $2.4.
Фиксированная стоимость подразумевает покупку конкретного количества машин, которые будут заниматься кодированием только вашего видео. 3 машины будут стоить что-то около $50-60 в месяц. На них можно кодировать как хочется и сколько хочется.
Предполагается делать 2 варианта оплаты: либо за машинное время, либо фиксированная стоимость в месяц. В первом случае, используется пул доступных для кодирования машин, и оплачивается машинное время. Предполагается, что стоимость машинного часа будет в районе $1.2. Предположим, вам нужно кодировать видеофайл, который идет 1 час, с пресетом veryfast, и получается, что видео кодируется в 3 раза быстрее, чем воспроизводится. Вы заплатите за 20 минут кодирования, т.е. $0.4. А если кодировать нужно с пресетом veryslow, и видео кодируется в 2 раза медленнее, то вы заплатите $2.4.
Фиксированная стоимость подразумевает покупку конкретного количества машин, которые будут заниматься кодированием только вашего видео. 3 машины будут стоить что-то около $50-60 в месяц. На них можно кодировать как хочется и сколько хочется.
Выше правильно заметили насчёт денег. Пересчитайте всё несколько раз, с разными сценариями использования и разными типами пользователей. Очень уж специфичная и узкая ниша.
> распараллеливать кодирование даже одного файла на несколько серверов
Это очень серьезный рост расходов. Ведь любое распараллеливание в сумме увеличивает расходы.
Т.е. идея распараллелить обработку на нескольких серверах во-первых, потребует серьезных инвестиций, которые вы потом будете забирать у клиентов, во-вторых никак не сделает дешевле ваше решение. Только дороже.
> я нашел место, где можно взять в аренду мощные компьютеры за крайне низкую стоимость.
Это место называется магазин. Дешевле чем там взять сложно. Через 2-3 месяца покупка Core i7 окупит любую аренду.
Я так и не понял в чем же ваша идея по кодированию и какие ценники вы собираетесь предложить.
Это очень серьезный рост расходов. Ведь любое распараллеливание в сумме увеличивает расходы.
Т.е. идея распараллелить обработку на нескольких серверах во-первых, потребует серьезных инвестиций, которые вы потом будете забирать у клиентов, во-вторых никак не сделает дешевле ваше решение. Только дороже.
> я нашел место, где можно взять в аренду мощные компьютеры за крайне низкую стоимость.
Это место называется магазин. Дешевле чем там взять сложно. Через 2-3 месяца покупка Core i7 окупит любую аренду.
Я так и не понял в чем же ваша идея по кодированию и какие ценники вы собираетесь предложить.
Т.е. идея распараллелить обработку на нескольких серверах во-первых, потребует серьезных инвестиций, которые вы потом будете забирать у клиентов, во-вторых никак не сделает дешевле ваше решение. Только дороже.Это будет не enterprise-решение. Я его делаю, главным образом, для себя, а там посмотрим, что из этого выйдет. Вполне возможно, что все провалится.
Это место называется магазин. Дешевле чем там взять сложно. Через 2-3 месяца покупка Core i7 окупит любую аренду.Скажем, я знаю где арендовать 8-ядерные Xeon с 16ГБ оперативки за $0.01 в час. Месяц аренды получается всего $7.2. Трафик неограничен, но и канал не супер. Они, безусловно, могут падать и отключаться в неподходящий момент, но это не проблема, т.к. планируется нарезать видео кусками секунд по 15-30.
Я так и не понял в чем же ваша идея по кодированию и какие ценники вы собираетесь предложить.
Просто хочу сделать еще один сервис, первым делом для себя, т.к. мне иногда приходится кодировать большое количество видео, а покупать для этого несколько компьютеров домой нецелесообразно.
«Не в каждую бизнес-модель это вписывается» — совершенно верно. В конечном счёте всё сводится к деньгам, всё остальное — следствие.
Касаемо пунктов 1 и 2 — вы пробовали облачные энкодеры типа Encoding.com, Zencoder, Camfoo?
Пункт 3 отчасти покрывается горизонтальным масштабированием. Распараллелить на несколько машин — и боттл-нэк уйдёт.
А вот плеер да, там сейчас изрядный зоопарк, однако одного универсального решения нет. Разве что JWPlayer, но и он не идеален.
Касаемо пунктов 1 и 2 — вы пробовали облачные энкодеры типа Encoding.com, Zencoder, Camfoo?
Пункт 3 отчасти покрывается горизонтальным масштабированием. Распараллелить на несколько машин — и боттл-нэк уйдёт.
А вот плеер да, там сейчас изрядный зоопарк, однако одного универсального решения нет. Разве что JWPlayer, но и он не идеален.
А как же лицензирование?
Ведь ютуб не просто так блокирует видео если там есть кадры с чужого видео.
Или вы хотите думаете какая нибудь бритниспирс будет судиться с сенейизказани?
Ведь ютуб не просто так блокирует видео если там есть кадры с чужого видео.
Или вы хотите думаете какая нибудь бритниспирс будет судиться с сенейизказани?
правильная статья, давайте дружить, CDN вашим клиентам в любом случае нужен будет как средство для раздачи пикового трафика
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем что-то придумывать, если есть YouTube?