8

現在、多くのエッジロケーションでCloudFrontを使用して、さまざまなサイズのサイズに動的にサイズ変更された製品画像（50万近く）を提供しています。Cloudfrontディストリビューションは、オリジンEC2 phpスクリプトを使用してS3から元の画像を取得し、提供されたクエリ文字列基準（幅、高さ、トリミングなど）に基づいて動的に変換し、Cloudfrontにストリーミングして、エッジの場所にキャッシュします。

ただし、キャッシュされていない画像を初めてロードするWebサイトの訪問者は、この非常に大きな変換に見舞われます。

エンドユーザーが特定のサイズの画像を最初にヒットしないように、（各画像のURLを要求するバッチジョブを使用して）画像を「事前キャッシュ」する機能が必要です。

残念ながら、画像はプリキャッシュサービスに割り当てられたEdge Locationにのみキャッシュされるため、別のEdge Locationを使用するWebサイトの訪問者は、キャッシュされた画像を取得できず、オリジンサーバーで大きなサイズ変更スクリプトが実行されます。

すべてのエッジロケーションが妥当なロード時間内に画像を取得できる、私たちが得た唯一のソリューションは次のとおりです。

オリジンEC2phpスクリプトを指すCloudfrontディストリビューションがあります。ただし、上記の画像変換を行う代わりに、オリジンスクリプトはリクエストとクエリ文字列のパラメーターを別のCloudfrontディストリビューションに転送します。このディストリビューションには、画像変換を実行するオリジンEC2phpスクリプトがあります。このように、画像は常にEC2インスタンス（アイルランド）の近くのエッジロケーションにキャッシュされるため、画像が別のエッジロケーションからリクエストされたときにさらに別の変換を実行する必要がありません。

したがって、たとえば、スウェーデンでのリクエストは、SwedishEdgeLocationがキャッシュしていない/image/ stream / id / 12345にヒットするため、アイルランドのEC2マシンであるオリジンにリクエストを送信します。次に、EC2の「ストリーミング」ページは別のCloudfrontディストリビューションから/ image / size / id / 12345をロードします。これは、キャッシュされていないIrishEdgeLocationにヒットします。次に、同じEC2マシンであるオリジンにリクエストを送信しますが、サイズ変更を行う「サイズ」ページにリクエストを送信します。この後、スウェーデンとアイルランドの両方のEdgeLocationに画像がキャッシュされます。

さて、フランスからのリクエストで同じ画像がリクエストされました。フレンチエッジロケーションにはキャッシュされていないため、オリジンを呼び出します。これは、アイルランドのEC2マシンであり、アイルランドのエッジロケーションに再びヒットする2番目のCFディストリビューションを呼び出します。今回は画像がキャッシュされており、すぐに返すことができます。これで、フランスのEdge Locationにも画像がキャッシュされますが、「サイズ変更」ページを呼び出す必要はありません。アイルランドでは、キャッシュされた画像を含む「ストリーミング」ページのみです。

これは、アイルランドの「事前キャッシュ」バッチサービスが、アイルランドのEdge Locationに対してリクエストを実行し、ウェブサイトの訪問者からリクエストされる前に画像を事前にキャッシュできることも意味します。

少しばかげているように見えることはわかっていますが、画像のサイズが変更されている間、エンドユーザーが長時間待つ必要がないという要望があれば、それが唯一の具体的な解決策のようです。

別の/より良い解決策を見落としていませんか？上記へのコメントはありますか？

4

2 に答える 2

1

これが読み込み時間を短縮するかどうかはわかりません (これが目標だった場合)。

はい、このセットアップは「変換時間」をいくらか節約しますが、一方で、サーバー間の追加の通信も作成します。

IEクライアントはフランスの POP を呼び出します >> フランスの POP はアイルランドの POP を呼び出します = ダウンロード時間の 2 倍 (および一部) は、「変換時間」よりも長くなる可能性があります...

私は Incapsula で働いており、ダイナミック コンテンツ キャッシングを処理する独自の動作分析ヒューリスティック プロセスを実際に開発しました。(ここに簡単に文書化されています: http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning )

私たちの施設は次のとおりです。

1 つの Web サイトに何百万もの動的オブジェクトを含めることができますが、繰り返し要求されるのはそのうちの一部だけです。

このロジックに従って、訪問パターンを学習し、キャッシュに適した「候補」を見つけて、それらを冗長サーバーにキャッシュするアルゴリズムがあります。（したがって、上記の「二重ダウンロード」を回避します）

その後、コンテンツは 5 分ごとに再スキャンされ、新鮮さを維持し、ヒューリスティック システムが追跡して、コンテンツが依然として人気があることを確認します。

これは単純化しすぎた説明ですが、ユーザーが最も必要としているものを見つけるという核となる考え方を示しています。すべての POP に参加します。鮮度を維持し、傾向を検出するために追跡します。

お役に立てれば。

于 2012-10-02T14:11:34.730 に答える
0

ちょっとした考え...

2 つのキャッシュを実行します。

  1. 各エッジロケーションに 1 つ、
  2. アイルランドのサーバー (複数のサーバーの場合は Elasticache) に 1 つ。数分以上キャッシュする必要はありません。

データ パイプラインまたはキューにアタッチされたマイクロ インスタンスを実行する。

リクエストがオリジンサーバーに届くと、画像を返し、サーバーがキャッシュします。また、URL をキューにドロップします。

次に、デーモンが各エッジ ロケーションに対して複数の呼び出しを行うようにします。この時点で、サーバーは再びヒットします (他のエッジ ロケーションには画像がないため)。ただし、高価な変換を実行する必要なく、キャッシュからすぐに提供されます。

変換を行っておらず、キャッシュからのみ提供している場合は、大したことではありません。

するとこんな流れになります

Request -> Cloud Front -> EC2 -> Add to cache   -> Response -> CloudFront Cache -> User
     -                        -> Queue new request at each edge location
Request -> Cloud Front -> EC2 -> already cached -> Response -> CloudFront -> User

すでに提供され、キャッシュされていることを示す何らかの形式のマーカーが必要です。そうしないと、無限ループになってしまいます。

于 2013-09-06T13:51:14.603 に答える