The Content Delivery Network (CDN)

Problem statement - Постановка задачи

Начнем с вопроса: если миллионы пользователей по всему миру используют наши ресурсоемкие приложения, а наш сервис развернут в едином дата-центре для обработки запросов пользователей, какие возможные проблемы могут возникнуть?

Возможные проблемы:

1. Высокая задержка (High latency): Пользователи будут сталкиваться с высокой задержкой из-за физического расстояния от обслуживающего дата-центра. Задержка, воспринимаемая пользователем, имеет много компонентов, таких как задержки передачи (зависят от доступной пропускной способности), задержки распространения (функция расстояния), задержки очередей (зависят от загрузки сети) и задержки обработки узлов. Таким образом, передача данных на большие расстояния приводит к увеличению задержки. Реальному времени приложениям требуется задержка менее 200 миллисекунд (мс) в общем случае. Для телефонии через Интернет (VoIP) задержка не должна превышать 150 мс, тогда как приложения потокового видео не могут допускать задержку более нескольких секунд.

Примечание: Согласно одному из измерений, проведенному 21 декабря 2021 года, средняя задержка от US East (Вирджиния) до US West (Калифорния) составляла 62,9 мс. Между континентами, например, от US East (Вирджиния) до Африки (Кейптаун), задержка составляла 225,63 мс. Это двусторонняя задержка, известная как задержка "туда-обратно" (round-trip latency).

Data-intensive applications - Ресурсоемкие приложения

Ресурсоемкие приложения требуют передачи большого объема данных. На большом расстоянии это может стать проблемой из-за того, что сетевой путь проходит через различные типы интернет-провайдеров (ISP). Из-за некоторых сегментов с меньшим максимальным размером передаваемого пакета (MTU) пропускная способность приложений в сети может снижаться. Также разные участки сетевого пути могут иметь разные характеристики загрузки. Проблема усугубляется с ростом числа пользователей, поскольку исходные серверы будут вынуждены предоставлять данные каждому пользователю индивидуально. Это означает, что первичный дата-центр будет вынужден отправлять много избыточных данных при запросе от нескольких клиентов. Приложения, использующие потоковые сервисы, являются как ресурсоемкими, так и динамическими по своей природе.

Примечание: Согласно опросу, 78% потребителей в Соединенных Штатах используют потоковые сервисы, что на 25% больше за последние пять лет.

Scarcity of data center resources - Нехватка ресурсов дата-центра

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

Примечание: Согласно одному исследованию, YouTube, Netflix и Amazon Prime в совокупности генерировали 80% интернет-трафика в 2020 году. В 2016 году CDN-провайдер Akamai обслуживал от 15% до 30% веб-трафика (около 30 терабит в секунду). Для 90% пользователей Интернета Akamai находился всего в одном переходе (hop) от них. Поэтому у нас есть веские причины для оптимизации доставки и потребления этих данных, не превращая ядро Интернета в узкое место.

How will we design a CDN? - Как мы будем проектировать CDN?

Мы разделили проектирование CDN на шесть уроков:

1. Introduction to a CDN: Мы дадим подробное введение в CDN и определим функциональные и нефункциональные требования.
2. Design of a CDN: Мы объясним, как спроектировать CDN. Также кратко опишем дизайн API.
3. In-depth Investigation of CDN: Part 1: Этот урок объясняет стратегии кэширования и архитектуру CDN. Также обсудим различные подходы к поиску ближайшего прокси-сервера.
4. In-depth Investigation of CDN: Part 2: Мы обсудим, как поддерживать консистентность контента в CDN и развертывание прокси-серверов. Также подробно рассмотрим специализированные и пользовательские CDN.
5. Evaluation of CDN: Этот урок предоставит оценку нашего предложенного дизайна.
6. Quiz on CDN System Design: Мы закрепим основные концепции проектирования CDN с помощью викторины.

Давайте подумаем над решением обсуждаемых проблем в следующем уроке.

Introduction to a CDN

Proposed solution - Предложенное решение

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

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

Рассмотрим, как CDN решает обсуждаемые проблемы:

1. Высокая задержка: CDN приближает контент к конечным пользователям, что сокращает физическое расстояние и уменьшает задержку.

2. Ресурсоемкие приложения: Поскольку путь к данным включает только интернет-провайдера и близлежащие компоненты CDN, нет проблем с обслуживанием большого числа пользователей через несколько компонентов CDN в конкретной области. Как показано ниже, исходный дата-центр должен будет предоставить данные локальным компонентам CDN только один раз, тогда как локальные компоненты CDN смогут предоставлять данные разным пользователям индивидуально. Ни одному пользователю не нужно будет загружать свою копию данных с исходных серверов.

