CDN:パフォーマンス最適化のトラブルシューティングガイド

パフォーマンスの問題は多くの要因に影響されます。トラブルシューティングを行う前に、リクエストが実際に CDN を経由していることを確認し、根本原因を絞り込むための対照群を確立してください。

アクセス効果の収集

再現可能なトラブルシューティングでは、少なくとも以下の情報を記録する必要があります：

• 協定世界時 (UTC)、クライアントのリージョンと ISP、マスクされたクライアント IP <CLIENT_IP>、ローカル DNS

• リクエスト URL、リクエストメソッド、ステータスコード、リダイレクトチェーン

• DNS の結果、実際に接続されたノード IP

• X-Cache、X-Swift-CacheTime、Age (存在する場合)、Via

• Cache-Control、Pragma、Expires、ETag、Last-Modified、Vary

• Content-Type、Content-Length、Content-Encoding、Accept-Ranges、Content-Range

• DNS、TCP、TLS、TTFB、ダウンロード、および合計時間

• 初回 CDN GET、繰り返し GET、指定ノード GET、およびオリジンサーバーへの直接 GET の同一リクエストの比較結果

curl -sS -D /tmp/cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntime_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\nsize_download=%{size_download}\n' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<CDN_NODE_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<ORIGIN_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip, br' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1023' \
  "https://<CDN_DOMAIN>/<LARGE_RESOURCE_PATH>"

curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"
curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

クライアントからノードへのネットワーク品質の低下またはスケジューリングの異常

症状：加速ドメインへの ping で高遅延またはパケットロスが発生。特定のリージョンまたは ISP のユーザーで低速アクセスが発生。ユーザーが遠隔地のノードにスケジューリングされている。

考えられる原因とトラブルシューティング：

• 加速リージョンの設定が正しくない：加速リージョンが「中国大陸のみ」に設定されている場合、海外ユーザーは中国大陸のノードにスケジューリングされます。「グローバル（中国大陸を除く）」に設定されている場合、中国大陸のユーザーは海外のノードにスケジューリングされます。ユーザーの分布に基づいて、加速リージョンを正しい範囲（例：「グローバル」）に設定してください。

• ドメインが ICP 登録を完了していない：未登録のドメインは「グローバル（中国大陸を除く）」しか選択できません。中国大陸のユーザーが海外ノード経由でアクセスすると、リンクが長くなり、速度が不十分になる可能性があります。中国大陸のユーザーに加速を提供するには、まず ICP 登録を完了してください。登録が不可能な場合は、Edge Security Acceleration (ESA) を使用して、中国大陸のユーザーが海外サイトにアクセスする際の遅延を減らすことを検討してください。

• クライアントの DNS 設定が正しくない：例えば、東京のユーザーが米国の DNS を使用している場合、近くのノードではなく米国のノードにスケジューリングされる可能性があります。ユーザーに、自身の場所と ISP に対応する DNS に変更するよう指示してください。

• リージョン ISP ネットワークの変動：加速リージョンと DNS が正しいにもかかわらずアクセスが遅い場合は、traceroute と MTR の情報を収集して、遅延が発生している特定のリンクセグメントを確認します。ユーザーリクエストが到達するノード IP をバインドしてテストし、ノード自体が正常に応答するかを確認した後、キャッシュヒットステータスとリソースサイズを組み合わせてさらに分析します。

キャッシュヒット率の低下または頻繁なオリジンフェッチによる低速アクセス

症状：レスポンスヘッダー X-Cache が MISS、X-Swift-CacheTime が 0。オリジンサーバーへの負荷が高く、オリジントラフィックが多い。初回アクセスがオリジンサーバーへの直接アクセスよりも遅い。

一般的な原因と最適化ソリューション：

• 初回アクセスにはキャッシュがない：ノードは初回の応答時にオリジンサーバーからデータをフェッチする必要があります。URL プリフェッチ機能を使用して、オリジンコンテンツを事前に CDN ノードにプリフェッチすることを推奨します。詳細については、「リソースの更新とプリフェッチ」をご参照ください。

