На #телекомночи отлично поговорили про CDN, опять и снова. Тему про интеграцию ИИ и CDN я комментировать не буду (собственно, я про это уже писал), а вот преза Яндекса была интересная. Проблемы у нас отчасти общие, размеры сравнимые, оттого ещё интереснее было посмотреть на их подходы.
Как и любой, кажется, "внутренний" CDN, яндексовый не вышел сразу хорошо - это наслоение нескольких поколений различных решений, каждое из которых решало вполне определённую задачу в конкретный момент времени. И все их нужно поддерживать, разумеется. Подходы со временем тоже изменялись, и будут изменяться дальше, я уверен, вместе с изменениями внутри самого Яндекса и Рунета в целом.
Основное отличие, конечно, в способе распределения кэш-серверов. Контент со своим CDN, в отличие от general purpose, имеет видимость end-to-end и желание управлять трафиком максимально гранулярно. Отсюда, с одной стороны, довольно точные предсказания, куда и сколько кэшей нужно поставить и как привести пользователя в нужный. С другой -- борьба со своими же алгоритмами, когда из-за перегруженных линков снижается качество, вместе с качеством объём трафика, и вроде даже и кэш ставить нет нужды - трафика-то нет... Нюансы, так сказать. В отличие от контента, сервис-провайдер такой высокой маржи не умеет, а зарабатывает с эксплуатации своей инфраструктуры, соответственно капекс нужно делать поменьше и кэши максимально-разумно агрегировать на точках притяжения трафика - региональных и федеральных IX, например, и крупных операторских узлах.
Ещё одна интересная мысль - колбасы портов операторов на всех не хватит, и тут либо CDN между собой придётся сражаться за благосклонность операторов, либо наоборот - операторам выбирать, чьи CDN-кэши принесут им максимум пользы.
@snakeslair #cdn