Примечание: Различные протоколы потоковой передачи используются провайдерами CDN для доставки динамического контента. Например, CDNsun использует Real-time Messaging Protocol (RTMP), HTTP Live Streaming (HLS), Real-time Streaming Protocol (RTSP) и многие другие для доставки динамического контента.

3. Нехватка ресурсов дата-центра: CDN используется для обслуживания популярного контента. По этой причине большая часть трафика обрабатывается на уровне CDN, а не на исходных серверах. Таким образом, различные локальные или распределенные компоненты CDN делят нагрузку на исходные серверы.

Примечание: Некоторые известные провайдеры CDN включают Akamai, StackPath, Cloudflare, Rackspace, Amazon CloudFront и Google Cloud CDN.

---

Does a CDN cache all content from the origin server?

Details

Answer

Not likely. A CDN caches a considerable portion of the content depending on its capabilities, and it mostly caches the static content.

It also depends on the size of the content. For example, it might be possible for Netflix to store more than 90% of its movies in the CDN, while this might not be feasible for a service like YouTube due to the humongous volume of content.

---

Requirements - Требования

Рассмотрим функциональные и нефункциональные требования, которые мы ожидаем от CDN.

Functional requirements - Функциональные требования

Следующие функциональные требования будут частью нашего дизайна:

1. Retrieve (Получение): В зависимости от типа моделей CDN, CDN должен уметь получать контент с исходных серверов. Мы рассмотрим модели CDN в следующем уроке.

2. Request (Запрос): Доставка контента с прокси-сервера осуществляется по запросу пользователя. Прокси-серверы CDN должны иметь возможность отвечать на каждый запрос пользователя в этом отношении.

3. Deliver (Доставка): В случае модели push исходные серверы должны иметь возможность отправлять контент на прокси-серверы CDN.

4. Search (Поиск): CDN должен уметь выполнять поиск по запросу пользователя для кэшированного или иным образом хранящегося контента в инфраструктуре CDN.

5. Update (Обновление): В большинстве случаев контент поступает с исходного сервера, но если мы запускаем скрипт в CDN, CDN должен уметь обновлять контент на одноранговых прокси-серверах CDN в точке присутствия (PoP).

6. Delete (Удаление): В зависимости от типа контента (статический или динамический) должно быть возможно удалять кэшированные записи с серверов CDN после определенного периода.

Non-functional requirements - Нефункциональные требования

1. Performance (Производительность): Минимизация задержки является одной из основных задач CDN. Предлагаемый дизайн должен обеспечивать минимально возможную задержку.

2. Availability (Доступность): CDN должны быть доступны в любое время из-за их важности. Доступность также включает защиту от атак, таких как DDoS.

3. Scalability (Масштабируемость): Увеличивающееся количество пользователей будет запрашивать контент через CDN. Наше предлагаемое решение CDN должно иметь возможность горизонтального масштабирования по мере роста требований.

4. Reliability and security (Надежность и безопасность): Наш дизайн CDN должен обеспечивать отсутствие единой точки отказа. Помимо сбоев, спроектированная CDN должна надежно справляться с огромными нагрузками на трафик. Более того, CDN должны обеспечивать защиту размещенного контента от различных атак.

Building blocks we will use

DNS is the service that maps human-friendly CDN domain names to machine-readable IP addresses. This IP address will take the users to the specified proxy server.
Load balancers distribute millions of requests among the operational proxy servers.

Design of a CDN

CDN Design - Проектирование CDN

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

CDN Components - Компоненты CDN

Следующие компоненты составляют CDN:

1. Clients (Клиенты): Конечные пользователи используют различные клиенты, такие как браузеры, смартфоны и другие устройства, чтобы запрашивать контент у CDN.

2. Routing system (Система маршрутизации): Система маршрутизации направляет клиентов к ближайшему узлу CDN. Для этого этот компонент получает данные от различных систем, чтобы понять, где размещен контент, сколько запросов сделано на конкретный контент, какую нагрузку обрабатывает определенный набор серверов и пространство имен URI (Uniform Resource Identifier) для различных контентов. В следующем уроке мы обсудим различные механизмы маршрутизации для перенаправления пользователей к ближайшему узлу CDN.

