Наверх ▲

CDN в России: от теории - к практике

Ярослав Городецкий Ярослав Городецкий Генеральный директор CDNvideo. В Интернете и телекоме с 1996 года. Обожает придумывать и запускать новые продукты и услуги.

Ярослав Городецкий: Итак, меня зовут Ярослав Городецкий. Я представляю компанию CDNvideo. Мой доклад называется «Как мы строим CDN в России».

 

Что такое CDN?

CDN расшифровывается как Content Delivery Network (сеть доставки контента). Она используется для того, чтобы раздавать контент большому числу пользователей, находящихся в разных городах, в разных странах, на разных континентах, быстро и более качественно, чем если бы контент раздавался из одной точки. Это территориально-распределенная сеть серверов.

Конференция посвящена высоконагруженным приложениям. Поэтому в терминологии трехзвенной архитектуры HighLoad CDN соответствует уровню серверов front-end – серверов, с которых контент раздается конечному пользователю.

Сети доставки контента могут быть частными. У крупных контент-провайдеров (таких, как Google, Yandex, Mail.Ru, Facebook, VKontakte), как правило, есть собственные CDN, которые служат только для распространения контента этих крупных контент-провайдеров.

Также в мире и в России есть операторы CDN, которые построили свои собственные CDN и предоставляют свои ресурсы в пользование всем желающим.

Как работает CDN?

Наверное, многие и так это знают, но все-таки повторим основы.

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

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

Как воспользоваться CDN?

Сначала вы выстраиваете взаимодействие с CDN-провайдером. Доставлять через сеть CDN можно видеоконтент, данные, статический веб-контент, любые приложения, дистрибутивы приложений и так далее. Этот контент распространяется по всем серверам CDN и отдается конечным пользователям.

Для распространения контента внутри сетей CDN и для забора контента от контент-провайдера, как правило, используется протокол HTTP. На самом деле, все эти сервера являются кэширующими HTTP-серверами. Для потокового видео используются протоколы RTMP/RTSP и другие подобные протоколы, обеспечивающие потоковую передачу данных (англ. Streaming).

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

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

Как правило, CDN используется для раздачи «тяжелого» контента (видео, аудио, фотографий, flash-анимации, CSS/JavaScript, клиентов игр и так далее).

В одном из сегодняшних докладов говорили о том, что CSS/JavaScript можно ужать на 40-50%. Это и в самом деле актуальная проблема. Для стабильной работы веб-сервисов требуется быстрая отдача CSS/JavaScript конечным пользователям. Можно ужимать, а можно использовать CDN для повышения скорости отдачи CSS/JavaScript конечным пользователям.

Как строить CDN?

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

Сетей CDN в мире достаточно много. Тема CDN развивается с 1998-го года, когда появился один из первых высоконагруженных сайтов – CNN. Наверное, это один из первых высоконагруженных сайтов, который не принадлежал технологической компании. На тот момент нагруженные сайты были у Microsoft и у поисковых систем.

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

Тогда появилась компания Akamai, которая решила эту проблему за CNN, расставив серверы по всему миру.

Какими бывают CDN?

Они различаются:

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

Как расставить серверы сети CDN таким образом, чтобы обеспечить наилучшее среднее качество для всех пользователей?

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

Что такое Интернет с точки зрения интернет-провайдеров, а не обывателя? Обычный человек полагает, что Интернет – это "облако". На самом деле, часть Интернета – это граф связанности нескольких интернет-провайдеров (российских и зарубежных). Я взял эти данные с очень хорошего ресурса rolltex.com, где можно для каждого интернет-провайдера получить такую карту связанности.

Когда вы строите CDN, вам нужно понять, где именно, у каких провайдеров есть ваши пользователи, и поставить туда свои серверы. Это один подход. Его использовала, в частности, компания Akamai. Этот же подход используем в своей деятельности мы.

Есть и другой вариант. Провайдеры, как правило, обмениваются между собой трафиком через Internet Exchange. Это точки бесплатного обмена трафиком. Их достаточно много в Европе. В Штатах их мало, потому что там обмен трафиком, в основном, платный. В России точки бесплатного обмена развиваются с переменным успехом. Московский Internet Exchange достаточно большой. Питерский Internet Exchange раз в 10 меньше московского.

Таким образом строит свои сети CDN ряд других провайдеров. Среди них – LimeLight (это основной западный конкурент Akamai) и российский интернет-провайдер NGENIX. Этот подход хорош тем, что вроде бы можно охватить большее количество провайдеров с одного узла. Но есть определенная проблема – такой подход требует достаточно приличных затрат на сетевое оборудование.

Третий подход. Если вы представляете магистрального оператора связи, то вы тоже можете построить сеть CDN. Чтобы получить CDN, по разным точкам сети нужно расставить серверы, но при этом в каких-то точках вы покупаете трафик, в каких-то – продаете.

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

Теперь поговорим о классификации CDN по способам распределения нагрузки. Их несколько.

Наиболее часто используемый – это балансировка нагрузки при DNS-запросе. Пользователь направляет DNS-запрос на CDN с каким-то заданным именем. CDN отдает IP-адрес в ответ на запрос того сервера, который ближе к пользователю.

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