• トラフィックが少なく、ファイルのアクセス頻度が低い：ノードキャッシュは人気度に基づいて最もアクセス頻度の低いアイテムを削除します。トラフィックの少ないリソースは早期に削除されます。低トラフィックのシナリオでは、キャッシュ時間を適切に延長するか、プリフェッチを使用して人気度を維持できます。

• 不合理なキャッシュ設定：

  • キャッシュルールが設定されておらず、静的ファイルが ETag および Last-Modified レスポンスヘッダーを返さない場合、ファイルはキャッシュできません。オリジンサーバーでこれらの 2 つのレスポンスヘッダーを追加するか、CDN 側でキャッシュルールを設定してください。詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

  • キャッシュルールが設定されていない場合、デフォルトのキャッシュポリシーが使用され、最大キャッシュ時間は 3600 秒を超えません。これにより、頻繁な有効期限切れとオリジンフェッチが発生しやすくなります。ビジネス要件に基づいて合理的なキャッシュ時間を設定してください。

  • オリジンサーバーのレスポンスヘッダーに s-maxage=0、max-age=0、no-cache、no-store、private、または Pragma: no-cache のいずれかが含まれている場合、キャッシュルールが設定されていてもコンテンツはキャッシュされません。オリジンサーバーのレスポンスヘッダーをキャッシュ可能な値（public など）に変更するか、CDN キャッシュルールで レスポンスヘッダーを無視 を有効にしてください。

• URL に可変パラメーターが含まれている：異なるパラメーターを持つ URL が同じファイルにアクセスする場合、CDN はそれらを異なるリソースとして扱い、それぞれオリジンサーバーからフェッチします。パラメーター無視機能を有効にしてください。詳細については、「パラメーター無視」をご参照ください。

• 大容量ファイルのオリジンフェッチが遅い：大容量ファイルのシナリオでは、Range オリジンフェッチを有効にしてオリジンフェッチの効率を最適化することを推奨します。詳細については、「Range オリジンフェッチの設定」をご参照ください。

• 頻繁なキャッシュ更新：URL またはディレクトリのキャッシュを頻繁に更新すると、ノードキャッシュが無効なままになり、ヒット率が低下します。コンテンツが更新された場合にのみ、影響を受けるリソースを更新してください。

検証方法：hosts ファイルでユーザードメインをオリジン IP にバインドして直接アクセスし、CDN アクセスとの読み込み時間を比較して、加速効果を検証し、ボトルネックがオリジンフェッチにあるのか、配信リンクにあるのかを確認します。ヒット率の最適化戦略の詳細については、「キャッシュのトラブルシューティング」をご参照ください。

動的リクエストの遅延

症状：API インターフェイスなどの動的コンテンツが遅い。静的リソースは速いが、ページ全体の読み込みが遅い。

原因：CDN はリアルタイムで変化する動的コンテンツをキャッシュできません。動的リクエストは毎回オリジンサーバーに転送されるため、CDN のキャッシュ加速は効果がありません。オリジンサーバー自体が遅い場合、動的リクエストも同様に遅くなります。

解決策：

• オリジンサーバーで静的コンテンツと動的コンテンツを分離する：静的リソースには CDN で加速されたドメインを使用し、動的リクエストにはオリジンサーバーに直接解決されるドメインを使用します。

• Edge Security Acceleration (ESA) を使用して、ルート最適化、トランスポート最適化などの技術を通じて動的リクエストを加速し、オリジンチェーンを短縮します。動的加速はリンクの最適化であり、オリジンサーバー自体が遅い場合は、依然としてオリジンサーバーの最適化が必要であることに注意してください。

国境を越えるオリジンフェッチの遅延

症状：オリジンサーバーと主要なユーザーが異なる国またはリージョンにいる場合、オリジンフェッチの品質が変動し、オリジンフェッチが遅く、オリジンフェッチの失敗率が高くなり、キャッシュとコンテンツ配信に影響を与えます。