3. Scrubber servers (Серверы очистки): Серверы очистки используются для отделения "чистого" трафика от вредоносного и защиты от известных атак, таких как DDoS. Серверы очистки обычно используются только при обнаружении атаки. В этом случае трафик очищается и затем направляется к целевому назначению.

4. Proxy servers (Прокси-серверы): Прокси-серверы или пограничные прокси-серверы предоставляют контент из оперативной памяти пользователям. Прокси-серверы хранят горячие данные в ОЗУ, хотя они также могут хранить холодные данные на SSD или жестком диске. Эти серверы также предоставляют информацию о счетах и получают контент от системы распространения.

5. Distribution system (Система распространения): Система распространения отвечает за распространение контента на все пограничные прокси-серверы в различных узлах CDN. Эта система использует Интернет и интеллектуальные методы широковещательной передачи для распространения контента на активные пограничные прокси-серверы.

6. Origin servers (Исходные серверы): Инфраструктура CDN предоставляет пользователям данные, полученные с исходных серверов. Исходные серверы обслуживают любые недоступные данные в CDN для клиентов. Исходные серверы используют соответствующие хранилища для хранения контента и других метаданных. Однако мы не будем обсуждать внутреннюю архитектуру исходной инфраструктуры здесь.

7. Management system (Система управления): Системы управления важны для CDN с точки зрения бизнеса и управления, где постоянно наблюдается использование ресурсов и статистика. Этот компонент измеряет важные метрики, такие как задержка, время простоя, потеря пакетов, нагрузка на сервер и так далее. Для сторонних CDN информация о счетах также может использоваться для выставления счетов.

---

Workflow - Рабочий процесс

Рабочий процесс для абстрактного дизайна выглядит следующим образом:

1. URI Namespace Delegation: Исходные серверы предоставляют делегирование пространства имен URI для всех объектов, кэшированных в CDN, системе маршрутизации запросов.

2. Content Publishing: Исходный сервер публикует контент в системе распространения, которая отвечает за распространение данных по активным пограничным прокси-серверам.

3. Content Distribution: Система распространения распределяет контент между прокси-серверами и предоставляет обратную связь системе маршрутизации запросов. Эта обратная связь помогает оптимизировать выбор ближайшего прокси-сервера для запрашивающего клиента. Обратная связь содержит информацию о том, какой контент кэширован на каком прокси-сервере, чтобы перенаправить трафик на соответствующие прокси-серверы.

4. Client Request: Клиент запрашивает систему маршрутизации о подходящем прокси-сервере.

5. Return IP: Система маршрутизации возвращает IP-адрес соответствующего прокси-сервера.

6. Traffic Scrubbing: Запрос клиента проходит через серверы очистки по соображениям безопасности.

7. Forwarding to Proxy: Сервер очистки пересылает чистый трафик на пограничный прокси-сервер.

8. Serving Content: Пограничный прокси-сервер обслуживает запрос клиента и периодически передает информацию о счетах в систему управления. Система управления обновляет исходные серверы и отправляет обратную связь системе маршрутизации о статистике и деталях контента. Однако запрос перенаправляется на исходные серверы, если контент недоступен на прокси-серверах. В случае, если контент не найден на пограничных прокси-серверах, возможна иерархия прокси-серверов, и запрос передается на родительские прокси-серверы.

---

API Design - Дизайн API

В этом разделе мы рассмотрим дизайн API для функциональностей, предлагаемых CDN. Это поможет понять, как CDN будет получать запросы от клиентов, получать контент от исходных серверов и взаимодействовать с другими компонентами сети. Разработаем API для следующих функциональностей:

• Retrieve content (Получение контента)
• Deliver content (Доставка контента)
• Request content (Запрос контента)
• Search content (Поиск контента)
• Update content (Обновление контента)
• Delete content (Удаление контента)

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

Retrieve (proxy server to origin server) - Получение (прокси-сервер к исходному серверу)

Если прокси-серверы запрашивают контент, метод GET получает контент через следующий API /retrieveContent:

retrieveContent(proxyserver_id, content_type, content_version, description)

Details of Parameters - Подробности параметров

Parameter	Description
proxyserver_id	Уникальный идентификатор запрашивающего прокси-сервера.
content_type	Эта структура данных содержит информацию о запрашиваемом контенте. В частности, она включает категорию (аудио, видео, документ, скрипт и т.д.), тип клиентов, для которых запрашивается контент, и запрашиваемое качество (если есть).
content_version	Представляет номер версии контента. Для API /retrieveContent параметр content_version будет содержать текущую версию контента, находящегося на прокси-сервере. Если на прокси-сервере нет предыдущей версии, то content_version будет NULL.
description	Указывает подробности о контенте, например, расширение видео, данные о разрешении и т.д., если content_type — это видео.

