CDN はどのように機能するのか？

Scrapeless プロキシを使用すると、アプリケーションは地域別のウェブリクエストに対してサポートされている出口ロケーションを選択できます。

CDN（コンテンツデリバリーネットワーク）は、ユーザーにより近い、またはより良好に接続されたネットワーク上のロケーションを介してコンテンツを配信する、分散したサーバー群のことです。CDN は一般的にキャッシュ可能なレスポンスを保存し、それ以外のリクエストをオリジンサービスへ転送します。これによりオリジンでの繰り返し処理を減らすことができますが、その動作はルーティングやキャッシュの構成に依存します。

データ収集者にとっての実務的な影響は、同じ URL であっても必ずしも新鮮なオリジンレスポンスを意味しないということです。リクエストは保存された表現、新たに取得された表現、または地域やリクエストヘッダーによって変化するレスポンスを受け取る場合があります。これらの経路を理解することが、観測結果が異なる理由を説明する助けになります。

オリジンとエッジとは何か？

オリジンはCDNの背後にあるソースサービスであり、エッジロケーションはCDNの配信ネットワーク内でリクエストを処理します。 コンテンツ配信ネットワークモデル すべてのクライアントが1つのオリジンロケーションと通信する必要があるのではなく、複数のロケーションに配信を分散します。

エッジは、ストレージからレスポンスを提供したり、リクエストを転送したり、TLS を終端させたり、設定されたロジックを適用したりする場合があります。すべての CDN が、すべてのリクエストに対してあらゆる機能を実行するわけではありません。そのため、有用な説明は、ネットワークの能力と、特定のホスト名で有効化されているポリシーとを切り分けて考える必要があります。

オリジンは、Web アプリケーション、オブジェクトストア、または別のサービスエンドポイントである場合があります。オリジン自体が負荷分散や複数のサーバーを利用していることもあります。CDN とオリジンは配信経路における論理的な役割であり、Web サイト全体が 1 台のソースマシンと 1 つのキャッシュだけで構成されていることを意味するわけではありません。

リクエストはどのようにしてCDNに到達するのか？

リクエストは、サイトで構成されたルーティングを通じて CDN に到達します。ここには DNS やネットワークルーティングに関する決定が含まれる場合があります。ホスト名はクライアントを CDN のエンドポイントへと誘導し、ネットワークは接続を適切な配信拠点へ運びます。選択される拠点は、必ずしも地理的に最も近い建物とは限りません。

ネットワークトポロジー、サービスポリシー、そして現在のルーティングは経路に影響を与えます。そのため、ある国にいるクライアントと別の国にあるプロキシ出口では、配信動作が異なって見えることがあります。結果は、コレクターの物理的なオフィス所在地から推測するのではなく、アプリケーション接続で測定すべきです。

エッジがリクエストを受信すると、ホスト、パス、メソッド、ヘッダー、および適用可能な設定が評価されます。静的アセットと認証済みアカウントページは、同じウェブサイトに属していても、異なる処理ルールに従うことがあります。CDN が存在するという事実だけでは、特定のレスポンスがキャッシュ可能かどうかは決まりません。

キャッシュヒットまたはミスが発生するとどうなりますか？

キャッシュヒットは、キャッシュが、そのルールに従って提供することを許可された適切な保存済みレスポンスを保持している場合に発生します。ミスは、要求が、利用可能な保存済みレスポンスでは満たすことができないコンテンツを必要とする場合に発生します。その場合、エッジは通常、オリジンまたは別のキャッシュ階層などの上流サービスからコンテンツを取得します。

1. エッジは、リクエストと設定されたルールからキャッシュキーを生成します。
2. そのキーおよび関連するバリエーションに一致する保存済みのレスポンスを探します。
3. それは最新性と、上位のサービスに連絡する必要があるかどうかを評価します。
4. 有資格のある応答を提供するか、適切な上流の応答を取得します。
5. 応答とキャッシュポリシーが保存を許可している場合にのみ、新しい応答を保存します。

