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

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

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

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

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

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

Подход

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

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

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

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

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

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

Соображения

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

Выбор CDN

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

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

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

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

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

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

Если вы используете несколько 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
• Джон Даунс | Главный инженер программного обеспечения
• Приянка Уилкинс | Разработчик основного содержимого

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

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

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