API возвращает ответ в виде JSON файла, который содержит текст, типы контента, ссылки на изображения или видео в контенте и так далее.

"Object_links": [
                 {
                 "name": "videos"
                 "link": https://app_server.com/api/assets/videos/
                 },
                 {
                 "name": "illustrations"
                 "link": https://app_server.com/api/assets/illustrations/
                 },
                ]

Deliver (origin server to proxy servers) - Доставка (исходный сервер к прокси-серверам)

Исходные серверы используют этот API для доставки указанного контента, обновленной версии, на прокси-серверы через систему распространения. Этот API называется /deliverContent:

deliverContent(origin_id, server_list, content_type, content_version, description)

Подробности параметров

Параметр	Описание
origin_id	Уникально идентифицирует каждый исходный сервер.
server_list	Определяет список серверов, на которые контент будет передан системой распространения.
content_version	Представляет обновленную версию контента на исходном сервере. Прокси-сервер, получивший контент, удалит предыдущую версию.

Остальные параметры уже были объяснены выше.

---

Request (clients to proxy servers) - Запрос (клиенты к прокси-серверам)

Пользователи используют этот API для запроса контента у прокси-серверов. Этот API называется /requestContent:

requestContent(user_id, content_type, description)

Подробности параметра

Параметр	Описание
user_id	Уникальный идентификатор пользователя, который запрашивает контент.

Указанный прокси-сервер возвращает запрашиваемый контент пользователю в ответ на вызов вышеупомянутого API.

"Object_links": [
                 {
                 "name": "components"
                 "link": https://cdn.app_server.com/api/components/
                 },
                 {
                 "name": "css"
                 "link": https://cdn.app_server.com/api/css/
                 },
                 {
                 "name": "illustrations"
                 "link": https://cdn.app_server.com/api/assets/illustrations/
                 },
                 {
                 "name": "videos"
                 "link": https://cdn.app_server.com/api/assets/videos/
                 },
                 {
                 "name": "icons"
                 "link": https://cdn.app_server.com/api/icons/
                 },
                 {
                 "name": "fonts"
                 "link": https://cdn.app_server.com/api/fonts/
                 },
                ]

Search (proxy server to peer proxy servers) - Поиск (прокси-сервер к одноранговым прокси-серверам)

Хотя контент сначала ищется локально на прокси-сервере, прокси-серверы могут также искать запрашиваемый контент на одноранговых прокси-серверах в той же точке присутствия (PoP) через API /searchContent. Этот запрос может быть отправлен на все прокси-серверы в PoP. В качестве альтернативы можно использовать хранилище данных в PoP для поиска контента, хотя прокси-серверам потребуется поддерживать информацию о том, какой контент доступен на каком прокси-сервере.

Пример API /searchContent приведен ниже:

searchContent(proxyserver_id, content_type, description)

Update (proxy server to peer proxy servers) - Обновление (прокси-сервер к одноранговым прокси-серверам)

Прокси-серверы используют API /updateContent для обновления указанного контента на одноранговых прокси-серверах в точке присутствия (PoP). Это происходит, когда на CDN выполняются изолированные скрипты, чтобы предоставлять такие услуги, как изменение размера изображений, преобразование разрешения видео, обеспечение безопасности и многое другое. Этот тип скриптов называется безсерверным скриптингом (serverless scripting).

Пример API /updateContent приведен ниже:

updateContent(proxyserver_id, content_type, description)

Подробности параметра

Параметр	Описание
proxyserver_id	Уникально идентифицирует прокси-сервер в PoP для обновления контента.

Остальные параметры уже были объяснены выше.

Примечание: API для удаления здесь не рассматривается. В нашей главе о кэшировании мы подробно обсудили различные механизмы вытеснения. Эти механизмы также применимы для удаления контента в CDN. Тем не менее, могут возникнуть ситуации, когда потребуется использовать API удаления. В следующем уроке мы рассмотрим несколько механизмов обеспечения консистентности контента, таких как время хранения контента в кэше.

В предстоящих уроках мы углубимся в характеристики CDN.

In-depth Investigation of CDN: Part 1

Content Caching Strategies in CDN - Стратегии кэширования контента в CDN

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

Push CDN

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

Pull CDN

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

