ウェブホスティング

CDN設定が気づかないうちにウェブサイトのパフォーマンスを低下させるメカニズム

CDNの設定 は手っ取り早い解決策のように聞こえますが、不正確なルール、SSLハンドシェイクのオーバーヘッド、弱いオリジン・リソースは、気づかないうちにロード時間を増加させる可能性があります。小さな設定の詳細がいかに大きなブレーキとなりうるか、そしてこれらのトラップを測定可能かつ恒久的に軽減する方法をお見せします。.

中心点

キャッシュ・ルール エッジサーバーがコンテンツを配信するか、常にOriginに負担をかけるかを決定する。.
SSL/TLS とプロトコルの選択により、ハンドシェイクと再利用が適合しない場合、ラウンドトリップが増加する。.
オリジン・リソース とI/Oはグローバルエッジにもかかわらずスループットを制限する。.
DNS/ルーティング エニーキャストとピアリングが不利な場合、レイテンシーが発生する。.
TTL/パージ 交換後の鮮度、一貫性、負荷のピークを管理する。.

なぜCDNは速度を低下させるのか

をよく見かける。 エッジ が特に効果的なのは、クリーンなキャッシュから可能な限り多くのオブジェクトを配信し、オリジンへのクエリーをまれにしか行わない場合だ。静的アセットと動的アセットが明確に分離されていない場合、CDNは無数の バイパス をOriginに追加することになり、優位性が薄れてしまう。追加のDNS解決、新しいTCPハンドシェイク、キープアライブの失敗のたびにミリ秒単位のコストがかかる。データパスが離れたPoPを経由する場合、遅延は数ホップにわたって蓄積されます。ユーザーは、レンダリング開始時の遅さや最初のバイトまでの時間として、これらの合計に気づく。.

キャッシュとルーティングにおける隠れた障害

違う キャッシュ・コントロール-ヘッダ、静的ファイルのクッキー設定、関連性のないクエリ文字列は、エッジにオリジンフェッチを強制します。私はまず、クッキー、認証ヘッダー、CSS/JS/画像のクエリーパラメーターの変更が本当に必要かどうかをチェックします。Varyルールが正しければ、キャッシュヒット率は顕著に向上する。より深く掘り下げたい場合は、簡単な例を見てみよう。 HTTPキャッシュヘッダである。同様に重要なのは、過負荷のPoPに不用意にリクエストを誘導し、コンマ何秒を無駄にするルーティング・ポリシーである。 レイテンシー を追加した。.

SSL/TLS：ハンドシェイクとプロトコルを正しく使う

TLSハンドシェイクを追加すると、2往復分のコストがかかる。遅延. .クライアントとエッジ間の単純なRTTが95ミリ秒だとすると、最初のバイトが流れる前に、新しいハンドシェイクが200ミリ秒近く追加されることになる。私はTLS 1.3、セッション再開、0-RTTに頼っているので、再訪問者は高価な再構築を開始することはない。HTTP/2はストリームを1つのコネクションにバンドルし、HTTP/3/QUICは不安定なネットワークでのヘッド・オブ・ラインのブロッキングを減らす。 安定性 を使用せずにスループットを向上させることができる。エッジとオリジン間のコネクションの再利用は依然として重要であり、そうでなければバックエンドのハンドシェイクが全ての利得を食いつぶしてしまう。.

ボトルネックとしてのオリジンサーバー

弱い起源なぜなら、ミスや再検証がそこで保留されるからである。CPUが十分でない場合、PHPやノードのプロセスがバックアップし、タイムアウトが蓄積される。RAMとIOPSが不足すると、データベースが遅くなり、キャッシュウォームフェーズがすべて顕著なキューで終わる。私はCDNを調整する前に、CPUスティール、iowait、オープンコネクションなどのメトリクスをチェックする。オリジンが高いパフォーマンスで応答したときだけ、CDNは大規模な接続をピックアップします。勝利端から。.

ネットワーク、レイテンシー、DNSの設計

