Позвольте мне начать с краткого введения в архитектуру системы, которую я планирую перейти на S3 + Cloudfront.
У нас есть число сущностей порядка в дереве. Листья дерева имеют несколько ресурсов (jpg-изображения должны быть конкретными), обычно в порядке 20-5000, со средним значением ~ 200. Каждый ресурс имеет уникальный URL-адрес, который сегодня доступен в нашей настройке колонок.
Я мог бы просто перенести все эти ресурсы на S3, настроить Cloudfront поверх этого и сделать это. Если бы мне не пришлось защищать ресурсы.
Большинство объектов являются общедоступными (то есть ~ 99%), остальные af защищены одним из многих способов (логин, ip, время и т.д.). Когда объект защищен, все ресурсы также должны быть защищены, и их можно получить только после того, как было выполнено действительное авторизацию.
Я мог бы решить это, создав два ведра S3 - одну частную и одну публику. Для личного контента я бы сгенерировал подписанный URL Cloudfront после того, как пользователь был авторизован. Однако состояние субъекта может быть изменено от публичного до частного произвольно, и наоборот. Администратор системы может изменить объект на любом уровне дерева сущностей, что приведет к каскадным изменениям по всему дереву. Одно изменение может вызвать изменение ~ 20 тыс. Сущностей, умноженное на 200 ресурсов, что повлияет на 4 миллиона ресурсов.
Я мог бы запустить службу в фоновом мониторинге для изменений состояния, но это было бы громоздким, и изменение ACL с 4 миллионами элементов S3 займет значительное время, и в то время как это произойдет, у нас либо будет незащищенный частный контент, либо общедоступный контент, который нам нужно будет генерировать подписанные URL-адреса для.
Другая возможность - сделать все ресурсы закрытыми по умолчанию. При каждом запросе, полученном для сущности, мы создадим настраиваемую политику, предоставляющую доступ для этого конкретного пользователя всем ресурсам, содержащимся в объекте (с использованием шаблона подстановочных знаков в пользовательской политике). Это потребовало бы создания политики для каждого посетителя, для каждого объекта - это не было бы проблемой. Однако это означает, что наши пользователи больше не смогут кэшировать что-либо, поскольку URL-адрес будет изменяться для каждого нового сеанса. Хотя это не проблема для частного контента, для нас было бы отбросить все кэширование для ~ 99% общедоступных объектов.
Еще одним вариантом было бы сохранить все содержимое конфиденциальным и использовать вышеуказанный подход для частных лиц. Для публичных объектов мы могли бы создать единую настраиваемую политику для каждого публичного объекта, которую все пользователи разделили бы. Если мы установим срок службы 6 часов и обеспечим создание новой политики через 5 часов, пользователю будет гарантирован срок действия политики не менее одного часа. Это имеет преимущество, позволяя кэшировать до 6 часов, позволяя частному контенту, возможно, быть открытым до 6 часов после изменения состояния. Это было бы приемлемо, но я не уверен, что это того стоит (мы пытаемся найти соотношение кеширования/ударов в настоящее время). Очевидно, мы могли бы настроить границу 5/6 часов, чтобы обеспечить более длительный/более короткий кеш за счет более длительного/более короткого воздействия на частные объекты.
Кто-нибудь развернул аналогичное решение? Любые функции AWS, с которыми я не обращаю внимания, могут быть полезны? Любые комментарии вообще?
