Назад | Перейти на главную страницу

CDN для кеширования REST api

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

Мы размещаем общедоступный REST API на инстансе Amazon EC2. Каждый вызов является динамическим и интенсивно использует процессор, но в целом активность довольно стабильна. Однако регулярно бывают короткие и высокие пики множества пользователей, одновременно запрашивающих один и тот же ресурс (-ы). Это происходит, например, после того, как кто-то пишет в блоге или твиттер ссылку на ресурс, и все переходят по ней.

Многие ресурсы меняются не часто, и мой сервер отправляет явные заголовки Cache-Control max-age, указывающие время, в которое каждый ресурс может и должен быть кэширован. Мне нужен веб-кеш / обратный прокси-сервер / CDN, который хорошо справляется с проверкой заголовков управления кешем и кешированием этих вызовов сервера, так что если 1000 клиентов запрашивают тот же ресурс в течение минуты, мой сервер должен обслуживать его только один раз, или по крайней мере, не 1000 раз.

Кроме того, CDN должна иметь возможность кэшировать любой HTTP-запрос GET, независимо от типа контента или URI. Ограничения на размер файла не проблема; вывод обычно краткий и компактный. Я сегодня экспериментировал с Cloudflare; однако они кэшируют только статические файлы на основе «расширения файла» URI, что делает его совершенно бесполезным для большинства REST api. И последнее, но не менее важное: я небольшой стартап, поэтому желательно что-нибудь доступное по цене, масштабируемое как вверх, так и вниз.

Какие поставщики могут соответствовать этим требованиям? Спасибо за любой опыт / совет.

Есть компании, которые специализируются на сервисах управления API, включая кеширование.

Два имени макушки моей головы:

  1. апиги
  2. Машери

Возможно, вам повезет больше, чем с традиционным CDN.

Если вы ищете собственный прокси-сервер обратного кеширования, то я думаю Лак сделает хорошую работу.

Любая сеть CDN, которая может выполнять «выборку из источника» (это отраслевой термин CDN, большинство из нас назвала бы это обратным прокси), должна делать то, что вам нужно. Я знаю, что среди недорогих CDN с оплатой за использование есть такая функция:

Обратите внимание, что Rackspace Cloud Files, который использует Akamai в качестве CDN, поддерживает только файлы статического происхождения, загруженные на их серверы.

Камнем преткновения может быть минимальное время жизни кеша. Быстрое перемешивание контента создает проблемы для CDN, которые предназначены для обслуживания статического контента. Поэтому, если вы установите «Cache-Control: max-age = 5», конкретный CDN может изменить это значение до некоторого минимального значения, например 3600, или вообще не кэшировать его, а просто передать запрос обратно в источник.

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

Я не могу говорить о других / меньших CDN, но я работал с Akamai и Level3. Я могу вам сказать, что Akamai определенно может кэшировать по mime-типу или даже по шаблонам uri-основы. Они могут делать практически все, что вы ищете, я просто не знаю, сможете ли вы найти их в рамках вашего бюджета.

После прохождения через Akamai, если все запросы относятся к www.yoursite.com и вы хотите кэшировать некоторые из них, вам нужно немного переделать свое приложение, если вы хотите сэкономить. Например, если вы храните его на сайте www.yoursite.com, все запросы начнут проходить через Akamai, если этот хост теперь перенаправлен на хост akamai. Все, что не настроено для кэширования, будет проксировано.

С другой стороны, вы можете переименовывать части своего сайта так, чтобы ваш файл cookie был установлен с доменом = * www.yoursite.com, и переписывать части таким образом, чтобы части, которые вы хотите кэшировать, фактически находились на хосте cdn.www.yoursite.com ( или что-то в этом роде, вы поняли). Это означает, что все, что вы не хотите кэшировать, идет прямо в источник, тогда как все, что находится в поддомене cdn.www.yoursite.com, на самом деле попадет в akamai. Вам нужно будет принять необходимые меры на исходном сервере, чтобы это тоже было возможно.

У Akamai есть вариант биллинга (если есть даже другой вариант для сайта, который видит количество посещений, измеряемых только тысячами в день), основанный на пропускной способности, и это может сэкономить вам немного денег.

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