を測定する。 通信事業者 ユーザー、Edge、Originを別々に監視しています。また、DNSの解決時間や接続の再利用率も監視しています。CDNバックボーンとオリジンのデータセンター間の不利なピアリングは、すべてのミスをより高価なものにする。エニーキャストはしばしば役に立ちますが、個々のケースではPoPが過密になります。エニーキャストDNS. .そのため、私はグローバルなテストを行う前に、実際のトレースでターゲットとなる地域をテストしている。流通を計算する。.

効果的なキャッシュパージとTTL戦略

クリーンなし TTL-ロジック、エッジは古すぎるコンテンツを配信したり、不必要な再検証をソースに浴びせたりします。私は、プロキシにはs-maxageを使い、測定可能なヘッダにはageヘッダを使い、If-None-Matchが本当に意味を持つ場合のみETagsを使う。トラフィックのピーク時には完全なパージは行わず、タグやパスごとにパージを行います。デプロイ後のDiffベースのパージは、リソースを節約し、キャッシュのコールドショックを防ぎます。以下の表は ガイドライン をスタート値として使用する：

コンテンツタイプ	推奨TTL	パージ・トリガー	TTLが高すぎる／低すぎる場合のリスク	CDNルールノート
バージョン管理されたCSS/JS（例：app.v123.js）	7～30日	新バージョン	高すぎる：リスクはほとんどない、低すぎる：ミスが多い	クッキーなしでキャッシュキー、クエリーは無視
画像/フォントは変更なし	30～365日	資産スワップ	高すぎる：時代遅れの資産、低すぎる：原点負荷	イミュータブル設定、Gzip/Brotliチェック
HTMLスタティック（マーケティングページ）	15～120分	コンテンツ更新	高すぎる：古いコンテンツ、低すぎる：再検証	s-maxage、Stale-While-Revalidate
HTMLダイナミック（ショップ、ログイン）	0～1分	ユーザーイベント	高すぎる：パーソナライゼーションが正しくない。	クッキー/認証ごとのBYPASS
API (GET)	30～300秒	データ変更	高すぎる：古いデータ、低すぎる：雷の鳴る炊飯器	スタール・イフ・エラー、ネガティブ・キャッシング

静的対動的 - 驚きの効果

ウェブサーバーは静的な ファイル 非常に高速で、多くの場合、動的ページよりも桁違いに高速です。しかし、プラグインが画像やCSSにクッキーを設定すると、CDNはこれらのアセットをプライベートとしてマークし、キャッシュをバイパスします。Edgeとブラウザは、それに応じて長いチェーンでソースに戻り続けます。そのため、私はすべての静的ルートのCookieフラグをチェックし、セッションCookieが含まれないように静的ドメインを分けています。これにより ヒット率 原点には本物のロジックの余地がある。.

ウォームアップとプリフェッチの賢い使い方

コールドキャッシュを殺す パフォーマンス リリース後、すべてのヒットがミスになり、Originが光るからです。私は特に重要なパスを予熱し、スタートページ、ベストセラー、重要なAPIエンドポイントに優先順位を付けます。プリフェッチとプリロードヘッダーは、フォローアップアセットを準備し、ローンチフェーズを大幅に短縮します。これを計画的に設定すれば、コンパクトなハウツーが CDNウォームアップ有用なインパルス。Stale-While-Revalidateと組み合わせることで、原点が短くてもエッジは供給可能なままである。吃音.

構成チェックリストのステップ・バイ・ステップ

私はまず キャッシュ・キー静的オブジェクトにはクッキーも不要なクエリーパラメーターも使わない。次に、Cache-Control、s-maxage、Stale-While-Revalidate、Stale-If-Errorをヘッダーで直接確認する。第三に、ダイナミック・パスのクッキー・ポリシーと認可をチェックし、パーソナライゼーションが正しく保たれるようにする。第四に、クライアント→エッジとエッジ→オリジンについて、レイテンシー、DNS時間、TLSハンドシェイクをターゲット地域から個別に測定する。第五に、デプロイ後のパージ自動化をコントロールし、新鮮なコンテンツがすぐにすべての地域で利用できるようにする。 エッジ 嘘だ。

