Где находятся сервера ютуба

Большинство пользователей интернета ни на секунду не задумывается о том, как работает система всемирной паутины

Они просто включают компьютер, запускают браузер и отправляются в очередное увлекательное путешествие в поисках «годного» контента……..

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

Как он функционирует ?

Каждое загруженное на YouTube видео хранится в одном из 14 центров Google по обработке данных, расположенных по всему миру.

Вот один из них ↓

→ В этих гигантских зданиях содержатся тысячи серверов — мощных компьютеров, которые ежедневно обрабатывают миллиарды поисковых запросов, а также хранят ваши видеоролики

Огромные башни для охлаждения поддерживают постоянную температуру в 27 градусов Цельсия (80 градусов Фаренгейта), обеспечивая бесперебойную работу всего оборудования.

P.S — Тем не менее каждый байт информации все равно хранится, как минимум, на двух серверах для дополнительной безопасности данных.

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

Кстати ↓

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

→ Однако, когда кто-то другой нажимает на «плей», то ролик сначала пересылается в ближайший к нему центр, обеспечивая более быстрый доступ.

Резервное устройство

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

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

Путешествие видеоролика по сервису

Регулярно около 1 миллиарда человек используют сервис YouTube для просмотра и загрузки видео.

Но что происходит с видеороликом, когда его загружают в систему .

Как происходит загрузка ↓

Каждую минуту на YouTube загружается более 300 часов видео

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

Каждая версия видео разделяется на несколько частей, называемых пакетами.

Пакеты преобразуются в радиоволны, которые в свою очередь, при помощи Wi-Fi или мобильного интернета, отправляются дальше.

1. Доставка на сервер YouTube

Когда сигнал достигает вышки сотовой связи или маршрутизатора, то при помощи проводного соединения он — передается на сервер YouTube !

1. Повторная сборка и хранение

Сервер YouTube получает пакеты, собирает их обратно в видео и сохраняет в одном из центров обработки данных Google.

Что происходит при Просмотре ?

Каждую минуту пользователи сети делятся в Твиттере более 700 видероликами

1. Пользователь нажимает на «плей»

Когда кто-то, намереваясь посмотреть тот или иной ролик, нажимает на «плей», то запрос по сети направляется на сервер YouTube.

1. Видео разделяется на части

YouTube выбирает наиболее подходящий для браузера пользователя формат видео и вновь разделяет его на пакеты.

1. Видео доставляется зрителю

При помощи проводного или беспроводного интернет-соединения пакеты доставляются на компьютер (планшет, телефон и т.д.) пользователя.

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

Если интернет-соединение слишком медленное, то видео временно не проигрывается — происходит его буферизация — до тех пор, пока не будет доставлен следующий видеопакет.

Платформа Видеохостинга : ↓↓↓

1. Apache
2. Python
3. Linux (SuSe)
4. MySQL
5. динамический компилятор Python (имеет высокую производительность)
6. веб-сервер lighttpd или «лайти», который пришел на смену Apache

Форматы

С момента создания все ролики на хостинге YouTube располагаются в формате более известном как — Adobe Flash Video Или же HTML 5

• Как известно flv-ролики оптимально подходят для воспроизведения онлайн, поскольку сохраняют высокое качество при небольших размерах .

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

К числу наиболее популярных относятся: ↓↓↓

• QuickTime от компании Apple проигрывает видео с расширением .mov
• RealMedia – популярный плеер от разработчика RealNetworks воспроизводит формат .rm
• Microsoft Windows Media – всем известный проигрыватель, который позволяет просматривать ряд потоковых мультимедиа со следующими расширениями: .wma для аудио, .wmv для видео и .asf для потокового видео формата Advanced Streaming
• Adobe Flash Player работает с популярным форматом f.l.v. а также предназначается для воспроизведения анимированных файлов, которые имеют расширение .swf

Формат видеофайла Flash Video обладает 2 плюсами которые выделяют его среди прочих мультимедийных форматов : ⇓

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

2) — Для проигрывания таких видео необходимо приложение JAVA- а не устанавливаемый отдельно видеопроигрыватель

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

Ютуб принимает видеофайлы в формате : ↓↓↓