Есть еще пара способов. Подстановка URL при генерации HTML-страницы. Есть такой способ, как Anycast, когда ответы посылаются на ближайший сервер. У всех серверов один и тот же IP-адрес. Грубо говоря, какой сервер получил запрос первым, тот и ответит на этот запрос.

Какой из этих способов лучше?

DNS используют почти все. Тем не менее, у него есть одна существенная проблема. Есть пользователи, которые пользуются чужими DNS (например, Google DNS 8888). Для них балансировка нагрузки вообще не будет работать. Они будут перенаправляться на тот сервер, который находится ближе к Google, а не к их интернет-провайдеру. В результате выигрыша от использования CDN они не получат. По нашим данным, местоположение около 10% запросов определяется неправильно.

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

Подстановка URL требует много серверных ресурсов. Anycast не всегда правильно работает с TCP, потому что при каких-то сетевых изменениях реальный сервер, который находится ближе, может поменяться.

Другой способ классификации CDN – по тому, как распространяется контент внутри самой сети CDN.

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

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

Последний вариант – одноранговая сеть (англ. peer-to-peer, P2P). Распространение контента в CDN осуществляется по принципу P2P. Серверы загружают контент друг другу, аналогично тому, как это делается в торрентах.

Такой способ использует одна известная академическая CDN (Coral CDN), а также некоторые провайдеры потокового вещания в интернет, те, кто делает возможной видеотрансляцию для большого числа пользователей. Пользователи перенаправляют запросы и тоже участвуют в распространении видеоконтента.

На западе есть компания Octoshape, которая этим занимается. В России примером такой компании можно назвать Lavina.TV.

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

Первый способ – по географии. Самый понятный, интуитивный способ. У нас есть сеть CDN. Например, можно поставить сервер в Новосибирске, и все пользователи из Новосибирска по этой GeoIP-базе направляются на этот новосибирский сервер.

Но, к сожалению, такой подход не работает в большинстве случаев. Многие интернет-провайдеры имеют между собой сложные взаимоотношения, между ними идут так называемые "пиринговые войны". Очень часто бывает так, что провайдеры из одного и того же города "тянут" трафик через другой город (а то и через другую страну) между собой.

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

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

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

Если вы работаете с региональными провайдерами (в России, по крайней мере), как правило, у всех них есть некая база данных локальных адресов, которую они ведут. Это тоже полезная вещь.

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

Как мы строим CDN?

Теперь я расскажу о нашем опыте построения сети CDN. Мы находимся в России, хотя работаем и в СНГ, и за его пределами. Но наша основная цель – построить CDN для русскоязычного интернета. У российского интернета есть ряд особенностей. Они перечислены на слайде, не будем их зачитывать.

Суть в том, что в России много провайдеров, при этом трафик достаточно сильно сконцентрирован в Москве. Провайдеры не любят друг друга и ведут "пиринговые войны". Наша особенность: помимо сетевых параметров, дополнительно надо учитывать стоимость трафика для конечного пользователя. Где-то он до сих пор не бесплатен, безлимитные тарифы все еще есть не везде.

Исходя из всех вышеперечисленных причин, мы избрали свой способ построения CDN (он описан на слайде). Сеть CDN строится на сетях интернет-провайдеров с использованием DNS, для нахождения кратчайшего пути до пользователя применяются данные о сетевой топологии и интегральные метрики.

Теперь я скажу несколько слов о том, какие услуги предоставляют CDN-провайдеры.

Это кэширование HTTP-контента:

  • статические файлы;
  • динамический долгоживущий контент.

Потоковое вещание видео/аудио:

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

Также CDN может предлагать услуги по защите контента. Можно ограничить доступ контенту, предоставляя его только тем пользователям, которые авторизованы данным провайдером. Здесь используются одноразовые ссылки на контент, можно делать авторизацию каждого запроса на стороне контент-провайдера. Только для flash-видео можно также подписывать flash-плеер и, соответственно, давать доступ только тем, кто имеет flash-плеер, загруженный с сайта контент-провайдера.

Как правило, в CDN есть интерфейс программирования приложений (API) для управления услугами, которые позволяют очистить кэш для статического контента при списании этого контента. Например, нужно срочно удалить файл с сайта, а если он уже попал в CDN, то, соответственно, со всех CDN-серверов. Также можно посмотреть статус услуги (сколько у того или иного видеопотока просмотров, сколько его просматривали раньше), проверить, не близок ли порог возможности CDN.

Мы составили памятку касательно того, как подключиться к CDN. Это общие рекомендации для всех CDN-провайдеров.

  1. Прежде всего, надо договориться с CDN-провайдером о том, где ему брать контент, который нужно распространять через CDN. Надо сообщить ему, где находится тот самый сервер, где есть этот контент.
  2. Получить ссылку для доступа к своему контенту, который потом размещается на своем сайте, в flash-плеере, в виде ссылки на HTML, в виде каких-то ссылок приложений для мобильных устройств или социальных сетей.
  3. Можно замаскировать CDN, сделав CNAME-запись в своем домене, который ссылается на CDN.
  4. Можно оставить ссылку на размещенный в CDN контент на сайте, в приложении, во flash-плеере и так далее.
