Критически важная глобальная доставка контента

Сети доставки содержимого (CDN) предлагают ряд возможностей для оптимизации производительности для пользователей, включая балансировку нагрузки глобального уровня 7 и оптимизированную маршрутизацию сети. Кэширование также является общим способом снижения нагрузки на внутренние службы и обеспечения дополнительной устойчивости к различным проблемам. Сети CDN, включая Azure Front Door, обеспечивают кэширование на пограничной сети.

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

Как упоминалось в предыдущей статье в этой серии, Azure Front Door предназначена для обеспечения максимальной устойчивости и доступности не только для наших внешних клиентов, но и для множества служб в компании Майкрософт. Хотя корпорация Майкрософт предлагает соглашение об уровне обслуживания в отрасли (SLA) для Azure Front Door, если у вас есть критически важное приложение, требующее еще большего соглашения об уровне обслуживания, вам потребуется использовать несколько CDN. Рассмотрим последствия этого подхода. Каждая сеть CDN предоставляет отдельный сетевой путь к серверам приложений, и необходимо настроить и проверить каждый CDN отдельно.

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

Подход

Сторонний CDN можно интегрировать в решение Azure, чтобы обеспечить изоляцию от инфраструктуры Майкрософт. Эта изоляция обеспечивает высокую степень устойчивости от сценариев стихийных бедствий. Если происходит сбой или авария, трафик автоматически перемещается между Azure Front Door и альтернативным CDN. Диспетчер трафика Azure можно использовать для обнаружения сбоя и перенаправления трафика в альтернативную сеть CDN.

Диаграмма ниже иллюстрирует, как трафик перемещается между CDNами.

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

  Во время обычных операций диспетчер трафика отправляет все запросы через Azure Front Door.

  Если Azure Front Door недоступен, деактивируйте конечную точку Azure Front Door. Затем диспетчер трафика отправляет все запросы через альтернативную сеть CDN.

• Azure Front Door обрабатывает и направляет большую часть трафика приложения. Azure Front Door направляет трафик на соответствующий исходный сервер приложений и предоставляет основной путь к приложению. Если Azure Front Door недоступна, трафик автоматически перенаправляется через дополнительный путь.

• Альтернативная сеть CDN настроена для отправки трафика на каждый сервер-источник.

• Серверы приложений-источника должны быть готовы принять трафик как Из Azure Front Door, так и другого CDN в любое время.

Соображения

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

Выбор CDN

Корпорация Майкрософт предлагает несколько продуктов CDN. Наше флагманское предложение — Azure Front Door Standard и Premium, и было объявлено о выходе на пенсию для всех остальных продуктов CDN. Другие продукты также совместно используют физическую инфраструктуру с Azure Front Door, поэтому мы рекомендуем выбрать другой продукт CDN для типа архитектуры, описанной в этой статье. Убедитесь, что вы выбрали альтернативную сеть CDN, которая соответствует вашим потребностям для возможностей функций, времени простоя и стоимости.

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

Равенство функций

Azure Front Door предоставляет различные возможности от многих CDN, а функции не эквивалентны между продуктами. Например, могут быть различия в обработке сертификатов TLS, брандмауэра веб-приложения (WAF) и правил маршрутизации HTTP.

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

Заполнение кэша

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

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

Проверьте переключение на резервный путь между Azure Front Door и альтернативной сетью доставки контента (CDN), чтобы обнаружить аномалии или проблемы с производительностью. Если решение подвержено риску из-за проблем с производительностью во время заполнения кэша, рассмотрите следующие подходы для снижения риска:

• Горизонтальное или вертикальное масштабирование ваших источников, чтобы справляться с более высокими уровнями трафика, особенно во время заполнения кэша.

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

Поддомены

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

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

Компромиссы

Использование нескольких CDN поставляется с некоторыми компромиссами.

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

• Каждый дополнительный компонент, добавляемый в решение, увеличивает затраты на управление.

• Во время переключения между Azure Front Door и альтернативным CDN могут возникнуть проблемы с производительностью.

• С помощью диспетчера трафика DNS можно случайным образом выбрать cdN для запроса. Если вы не позаботитесь о реализации согласованных параметров кэша в сети CDN (например, кэширование в Azure Front Door), это может привести к снижению производительности и увеличению расходов на исходящий трафик с сервера.

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Дэйв Беркхардт | Главный диспетчер программ, Azure Front Door
• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Акхил Кармелькар | Главный диспетчер программ, Azure Front Door
• Приянка Уилкинс | Разработчик основного содержимого, шаблоны и практики Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

Просмотрите глобальный сценарий входящего трафика HTTP , чтобы понять, применяется ли оно к решению.