Все на одного или как мы построили 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 трафика сейчас генерируется узлами вне Москвы. Интересно суточное колебание (график показывает отношение сгенерированного в регионах трафика к суммарному, время московское).
Кликабельно:
Очень чётко видно, что ночью нагрузка на CDN минимальная. Тому есть несколько причин, но основная из них — ночью люди смотрят непопулярный контент. Такой, который не закэширован (и не закэшируются). Максимальная же нагрузка на CDN — это время, когда люди к востоку от Москвы уже проснулись, а москвичи пока ещё спят :)
Локализация трафика на узле колеблется от 40% (маленькие односерверные узлы) до 90% (на самых крупных узлах). Без сомнения, это не могло не сказаться на качестве обслуживания абонентов. Вот красивый график:
Свежие данные приводить не буду — они уже давно колеблются на уровне статистической погрешности, и такой красивой «ступеньки» там уже не увидеть.
Эта статья задумывалась как обзорная про наш CDN. Следующим аспектом я планирую рассказать про балансировку нагрузки между городами и весями. А какие ещё аспекты нашего CDN вам были бы интересны?