На этом все. Спасибо за внимание! Жду ваших вопросов.

Вопросы и ответы

Вопрос из зала:
Вопрос относительно отказоутойчивости. Предположим, что один из серверов CDN по каким-то причинам "умер". Вы маршрутизируете посредством DNS. DNS-запросы кэшируются у пользователей, они никак не могут узнать, что надо "ходить" уже в другое место. Как вы это решаете?
Ярослав Городецкий:
Если объем кэширования равен нулю, например. Тогда, соответственно, время на кэширование DNS равно нулю. Пользователь не будет кэшировать данные от DNS.
Вопрос из зала:
Это создает какие-то задержки – небольшие, но лишний запрос каждый раз.
Ярослав Городецкий:
Да. Но поскольку серверы расположены близко к пользователям, задержка минимальна.
Вопрос из зала:
Представьте, что у меня очень много контента (миллиард файлов) с каким-то очень длинным "хвостом", на который редко идут запросы. Как обычно раскладывается контент по CDN? Я как владелец контента говорю: «Разложите все мои файлы» - или это делается по запросу от пользователя? Пользователь пришел на сервер, там увидели, что файла нет, сходили ко мне, забрали, отдали пользователю.
Ярослав Городецкий:
Вообще CDN больше предназначена не для "длинного хвоста", а для популярного контента, на который много раз идет запрос от пользователя. Поэтому по умолчанию используется по запросу. Есть необходимость показать тот или иной контент пользователю – только тогда этот контент забирается с сервера контент-провайдера, и все следующие запросы идут сразу уже с CDN.
В принципе, возможен и вариант, когда вся библиотека контента сначала загружается в CDN. Это больше для «тяжелого» контента, если нужно библиотеку фильмов, например, показывать. Фильмы загружаются долго. В стандартном варианте делается взаимодействие по запросам.
Вопрос из зала:
Большинство хостингов в России предоставляет бесплатный трафик. Почему в российских CDN надо платить за трафик? Можно по тем же самым городам сделать его бесплатным.
Ярослав Городецкий:
Вы про нас говорите?
Вопрос из зала:
И про вас тоже.
Ярослав Городецкий:
Надо за что-то платить. Самый простой честный способ посчитать затраты CDN на то, что этот трафик берется из одного места, доводится по всем серверам и дальше раздается с разных серверов географически распределенных, - это тарифицировать по трафику.
Но, в принципе, мы предлагаем и другие варианты. Для распределения потокового видео у нас есть фиксированные тарифы по количеству одновременных подключений. Тогда это бесплатно.
Вопрос из зала:
Вопрос по поводу того, что построено у нас. Спрошу как человек, которому знакома тема видео. Какова скорость забора информации от клиента. Если я клиент CDN, и у меня есть видеофайл, насколько быстро вы можете его доставить через себя к абонентам?
Второй вопрос. Какая сеть на данный момент имеется? Какая география, мощность?
Ярослав Городецкий:
Первый вопрос. Это во многом зависит от ширины вашего канала. У нас достаточно широкие каналы. Мы делаем в виде трансляций, каких-то мероприятий. Там это проблема. Чтобы показывать видеопоток в хорошем качестве, нам нужно, чтобы у контент-провайдера, который транслирует мероприятие, был достаточно приличный канал в Интернете, и при этом хорошего качества.
По географии. У нас сейчас сеть развивается, к концу года будет 7 городов. Сейчас – Москва, Питер, Екатеринбург, Новосибирск, Киев, Западная Европа.
Вопрос из зала:
Как быстро вы сможете среагировать, если мы скажем, что у нас будет серьезная нагрузка. Вы сможете расширить возможности для наших требований?
Ярослав Городецкий:
В принципе, мы не лимитируем. Конечно, да, все возможно.
Вопрос из зала:
Сколько – месяц, два?
Ярослав Городецкий:
Меньше месяца.
Вопрос из зала:
Не совсем удобно, что Akamai можно использовать по всему миру, а в России надо идти в вашу сеть. Как можно решить эту проблему? Существует ли возможность интеграции?
Ярослав Городецкий:
Да, да, существует. Подходите, в кулуарах я вам расскажу об этом.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Александр Шигин

Александр Шигин

SRE в Google, Дублин.

Александр Шигин (Rambler) рассказывает о распространенных методах и ошибках тестирования.

Дмитрий Сатин

Дмитрий Сатин

Советник министра в Министерстве связи и массовых коммуникаций Российской Федерации, евангелист юзабилити

Довольно интимный, интроспективный доклад о самомотивации не для всех. Дмитрий Сатин объясняет, "как не стереться в пыль".

Станислав Богатырев

Станислав Богатырев

Ведущий системный администратор облачного хостинга виртуальных ресурсов и систем хранения данных Clodo.

Станислав Богатырев (Clodo) делится опытом создания облачного хранилища для разных данных, в том числе бинарных.