典型的なアンチパターンとそれを避ける方法

私はグローバルに活動しない フルパージ というのも、ピーク時にはすべてのユーザーがハズレに当たってしまうからです。私は、„安全のため “に画像に非常に低いTTLを設定しません。キャッシュ内のオブジェクト数が爆発的に増えるような大げさなVaryルールは作らない。たとえ „便利 “に見えても、静的ドメインでクッキーを実行しない。そして、stale-while-revalidateの方がはるかに少ないコストで同じように新鮮な印象を与えるのに、HTMLに積極的なrevalidateは使いません。負荷達成。.

アーキテクチャの決定マルチCDN、地域ピアリング

A マルチCDN レイテンシ・コントロール・ルーティングを使うと、リクエストを現在最も速いルートに振り分けることができる。私はオリジン・シールドか階層化キャッシュを使って、ミス・ストームの場合にオリジンを保護し続けます。大規模なISPとのリージョナルピアリングは、どんなコードの微調整よりもRTTとパケットロスを減らすことが多い。404/410のネガティブキャッシングは、エラーしか返さないようなミスの繰り返しを制限する。クリーンなヘルスチェックにより、フェイルオーバーは目に見える形で機能する。 ドロップアウト ユーザーのために。.

エッジ機能：ワーカー、ESI、フラグメント・キャッシング

多くのCDNは エッジ演算ヘッダーを書き換えたり、ルートを決定したり、HTMLを動的に組み立てたりする小さな関数です。私はこれを、パーソナライゼーションをエッジでカプセル化し、HTMLの大部分をキャッシュ可能な状態に保つために使っている（フラグメント／ESIアプローチ）。落とし穴：低速な関数のコールドスタート、寛大すぎるCPU/時間制限、再現性のない状態。私は、関数を決定論的なものに保ち、p95の実行時間を測定し、キャッシュ・ヒットを可能にするか防ぐかを明示的に記録しています。.

画像、フォーマット、圧縮のクリーンコントロール

ブレッドスティック テキスト（HTML、CSS、JS）用のOrigin圧縮は、Gzipよりも圧縮率が高いですが、2回使用してはいけません。Edgeがすでにきれいに圧縮している場合はOrigin圧縮を解除し、コンテンツの長さと転送エンコーディングに注意します。WebP/AVIF形式は画像には価値がありますが、圧縮をコントロールする必要があります。可変-戦略だ。キャッシュが爆発しないようにAcceptヘッダーを正規化し、クエリー文字列ではなくファイル名でバージョン管理を行う。.

キャッシュキーの正規化とパラメータのホワイトリスト

不要 クエリーパラメーター UTM/Campaignのようなものはローファクトバリアントを生成します。私は、レンダリングやデータを本当に変更するいくつかのパラメータだけをホワイトリストに登録し、キャッシュキーの他のすべてを無視します。静的アセットについては、私は一貫してキーからクッキーを削除します。また、ほとんど関連性のないヘッダー（Accept-Languageなど）をフラットにして、機能を失うことなくオブジェクトの種類を減らしている。こうすることで、ヒット率が2桁上がることがよくあります。.

認証、署名、プライベート・コンテンツ

パーソナライズされた領域は保護する必要があるが、完全にキャッシュできないようにする必要はない。私は プライベート パブリックフラグメント（キャッシュ可能）からユーザーデータ（BYPASS）を取得し、TTLの短いダウンロード可能なオブジェクトには署名されたURLやクッキーを使用する。Authorisation/Cookieのようなセキュリティ・フラグが不用意にエッジにキャッシュされないようにする。APIについては、GETに対してのみ „public, s-maxage “を設定し、レスポンスが本当にidempotentである場合にのみ設定する。.

優先順位付け、アーリーヒント、プレコネクト

