[Caching] Виртуальный контент Cloudfront + подписанная архитектура URL-адресов


Answers

Активы в одном и том же ведре могут иметь разные политики конфиденциальности. Таким образом, вы можете иметь публичные и частные активы в одном и том же ковше.

Во время загрузки просто установите параметр конфиденциальности.

Затем просто подпишите URL-адрес для доступа к частным активам.

Question

Позвольте мне начать с быстрого введения в архитектуру системы, которую я рассматриваю, чтобы перейти на S3 + Cloudfront.

У нас есть число сущностей в дереве. Листья дерева имеют несколько ресурсов (jpg-изображения должны быть конкретными), обычно в порядке 20-5000, со средним значением ~ 200. Каждый ресурс имеет уникальный URL-адрес, который предоставляется через нашу установку colo.

Я мог бы просто передать все эти ресурсы на S3, установить Cloudfront поверх этого и сделать это. Если бы мне не пришлось защищать ресурсы.

Большинство объектов являются общедоступными (то есть ~ 99%), остальные защищены одним из многих способов (логин, ip, время и т. Д.). После того как объект защищен, все ресурсы также должны быть защищены, и их можно получить только после того, как была выполнена действительная авторизация.

Я мог бы решить это, создав два ведра S3 - одну частную и одну публику. Для личного содержимого я бы сгенерировал подписанный URL Cloudfront после того, как пользователь был авторизован. Однако состояние субъекта может быть изменено от публичного до частного произвольно, и наоборот. Администратор системы может изменить объект на любом уровне дерева сущностей, что приведет к каскадным изменениям по всему дереву. Одно изменение может вызвать изменение ~ 20 тыс. Сущностей, умноженное на 200 ресурсов, что повлияет на 4 миллиона ресурсов.

Я мог бы запустить службу в фоновом мониторинге для изменений состояния, но это было бы громоздким, и изменение ACL из 4 миллионов элементов S3 займет значительное время, и, хотя это происходит, мы либо будем иметь незащищенный частный контент, либо публичный контент, который нам нужно будет генерировать подписанные URL-адреса.

Другая возможность - сделать все ресурсы частными по умолчанию. По каждому запросу, отправленному сущности, мы создадим настраиваемую политику, предоставляющую доступ для этого конкретного пользователя ко всем ресурсам, содержащимся в объекте (с использованием шаблона подстановочного знака в пользовательской политике). Это потребовало бы создания политики для каждого посетителя, для каждого объекта - это не было бы проблемой. Однако это означает, что наши пользователи больше не смогут кэшировать что-либо, поскольку URL-адрес будет изменяться для каждого нового сеанса. Хотя это не проблема для частного контента, для нас было бы отбросить все кэширование для ~ 99% общедоступных объектов.

Еще одним вариантом было бы сохранить все содержимое конфиденциальным и использовать вышеуказанный подход для частных лиц. Для публичных объектов мы могли бы создать единую настраиваемую политику для каждого публичного объекта, которую все пользователи разделили бы. Если мы установим срок службы 6 часов и обеспечим создание новой политики через 5 часов, пользователю будет гарантирован срок действия политики не менее одного часа. Это имеет преимущество, позволяя кэшировать до 6 часов, позволяя частному контенту, возможно, быть открытым до 6 часов после изменения состояния. Это было бы приемлемо, но я не уверен, что это того стоит (мы пытаемся найти соотношение кеширования / ударов в настоящее время). Очевидно, мы могли бы настроить границу 5/6 часов, чтобы обеспечить более длинный / более короткий кеш за счет более длительного / более короткого воздействия на частные лица.

Кто-нибудь развернул аналогичное решение? Любые функции AWS, с которыми я не обращаю внимания, могут быть полезны? Любые комментарии вообще?