12

私はプルアンドプッシュCDNについて読んでいます。サイズ変更された画像のプルCDNとしてCloudfrontを使用しています。

  • クライアントから画像を受信する
  • 画像をS3に入れる

後で、クライアントがCloudfrontにURLをリクエストすると、Cloudfrontにはイメージがないため、サーバーに転送する必要があります。これにより、次のようになります。

  • リクエストを受け取る
  • S3から画像をプル
  • 画像のサイズを変更する
  • 画像をCloudfrontにプッシュバック

ただし、これには数秒かかります。これは、最初に美しい画像をアップロードして見たいときに、非常に煩わしい待機です。遅延は、サイズ変更ではなく、ほとんどの場合ダウンロード/再アップロード時間であるように見えます。これはかなり高速です。

サイズ変更された画像をプロアクティブにCloudfrontにプッシュしてURLに添付し、将来のリクエストで準備された画像をすぐに取得できるようにすることは可能ですか？理想的には

  • クライアントから画像を受信する
  • 画像をS3に入れる
  • 一般的なサイズの画像のサイズを変更する
  • これらのサイズを先制的にクラウドフロントにプッシュする

これにより、ダウンロード/再アップロードサイクル全体が回避され、一般的なサイズが非常に高速になりますが、あまり一般的でないサイズにもアクセスできます（最初は遅延がありますが）。ただし、これを行うには、イメージをCloudfrontにプッシュする必要があります。これ：

http://www.whoishostingthis.com/blog/2010/06/30/cdns-push-vs-pull/

それができることを示唆しているようですが、私が見た他のすべてはそれについて言及していません。私の質問は：それは可能ですか？または、私が見逃しているこの問題に対する他の解決策はありますか？

4

3 に答える 3

6

私たちはさまざまな CDN プロバイダーで同様のことを試みましたが、CloudFront の場合、クラウドフロント ディストリビューションがあなたのカスタムの原点。

私が考えることができる1つの方法は、@ Xint0で言及されているように、プッシュしたいファイル（あなたの場合はサイズ変更された画像）を具体的にホストするために別のS3バケットをセットアップすることです。基本的に、2 つの cloudFront ディストリビューションがあり、1 つはめったにアクセスされないファイルをプルし、もう 1 つは頻繁にアクセスされるファイルとサイズ変更が予想されるイメージをプッシュします。これは少し複雑に聞こえますが、それはあなたがしなければならないトレードオフだと思います。

別の CDN プロバイダーである EdgeCast を参照することをお勧めします。これは load_to_edge という関数を提供します (先月、これをサービスに統合するためにかなりの時間を費やしました。そのため、はっきりと覚えています)。まさにあなたが期待するもの。また、カスタムのオリジン プルもサポートしているため、そこで試用できるかもしれません。

于 2012-05-08T01:50:35.520 に答える
5

OPはプッシュCDNソリューションを求めていますが、彼は本当に物事をより速くしようとしているようです. おそらくCDNプッシュを実装する必要はなく、オリジンサーバーパターンを最適化するだけでよいと思います。

OP さん、サポートしている画像サイズはほんの一握りだと思います。たとえば、128x128、256x256、512x512 などです。また、これらのイメージの元のバージョンが S3 にあるようです。

これは、キャッシュ ミスで現在発生していることです。

  1. CDN が 128x128 バージョンのイメージのリクエストを受け取る
  2. CDN にはそのイメージがないため、オリジン サーバーから要求します
  3. オリジンサーバーがリクエストを受け取ります
  4. オリジンサーバーが S3 から元のイメージをダウンロードします (おそらくより大きなイメージ)
  5. オリジンはその画像のサイズを変更し、CDN に返します
  6. CDN はその画像をユーザーに返し、キャッシュします

代わりに何をすべきか：

正確な状況に応じて、いくつかのオプションがあります。

現在の設定ですぐに修正できることがいくつかあります。

  1. S3 から元の画像をフェッチする必要がある場合、基本的には、キャッシュ ミスが発生すると、すべての画像のダウンロードに元のサイズの画像と同じくらいの時間がかかるようになります。可能であれば、元のサーバーがすぐにアクセスできる場所に元の画像を隠しておくようにしてください。ここには、セットアップに応じて 100 万の異なるオプションがありますが、S3 からそれらをフェッチするのは、それらすべての中で最も遅いです。少なくとも、Glacier を使用していません ;)。
  2. サイズ変更された画像をキャッシュしていません。これは、Cloudfront が使用するすべてのエッジ ノードがこのイメージを要求し、それがサイズ変更プロセス全体をトリガーすることを意味します。Cloudfront には何百もの個別のエッジ ノード サーバーがある場合があります。Cloudfront が階層型配布に対して何を行うか、およびファイル ヘッダーをどのように設定するかによって、実際にはそれほど悪くはないかもしれませんが、良くはありません。
  3. 私はここで手足を出していますが、カスタムの有効期限ヘッダーを設定していないに違いありません。つまり、Cloudfront はこれらの各イメージを 24 時間しかキャッシュしていません。アップロードした画像が不変である場合は、新しいバージョンを長い間チェックしないように CDN に指示する有効期限ヘッダーを返すことで、本当にメリットが得られます。

潜在的により良いパターンのいくつかのアイデアを次に示します。

  1. 誰かが新しい画像をアップロードしたら、すぐにサポートするすべてのサイズにトランスコードし、S3 にアップロードします。次に、CDN をその S3 バケットに向けるだけです。これは、サポートされている画像サイズの管理可能な数があることを前提としています。ただし、サポートする画像サイズが多すぎる場合、CDN は完全に間違ったソリューションになる可能性があることを指摘しておきます。キャッシュ ヒット率が非常に低いため、CDN が実際に邪魔をしている可能性があります。その場合は、次のポイントを参照してください。
  2. 継続的なサイズ変更のようなものをサポートしている場合 (つまり、image_57x157.jpg や image_315x715.jpg などをリクエストでき、サーバーがそれを返す)、CDN は実際には、余分なホップを導入することで、あなたの元。その場合、利用可能なすべてのリージョンで EC2 インスタンスをスピンアップし、それらにオリジン サーバーをインストールしてから、クライアント IP に基づいてイメージ URL をリージョンごとに適切なオリジンにスワップします (独自の CDN を効果的にローリングします)。

そして、本当に Cloudfront にプッシュしたい場合:

おそらくその必要はありませんが、どうしても必要な場合は、次の 2 つのオプションがあります。

  1. webpagetest.org APIを使用して世界中のさまざまな場所から画像を取得するスクリプトを作成します。ある意味では、すべての異なるエッジ位置にプル コマンドをプッシュすることになります。これにより、すべてのエッジ ロケーションにデータが入力されることが保証されるわけではありませんが、おそらく近くなる可能性があります。webpagetest.org がこのように使用することにどれほど興奮するかはわかりませんが、使用条件 (IANAL) には何も表示されません。
  2. サードパーティを使用したくない場合、または webpagetest.org をいらいらさせるリスクがある場合は、すべてのリージョンでマイクロ EC2 インスタンスをスピンアップし、それらを使用してコンテンツを取得します。これは #1 と同じです。
于 2013-10-24T23:45:55.433 に答える
2

私の知る限り、CloudFront は S3 バケットをデータストアとして使用します。そのため、画像のサイズを変更した後、サイズ変更された画像を CloudFront が直接使用する S3 バケットに保存できるはずです。

于 2012-05-02T18:54:50.790 に答える