原因：国境を越えるオリジンフェッチは、海底ケーブルの容量や国間の公衆網の輻輳に影響されます。

解決策：Global Accelerator (GA) を使用して、対応する国のオリジンサーバーに特化した加速を提供し、CDN のリージョン別オリジンフェッチポリシーを設定して、キャッシュミス時のオリジンフェッチ品質を向上させます。GA は ECS、ALB、OSS などのオリジンタイプをサポートし、「GA と CDN を使用した back-to-origin の高速化」などのソリューションを提供します。

ウェブサイトのホームページの読み込みが遅い

症状：ホームページのリクエストが Network パネルで長時間 Pending 状態のままになる。ホームページが返された後、静的リソースは迅速に読み込まれる。

原因：ホームページは通常、動的リソースであるか、キャッシュ不可として設定されているため、すべてのアクセスがオリジンサーバーに戻ります。オリジンサーバーの応答が遅い場合、ホームページのリクエストがブロックされ、ホームページの HTML によって参照される画像、JS、CSS などの後続リソースの読み込みを開始できません。

解決策：まず、レスポンスヘッダーを通じてホームページがキャッシュにヒットしているかを確認します（「低速アクセス問題の方向性を特定する方法」をご参照ください）。ミスしている場合は、「キャッシュヒット率の低下または頻繁なオリジンフェッチによる低速アクセス」に従ってキャッシュ設定のトラブルシューティングを行います。オリジンサーバーの応答が遅い場合は、オリジンサーバーのパフォーマンスを最適化するか、「静的/動的分離」を採用します。

大容量リソースの読み込みが遅い

症状：Timing の中で Content Download が大きな割合を占める。ページリソースの合計サイズが大きい。

解決策：パフォーマンス最適化機能（スマート圧縮、ページ最適化など）を有効にして、ファイルサイズを削減し、読み込み速度を向上させます。詳細については、「パフォーマンス最適化」をご参照ください。スマート圧縮は、text/xml、text/plain、text/css、application/javascript、application/x-javascript、application/rss+xml、text/javascript、image/tiff、image/svg+xml、application/json、application/xml の各フォーマットをサポートしています。

オリジンフェッチ後の Gzip 圧縮が機能しない

症状：オリジンサーバー（Nginx など）で Gzip 圧縮が有効になっており、クライアントがオリジンサーバーに直接アクセスするとレスポンスヘッダーに Content-Encoding: gzip が返される。CDN 経由でリクエストヘッダーに Accept-Encoding: gzip, deflate を含めてアクセスすると、レスポンスヘッダーには Content-Length のみが返され、コンテンツは圧縮されていない。

原因：CDN のオリジンフェッチリクエストには、リクエストがプロキシサーバーからのものであることを識別するために Via リクエストヘッダーが含まれています。Nginx の ngx_http_gzip_module モジュールは、gzip_proxied 設定を使用して、プロキシリクエストに対して圧縮を有効にするかどうかを制御します。この設定のデフォルト値は off であるため、CDN からのオリジンフェッチリクエストは圧縮されたコンテンツを返しません。

解決策：

1. Nginx の設定ファイル（http、server、または location ブロックのいずれか該当するもの）で gzip_proxied any を設定し、プロキシサーバーからのすべてのリクエストが圧縮されるようにします。

2. nginx -t を実行して設定が正しいことを確認し、次に nginx -s reload を実行して設定を再読み込みします。

3. CDN 経由でアクセスし、レスポンスヘッダーに Content-Encoding: gzip が含まれていることを確認します。

検証方法：curl を使用してオリジンサーバーに対して直接テストします。Via ヘッダーを送信しない場合は Content-Encoding: gzip が返されます。-H 'Via:xxx' を追加してプロキシリクエストをシミュレートすると、Content-Length のみが返されます。これにより、問題が gzip_proxied 設定に起因することが確認できます。

