Наверно, все слышали о интересных решениях, предлагаемых Amazon: Elastic Compute Cloud (EC2), SimpleDB, Simple Storage Service (S3), Simple Queue Service.
Буквально недавно список пополнился CloudFront
CloudFront — это CDN или сеть доставки контента. Конечно, это не ново и альтернатив много, но данный сервис будет особенно полезен и интересен тем, кто использует другие сервисы Amazon.
Поскольку мы храним часть данных на S3 и заинтересованы, чтобы наши пользователи получали контент максимально быстро, данное решение показалось заманчивым.
CloudFront использует 4 дата центра: в CША, в Европе, в Гонконге и Японии. Представляет из себя кэш, которые знает о хранилище, содержащем нужные файлы (это может быть свой сервер или S3).
Таким образом когда пользователь запрашивает файл, определяется ближайший дата центр и осуществляется поиск необходимого файла. Если файл в кэше не найден, он запрашивается у хранилища. Закэшированное значение «жить» вечно не будет, по умолчанию время жизни 24 часа и это минимально допустимое значение. Можно повышать это значение, используя заголовки Cache-Control, Pragma, или Expires.
Важным моментом является то, что иногда нужно версионировать файлы. Иначе пользователи будут получать старые файлы, несмотря на изменения в хранилище. В нашем случае с этим у нас проблем быть не должно — файлы в хранилище мы не меняем.
По заверению разработчиков настроить S3 с CloudFront дело нескольких минут. Попробуем.
Итак предполагаем что S3 бакеты у вас имеются.
Основная задача создать Distribution, по рабоче крестьянски это персональный именнованный кэш. Под именнованностью понимается, что в результате будет получен неких домен, который и нужно будет использовать при постороении пути к файлам.
Для начала создаем конфигурацинный файл, который будет настраивать дистрибьюшен.
В Origin указывается S3 бакет в формате <bucket name>.s3.amazonaws.com. Это стандартная возможность S3 вместо s3.amazonaws.com/<bucket name>. Обращаю внимание, при таком подходе на имена бакетов накладываются определенные ограничения, навскидку, нельзя использовать заглавные буквы.
CallerReference уникальное число, необходимое для того, чтобы исключить случайные повторные запросы.
Далее запускаем
Чтобы не отвлекаться на то, что такое cfcurl.pl и friendly key name, расскажу об этом позже.
И получим ответ, примерно такого содержания
Id уникальный номер дистрибьюшена.
Status может принимать два значения InProgress и Deployed. InProgress означает, что дистрибьюшен еще не создан. Нужно дожидаться его создания (Deployed)
Проверить статус можно вызвовом
DomainName элемент содержит доменное имя, которое нужно использовать при построении пути к файлу.
Это все. Теперь чтобы создать ссылку на image.jpg нужно использовать такой путь <domain name>/image.jpg
где <domain name> в примере был e604721fxaaqy9.cloudfront.net.
Мы используем насколько бакетов для хранения всех файлов. Цель одна — добиться параллельной загрузки. Файлы немальнькие, а их количество может быть приличным. Подробней об этой технике можно прочитать, например на Webo.in
Таким образом нам нужно создать несколько дистрибьюшенов для разных бакетов и внести изменения в проект.
Как видно, реализация достаточно проста. Теперь к более интересному вопросу цены.
Очевидно, что за счет кэширования, трафик на S3 упадет, сократится также и число GET запросов. В процентном соотношении оценить сложно.
К этому всему добавится еще трафик CloudFront'a. Величина его известна, а вот сумму посчитать сложно, в разных регионах она разная (нужно знать распределение трафика по регионам)
В описании указано, что цены за трафик могут быть даже меньше, чем у S3. Это так, но выгода будет только если у вас в США и Европе величина трафика превышает 10Тб, а в Азии 40Тб. Наш проект таких цифр пока не достиг, так что CloudFront будет обходиться чуть-чуть дороже.
Скачать скрипт можно с сайта Amazon
Далее необходимо создать файл .aws-secrets в домашней папке
при такой конфигурации в качестве <friedly key name> нужно указывать primary.
Буквально недавно список пополнился CloudFront
CloudFront — это CDN или сеть доставки контента. Конечно, это не ново и альтернатив много, но данный сервис будет особенно полезен и интересен тем, кто использует другие сервисы Amazon.
Поскольку мы храним часть данных на S3 и заинтересованы, чтобы наши пользователи получали контент максимально быстро, данное решение показалось заманчивым.
CloudFront использует 4 дата центра: в CША, в Европе, в Гонконге и Японии. Представляет из себя кэш, которые знает о хранилище, содержащем нужные файлы (это может быть свой сервер или S3).
Таким образом когда пользователь запрашивает файл, определяется ближайший дата центр и осуществляется поиск необходимого файла. Если файл в кэше не найден, он запрашивается у хранилища. Закэшированное значение «жить» вечно не будет, по умолчанию время жизни 24 часа и это минимально допустимое значение. Можно повышать это значение, используя заголовки Cache-Control, Pragma, или Expires.
Важным моментом является то, что иногда нужно версионировать файлы. Иначе пользователи будут получать старые файлы, несмотря на изменения в хранилище. В нашем случае с этим у нас проблем быть не должно — файлы в хранилище мы не меняем.
По заверению разработчиков настроить S3 с CloudFront дело нескольких минут. Попробуем.
Итак предполагаем что S3 бакеты у вас имеются.
Основная задача создать Distribution, по рабоче крестьянски это персональный именнованный кэш. Под именнованностью понимается, что в результате будет получен неких домен, который и нужно будет использовать при постороении пути к файлам.
Для начала создаем конфигурацинный файл, который будет настраивать дистрибьюшен.
<?xml version="1.0" encoding="UTF-8"?>
<DistributionConfig xmlns="http://cloudfront.amazonaws.com/doc/2008-06-30/">
<Origin>mybucket.s3.amazonaws.com</Origin>
<CallerReference>20080930090000</CallerReference>
<Comment>Creating my first distribution</Comment>
<Enabled>true</Enabled>
</DistributionConfig>
* This source code was highlighted with Source Code Highlighter.
В Origin указывается S3 бакет в формате <bucket name>.s3.amazonaws.com. Это стандартная возможность S3 вместо s3.amazonaws.com/<bucket name>. Обращаю внимание, при таком подходе на имена бакетов накладываются определенные ограничения, навскидку, нельзя использовать заглавные буквы.
CallerReference уникальное число, необходимое для того, чтобы исключить случайные повторные запросы.
Далее запускаем
./cfcurl.pl --keyname <friendly key name> -- -X POST -i -H "Content-Type:text/xml; charset=UTF-8" --upload-file create_request.xml cloudfront.amazonaws.com/2008-06-30/distribution
* This source code was highlighted with Source Code Highlighter.
Чтобы не отвлекаться на то, что такое cfcurl.pl и friendly key name, расскажу об этом позже.
И получим ответ, примерно такого содержания
201 Created
Location: cloudfront.amazonaws.com/2008-06-30/distribution/PDFDVBD632BHDS5
<?xml version="1.0" encoding="UTF-8"?>
<Distribution xmlns="http://cloudfront.amazonaws.com/doc/2008-06-30/">
<Id>PDFDVBD632BHDS5</Id>
<Status>InProgress</Status>
<LastModifiedTime>2008-07-24T19:37:58Z</LastModifiedTime>
<DomainName>e604721fxaaqy9.cloudfront.net</DomainName>
<DistributionConfig>
<Origin>mybucket.s3.amazonaws.com</Origin>
<CallerReference>20080930090000</CallerReference>
<Comment>Creating my first distribution</Comment>
<Enabled>true</Enabled>
</DistributionConfig>
</Distribution>
* This source code was highlighted with Source Code Highlighter.
Id уникальный номер дистрибьюшена.
Status может принимать два значения InProgress и Deployed. InProgress означает, что дистрибьюшен еще не создан. Нужно дожидаться его создания (Deployed)
Проверить статус можно вызвовом
./cfcurl.pl --keyname <friendly key name>
-- cloudfront.amazonaws.com/2008-06-30/distribution<your distribution's ID>;
* This source code was highlighted with Source Code Highlighter.
DomainName элемент содержит доменное имя, которое нужно использовать при построении пути к файлу.
Это все. Теперь чтобы создать ссылку на image.jpg нужно использовать такой путь <domain name>/image.jpg
где <domain name> в примере был e604721fxaaqy9.cloudfront.net.
Мы используем насколько бакетов для хранения всех файлов. Цель одна — добиться параллельной загрузки. Файлы немальнькие, а их количество может быть приличным. Подробней об этой технике можно прочитать, например на Webo.in
Таким образом нам нужно создать несколько дистрибьюшенов для разных бакетов и внести изменения в проект.
Как видно, реализация достаточно проста. Теперь к более интересному вопросу цены.
Очевидно, что за счет кэширования, трафик на S3 упадет, сократится также и число GET запросов. В процентном соотношении оценить сложно.
К этому всему добавится еще трафик CloudFront'a. Величина его известна, а вот сумму посчитать сложно, в разных регионах она разная (нужно знать распределение трафика по регионам)
В описании указано, что цены за трафик могут быть даже меньше, чем у S3. Это так, но выгода будет только если у вас в США и Европе величина трафика превышает 10Тб, а в Азии 40Тб. Наш проект таких цифр пока не достиг, так что CloudFront будет обходиться чуть-чуть дороже.
Использование cfcurl.pl
Скачать скрипт можно с сайта Amazon
Далее необходимо создать файл .aws-secrets в домашней папке
%awsSecretAccessKeys = (
# primary account
primary => {
id => '<Your primary AWS Access Key ID>',
key => '<Your primary Secret Access Key>',
},
);
* This source code was highlighted with Source Code Highlighter.
при такой конфигурации в качестве <friedly key name> нужно указывать primary.