Прошла пара лет с тех пор как я работал в провайдере/операторе услуг по доставке контента (CDN). Название компании не важно, однако, по "джентельменскому" договору срок "типа секретности" уже прошёл. Можно говорить. Вот, собственно, обзорная статья на эту тематику.
Итак, что же такое CDN?
Как ни странно - это то, как и переводится с английского - сеть, как правило распределённая регионально, доставки контента пользователю.
Какие очевидные выигрыши она несёт?
Из очевидных вещей - разгрузка источника контента и хранение кэша в наиболее близкой для потребителя географической точке. Зачем? да всё просто - чтобы потребитель получал свой контент с наименьшими задержками. Это для обычного http-траффика, что же касается, например, поточного вещания - то пользователь получает более устойчивую картинку, а медиапоток реже срывается и чаще проигрывается на наиболее выском качестве (при мультибитрейте). Кроме того, если CDN сторонний, то есть возможность сбрасывать в него только пики нагрузки, поддерживая при этом минимально-комфортную ширину канала (каналы стоят дорого) и экономя на конечном оборудовании и его обслуживании.
Самый "вкусный" вопрос - как оно устроено?
О, это действительно довольно интересный вопрос! И, пожалуй, тут я себе позволю расписать несколько разных вариантов на тему.
Итак, начнём с наиболее знакомого и наиболее "жлобского" варианта (максимальная экономия).
Сеть - естественно, это сети крупных провайдеров, держащих свои ДЦ, напр. Мегафон, Центральный телеграф, и тд и тп в т.ч. региональные компании. Бэкбона как такового - нет, всё гоняется по одним каналам с абонентским и клиентским траффиком. Пиринговые отношения с провайдерами интернетов для "хомячков" - крайне слабые, рудиментарные.
Оборудование - тут как правило без своего не обойтись, так как многие вещи упираются в дисковую подсистему, а она (несмотря на заявления многих представителей профильных "железных" компаний) виртуализируется крайне фигово, драгоценные IOPS-ы в поцессе виртуализации теряются. SSD почти не применяются, ибо дорогвато. Часть оборудования - виртуалки - это DNS-серверы прежде всего и всяческие API для клиентов. Иногда виртуализации подвергается часть серверов поточного вещания - мультиплексирующие клиентские rtmp-потоки прямых трансляций.
Сервисы - как правило сами сервера "универсальные" - то есть они используются как под поточное вещание (rtmp|rtsp|hls hds) так и под веб-кэши и стримовые сервера для flv и mp4 файлов. На этих же серверах сидят и DNS.
Балансировка ведётся только средствами DNS - view-шки по регионам/провайдерам и тд.
Соответственно, качество сервиса "так себе", такой CDN вполне можно использовать для распространения (кэширования) mp4 и flv роликов или больших файлов. В виду того, что на нодах крутится разное ПО, задержки такого CDN весьма варьируются, поэтому для поточного вещания такая сеть не подходит, также как и для "быстрого" веб-траффика (сайт не ускоришь).
Более-менее нормальный CDN (в основном крупные забугорные - Akamai, L3, CDNetworks) предпочитают не жлобиться на инфраструктуре, потому что понимают перспективность таких вложений, в них всё устроено несколько по-другому.
Сеть - есть своя backbone-сеть, для внутреннего и служебного траффика, мало того, есть свои AS (автономные системы) то есть вопросы маршрутизации они держат в своих руках. Пиринговые отношения с провайдерами услуг интернета - довольно тесные, вплоть до полноценного присутствия в сетях крупных ISP.
Балансировка - anycast + DNS + LVS. Из архитектуры сети и возможностей маршрутизации проистекает и возможность балансировки запросов от клиентов методами не только view-шек DNS, но и anycast-ом. А на каждом IP-адресе вешается балансировщик, позволяющий отправлять запросы клиентов разным серверам, в том числе для отказоустойчивости.
Естественно, ни о каких "универсальных" нодах речи нет, также как и о виртуализации некритичных сервисов. Есть сервера, закачивающие контент (промежуточные кэши), есть сервера для раздачи "быстрого" контента, в том числе и промежуточные мемкэши и фронты. Есть промежутчные "хранилки" для медленного или большого контента и, в комплект к ним, стримящие фронты и раздающие фронты. Есть сервера - начальные мультиплексоры (на которые заказчик публикует поток), промежуточные мультиплексоры и оконечные мультиплексоры. В случае если на выходе нужен hls, hds или sliverlight-стриминг, оконечными серверами, как правило, являются веб-кэши для быстрого контента.
Вобщем-то, такая архитектура позволяет CDN-у выдерживать чудовищные нагрузки без опасности аффекта всех клиентов и заказчиков сети, либо, если это частный CDN - то более рационально использовать возможности оборудования на максимальных нагрузках, обеспечивая при этом высокий уровень качества обслуживания (разброс задержек, количество срывов потоков).
С технической стороны:
Веб-кэши - это nginx, ибо у этого сервера есть всё что нужно для кэширования и проксирования запросов, также к нему можно написать свои модули, в том числе по запросу закачивающие в кэш нужный контент, чистящий определённые сущности в кэше, собирающие статистику ( и, например, кладущие её прямо в mongo-базу) и тд + коммерческая поддержка со стороны производителя.
L3 исторически разработала для себя свой велосипед свой nginx свой веб-сервер.
Стримящие сервера - во многих случаях это либо что-то своё (как правило на основе чего-то готового вроде red5 или чего-то в этом духе) либо просто Wowza Media Server.
Сервера, на которые публикует свои потоки заказчик - как правило Adobe FMS.
Сервера хранения - тут кто во что горазд - это и объектные хранилища на вроде hadoop или mogilefs и огромные фс на вроде Lustre или набирающая популярность Gluster. Также в некотором роде популярными являются OpenStack-овые хранилища Swift, хотя это довольно новомодное явление, пока не получившее широкого распространения из-за своей сырости.
Транскодеры - тут классика жанра - это как правило ffmpeg с довольно большой самописной обвязкой (следящее ПО, чтоб демон по памяти не зажрался, менеджер очереди заданий и тд.)
Статистика. Здесь тоже, как правило, кто во что горазд, всё сильно зависит от методик тарифообразования и схем биллинга. Однако есть некоторые моменты от которых не уйдёшь. Учёт статистики с помощью netflow в большинстве случаев просто невозможен, т.к. объёмы траффика довольно велики и тратиться на такое большое количество оборудования на обсчёт (+ распараллеливание процесса) просто не рационально. Статистика ведётся по логам. Начиная с оконечных нод, где банально схлопываются повторяющиеся запросы (запросы на один урл с одного IP|подсети), далее агрегированные логи молотятся на спец-серверах, где выводится статистика для биллинга и для технических нужд.
Более детально о статистике - тут как правило имеется возможность построить график во времени для следующих показателей: количество запросов в ед. времени, количество клиентов (для поточного вещания), количество ошибок единицу времени (обрывы для потоков или 404|500|502 для http-сервера). Раскладка гафиков по гео-статистике. Коэфициент кэширования или коэфициент мультиплексирования (для поточного вещания) в определённый момент времени. Для внутреннего использования, как правило, собирается статистика о временах отклика для нелимитированных по скорости ответов для фронтов, для промежуточных серверов, временнАя статистика источников.
Своё API для взаимодействия с CDN - это необходимый мех-м, без которого cdn не существует. Как правило он позволяет почистить либо весь кэш либо выборочные объекты, произвести какие-либо настройки и даже инициировать закачку файла с источника для предварительного кэширования его на нодах в cdn.
В общих чертах вроде всё. Если вдруг возник более глубокий интерес по этой тематике, добро пожаловать в джаббер, на slackware-current@conference.jabber.ru :)