ミスがあるからといって、必ずしも CDN が壊れていることを意味するわけではありません。新しいコンテンツ、有効期限が切れたエントリ、意図的にキャッシュしないページ、まれなバリアントなどは、いずれもオリジンサーバーでの処理を必要とする場合があります。ヒット率が高いことが有用なのは、その配信されるコンテンツが、関係するユーザーとリクエストに対して正しい場合に限られます。

異なるエッジロケーションでは異なるオブジェクトを保持している場合があります。あるロケーションでの取得が成功しても、すべてのロケーションに同じ保存済みレスポンスがすでに存在することの証明にはなりません。配信システムはいくつかのキャッシュ階層を使用できるため、正確な経路はプロバイダーやサイト構成によって異なります。

キャッシュキーを決定するものは何か？

キャッシュキーは、どのリクエストが同じ保存済み表現を再利用できるかを決定する。一般的には、対象リソースの識別情報を含み、標準的なセマンティクスやサイト固有の設定を通じて、追加のリクエスト特性を組み込むことができる。

The HTTP Vary フィールド 表現の選択に影響したリクエストフィールドを特定します。受け入れられたエンコーディングや言語によってコンテンツが異なる場合、それらの次元は保存されたレスポンスを選択する際に重要になることがあります。重要な変化を無視するキャッシュは、誤った表現を返す可能性があります。

クエリ文字列には明確なポリシーが必要です。いくつかのアプリケーションでは、クエリ文字列は異なるリソースを識別するために使用されますが、他のものではトラッキングのために使用されます。すべてのクエリパラメータを無関係とみなすと、別個のコンテンツが統合されてしまう可能性があります。すべてのパラメータを一意のキーとして扱うと、キャッシュが断片化され、再利用性が低下する可能性があります。

仮想的な地域向け製品ページについて、通貨とマーケットを URL、ヘッダー、またはクッキーのどれで表現するかを決定します。その決定は、アプリケーションとキャッシュ設定の両方に影響します。キャッシュキーは、パスだけに基づく推測ではなく、表現の実際の同一性を反映すべきです。

鮮度、検証、保存は別物である

鮮度は、保存されたレスポンスを上流を確認せずに再利用できるかどうかを判断し、一方、検証はその保存されたレスポンスが依然として適用可能であるかどうかを確認します。ストレージポリシーは、そもそもそのレスポンスを保存してよいかどうかを決定します。 HTTP キャッシュ規則 これらの決定を区別する。

no-cache のレスポンスは依然として保存可能ですが、再利用には、適用されるルールの下での検証成功が必要です。no-store のレスポンスは、キャッシュに保存しないよう指示します。private のレスポンスは、通常の無条件の場合には共有キャッシュへの保存を制限します。これらのディレクティブは、すべてのキャッシュを無効化するための互換的な別表記として扱うべきではありません。

エンティティタグなどのバリデーターにより、上流サーバーは保存された表現が引き続き利用可能であることを確認できます。条件付きリクエストにより、表現が変更されていない場合に、完全なボディを再転送することを避けられる場合があります。検証では依然として上流での確認が必要であり、保存された新鮮なレスポンスを即座に提供することとは異なります。

Age フィールドは、レスポンスがキャッシュおよび関連する転送経路内にとどまっているおおよその時間を表します。これは基礎となるビジネス事実の経過時間ではありません。レスポンスが最近生成された場合でも、製品価格が何日も変わっていないこともあれば、キャッシュされたレスポンスが作成された後にソース側で変更されていることもあります。

コンテンツ更新はどのようにエッジへ届くのか？

コンテンツ更新は、有効期限切れ、検証、明示的な無効化、または新しいリソース ID を通じてユーザーに届きます。どのメカニズムが適用されるかは、サイトのデプロイ方法とキャッシュポリシーによって異なります。オリジンで変更を公開しても、すべての保存済みエッジレスポンスがすでに削除されていることを自動的に意味するわけではありません。

バージョン付きアセット URL は、変更されたファイルに明確な ID を与えます。デプロイが新しいファイル名を参照するようになると、キャッシュは古いオブジェクトを保持していても、それを新しいものと混同しません。このアプローチは、1 つの URL の下で内容が安定しているべきアセットに有用です。