Когда пользователи запрашивают веб-контент в модели Pull CDN, CDN самостоятельно отвечает за извлечение запрашиваемого контента с исходного сервера и его доставку пользователям. Поэтому этот тип CDN более подходит для обслуживания динамического контента.

Как уже упоминалось, Push CDN в основном используется для доставки статического контента. Поскольку статический контент предоставляется широкому кругу пользователей дольше, чем динамический контент, схема Push CDN поддерживает большее количество реплик по сравнению с Pull CDN, что улучшает доступность. С другой стороны, Pull CDN предпочтительнее для часто изменяющегося контента и высокого трафика. Низкое потребление памяти — одно из основных преимуществ Pull CDN.

---

Let’s say you’re managing a website with two distinct content types:

• News feed: Frequently updated articles and blog posts with varying popularity.
• Static assets: Infrequently updated items, including the company logo, website design elements, and product images.

Choose between a push CDN and a pull CDN for each content type. Justify your choice.

Details

Answer

For managing a website with two distinct content types, the choice between a push CDN and a pull CDN should be as follows:

Push CDN should be used for static assets such as the company logo, website design elements, and product images. This is because these items change infrequently, and using a push CDN allows for these assets to be pre-uploaded to edge servers. This ensures consistent branding and fast loading times for users, as the content is served directly from a nearby server, reducing latency.

Pull CDN is more suitable for the news feed, which consists of frequently updated articles and blog posts with varying popularity. The dynamic nature of this content type makes a pull CDN ideal, as it only fetches content from the origin server upon user request. This approach helps to conserve storage on edge servers and ensures that the content is up-to-date.

---

Примечание: Большинство поставщиков контента используют оба подхода кэширования, как Pull, так и Push CDN, чтобы получить преимущества обоих методов.

Оптимизация кэширования динамического контента

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

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

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

Еще один популярный подход для сжатия динамических данных — это язык разметки Edge Side Includes (ESI). Обычно небольшая часть веб-страниц изменяется через определенное время. Это означает, что повторная загрузка полной веб-страницы при каждом небольшом изменении содержит много избыточных данных. Для решения этой проблемы производительности ESI указывает, где именно контент был изменен, чтобы остальная часть веб-страницы могла быть закэширована. ESI собирает динамический контент на сервере на краю CDN или в браузере клиента. ESI пока не стандартизирован Всемирным консорциумом по всемирной паутине (W3C), но многие поставщики CDN его используют.

Примечание: Dynamic Adaptive Streaming over HTTP (DASH) использует манифестный файл с URI видео в разных разрешениях, чтобы клиент мог загружать то, что подходит для текущих условий сети и конечного узла. Netflix использует собственную версию DASH с Byte-range в URL для дальнейшей оптимизации запросов и доставки контента.

Многоуровневая архитектура CDN

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

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

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

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

---

What happens if a child or parent proxy server fails or if the origin server fails?

Details

Answer

Each PoP contains a collection of CDN proxy servers. When any child proxy server stops working due to any failures, DNS can route clients to a different child-level proxy server. Each child proxy server knows many upper-layer parent servers, and if one fails, it can go to the other one. The origin server is a set of servers with a hot backup(s), and content is in replicated store. If any of the origin servers fail, other servers take the load.

---

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

Найти ближайший прокси-сервер для получения данных

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

Важные факторы, влияющие на выбор ближайшего прокси-сервера

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

1. Сетевая дистанция между пользователем и прокси-сервером является критически важной. Это функция следующих двух вещей:

   • Длина сетевого пути.
   • Ограничения по пропускной способности на сетевом пути.
   • Самый короткий сетевой путь с наибольшей пропускной способностью (bandwidth) является ближайшим прокси-сервером для пользователя. Этот путь помогает пользователю быстрее загружать контент.

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

Техники маршрутизации пользователей к ближайшему прокси-серверу

DNS-редирект

В типичном разрешении DNS мы используем систему DNS для получения IP-адреса против удобочитаемого имени. Однако DNS также может вернуть другой URI (вместо IP-адреса) клиенту. Такой механизм называется DNS-редиректом.

Поставщики контента могут использовать DNS-редирект, чтобы отправить клиента на определенный CDN. Например, если клиент пытается разрешить имя, которое содержит слово "video", авторитетный DNS-сервер предоставляет другой URL (например, cdn.xyz.com). Клиент выполняет еще одно разрешение DNS, и авторитетный DNS CDN предоставляет IP-адрес соответствующего прокси-сервера CDN для получения необходимого контента.

В зависимости от местоположения пользователя, ответ DNS может быть различным. Посмотрим на следующие слайды, чтобы понять, как работает DNS-редирект:

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

