Лучшие практики - Video CDN [RU]
Избегайте наслоения CDN-на-CDN
Использование внешних проксирующих CDN (например Cloudflare) перед vCDN/aCDN не рекомендуется.
Подобная конфигурация приводит к:
Увеличению задержек, поскольку каждый запрос проходит через два слоя CDN последовательно.
Увеличению вероятности несогласованости кешей между edge нодами.
Сложностям во время траблшутинга, при появлении проблем с доставкой.
Неэфективному использованию возможностей CDN: реальная длительность обработки запроса будет ограничена самым медленным в цепочке.
CDNы созданы для их применения первым слоем в цепочке доставки контента. Стэкование не увеличивает производительность. Обычно все происходит наоборот - производительность ухудшается.
Что бы помочь отследить неточности в настройках:
Панель сверяет DNS записи подключенных доменов.
Если домен указывает на Cloudflare или другой внешний CDN, интерфейс отображает предупреждение (например ⚠️).
Рекомендация: Всегда направляйте домен напрямую на Video CDN. Избегайте настройки поверх других проксирующих CDN, что бы иметь предсказуемое кеширование,приемлимую скорость обработки запроса и избежать сложностей при построении мониторинга.
Если у вас нет возможности придерживаться даной рекомендации, ознакомьтесь с рекомендациями раздела Влияние на алгоритм доставки, о том, как избежать негативных последствий.
Используйте callback для проверки статуса
Если клиенту нужен более тонкий контроль над процессом импорта (например, чтобы убедиться, что файл действительно загружен в CDN), самый простой (но не идеальный) способ — периодически запрашивать файл у CDN и проверять HTTP-ответ: 200 OK, если файл доступен, или 404 Not Found, если нет.
Однако этот метод не полностью надежен, поскольку статус файла может кэшироваться по-разному на разных редиректорах. В результате один запрос может вернуть 200 OK с одного узла и 404 Not Found с другого, что приводит к несогласованным проверкам статуса.
Есть лучший способ.
Для этого мы предлагаем механизм callback. При добавлении файла в CDN клиент может указать не только исходный URL (откуда файл должен быть загружен), но и URL для callback. Как только CDN определит, был ли файл успешно импортирован или отклонен, он сделает запрос на этот callback URL.
Что считается успешным импортом? Например, если клиент указал ожидаемый размер файла, но origin вернул другой размер, CDN отклонит файл и отметит его как неудачный, записав причину, чтобы клиент мог принять корректирующие меры.
Когда файл успешно загружен и становится активным, CDN вызывает callback URL. Это позволяет клиенту автоматически обработать событие — например, обновить базу данных или выполнить PHP-скрипт, чтобы отметить файл как готовый к использованию.
См. также
Как настроить callback url для импорта файлов
Скорость реагирования CDN на завершение импорта
Как настроить callback url для импорта файлов
Гайд по реализации рекомендации
Следите за вашим origin
С точки зрения пользователя, проще всего описать CDN как облачный слой, который самостоятельно обрабатывает доставку контента. Если определенные файлы отсутствуют на edge-узлах, CDN может проксировать эти запросы к origin-серверу и уже таким образом доставлять контент конечным пользователям. Чтобы гарантировать непрерывность доступа, CDN постоянно мониторит нагрузку и доступность. (См. страницу Обработка запросов к несуществующим файлам для подробностей)
Если origin временно недоступен, система отвечает соответствующим HTTP кодом состояния (например, 501), который браузер отображает как сообщение об ошибке. Это помогает клиентам и техническим командам определить, что проблема связана с загрузкой или доступностью origin-сервера.
Также стоит отметить, что многие клиенты могут не активно отслеживать метрики системы. В результате они могут обнаружить проблему только тогда, когда конечные пользователи начнут сообщать, что «сервис не работает». Поэтому рекомендуется настроить понятные оповещения и заранее сообщать о достижении предела capacity origin — чтобы клиенты знали, что необходимо предпринять действия.