注：Brotli 圧縮が機能しない場合も、トラブルシューティングのアプローチは同様です。オリジンサーバーが Via リクエストヘッダーや gzip_proxied のような設定のためにプロキシリクエストに対して圧縮コンテンツを返すことを拒否しているかどうかを確認し、Gzip 関連の設定を対応する Brotli 設定に置き換えます。

ページ最適化とのトレードオフ：ページ最適化も有効にする場合、オリジンサーバーでの圧縮とページ最適化は相互排他的であることに注意してください。オリジンサーバーが圧縮コンテンツを返した後、CDN はページ最適化を実行できません。ビジネスの優先順位に基づいて、オリジンサーバーでの圧縮（オリジン帯域幅の節約）とページ最適化（HTML サイズの削減）のどちらかを選択してください。

ページ最適化と Gzip 圧縮の両方が有効な場合にページ最適化が機能しない

症状：ページ最適化が有効になっている。Accept-Encoding リクエストヘッダーなしで curl を送信すると、返される HTML は最適化されるが、ブラウザからアクセスする（デフォルトで Accept-Encoding: gzip を送信する）と、返されるコンテンツはページ最適化されていない。

原因：

• オリジンサーバーが Gzip 圧縮されたコンテンツを返す：ブラウザはデフォルトで Accept-Encoding: gzip リクエストヘッダーを送信し、CDN はオリジンフェッチ時にこのヘッダーを転送します。オリジンサーバーで Gzip が有効になっている場合、圧縮されたコンテンツが返されます。CDN ノードは、オリジンサーバーによって既に圧縮されたコンテンツを解凍してからページ最適化を行うことはないため、オリジンサーバーが圧縮コンテンツを返すとページ最適化は有効になりません。

• CDN のスマート圧縮はページ最適化を妨げない：CDN のスマート圧縮はページ最適化の後に実行されるため、両者は競合しません。この症状は、オリジンサーバーが既に圧縮コンテンツを返している場合にのみ現れます。オリジンサーバーでの事前圧縮が CDN によるページ最適化を妨げるのであり、CDN 側のスマート圧縮とは無関係です。

解決策：

• オプション 1：オリジンサーバーが CDN のオリジンフェッチリクエストに対して Gzip 圧縮されたコンテンツを返さないようにします。Nginx オリジンサーバーの場合、gzip_proxied パラメーターを変更して、プロキシサーバーからのリクエストが圧縮コンテンツを返さないようにします。

• オプション 2：CDN の設定で、オリジン HTTP リクエストヘッダーから Accept-Encoding を削除し、オリジンサーバーが非圧縮コンテンツを返し、CDN がページ最適化を実行するようにします。

注：オリジンサーバーが圧縮コンテンツを返さなくなった後、CDN はスマート圧縮機能を通じてクライアントへのレスポンスを圧縮でき、ページ最適化と転送圧縮の両方を実現できます。

パラメーター無視を有効にした後の業務上の例外

症状：パラメーター無視を有効にした後、認証の失敗、ユーザーデータの混在、誤ったキャッシュコンテンツの返却、または画像処理が無効になる。

原因：パラメーター無視が有効になると、CDN は異なるパラメーターを持つリクエストをキャッシュのために同じリソースとして扱います。以下のタイプの URL パラメーターは、グローバルに無視すべきではありません：

• ユーザー ID（UID、トークン、セッション ID など）：これらを無視すると、認証の失敗やユーザーデータの混在が発生します。

• 動的コンテンツの区別（バージョン ?v=1、ページ番号 ?page=2 など）：これらを無視すると、誤ったキャッシュコンテンツが返されます。

• オリジン処理の指示（OSS 画像処理パラメーター x-oss-process など）：これを無視すると、処理パラメーターが無効になり、未処理のオリジナルリソースが返されます。

トラブルシューティングと解決策：

1. パラメーター無視の設定を削除または無効にします。

2. キャッシュ更新（URL 更新またはディレクトリ更新）を実行して、エッジノード上の古いキャッシュをクリアします。