Шаги метода DNS-редиректа:

1. Первый шаг: Сопоставление клиентов с соответствующим сетевым местоположением.
2. Второй шаг: Распределение нагрузки между прокси-серверами в этом местоположении для балансировки нагрузки среди прокси-серверов (подробнее см. разделы о DNS и балансировке нагрузки).

DNS-редирект учитывает оба этих важных фактора — сетевую дистанцию и нагрузку запросов, что уменьшает задержку до прокси-сервера.

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

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

Anycast

Anycast — это метод маршрутизации, при котором все пограничные серверы, расположенные в нескольких местах, используют один и тот же IP-адрес. Этот метод использует протокол пограничного шлюза (BGP) для маршрутизации клиентов на основе естественного сетевого потока в Интернете. Провайдер CDN может использовать механизм Anycast, чтобы клиенты направлялись к ближайшим прокси-серверам для получения контента.

Мультиплексирование клиентов

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

HTTP-редирект

HTTP-редирект — это самый простой из всех подходов. В этой схеме клиент запрашивает контент с исходного сервера. Исходный сервер отвечает с использованием протокола HTTP для перенаправления пользователя по URL-адресу контента.

Пример HTML-кода, предоставленного Facebook, приведен ниже. Как показано на строке 8, пользователь перенаправляется на CDN для загрузки логотипа Facebook:

<!––  The code below is taken from Facebook. -->
<div class="fb_content clearfix " id="content" role="main">
  <div>
    <div class="_8esj _95k9 _8esf _8opv _8f3m _8ilg _8icx _8op_ _95ka">
      <div class="_8esk">
        <div class="_8esl">
          <div class="_8ice">
            <img
              class="fb_logo"
              src="https://static.xx.fbcdn.net/rsrc.php/y8/r/dF5SId3UHWd.svg"
            />
          </div>
          <h2 class="_8eso">
            Facebook helps you connect and share with the people in your life.
          </h2>
        </div>
      </div>
    </div>
  </div>
</div>

In-depth Investigation of CDN: Part 2

Content Consistency in CDN - Обеспечение консистентности контента в CDN

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

Periodic Polling - Периодический опрос

При использовании модели Pull прокси-серверы периодически запрашивают у исходного сервера обновленные данные и соответствующим образом обновляют контент в кэше. Когда контент изменяется редко, подход с периодическим опросом потребляет ненужную полосу пропускания. Периодический опрос использует время для обновления (Time-to-Refresh, TTR) для регулирования периода времени, в течение которого запрашиваются обновленные данные с исходных серверов.

Time-to-Live (TTL) - Время жизни

Из-за TTR прокси-серверы могут бесполезно запрашивать исходные серверы на предмет обновленных данных. Более эффективный подход, который можно использовать для уменьшения частоты сообщений о обновлении, — это подход Time-to-Live (TTL). В этом подходе каждому объекту присваивается атрибут TTL, назначенный исходным сервером. TTL определяет срок действия контента. Прокси-серверы предоставляют пользователям одну и ту же версию данных до тех пор, пока этот контент не истечет. По истечении срока действия прокси-сервер проверяет наличие обновления на исходном сервере. Если данные изменены, он получает обновленные данные с исходного сервера и затем отвечает на запросы пользователей обновленными данными. В противном случае он сохраняет те же данные с обновленным временем истечения от исходных серверов.

Leases - Аренда

Исходный сервер предоставляет аренду (lease) данных, отправляемых на прокси-сервер, используя эту технику. Лизинг (lease) обозначает интервал времени, в течение которого исходный сервер обязуется уведомлять прокси-сервер о любых изменениях в данных. Прокси-сервер должен отправить сообщение с запросом на продление аренды после истечения срока действия. Метод аренды помогает уменьшить количество сообщений, передаваемых между прокси-сервером и исходным сервером. Кроме того, длительность аренды может динамически оптимизироваться в зависимости от наблюдаемой нагрузки на прокси-сервера. Этот метод известен как адаптивная аренда (adaptive lease).

Развертывание - Deployment

Прежде чем установить CDN, необходимо четко ответить на следующие вопросы:

• Каковы лучшие места для установки прокси-серверов для максимального использования технологии CDN?
• Сколько прокси-серверов CDN следует установить?

Placement of CDN Proxy Servers - Размещение прокси-серверов CDN

Прокси-серверы CDN должны быть размещены в сетевых локациях с хорошей связностью. Рассмотрим следующие варианты:

