Push файлы до Amazon Cloudfront: возможно?

Я читал о том, чтобы вытащить и протолкнуть CDN. Я использовал Cloudfront как выталкивающий CDN для измененных изображений:

  • Получить изображение с клиента
  • Поместите изображение в S3

В дальнейшем, когда клиент делает запрос на облачный интерфейс для URL-адреса, Cloudfront не имеет изображения, поэтому он должен перенаправить его на мой сервер, который:

  • Получить запрос
  • Потяните изображение с S3
  • Изменить размер изображения
  • Нажать изображение обратно в Cloudfront

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

Можно ли активно продвигать измененное изображение в Cloudfront и привязывать его к URL-адресу, чтобы будущие запросы могли сразу получить подготовленное изображение? В идеале я хотел бы

  • Получить изображение с клиента
  • Поместите изображение в S3
  • Изменить размер изображения для обычных размеров
  • Предварительно надавить эти размеры на облачный

Это позволяет избежать всего цикла загрузки/повторной загрузки, что делает общие размеры очень быстрыми, но доступ к менее распространенным размерам (хотя и с задержкой в ​​первый раз). Однако для этого мне нужно будет подтолкнуть изображения до Cloudfront. Это:

http://www.whoishostingthis.com/blog/2010/06/30/cdns-push-vs-pull/

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

ОТВЕТЫ

Ответ 1

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

Один из способов, о котором я могу думать, также, как упоминалось в @Xint0, - создать еще одно ведро S3, чтобы специально разместить те файлы, которые вы хотели бы нажать (в вашем случае эти измененные изображения). В основном у вас будет два дистрибутива cloudFront, для которых редко доступны эти файлы, а другой - для быстрого доступа к тем файлам, а также к тем изображениям, которые вы ожидаете изменить. Это звучит немного сложнее, но я считаю, что компромисс вы должны сделать.

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

Ответ 2

OP запрашивает решение CDN, но похоже, что он просто пытается ускорить работу. Я решаюсь, что вам, вероятно, не нужно реализовывать CDN-push, вам просто нужно оптимизировать шаблон исходного сервера.

Итак, OP, я собираюсь предположить, что вы поддерживаете не более нескольких размеров изображений - скажем 128x128, 256x256 и 512x512. Это также похоже на то, что у вас есть оригинальные версии этих изображений на S3.

Это то, что в настоящее время происходит при пропуске кеша:

  • CDN получает запрос на версию изображения 128x128
  • CDN не имеет этого изображения, поэтому он запрашивает его с вашего исходного сервера.
  • Сервер происхождения получает запрос
  • Ваш исходный сервер загружает исходное изображение с S3 (предположительно большее изображение)
  • Ваше происхождение изменяет размер этого изображения и возвращает его в CDN
  • CDN возвращает это изображение пользователю и кэширует его

Что вы должны делать вместо этого:

В зависимости от вашей конкретной ситуации существует несколько вариантов.

Вот некоторые моменты, которые вы могли бы исправить быстро, с вашей текущей настройкой:

  • Если вам нужно получить исходные изображения с S3, вы в основном делаете это так, чтобы промахивание кеша приводило к тому, что каждое изображение принималось так же долго, как и исходное изображение. Если это вообще возможно, вы должны попытаться скрыть те исходные изображения где-нибудь, к которым ваш исходный сервер может получить доступ быстро. Здесь в зависимости от вашей установки есть миллион различных вариантов, но выбор их из S3 - это самый медленный из всех них. По крайней мере, вы не используете Glacier;).
  • Вы не кэшируете измененные изображения. Это означает, что каждое ребро node Cloudfront будет запрашивать это изображение, которое запускает весь процесс изменения размера. Cloudfront может иметь сотни отдельных серверов node, что означает сотни отсутствующих и изменение размера изображения. В зависимости от того, что Cloudfront делает для многоуровневого распространения и как вы устанавливаете заголовки файлов, это может быть не так уж плохо, но это будет не так.
  • Я выхожу на конечность здесь, но я уверен, что вы не устанавливаете пользовательские заголовки истечения, а это означает, что Cloudfront кэширует каждое из этих изображений в течение 24 часов. Если ваши изображения неизменяемы после загрузки, вам действительно выгодно возвращать заголовки истечения, сообщая CDN, чтобы они не проверяли новую версию в течение долгого времени.

Вот несколько идей для потенциально лучших моделей:

  • Когда кто-то загружает новое изображение, немедленно перекодируйте его на все поддерживаемые вами размеры и загружайте их на S3. Затем просто укажите свой CDN в этом ведре S3. Это предполагает, что у вас есть количество поддерживаемых форматов. Однако я хотел бы указать, что если вы поддерживаете слишком много размеров изображений, CDN может быть неправильным решением. Скорость вашего кеша может быть настолько низкой, что CDN действительно мешает. Если это случай, см. Следующую точку.
  • Если вы поддерживаете что-то вроде непрерывного изменения размера (т.е. я могу запросить image_57x157.jpg или image_315x715.jpg и т.д., и сервер вернет его), тогда ваш CDN может на самом деле сделать вам неприятный случай, добавив дополнительный прыжок без разгрузки много от вашего происхождения. В этом случае я, вероятно, буду раскручивать экземпляры EC2 во всех доступных регионах, установить на них исходный сервер и затем обменивать URL-адреса изображений на соответствующие региону источники на основе IP-адреса клиента (фактически сворачивая собственный CDN).

И если вы reeeeeally хотите нажать на Cloudfront:

Вам, вероятно, не нужно, но если вам просто нужно, вот пара вариантов:

  • Введите script в с помощью API webpagetest.org, чтобы получить изображение из разных мест по всему миру. В каком-то смысле вы будете нажимать команду pull на все разные граничные положения. Это не гарантирует заполнения каждого края, но вы, вероятно, можете приблизиться. Обратите внимание, что я не уверен, насколько волнующий webpagetest.org мог бы использовать его таким образом, но я не вижу в этом никаких условий использования (IANAL).
  • Если вы не хотите использовать сторонний или рискованный веб-сайт webpagetest.org, просто разверните экземпляр micro EC2 в каждом регионе и используйте его для получения содержимого, как и в # 1.

Ответ 3

AFAIK CloudFront использует ведра S3 в качестве хранилища данных. Таким образом, после изменения размера изображений вы сможете сохранить измененные изображения в ведро S3, которое используется CloudFront напрямую.