S3+Cloudfront への移行を検討しているシステムのアーキテクチャの簡単な紹介から始めましょう。
ツリーには多数のエンティティの順序があります。木の葉には多数のリソース (具体的には jpg 画像) があり、通常は 20 ～ 5000 のオーダーで、平均は ~200 です。各リソースには固有の URL があり、今日の colo セットアップを通じて提供されます。
これらのリソースをすべて S3 に転送し、その上に Cloudfront をセットアップすれば完了です。リソースを保護する必要がなければ。
ほとんどのエンティティは公開されており (つまり、~99%)、残りは多くの方法 (ログイン、IP、時間など) のいずれかで保護されています。エンティティが保護されたら、すべてのリソースも保護する必要があり、有効な承認が実行された後にのみアクセスできます。
これを解決するには、2 つの S3 バケット (1 つはプライベート、もう 1 つはパブリック) を作成します。プライベート コンテンツについては、ユーザーが承認された後に、署名付きの Cloudfront URL を生成します。ただし、エンティティの状態は、パブリックからプライベートに任意に変更される場合があり、その逆も同様です。システムの管理者は、エンティティ ツリーの任意のレベルでエンティティを変更する可能性があるため、ツリー全体にカスケード変更が発生します。1 つの変更により、約 20,000 個のエンティティが変更され、200 個のリソースが乗算され、400 万個のリソースに影響を与える可能性があります。
状態の変化を監視するバックグラウンドでサービスを実行することもできますが、それは面倒です。また、400 万の S3 アイテムの ACL を変更するにはかなりの時間がかかります。その間、保護されていないプライベート コンテンツまたはパブリック コンテンツが保護されていないことになります。の署名付き URL を生成する必要があります。
もう 1 つの可能性は、デフォルトですべてのリソースを非公開にすることです。エンティティに対して行われるすべてのリクエストで、その特定のユーザーに対して、エンティティに含まれるすべてのリソースへのアクセスを許可するカスタム ポリシーを生成します (カスタム ポリシーでワイルドカード URL を使用することにより)。これには、訪問者ごと、エンティティごとにポリシーを作成する必要がありますが、問題にはなりません。ただし、新しいセッションごとに URL が変わるため、ユーザーは何もキャッシュできなくなります。プライベート コンテンツにとっては問題ではありませんが、公開されているエンティティの ~99% に対してすべてのキャッシュを破棄するのは面倒です。
さらに別のオプションは、すべてのコンテンツを非公開にして、上記のアプローチを非公開エンティティに使用することです。パブリック エンティティの場合、すべてのユーザーが共有する、パブリック エンティティごとに 1 つのカスタム ポリシーを生成できます。有効期間を 6 時間に設定し、5 時間後に新しいポリシーを確実に生成した場合、ユーザーには少なくとも 1 時間のポリシー有効期間が保証されます。これには、キャッシュを最大 6 時間有効にできるという利点がありますが、状態が変化した後、プライベート コンテンツを最大 6 時間公開できる可能性があります。これは受け入れられますが、それだけの価値があるかどうかはわかりません (現在、リクエストのキャッシュ/ヒット率を計算しようとしています)。明らかに、5/6 時間の境界を微調整して、プライベート エンティティへの露出が長く/短くなるという代償を払って、キャッシュを長く/短くすることができます。
誰かが同様のソリューションを展開しましたか? 私が見落としている AWS の機能のうち、役に立つものはありますか? 一般的なコメントはありますか？