Исправление медленного отклика псевдонима Route 53 CNAME с помощью Cloudfront

Я только что настроил дистрибутив CloudFront, чтобы ускорить изображения моего сайта. Мои изображения хранятся на S3. Я настроил собственный субдомен в Route53, используя псевдоним CNAME для моей конечной точки распространения CloudFront.

Однако при тестировании скорости с образцом изображения я обнаружил следующее:

Эти 3 URL-адреса указывают на одно и то же изображение:

  • Первый URL-адрес — исходное изображение с S3.
  • Второй URL — это изображение из дистрибутива CloudFront при доступе через псевдоним CNAME, настроенный в Route53.
  • Третий URL-адрес — это изображение непосредственно из дистрибутива Cloudfront.

Тесты проводились с использованием Pingdom из Далласа. Я достиг аналогичных результатов из других мест.

Более медленное время загрузки из S3 имеет смысл. Изображение не кэшируется по краям. Однако почти удвоение времени загрузки только за счет использования CNAME перед дистрибутивом кажется слишком медленным. Я бы предпочел использовать CNAME, но не с такой ценой производительности.

Я что-то упустил здесь? Я везде читал, что дополнительный поиск DNS CNAME будет незначительным в большинстве ситуаций.


amazon-s3 performance amazon-route53 amazon-cloudfront
person Augusto Samamé Barrientos    schedule 16.04.2016    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Задержка CNAME должна раствориться в шуме, как только результат поиска CNAME и его цели будут кэшированы любым заданным распознавателем, но если это не CNAME, который не охватывает несколько доменов (например, foo.example.com. CNAME bar.example.com.), время двойного поиска всегда будет быть неизбежным.

Однако вам не нужен CNAME для Route 53, чтобы указать на раздачу CloudFront. Вы можете использовать псевдоним записи A, который использует внутреннюю функцию Route 53, чтобы поиск выполнялся внутри Route 53, а не по внешней ссылке CNAME. Затем задержка исчезает, потому что Route 53 предоставляет ответ из своих внутренних баз данных.

Отредактируйте существующий RR в консоли Route 53... измените его с CNAME на A, затем установите для Alias ​​значение Yes. Затем выберите раздачу CloudFront из списка выбора цели псевдонима и сохраните запись.

person Michael - sqlbot    schedule 16.04.2016
comment
Если вы используете DNS, отличный от Route 53, вместо CNAME вы можете использовать более эффективную настройку делегирования субдомена: docs.aws.amazon.com/Route53/latest/DeveloperGuide/. Вы создаете свою зону в Route 53 и используете Псевдоним записи A. Затем вы добавляете запись NS, чтобы делегировать свой субдомен в AWS. - person ofavre; 20.09.2017
comment
Дело в том, что ALIAS для дистрибутивов CloudFront заключается в том, что их TTL составляет 60 с (и сами записи дистрибутива CF тоже). Это не очень оптимально, так как в основном кэширование минимально. В нашем случае время разрешения DNS — это самая большая часть HTTPS-запроса к CloudFront. - person Nikolay Dimitrov; 09.07.2020
comment
@NikolayDimitrov это правда, но это что-то вроде классического компромисса - низкий TTL является частью стратегии устойчивости. Характер интеграции публично не задокументирован, но CloudFront и Route 53 тесно связаны между собой, так что запросы для каждого назначенного имени хоста в *.cloudfront.net (а также любых псевдонимов, указывающих на него) могут получать индивидуальный ответ, основанный не только на местоположении средства просмотра, но и то, что система знает о текущем состоянии пограничной сети CloudFront. При использовании CNAME цель CNAME по-прежнему имеет низкий TTL, поэтому ваше беспокойство все еще присутствует. - person Michael - sqlbot; 09.07.2020
comment
@ Майкл-sqlbot, я понимаю. Я просто надеюсь, что когда-нибудь AWS сможет обеспечить устойчивость, используя фиксированные (или долгоживущие) IP-адреса, а не полагаясь на балансировку нагрузки DNS. - person Nikolay Dimitrov; 13.07.2020