頻繁に変更されるドキュメントには、異なる鮮度ポリシーが必要です。公開のお知らせページと口座残高ページは、どちらも HTML で配信されたとしても要件が異なります。キャッシュ有効期間は、コンテンツの許容される陳腐化度合いと、表現のプライバシー特性に合わせるべきです。

更新を調査する際は、URL、レスポンスヘッダー、ボディのバージョンを合わせて比較してください。cache-status ヘッダーは有用な証拠になり得ますが、そのフィールド名と解釈はプロバイダーごとに異なります。あるベンダーのヘッダー語彙を、普遍的な HTTP 標準として扱うことは避けてください。

TLS 終端は何を変えるのか？

TLS を終端する CDN は、クライアント接続を復号し、オリジンへの別のセキュア接続を作成する場合があります。 TLS 接続モデル は、それぞれのセキュア接続に個別に適用されます。

エッジは、コンテンツ認識型のルーティングとキャッシュを適用するために HTTP リクエストへアクセスする必要があります。エッジからオリジンへの接続は、別個の信頼および転送設定を持ちます。公開ホスト名で有効な証明書があっても、それだけではオリジン向き接続の構成を検証したことにはなりません。

収集者にとって、公開証明書はクライアントの信頼ルールの下で想定されるエンドポイントを認証します。ただし、それによってボディがキャッシュから来たのか、どの内部サービスが生成したのか、ページに目的のレコードが含まれているのかはわかりません。これらの問いには、レスポンスとコンテンツの検査が必要です。

なぜ地域別チェックでコンテンツが異なることがあるのか

地域別チェックが異なる結果になるのは、Web サイトおよび配信システムが異なるリクエストコンテキストを受け取るためです。出口ロケーション、リゾルバの挙動、言語ヘッダー、保存されたセッション設定などが、観測される表現に影響を与え得ます。違いを CDN の不整合と表現する前に、その差異を調査するべきです。

「 Scrapeless のプロキシロケーション設定 」では、利用可能な出口ロケーションの選択をサポートしています。比較の中では選択した地域を安定させ、観測結果とあわせて想定する市場を記録してください。ゲートウェイの地域が、宛先側で使用される出口地域であるとは限りません。

Scrapeless プロキシソリューション は、アプリケーション側がコンテンツ検証を担う一方で、これらのチェックのためのネットワーク観点を提供できます。関連する クラウドプロキシアーキテクチャ の記事では、その中継的役割を説明しています。地域別アセットやページチェックの帯域を見積もる際は、 Scrapeless 料金 を参照してください。

有用な観測記録には、要求された URL、最終的な URL、収集コンテキスト、応答時間、適切であればコンテンツ識別子またはハッシュが含まれます。ハッシュは比較されるバイト列の同一性を証明するものであり、ユーザー体験の同一性を証明するものではありません。動的スクリプトは、初期ドキュメントが似ていても、異なる描画挙動を生み出すことがあります。

CDN の症状をどのように解釈するか

CDN の症状は、接続性、キャッシュ挙動、コンテンツの正しさを切り分けて解釈してください。あるアセットは読み込めるがページは読み込めない場合、それぞれのポリシーと上流サービスを比較します。レスポンスが古い場合は、収集クライアントを変更する前に、鮮度および検証の証拠を確認してください。

素早く配信されたレスポンスが、エッジに保存または生成されたエラーページであることもあります。ゆっくり配信されたレスポンスでも、正しく、オリジンから新たに取得されたものである場合があります。レイテンシだけでは結果を分類できません。アプリケーションが要求するフィールドやページマーカーを利用してください。

同様に、あるリソースが CDN によって正常に配信されたとしても、認証されたアプリケーションビューが正しくレンダリングされていることの証明にはなりません。そのリソースは公開されている一方で、そのビューは認証情報、スクリプト、その他の依存関係を必要とするかもしれません。実際の要件がユーザー向け操作全体である場合は、その一連の操作を検証してください。

結論

CDN は、明示的なキャッシュルールの下でリクエストをルーティングし、再利用可能なコンテンツを再利用します。レスポンスを解釈する前に、キャッシュキー、鮮度ポリシー、TLS 境界を理解してください。地域データの作業では、収集コンテキストを保持し、成功を配信速度ではなく返された表現によって判断してください。