S3 + Cloudfront 로의 마이그레이션을 고려중인 시스템 아키텍처에 대한 간단한 소개부터 시작하겠습니다.Cloudfront 비공개 콘텐츠 + 서명 된 URL 아키텍처
우리는 여러 엔티티 순서를 트리에 가지고 있습니다. 트리의 나뭇잎에는 보통 20 ~ 5000 개 정도의 평균 자원이있는 자원 (jpg 이미지)이 있습니다. 각 리소스에는 오늘 colo 설정을 통해 제공되는 고유 한 URL이 있습니다.
나는 이러한 모든 리소스를 S3로 전송하고, Cloudfront를 설치하고 완료 할 수 있습니다. 만약 내가 자원을 보호 할 필요가 없다면.
대부분 엔티티는 공개 (즉, ~ 99 %)이고 나머지는 여러 가지 방법 (로그인, IP, 시간 등) 중 하나로 보호됩니다. 엔티티가 보호되면 모든 리소스를 보호해야하며 유효한 권한 부여가 수행 된 후에 만 액세스 할 수 있습니다.
두 개의 S3 버킷 (하나는 비공개이고 다른 하나는 공개)을 만들어서 해결할 수 있습니다. 비공개 콘텐츠의 경우 사용자가 승인 된 후에 서명 된 Cloudfront URL을 생성합니다. 그러나 엔티티의 상태는 공개에서 비공개로 임의로 변경 될 수 있으며 반대의 경우도 마찬가지입니다. 시스템 관리자는 엔티티 트리의 모든 레벨에서 엔티티를 변경할 수 있으므로 트리 전체에서 계단식 변경이 발생합니다. 하나의 변경으로 인해 ~ 20,000 개의 엔티티가 200 개의 리소스로 변경되어 4 백만 개의 리소스에 영향을 줄 수 있습니다.
상태 변경에 대한 백그라운드 모니터링에서 서비스를 실행할 수는 있지만 성가신 일이며 4 백만 개의 S3 항목의 ACL을 변경하는 데는 상당한 시간이 걸릴 것입니다. 그런 일이 발생하는 동안 비공개 개인 콘텐츠, 또는 서명 된 URL을 생성해야하는 공개 콘텐츠
또 다른 가능성은 기본적으로 모든 리소스를 비공개로 만드는 것입니다. 엔티티에 대한 모든 요청마다 엔트리에 포함 된 모든 리소스 (사용자 지정 정책의 와일드 카드 URL을 사용하여)에 특정 사용자에 대한 액세스 권한을 부여하는 사용자 지정 정책을 생성합니다. 이것은 엔티티마다 각 방문자에 대한 정책을 생성해야합니다.하지만 문제는되지 않습니다. 그러나 이는 새로운 세션마다 URL이 변경되므로 사용자가 더 이상 캐시 할 수 없음을 의미합니다. 비공개 콘텐츠에는 문제가되지 않지만 공개 된 엔티티의 99 %에 대해 모든 캐싱을 처리해야합니다.
또 다른 옵션은 모든 콘텐츠를 비공개로 유지하고 위의 방식을 개인 엔터티에 사용하는 것입니다. 공개 엔티티의 경우 모든 사용자가 공유 할 공용 엔티티 당 하나의 사용자 정의 정책을 생성 할 수 있습니다. 6 시간의 수명을 설정하고 5 시간 후에 새 정책을 생성하게되면 사용자는 최소 1 시간의 정책 수명을 보장 받게됩니다. 이렇게하면 상태를 변경 한 후 최대 6 시간 동안 비공개 콘텐츠를 공개 할 수 있으며 최대 6 시간 동안 캐싱을 사용할 수 있다는 이점이 있습니다. 이것은 받아 들일 만하지만, (캐시/요청 비율의 현재 작업을 시도하는) 가치가 있는지 모르겠습니다. 분명히 민간 단체에 대한 더 길거나 더 짧은 노출의 비용으로 길거나 짧은 캐시를 가능하게하기 위해 5/6 시간 경계를 조정할 수 있습니다.
비슷한 솔루션을 배포 한 사람이 있습니까? 내가 간과하고있는 AWS 기능은 사용 중일 수 있습니까? 일반적으로 의견이 있습니까?
@ 마크 업적으로 편집 해 주시면 고맙겠습니다. –
귀하의 의견에 따라 편집 된 부분을 제거하고 답변을 추가했습니다. 감사! –