HTTP/2の優先順位付けは、エッジがやみくもに並び替えない場合にのみ機能する。優先順位は クリット・パス (画像の前にCSS）、103アーリーヒントを使用して、実際のHTMLの前にプリロードリンクを送信します。. プリコネクト 一方、過剰なdnsプリフェッチはアイドルワークを生み出す。これらのヒントが本当にダウンロードの順番を変えるかどうかを測定し、そうでなければ優先順位を修正するか、余計なヒントを省く。.

タイムアウト、リトライ、オリジンの保護

攻撃的すぎる リトライ ミスが発生するとオリジンの負荷が増加し、多くのワーカーが同時に同じリソースを待っている場合は TTFB が延長されます。短いタイムアウト、指数関数的バックオフ、コラプス・リバリデーション（「リクエストのコラプシング」）を設定し、1つのフェッチだけがオリジンに到達するようにする。サーキットブレーカーは、エラーレートが もしエラーなら はユーザーに5xxを送る代わりに配信を受け取ります。重要：エッジとオリジン間のアライブとコネクションプールを安定させてください。.

WAF、ボットトラフィック、レート制限

WAF規則 WAFは、すべてのリクエストを同期的にチェックすることが多く、レイテンシーを大幅に増加させる可能性がある。私は、安全な場所ではWAFを通過する静的パスを実行し、武装する前にルールを「ログのみ」に設定する。エラーに強いボットやスクレイパーに対しては、エッジのレート制限を制限し、既知の404ルートにはネガティブキャッシングを使用している。これにより、エッジは軽快になり、オリジンは保護され、正当なトラフィックは妨害されなくなる。.

本当に役立つメトリクス、ログ、トレース

上位パーセンタイルなしで盲目的になるのは最大の間違いだ。私は p95/p99 TTFB, エッジのヒット率、再利用率、TLS ハンドシェイク時間、オリジン・フェッチ時間を個別に記録する。キャッシュ・ステータス（HIT/MISS/STALE/BYPASS）、年齢、サービングPoPを含むレスポンス・ヘッダがログに記録され、アプリケーションからのトレースIDと関連付けられる。これにより、異常値がルーティング、TLS、CPU待機、WAFのいずれに由来するのかを確認できる。また、モバイル・エッジを個別に認識するために、地域とデバイスごとにRUMデータをサンプリングしています。.

ルールの展開、テスト、バージョンアップ

CDNのルール製造. .私は機能フラグの背後に変更を封印し、地域/パーセンテージごとにそれを展開し、コントロールグループとメトリクスを比較する。各ルールには、バージョン、チケット、測定可能なターゲット（例：%ヒット率+8、TTFB-40ms p95）が与えられている。ロールバックは準備され、自動化される。合成テストでは、実際のトラフィックが変更に当たる前に、キャッシュヘッダー、クッキー、Varyが計画通りに機能するかどうかを事前にチェックします。.

ストリーミングとレンジリクエストを正しく操作する

ビデオ、大容量のダウンロード、PDFには、次のような利点があります。 レンジのリクエスト と206のレスポンスがあります。私は、エッジがサブレンジをキャッシュすることを許可されていること、セグメントの名前が一貫していること、オリジンサーバーがバイトレンジを効率的に配信していることを確認している。後続のセグメントのプリフェッチはビットレートの変化をスムーズにし、エラーが発生した場合は、短時間のオリジン障害が発生してもストリームを流し続ける。重要：帯域幅がボトルネックになるような、スロットルなしの並列レンジリクエストは禁止。.

簡単にまとめると次のステップ

正直なところから始めよう測定ユーザーリージョンからクライアント→エッジを分離し、エッジ→オリジンを分離する。クリーンヘッダー、クッキーダイエット、適切なTTLでキャッシュヒット率を高める。予熱、陳腐化対策、経済的なパージプランでオリジンの負荷を軽減する。TLS、HTTP/2/3、コネクションの再利用を最適化し、ハンドシェイクがストップウォッチを支配しないようにする。コードやハードウェアを調整する前に、ピアリング、エニーキャスト・マッピング、PoPの利用状況を確認し、持続的な接続で成功を確実にする。 モニタリング.