Какой самый эффективный способ обслуживания index.html для одностраничного приложения среди всех сервисов aws?

Question

Попытка найти наиболее эффективный способ обслуживания файла index.html для одностраничного приложения в AWS. Основные требования:

1. Служба AWS должна иметь возможность обслуживать файл из подстановочного домена, такого как *.domain.com.
2. SPA скорее не будет использовать маршрутизацию на основе хеша,Это означает, что https://foo.domain.com/path/to/resource предпочтительнее, чем URL-адрес, такой как https://foo.domain.com/#/path/to/resource.

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

Мы «безуспешно» пытались использовать облачный фронт, поддерживаемый источником S3. Чтобы использовать SPA с облачным фронтом и маршрутизацией пути HTML5 (не на основе хеш-функции), необходимо указать CustomErrorResponses, чтобы обслуживать файл index.html для кодов состояния http 404 и 403. Хотя это работает для правильного обслуживания файла index.html, ответы всегда заканчиваются заголовком x-cache: Error from cloudfront. Это означает, что cloudfront потребовалось время, чтобы найти путь HTML5 в источнике S3, прежде чем использовать index.html в качестве документа ошибки по умолчанию. В сочетании с тем, что облачный фронт использует функцию Lambda @ Edge origin-response для добавления пользовательских заголовков http, добавляется задержка для этих не кэшированных ответов.

В некоторых регионах США мы наблюдаем запросы наЭтот файл занимает 500-1000 миллисекунд. Например, с распределением облачного фронта, размещенным в Вирджинии, и зрителем в центральной части США, кажется, что запрос направляется от зрителя к ближайшему краевому местоположению (иногда дальше на запад), затем проходит в Вирджинию и из нее (где находится источник S3)затем, наконец, вернемся из граничного местоположения в средство просмотра.

Мы также безуспешно пытались использовать Lambda @ Edge для кэширования тела ответа об ошибке вместе с заголовками.

Мы еще не пробовали:

1. Балансировщик нагрузки приложения, указывающий на лямбда-функцию (с шлюзом API или без него)
2. Балансировщик нагрузки приложенияпрямо на экземпляр EC2.

Прежде чем мы решим попробовать эти более дорогие варианты хостинга, спросите сообщество, есть ли способ сделать облачный фронт более производительным с учетом наших требований. Если нет, то я ожидаю, что у EC2 есть потенциал, чтобы быть более производительным, чем ALB / лямбда, так как у EC2 не должно быть холодных запусков? Это точное предположение?

Answer 1

Решением этой проблемы является распределение облачного фронта для определения других вариантов поведения кэша в дополнение к DefaultCacheBehavior (*).

Настройка поведения кэша по умолчанию с использованием связи lambda @ edge origin-request. Когда вызывается связь источника с запросом, она должна вернуть ответ, включающий содержимое файла index.html вместе со всеми необходимыми заголовками. Этот ответ будет кэшироваться в дистрибутиве для любых запрошенных виртуальных путей. Для функции lambda @ edge есть два способа получить это содержимое:

1. Из кода функции вызвать http (s) get для файла index.html по URL-адресу облачного фронта(например, dklyksfhsksdgjh.cloudfront.net/index.html). Дистрибутив вернет файл на основе другого поведения кэша, отличного от заданного по умолчанию, которое вы также настроите. Этот подход обеспечивает менее оптимальную производительность при первом запросе любого виртуального пути html5, хотя последующие запросы будут обслуживать содержимое из кеша распространения облачного фронта.

2. Встраивать содержимое index.htmlфайл в код функции lambda @ edge в процессе сборки функции. Этот подход обеспечивает лучшую производительность, чем вариант № 1, поскольку сетевой запрос для получения содержимого файла не требуется.

Дополнительно настройте другое поведение кэша для шаблона пути /index.html с источником-ответ лямбда @ край ассоциация. Когда вызывается связь происхождения и ответа, в ответ должны быть добавлены все необходимые заголовки.

Если в дистрибутиве содержатся другие файлы (такие как /robots.txt, /favicon.ico, / fonts, / scripts,/ styles и т. д.), установите дополнительные режимы кэширования, соответствующие этим путям. Это необходимо для того, чтобы запросы к этим файлам не возвращали файл index.html во время исходного запроса-привязки поведения кэша lambda @ edge Ассоциации.

При таком подходе запросы на корень приложения (т. Е. Www.site.com или www.site.com/index.html) будет соответствовать поведению кэша /index.html, получит файл из его источника S3, добавит все необходимые заголовки с помощью ассоциации lambda @ edge origin-response и кэшируетфайл. Первый запрос должен содержать заголовок ответа x-cache: Miss from cloudfront, но последующие запросы должны возвращать x-cache: Hit from cloudfront до истечения срока действия кэша TTL.

Запросы для других файлов (например, /robots.txt, /scripts/myscript.js). и т. д.) будут соответствовать другим режимам кэширования, которые вы определяете для других путей к файлам в дистрибутиве.

Запросы для виртуальных путей HTML5 (т. е. www.site.com/path/handled/by/javascript) будут совпадать со значениями по умолчаниюповедение кэша и из-за привязки lambda @ edge origin-запроса возвращают index.html без проверки каких-либо файлов в источнике S3. Вам все равно нужно будет добавить все необходимые заголовки, такие как привязка lambda @ edge происхождение-ответ, для поведения кэша /index.html. Запросы будут кэшироваться, хотя каждый виртуальный путь HTML5 будет кэшироваться отдельно. Например, запрос для / foo и запрос для / bar вызовут ассоциацию lambda @ edge origin-request перед кэшированием.