Профили и конечные точки Azure CDN

Сеть доставки содержимого (CDN) — это распределённая сеть серверов, размещённых в географических точках присутствия (PoPs) рядом с конечными пользователями. Когда пользователь запрашивает содержимое, CDN выдаёт его из кэша ближайшей PoP, а не с исходного сервера. Это уменьшает задержку (особенно для пользователей, находящихся далеко от региона исходного сервера), снижает нагрузку на исходный сервер и повышает устойчивость. Azure CDN изначально интегрируется с Blob Storage, App Service и любым общедоступным источником HTTP.

Azure CDN предлагается на нескольких уровнях поставщиков: Azure CDN Standard from Microsoft — вариант по умолчанию с тесной интеграцией, базовыми правилами кэширования и поддержкой HTTP/2. Azure CDN Standard from Akamai — широкое глобальное покрытие PoPs и быстрое распространение изменений. Azure CDN Standard/Premium from Verizon — расширенный обработчик правил и аналитика (уровень Premium). У каждого поставщика свой набор возможностей и тарифы; в большинстве сценариев AZ-900 основное внимание уделяется Azure CDN Standard from Microsoft.

Профиль Azure CDN — это контейнер верхнего уровня, объединяющий конечные точки CDN и определяющий поставщика и ценовой уровень. Конечная точка CDN — это конкретное имя узла (например, myapp.azureedge.net), соответствующее источнику. Для каждой конечной точки отдельно настраивается поведение кэша. Один профиль может содержать несколько конечных точек — например, отдельные конечные точки для статических ресурсов, ответов API и видеопотоков с разными правилами кэширования для каждой.

Время жизни (TTL) определяет, как долго кэшированный ответ хранится в PoP, прежде чем его потребуется обновить из источника. Правила кэширования можно задать на трёх уровнях: глобальное правило кэширования (применяется ко всем запросам конечной точки), пользовательские правила (соответствуют шаблону пути или расширению файла) и обработка строки запроса (раздельное кэширование для каждой уникальной строки запроса или игнорирование строк запроса). Рекомендуется задавать TTL в зависимости от типа содержимого: более длительный для изображений и более короткий для HTML.

Одна из наиболее распространённых конфигураций Azure CDN использует контейнер Blob Storage в качестве источника. Загрузите статические ресурсы (изображения, CSS, JS, видео) в учётную запись Storage, сделайте контейнер общедоступным для чтения и настройте конечную точку CDN, указывающую на основной адрес Blob (myaccount.blob.core.windows.net). CDN кэширует Blob в PoPs по всему миру, а пользователи загружают их из ближайшей PoP, а не из региона Storage. Для размещения статического веб-сайта также можно использовать пользовательское имя узла источника.

При обновлении содержимого в источнике (например, при развёртывании новой версии файла JavaScript) кэшированные копии в PoPs могут возвращать устаревшее содержимое, пока не истечёт TTL. Очистка кэша немедленно удаляет указанные файлы или всё кэшированное содержимое из каждого PoP, заставляя следующий запрос заново получить данные из источника. Можно очистить отдельные URL, пути с подстановочными знаками (например, /assets/*) или всё содержимое конечной точки. Распространение очистки занимает 2–3 минуты, после чего она становится доступной во всех PoPs по всему миру.

По умолчанию конечные точки CDN используют домен .azureedge.net. Чтобы предоставлять содержимое из собственного домена (например, static.contoso.com), добавьте его как пользовательский домен в конечной точке CDN, создав запись CNAME, указывающую на имя узла конечной точки. После добавления домена можно включить для него HTTPS, используя сертификат, управляемый Azure (бесплатный, с автоматическим продлением), или собственный сертификат, хранящийся в Key Vault. Принудительное использование HTTPS автоматически перенаправляет трафик HTTP.

Включение сжатия файлов в конечной точке CDN уменьшает размер файлов, передаваемых по сети, сжимая текстовые ресурсы (HTML, CSS, JavaScript, SVG) с помощью gzip или Brotli. CDN сжимает содержимое перед его кэшированием в PoP, поэтому последующие запросы того же ресурса получают сжатую версию без дополнительной нагрузки на CPU. Сжатие особенно эффективно для пакетов JS, размер которых после сжатия может уменьшиться в 5–10 раз.

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

Azure CDN предоставляет на портале встроенную аналитику использования, включая потреблённую пропускную способность, соотношение попаданий и промахов кэша, общее число запросов и экономию пропускной способности по сравнению с обслуживанием из источника. Для CDN уровня Microsoft можно также отправлять журналы доступа в рабочую область Log Analytics или учётную запись Storage через параметры диагностики, что позволяет выполнять запросы KQL к необработанным данным журналов доступа CDN. Анализ коэффициентов попаданий в кэш помогает настроить TTL: низкий коэффициент означает, что большинство запросов проходит к источнику, тем самым сводя на нет предназначение CDN.

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

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900), рассмотренных в этом уроке.

В этом уроке Вы узнали, что профили и конечные точки Azure CDN доставляют кэшированное содержимое из PoPs, расположенных рядом с пользователями, чтобы уменьшить задержку; правила кэширования и TTL определяют, как долго содержимое хранится в кэше до повторного получения из источника; а очистка кэша немедленно удаляет устаревшее содержимое после обновления источника. Далее мы рассмотрим Azure Front Door для глобальной балансировки нагрузки и маршрутизации между несколькими внутренними источниками.