Все на одного или как мы построили CDN

    Среди высоконагруженных (highload) систем существует большая разница между системами с высокой нагрузкой в плане количества запросов в секунду (RPS, requests per second) и высокой нагрузкой в плане генерируемого трафика (того, который меряется гигабитами в секунду). В нашем ivi.ru нагрузка есть и та, и другая. Сейчас я хочу рассказать про то, как мы генерируем сотни гигабит в секунду, и никому от этого не плохеет.



    Мечты о велосипеде


    Летом 2011-го года случилось страшное: рунету так понравилось смотреть бесплатное кино, что рост нагрузки некоторое время обгонял рост мощностей. Всё это шло в каналы единственного провайдера из единственного московского датацентра. Доходило до того, что некоторые московские же абоненты получали кино через Амстердам. Понятно, что в таких условиях бороться за звание дома высокой культуры быта лучшего интернет-кинотеатра России достаточно проблематично. Было принято волевое решение использовать CDN (Content Delivery Network, сеть доставки контента), и всё завертелось (включая моё скромное участие).

    Когда мы хотим донести до пользователя несколько мегабит видео-трафика, у нас есть две фундаментальные проблемы (проблем, конечно, больше, но они не носят такого фундаментального характера):

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

    Протокол TCP настаивает, что чем больше время оборота пакета (RTT, return-trip-time), и чем больше потери пакетов (packet loss), тем меньше скорость передачи данных. Опять же, междугородние магистральные каналы – самые дорогие, а значит – забитые. Как следствие – вероятность потери пакетов увеличивается с увеличением расстояний. Соответственно, нам, с нашим HTTP (работающим поверх TCP) надо держать серверы поближе к абонентам.

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

    С другой стороны, строительство своего CDN имеет три основных недостатка:

    1. Надо научиться его строить
    2. Придётся работать со множеством поставщиков (вместо одного, ладно – двух, оператора CDN)
    3. Поддерживать, развивать и умощнять придётся самим.

    Но так ли это страшно на самом деле?

    Велосипедная фабрика


    Большинство операторов коммерческих CDN предлагает бесплатное (или за разумную денежку) тестирование. И мы этой возможностью воспользовались. Международные операторы CDN удивили тем, что могли отправить абонента из, скажем, Новосибирска на сервер где-нить в Южной Америке. И, разумеется, серверных мощностей на территории России (а мы за рубежом кино не показываем), у них на тот момент не было. Справедливости ради скажу, что сейчас некоторые из них ставят сейчас свои узлы у нас в стране. А про Южную Америку мне потом специалист другого отечественного оператора CDN разъяснил. В поражённых западным капитализмом сетях другая цель балансировки – они считают, что каналов связи хватает. У них ограничителем является серверная мощность. Вот и балансируют туда, где сервера посвободнее…

    И зарубежные, и отечественные CDN в итоге показали уровень качества (под которым мы понимали эффективную скорость закачки контента конечным пользователем), сопоставимый с тем, что мы могли сделать сами уже в тот момент. А вот по ценам всё оказалось далеко не так радужно, как в теории. Понимаете теперь, почему ни названий компаний, ни цифр замеров, здесь не будет?

    Кстати, уже в этом году вышло исследование «State of the Union: Ecommerce Page Speed & Web Performance» (доступное, например, тут) – что использование CDN замедляет загрузку сайта. Тут, как говорится, совпало. О том, почему это происходит, я планирую написать отдельно.

    Ну да ладно, возвращаемся к нашему CDN. Стало очевидным, что сеть должна быть своя. Как её построить – вот стал основной вопрос. Но тут нам повезло. Во-первых, оказалось, что архитектура серверов на нашей центральной площадке уже тогда разделялась на edge- (пограничные) и origin-серверы (исходные). А edge-серверы, как оказалось, очень неплохо выносились на внешние площадки.

    Во-вторых, оказалось, что провайдеры знают такой ресурс как ivi.ru, и в большинстве своём хотят работать с нами, чтобы локализовать трафик. В заметном количестве случаев операторы сами выходили на контакт и предлагали сотрудничество. Это, безусловно, помогало в работе по строительству новых узлов. В нескольких регионах представители местных провайдеров мне прямо говорили: «Для нас качество, с которым смотрится ivi.ru – важное конкурентное преимущество».

    В-третьих, выяснилось, что нам ничего из дополнительной функциональности, предлагаемой провайдерами CDN, не нужно. Не нужно перекодирования контента «на лету» (весь контент заранее закодирован во всех возможных вариантах). Не нужно экзотических протоколов, вроде RTMP (у нас всё по HTTP, и даже новомодный HLS – это HTTP). Не нужно толстого канала с QoS до Москвы (для управления узлом и обновления кэша достаточно «обычного» интернета в количестве 50-100Мбит/с), даже падение такого интернета не останавливает обслуживание абонентов. Не нужно «распасовщика» и «запатентованных алгоритмов балансировки» (это сейчас расписывать не буду, оставлю для другой статьи).

    В итоге мы смогли в очень сжатые сроки развернуть собственный CDN по всей территории страны.



    В результате этой работы сейчас узлы ivi.ru присутствуют в 23 городах России. Если честно, после 20 мне уже неинтересно стало пересчитывать, новые узлы появляются постоянно. Само развёртывание нового узла занимает один рабочий день. Размеры узлов колеблются от одного до восьми серверов. На многосерверных узлах, само собой, стоит ещё и сетевое оборудование: cisco серий 3750X или 4500-X. На части узлов серверы подключаются аггрегированным линком 4 * 1 GbE (это узлы малого и среднего размера). На крупных узлах серверы подключаются 10GbE интерфейсами.

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

    Более половины генерируемого ivi.ru трафика сейчас генерируется узлами вне Москвы. Интересно суточное колебание (график показывает отношение сгенерированного в регионах трафика к суммарному, время московское).

    image Кликабельно:



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

    Локализация трафика на узле колеблется от 40% (маленькие односерверные узлы) до 90% (на самых крупных узлах). Без сомнения, это не могло не сказаться на качестве обслуживания абонентов. Вот красивый график:



    Свежие данные приводить не буду – они уже давно колеблются на уровне статистической погрешности, и такой красивой «ступеньки» там уже не увидеть.

    Эта статья задумывалась как обзорная про наш CDN. Следующим аспектом я планирую рассказать про балансировку нагрузки между городами и весями. А какие ещё аспекты нашего CDN вам были бы интересны?
    Онлайн-кинотеатр ivi
    79,00
    Компания
    Поделиться публикацией

    Комментарии 29

      +3
      Хороший почин, уже жду продолжения. И, как всегда, хочется больше деталей, тема-то интересная.
        +2
        Одна тема для продолжения намечена: гео-балансировка. Просите конкретику: каких деталей больше хочется? ;) Мы «будем посмотреть», кто из нас лучше какую тему опишет. :)
          0
          Например, было бы интересно почитать чем руководствовались при выборе оборудования/поставшика. Это ведь первое о чём задумываешься начиная любой проект. Одно дело слушать маркетологов на семинарах у которых всё хорошо, а другое услышать комментарии от людей которые используют оборудования каждый день для больших задач. Опять же интересно как реализуете масштабируемость и целостность данных.
            +2
            У меня есть много баек про не-cisco, которые я люблю травить в узком кругу. ;)
            Посмотрим, что мы сможем интересного рассказать. У нас по оборудованию, на самом деле, всё очень просто. Для затравки скажу, что у нас вообще нет балансировщиков. А как так вышло — это хорошая тема для отдельной статьи.
        0
        А как обеспечивается зарубежный трафик?
          +1
          Хочется ответить цитатой из оферты, но не буду. ;)
          На данном этапе ivi.ru обслуживает только российских пользователей. Поэтому тема зарубежного CDN для нас неактуальна.
            0
            А когда конец данного этапа и начало следующего?
              0
              Этот вопрос — целиком и полностью в руках акционеров. Такой информации у меня нет.
          0
          Читал ради технических подробностей, а о них тут почти ни слова.

          Интересует:
          Как выбирается к какому узлу отправлять абонента? На каком этапе?
          Как происходит скачивание новых данных на узлы? Используете ли p2p между узлами?
          Как система работает если на ближайшем узле фильма в кэше нету? Отправляете к другому узлу или пользователь ждет пока будет скачиваться фильм в кэш?
            +1
            Я ж говорю: это такая обзорная статья. Я её специально не стал в техническую сторону уводить.
            На первый вопрос скоро (ну, как шеф решит) отвечу статьёй. Остальные — принято, подумаем, как и кто распишет.
            Спасибо!
            +1
            Очень хочется прочесть про настройки отдающих серверов — какие hdd стоят, какие настройки ядра вы сделали, как живет nginx. Как файловый кеш. Может быть вы из ОЗУ все отдаете или с SSD? Если нет, то как HDD живут, эффективность файлового кеша.
            Если поделитесь инфой, буду крайне благодарен.
              0
              А вот по ценам всё оказалось далеко не так радужно, как в теории. Понимаете теперь, почему ни названий компаний, ни цифр замеров, здесь не будет?

              Ну тогда вы же считали, сколько у вас выходит полностью поддержка этого сервиса в месяц, со всеми расходами на сервера-каналы-инженеров-офисы-бухгалтерию-канцелярию-налоги-туалетную бумагу и т.д. и если это поделить на количество прокачиваемых GB в месяц, вы получите стоимость за GB. Озвучите её пожалуйста, ибо вы правильно писали про велосипед, без этих данных это конечно: интересно, своё, много серверов, настраивать и проектировать всё нужно, я как инженер это понимаю, здорово и все такое ) Но с точки зрения экономики это велосипед. Озвучит пожалуйста стоимость за GB в месяц.
                +1
                Считали, конечно.
                По моему рассуждению, такая информация — очень сильно конфиденциальная, а то и коммерческая тайна. Я узнаю наше отношение к этому вопросу, и если мне разрешат, тогда напишу.
                  –3
                  По моему рассуждению, такая информация — очень сильно конфиденциальная, а то и коммерческая тайна. Я узнаю наше отношение к этому вопросу, и если мне разрешат, тогда напишу.

                  Были на мастер-классе у Джейн Псаки?
                  0
                  По нашим подсчётам (считали в 2011 году) стоимость своей распределённой сети выходила в 10 раз дешевле, чем использование например CloudFront. Но я имею ввиду лишь стоимость аренды серверов после интеграции.
                  0
                  Когда можно ждать продолжения?

                  вопросы:
                  1. используете ли другие протоколы доставки кроме HLS (HDS, SmoothStreaming, MPEG-DASH)?
                  2. как организован транскодинг? (можно отдельной статьей)
                  3. в качестве edge-сервиса, использовали nginx или свое решение?
                    0
                    Продолжение — это как меня шеф выпустит на это дело. ;)
                    На два вопроса сразу отвечу:
                    1) нет. Сейчас у нас только HTTP/HLS
                    3) стримает, конечно, NGINX, но под ним логика своя написана, которая находит контент, ведёт учёт популярности контента и кластеризуется.

                    Оставшийся вопрос — это к кому-то другому. Я в этой теме совсем не ориентируюсь.
                    0
                    BGP anycast? Если да — сколько у вас узлов в Новосибе, например? Если серверов много — кто и как между ними распределяет контент?
                      0
                      Можно я сейчас не буду отвечать на первый и третий вопросы? ;) А то до следующей статьи дело не дойдёт. ;)
                      В Новосибе один узел, один из самых крупных региональных.
                      0
                      В поражённых западным капитализмом сетях


                      :):):)
                        0
                        А отчего не привели списка городов, где есть ваши узлы? И что означает цвет(синий и зелёный) на карте?
                          0
                          Зачем? Чтобы увеличить объём текста? Даже с моим знанием географии «на тройку» все города по карте узнаваемы. :)
                          Ну, ещё могу рекомендовать воспользоваться RIPE DB. У нас там актуальная информация.
                          0
                          Интересуют технические подробности, как всегда. Сделаете?
                            0
                            Технические подробности — понятие растяжимое. ;) Как всегда, хочется знать, какие именно? В какую область двигаться?
                              0
                              К примеру, развертывание новых узлов, вы автоматизировали каким-то образом?
                              Или, например, каков стек ПО для выдачи контента? С чего начали, что пробовали, на чем остановились?
                              Были ли сложности, с которыми вы столкнулись, не описанными в статье?

                              P.S. я с CDN не работал, поэтому было бы интересно изучить ваш опыт, помимо множества других историй с хабра и не только
                                0
                                Серверы готовятся puppet'ом. Циски конфигурятся копи-пастом и последующей доводкой напильником по месту.
                                Насчёт набора софта — это тема для отдельной хорошей статьи (и не моего авторства).
                                Сложности — они всегда есть. Даже вот так на вскидку ничего выделить не могу. Но обещаю по теме дальнейших статей по возможности это освещать.
                                  0
                                  Я правильно полагаю, что главная проблема — доставка и установка железок? Ответ опять будет спойлером для последующих статей? :)
                                    0
                                    Да какая ж это проблема? Коробки с преднастроенным оборудованием отдаются курьерской компании, и — вперёд! Монтаж, как правило, делаем силами сотрудников ЦОД. Хотя, я вот в Краснодар съездил с огромным удовольствием в июне. :)
                                    Проблемы — это когда какой-то непредусмотренный фактор вылезает. Один раз шефу пришлось решать проблему электроснабжения стойки. Но это всё-таки экзотика.
                                    0
                                    спасибо. продолжайте, если время будет )

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

                            Самое читаемое