Посетители загружают на сервер собственные видеоролики в любом из перечисленных форматов, а Ютуб уже конвертирует их в формат f.l.v.

Алгоритмы !

Алгоритм YouTube — это автоматизированная система, которая определяет то, какие видео увидит пользователь, зайдя на сайт.

Следует выделить шесть ключевых мест, где алгоритм влияет на то, какие именно видео вы увидите: ↓↓↓

1. Результаты поиска
2. Раздел «Рекомендации»
3. Главная страница
4. Раздел «В тренде»
5. Раздел, отображающий подписки пользователя
6. А также любые установленные вами уведомления.

→ «Основная цель YouTube — помочь пользователям найти те видеоролики, которые они ищут»

Поисковая Система ранжирования YouTube основывается на том, как аудитория взаимодействует с видео.

Искусственный интеллект «ежедневно изучает более 80 миллиардов байт обратной связи с пользователями, что позволяет предоставлять правильные видео в правильное время».

В широком смысле такая обратная связь с аудиторией включает информацию о том: ↓↓↓

• Что они смотрят (и не смотрят)
• Сколько времени они тратят на просмотр видеороликов (время просмотра)
• Сколько времени они тратят на просмотр видеороликов в каждое свое посещение YouTube (время сессии)
• Лайки, дислайки и отметки « его подобное не интересует »

Сервера

Интернет-серверы : ↓↓↓

1. Net.Scalar. предназначен для сбалансированной нагрузки а также кэширования постоянной информации
2. Apache в связке с mod.fast.cgi.
3. Запросы проходят маршрутизацию с целью обработки сервером программ на Python.

Видеообслуживание : ↓↓↓

1) В стоимость обслуживания включена:

• пропускная способность видеоканала
• аппаратное обеспечение
• и потребление энергии.

2) Все ролики принимается маленьким кластером.

Все видеоролики обслуживается больше чем 1 компьютером.

Что означает использование кластеров . :

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

Ключевые моменты видеообслуживания : ↓↓↓

1. Все операции просты и понятны.
2. Простой сетевой путь. Между контентом и конечным пользователям находится относительно небольшое количество компьютеров и прочих девайсов. Маршрутизаторы, коммутаторы и другие устройства могут не справиться с такой нагрузкой .
3. Использование недорогого стандартного оборудования. Чем дороже используемое оборудование, тем дороже любые предоставляемые услуги. Кроме того, в таким случае вероятность найти нужную информацию в сети снижается.
4. Использование простых универсальных инструментов. Большинство используемых инструментов встроено в Linux и надстроено над ними.

Использование миниатюр (картинок) :

• Удивительно тяжело сделать все грамотно.
• Для каждого видео используется 4 миниатюры. То есть миниатюр больше, чем видео.
• Миниатюры хранятся лишь на нескольких компьютерах.

Базы данных

Ранее Для хранения таких метаданных, как: пользователи, теги и описания использовалась система MySQL .

Стратегия центра обработки данных : Конспект

1. Использование провайдеров управляемого хостинга на первом этапе. Это единственный возможны вариант при жизни за счет кредитных карт.
2. Управляемый хостинг не может подстроиться под вас. Вы не сможете контролировать оборудование или создавать благоприятные сетевые соглашения.
3. Поэтому они заключили соглашение о совместном размещении. Теперь они могут настраивать все по своему собственному смотрению и обсуждать свои собственные соглашения.
4. Использование 5 или 6 центров обработки данных плюс сеть доставки данных.
5. Видео выпускается из любого центра обработки данных. Отсутствует соответствие по ближайшему расположению или чему-либо еще. Если видео достаточно популярно, оно перемещается в сеть доставки данных.
6. Зависимость от широты частоты сигнала, а не времени запаздывания. Может отправляться из любой колокации.
7. Для изображений время запаздывания имеет значение, особенно когда у вас 60 изображений на одной странице.
8. Изображения дублируются в разные центры обработки данных при помощи системы управления данными типа BigTable Код анализирует различные показатели, чтобы узнать, кто находится ближе всего .

Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?

Платформа

• Apache
• Python
• Linux (SuSe)
• MySQL
• psyco, динамический компилятор Python→C
• lighttpd для видео

Что внутри?

Статистика