3. 一部のパラメーターを保持する必要がある場合は、「指定したパラメーターを保持」モードを使用し、キーパラメーター（x-oss-process、token など）を保持対象として設定します。パラメーター無視機能の詳細については、「パラメーター無視」をご参照ください。

パラメーター無視の設定変更が反映されない

症状：パラメーター無視の設定を変更した後も、アクセスが異常なまま、またはオリジントラフィックが減少しない。

原因：設定が変更された後、エッジノードに既にキャッシュされているファイルは自動的に更新されません。古いキャッシュは依然として古いポリシーに従って応答します。

トラブルシューティングの手順：

1. 設定が保存されているかの確認：CDN コンソールにログインし、パラメーター無視の設定ページを再度開き、現在の設定が期待される状態と一致していることを確認します。

2. カスタムキャッシュキーとの競合の確認：カスタムキャッシュキーはパラメーター無視の設定を上書きします。カスタムキャッシュキーが有効になっている場合、パラメーター無視の設定は有効になりません。両方が同時に有効になっていないことを確認してください。

3. キャッシュ更新の実行：「リソースの更新とプリフェッチ」ページで、URL 更新またはディレクトリ更新を実行します。新しい設定は、古いキャッシュがクリアされた後にのみ完全に有効になります。

4. 設定効果の検証：curl -I "full URL" を実行し、レスポンスヘッダー X-Cache を確認して、キャッシュヒットステータスが期待通りであることを確認します。

OSS の画像処理または動画フレームキャプチャのコンテンツが正しくない

症状：OSS の画像処理（x-oss-process=image/resize,w_200 など）または動画フレームキャプチャを使用すると、アクセス時に未処理の元の画像または動画が返されるか、異なる処理パラメーターを持つリクエストが同じコンテンツを返す。

原因：CDN ドメインでパラメーター無視が有効になっていると、元の画像リンクと処理パラメーター付きのリンクが同じリソースとしてキャッシュされ、コンテンツが正しくなくなります。

解決策：CDN コンソールのパラメーター無視設定で、x-oss-process パラメーターを「指定したパラメーターを保持」モードに設定し、画像処理パラメーターを持つ URL が個別にキャッシュされ、元の画像のキャッシュと競合しないようにします。設定を変更した後、キャッシュを更新してください（「パラメーター無視の設定変更が反映されない」をご参照ください）。

パラメーター無視を有効にした後のキャッシュヒットステータスが一致しない

症状：パラメーター無視が有効になっているが、クライアント間でキャッシュヒットステータスが一致しない。一部のリクエストで X-Cache が MISS と表示される。

考えられる原因：

1. URL に無視されていない動的な認証パラメーターが含まれている：例えば、URL に auth_key などの認証パラメーターが保持対象として設定されている場合。各リクエストで認証値が異なるため、CDN はそれらを依然として異なるリソースとして認識します。

2. ノードでの初回アクセスにはキャッシュがない：リソースがそのエッジノードにまだキャッシュされていないため、初回アクセスは必然的に MISS と表示されます。

3. クライアントのリクエストヘッダーの違い：例えば、異なる Accept-Encoding は複数コピーキャッシュ（Gzip 版と非 Gzip 版が別々にキャッシュされる）をトリガーする可能性があります。オリジンサーバーが Vary: User-Agent を返す場合、異なる UA からのリクエストも別々にキャッシュされます。

4. カスタムキャッシュキーとの競合：カスタムキャッシュキーはパラメーター無視の設定を上書きします。両方が有効になっている場合、パラメーター無視は有効になりません。

トラブルシューティング方法：クライアントで curl -I "full URL" を実行し、レスポンスヘッダー X-Cache と X-Swift-CacheTime を比較してキャッシュステータスを確認します。解決策：パラメーター無視の設定が正しいこと（有効であり、キーパラメーターが保持されていること）、クライアントのリクエストヘッダーストラテジーが一貫していること、およびカスタムキャッシュキーが同時に有効になっていないことを確認してください。