• On-premises (На месте): Это представляет собой небольшой дата-центр, который может быть размещен рядом с крупными точками обмена интернет-трафиком (IXP).
• Off-premises (Вне помещений): Это размещение прокси-серверов CDN в сетях интернет-провайдеров (ISP).

Сегодня, возможно, можно хранить большую часть данных фильма в инфраструктуре CDN, которая находится внутри ISP. Тем не менее, для таких сервисов, как YouTube, данные настолько велики и постоянно растут, что сложно решить, что именно нужно разместить поближе к пользователю. Google использует split TCP для уменьшения задержек, воспринимаемых пользователем, поддерживая постоянные соединения с огромными окнами TCP от инфраструктуры уровня IXP до своих основных дата-центров. TCP-запросы клиента завершаются на инфраструктуре уровня IXP, а затем пересылаются по уже установленным соединениям с низкой задержкой.

Это значительно снижает задержку, воспринимаемую клиентом, благодаря избеганию начального трехстороннего рукопожатия TCP и стадий медленного старта при подключении к удаленному хосту (если бы клиент хотел обратиться в основные дата-центры Google). Задержка на уровне IXP обычно очень мала. Поэтому трехсторонние рукопожатия и медленный старт на этом уровне несущественны. Прогнозирующая отправка (Predictive push) — это значительное направление исследований, чтобы определить, что именно следует отправить поближе к клиентам.

Мы можем использовать измерения для упрощения принятия решения о размещении прокси-сервера. Одним из таких инструментов является ProxyTeller, который помогает определить, где разместить прокси-сервер и сколько прокси-серверов требуется для достижения высокой производительности. ProxyTeller использует коэффициент попадания (hit ratio), пропускную способность сети и время отклика клиента (задержку) в качестве параметров производительности для определения размещения прокси-серверов. Также для размещения прокси-серверов используются другие алгоритмы, такие как жадный алгоритм (greedy), случайный (random) и алгоритмы для горячих точек (hotspot).

Примечание: Akamai и Netflix популяризировали идею размещения своих прокси-серверов CDN внутри сетей интернет-провайдеров клиентов. Для многих клиентов Akamai контент находится всего в одном сетевом переходе. С другой стороны, Google также имеет свою частную инфраструктуру CDN, но в большей степени полагается на свои серверы, расположенные рядом с IXP. Одной из причин этого может быть огромное количество данных и характер их изменений.

---

What benefits could an ISP get by placing the CDN proxy servers inside their network?

Answer

• A CDN node cuts down the amount of external bandwidth that ISPs need and pay for. The SLA defined by ISPs with the proxy server providers may benefit the ISPs economically.
• A CDN node improves responsiveness for the ISP’s customers, which makes the ISP’s customers happier. This gives them a competitive advantage over ISPs that don’t have a CDN node.
• Bringing content closer to the users reduces data on the Internet core.

---

CDN as a Service - CDN как услуга

Большинство компаний не создают свои собственные CDN. Вместо этого они используют услуги провайдера CDN, такого как Akamai, Cloudflare, Fastly и другие, для доставки своего контента. Подобным образом игроки, такие как AWS, предоставляют возможность любому желающему использовать глобальные возможности CDN.

Компании заключают контракт с поставщиком услуг CDN и передают ему свой контент, позволяя CDN распространять этот контент конечным пользователям. Однако использование публичного CDN вызывает у поставщиков контента следующие опасения:

• Недоступность публичного CDN: Поставщик контента не может ничего сделать, если публичный CDN выходит из строя.
• Отсутствие прокси-серверов в регионе: Если у публичного CDN нет прокси-серверов в регионе или стране, откуда идет трафик на сайт, то такие клиенты остаются без доступа. В таких случаях поставщикам контента приходится приобретать услуги CDN у других провайдеров или развертывать и использовать собственный частный CDN.
• Блокировка доменов и IP-адресов: Возможно, что некоторые домены или IP-адреса провайдеров CDN блокируются или ограничиваются в некоторых странах, так как они могут доставлять контент, запрещенный в этих странах.

Примечание: Некоторые компании создают свои собственные CDN, вместо того чтобы использовать услуги провайдеров CDN. Например, Netflix имеет свой собственный CDN, созданный специально для их нужд, под названием Open Connect.

Specialized CDN - Специализированный CDN