• Поддержка обработки более 100 миллионов видеороликов в сутки
• Сервис был запущен в феврале 2005 года
• В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
• К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
• Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных

Рецепт управления огромными темпами роста

Этот цикл проходит далеко не одну итерацию ежедневно.

Веб-серверы

• NetScalar используется для балансировки нагрузки и кэширования статического контента.
• Apache работает с включенным mod_fast_cgi
• Запросы отправляются на обработку с помощью серверного приложения на Python.
• Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
• Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
• Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
• Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
• На формирование страницы обычно уходит не более 100 миллисекунд.
• psyco, динамический компилятор Python→C, использует JIT подход к компилированию для оптимизации внутренних циклов
• Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
• Какая-то часть заранее сгенерированного HTML хранится в кэше.
• Кэширование данных в СУБД на уровне строк.
• Кэшируются полностью сформированные объекты Python.
• Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.

Управление видео

• Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
• Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
• Использование кластеров влечет за собой: – увеличение производительности пропорционально количеству дисков, на которых расположен контент; – возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров; – возможность организации создания резервных копий online.
• В роли HTTP-сервера для работы с видео используется lighttpd: – Он способен дать фору Apache в плане производительности предоставления статического контента; – Для работы с событиями ввода-вывода используется epoll; – Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
• Самая популярная часть контента размещается в CDN –CDN реплицирует весь контент в разных частях системы; – Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
• Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation: – Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках; – В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств; – Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность; – Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.

Ключевые моменты

• Чем проще – тем лучше;
• Старайтесь минимизировать количество устройств (маршрутизаторов, коммутаторов и тому подобных) между контентом и пользователями: далеко не факт, что все они будут способны выдерживать интенсивную нагрузку;
• Старайтесь использовать самое обыкновенное оборудование. Hi-end оборудование обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождение решения той или иной проблемы с оборудованием в Сети;
• Используйте самые простые распространенные утилиты. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе;
• Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.

Управление миниатюрами видео

• На удивление сложно решаемая задача, особенно если необходима эффективность;
• Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
• Миниатюры хранятся всего на нескольких компьютерах;
• Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов: – Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode‘ов файловой системы; – Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе – не самая лучшая идея; – Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов; – В условиях таких нагрузок Apache показывает плохую производительность; – Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20; – Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность; – С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов; – Перезагрузка занимала 6-10 часов, так как кэш должен был "разогреться" прежде чем перестать использовать данные с жестких дисков.
• Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google: – Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе. – Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети. – Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.

Базы данных

• Раньше: –MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее. – Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков; – Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день. – Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре. – Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них. – Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации. – Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации. – Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
• Сейчас: – Используются распределенные базы данных; – Сегментированная система (прим.: по аналогии с Flickr); – Распределенные чтение и запись; – Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками; – Такая архитектура привела к 30%-й экономии на оборудовании; – Задержки в реплицировании сведены к нулю; – Размеры базы данных могут расти практически неограниченно

Стратегия размещения в датацентрах

• Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
• Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
• Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
• Было использовано 5 или 6 разных датацентров в дополнение к CDN .
• Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным – он перемещается в CDN .
• Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
• Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
• Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.

Подводим итоги

• Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
• Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
• Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
• Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
• Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
• Постоянная работа над поиском и устранением узких мест в системе:– на программном уровне это чаще всего бывает кэширование и работа с СУБД; – на уровне операционной системы – операции ввода-вывода; – на уровне оборудования – оперативная память и RAID массивы.
• Залог Вашего успеха – командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.

Источники информации

В отличии от остальных, этот перевод статьи от Todd Hoff’а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:

nslookup www.youtube.com 8.8.8.8
Каждый раз выдаёт другой ip-адрес.

Различные DNS выдают разные адреса, некоторые списком, некоторые по одному.

• Вопрос задан более года назад
• 2755 просмотров

То есть даже для youtube.com ip разный. В вопросе был www.youtube.com

Разумеется он разный. Очень мало шансов что вам выпадет один и тот же.
www.youtube.com и youtube.com это одно и тоже, и никак на адрес не влияет.

И не понято, какой же всё-таки полный список ip

Это называется балансировка по DNS

DNS сервер отдает пользователю нужный адрес исходя из нагрузки на конкретный сервер, региона, и.т.д.

Самих серверов у крупных компаний тысячи, IP адресов тоже может быть много.