さまざまなタイプのアセット/ファイルを別々の S3 バケットに保存するための推奨戦略があるのか 、それともすべてを 1 つのバケットに入れるだけなのか疑問に思っていますか? 私が持っているさまざまな種類のアセットには、静的なサイト画像、ユーザーのプロフィール画像、ドキュメント、ファイル、ビデオなどのユーザー生成コンテンツが含まれます。
1 に答える
0
ファイルをバケットにグループ化する方法に関する限り。コンテンツの種類ごとに異なるドメイン名または CNAME を使用する場合を除き、これはそれほど重要な問題ではありません。その場合、使用するドメイン名ごとに個別のバケットが必要になります。
それらを機能別にグループ化する傾向があります。おそらく、完全に制御できるアプリケーションで使用される静的ファイルは、ユーザーが生成するコンテンツとは別のバケットにデプロイされる可能性があります。または、画像などとは異なるバケットにビデオを入れたい場合があります。
S3 メタデータに関する以前のコメントに追加します。これは、S3/Cloudfront からコンテンツをサーバーにアップロードする方法を最適化する上で重要な部分になります。
基本的に、S3 メタデータはキーと値のペアで構成されます。したがって、たとえばファイルが .jpg の場合、Content-Type値をキーとして持つことができます。image/jpegこれにより、S3 URL に直接または Cloudfront 経由で行われたリクエストの値に対応する適切な Content-Type ヘッダーが自動的に送信されます。同じことが Cache-Control メタタグにも当てはまります。独自のカスタム メタタグを使用することもできます。たとえばx-amz-meta-md5、ファイルの md5 ハッシュを保存するために、という名前のカスタム メタタグを使用します。リビジョン管理システムに保存されているコンテンツとの単純なバケット比較に使用されるため、バケット内の各ファイルのチェックサムをその場で作成する必要はありません。これを使用して、差分コンテンツの更新をバケットにプッシュします (つまり、変更されたもののみをプッシュします)。
リビジョン管理がどのように行われるかについて。バージョン管理されたファイル名を使用することを強くお勧めします。つまり、bigimage.jpg があり、更新を行いたいとします。これを bigimage1.jpg と呼び、これを反映するようにコードを変更します。なんで？最適には、Cache-Control ヘッダーに長い有効期限を設定したいからです。残念ながら、その後同じ名前のファイルをデプロイする必要があり、Cloudfront を使用している場合、エッジ キャッシュの場所を無効にすることが問題になります。一方、新しいファイル名がある場合、Cloudfront はエッジ ノードへの入力を開始するだけなので、キャッシュの無効化についてまったく心配する必要はありません。
同様に、ユーザーが作成したコンテンツの場合、md5 またはその他の (ほとんどの場合) 一意の識別子スキームを含めて、各ビデオ/画像に独自の一意のファイル名と場所をキャッシュに含めることができます。
参考までに、Cloudfront でのストリーミングの設定に関する AW のドキュメントへのリンクを次に示します。
于 2012-09-06T19:14:15.307 に答える