Мы обсуждали, что многие компании используют CDN как услугу, но существуют случаи, когда компании создают свой собственный CDN. На это решение влияют несколько факторов. Один из них — это стоимость коммерческой CDN-услуги. Специализированный CDN состоит из точек присутствия (PoPs), которые обслуживают контент только для своей компании. Эти PoP могут быть серверами кэширования, обратными прокси или контроллерами доставки приложений. Хотя специализированный CDN имеет высокие первоначальные затраты на настройку, со временем затраты снижаются. В сущности, это выбор между покупкой и созданием.

PoP специализированного CDN состоят из множества прокси-серверов, которые обслуживают петабайты контента. Частный CDN может использоваться вместе с публичным CDN. В случае, если мощности частного CDN недостаточно или возникает сбой, приводящий к снижению производительности, публичный CDN используется в качестве резервного. Open Connect Appliance (OCA) от Netflix — это пример CDN, специализированного на доставке видео.

Серверы Netflix OCA не хранят данные пользователей. Вместо этого они выполняют следующие задачи:

• Они передают информацию о своем статусе — состояние, изученные маршруты и детали закэшированного контента — в управляющую плоскость Open Connect, которая находится в AWS (Amazon Web Services).
• Они обслуживают закэшированный контент, запрашиваемый пользователем.

Все развернутые OCA, расположенные в точках обмена интернет-трафиком (IXP) или встроенные в сеть интернет-провайдера (ISP), мониторятся командой эксплуатации Open Connect.

Почему Netflix построил свой CDN

С ростом популярности Netflix компания решила создать и управлять своим собственным CDN по следующим причинам:

• Провайдерам услуг CDN было сложно расширять свою инфраструктуру из-за быстрого роста спроса клиентов на видеостриминг Netflix.
• С увеличением объема потокового видео возросли расходы на использование услуг CDN.
• Видеостриминг является основным бизнесом и основным источником дохода для Netflix. Поэтому защита данных всех видео на платформе критически важна. OCA от Netflix лучше управляет потенциальными рисками утечки данных.
• Чтобы обеспечить оптимальную доставку потокового мультимедиа клиентам, Netflix нужно было максимизировать контроль над видеоплеером пользователя, сетью между пользователем и серверами Netflix.
• OCA от Netflix может использовать пользовательские модули HTTP и алгоритмы подключения TCP для быстрого обнаружения сетевых проблем и устранения любых неисправностей в сети CDN.
• Netflix хотел хранить популярный контент в течение длительного времени. Это не всегда было возможно при работе с публичным CDN из-за высоких затрат на хранение и обслуживание.

Примечание: Netflix удается достичь коэффициента попадания (hit ratio) близкого к 95%, используя OCA.

Evaluation of CDN's Design - Оценка дизайна CDN

Evaluation - Оценка

Здесь мы рассмотрим, как наш дизайн удовлетворяет требования, обсуждаемые в предыдущих уроках. Наши основные требования — высокая производительность, доступность, масштабируемость, надежность и безопасность. Давайте обсудим их поочередно.

Performance - Производительность

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

• Прокси-серверы обычно обслуживают контент из оперативной памяти (RAM).
• Прокси-серверы CDN размещаются рядом с пользователями для обеспечения быстрого доступа к контенту.
• CDN может также предоставлять прокси-серверы, расположенные в сетях интернет-провайдеров (ISP) или точках обмена интернет-трафиком (IXP), для обработки высокого трафика.
• Система маршрутизации запросов направляет пользователей к ближайшим прокси-серверам, как обсуждалось ранее.
• На прокси-серверах хранится контент с длинным хвостом в энергонезависимых системах хранения, таких как SSD или HDD. Обслуживание с этих ресурсов приводит к меньшей задержке, чем при обслуживании контента с исходных серверов.

Long-tail Content - Контент с длинным хвостом

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

Availability - Доступность

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

Scalability - Масштабируемость

Дизайн CDN способствует масштабируемости следующими способами:

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

Reliability and Security - Надежность и безопасность

CDN обеспечивает отсутствие единой точки отказа, тщательно реализуя циклы обслуживания и интегрируя дополнительное оборудование и программное обеспечение по мере необходимости. Помимо сбоев, CDN справляется с массивными нагрузками, равномерно распределяя нагрузку на пограничные прокси-серверы. Мы можем использовать scrubber-серверы для предотвращения DDoS-атак и безопасного размещения контента. Кроме того, мы можем использовать протокол heartbeat для мониторинга состояния серверов и исключения неисправных серверов. Реальные приложения также создают свои собственные специализированные CDN для предотвращения утечек контента и безопасного предоставления контента конечным пользователям.

Conclusion - Заключение

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