画像はすぐに表示されるのに、ログインボタンを押すと読み込みが続く。商品一覧は開けても、検索や注文には数秒かかる。米国のサーバーから中国本土のユーザーにサービスを提供する場合、CDN導入後もこのような差が生じることがあります。

DDoS対策CDNは、動的リクエストの転送とオリジンへの接続に適した機能があり、遅延の一部がネットワークに起因する場合、動的APIの応答を改善できます。 動的APIをキャッシュできなくても、経路の最適化や接続の再利用が役立つ可能性があります。一方、データベースのクエリ、アプリケーションの待機、外部APIが遅い場合は、バックエンドも改善する必要があります。

効果を左右するのは、ユーザーが接続するエッジ拠点だけではありません。その拠点から米国のオリジンサーバーまでの経路も重要です。

動的APIが毎回オリジンにアクセスするのに、なぜ高速化できるのか？

静的リソースがキャッシュにヒットすれば、CDNはエッジから直接返せます。一方、ログイン、注文照会、フォーム送信などの動的リクエストは通常、アプリケーション側で処理する必要があり、前のユーザーへの応答をそのまま次のユーザーに返すことはできません。

キャッシュしないことと、高速化できないことは別です。

米国のオリジンサーバーに直接接続する場合、ユーザー側のネットワークで越境接続とリクエストの往復が発生します。CDN経由では、ブラウザーがまずエッジ拠点に接続し、そこから米国のオリジンへリクエストを転送します。後半の経路がより適切で、接続の繰り返し確立を減らせれば、全体の待ち時間を短縮できる可能性があります。

そのため、DDoS対策CDNの評価をトップページや画像だけで済ませることはできません。キャッシュヒットは静的コンテンツの配信を確認できても、ログインや注文APIの改善までは示しません。

米国サーバーへのアクセスが遅いときは、どこで時間がかかっているかを調べる

動的リクエストには、DNS解決、接続の確立、リクエストの送信、エッジでの処理、オリジンへのアクセス、アプリケーション処理、応答の受信などが含まれます。これらは必ずしも完全に直列ではありませんが、段階を分けると改善対象を見つけやすくなります。

夜間のピーク時に遅くなるなら、越境経路を調べる

オリジンでの処理時間はほぼ変わらないのに、日中は正常で夜間に待機、遅延のばらつき、タイムアウトが増える場合は、混雑やパケットロスを調査します。

結果は地域や中国電信、中国聯通、中国移動などの通信事業者によって異なります。中国本土以外の測定地点から米国のオリジンに速くアクセスできても、中国本土のユーザー体験を代表しません。ある都市での良好な結果も、すべてのユーザーには当てはまりません。

この場合は、サーバーのCPUを増やすだけでなく、DDoS対策CDNを候補として、ユーザーからの接続経路とオリジンへの経路が改善するかを測定します。

すべての地域で遅いなら、アプリケーション側がボトルネックかもしれない

例えば、リクエスト全体に2秒かかり、バックエンドの計測で主要な処理にすでに1.6秒を要しているとします。ネットワークを改善しても残りの400ミリ秒をすべてなくせるわけではなく、CDNを変えてもアプリケーション処理の1.6秒は消えません。

これは仮定の例であり、実測値ではありません。ここから分かるのは、バックエンド処理の比率が大きいほど、ネットワーク経路の改善だけで得られる全体の効果は通常小さくなるという点です。

遅いSQLクエリ、データベースのロック待ち、スレッドプール、外部の決済・SMSサービス、複数のリモートサービスへの直列呼び出しを確認します。サーバーのCPU使用率が低くても、こうした待機は起こり得ます。

画面操作の遅さは、複数のリクエストの直列実行が原因かもしれない

例えば、フロントエンドがログイン状態を確認し、次にユーザー情報を取得し、それを使ってアプリケーションデータを要求する場合です。各処理が前の処理を待つため、越境通信の待ち時間が積み重なります。

CDNは各リクエストのネットワーク部分を改善できる可能性があります。同時に、不要な直列呼び出しの削減、適切なAPIの統合、独立したリクエストの並列化も重要です。CDN導入後も、フロントエンドとバックエンドの呼び出し構造を調べる必要があります。

どこから調べるべきか迷う場合は、 Webサイトの遅延を段階ごとに調べる方法 を参考に、「ページが遅い」という問題を個々のリクエストと待機段階に分けて確認してください。

DDoS対策CDNは、キャッシュしない動的APIをどう改善するのか？

安定したオリジンへの経路を選ぶ

ユーザーの通信事業者から米国のデータセンターへのインターネット経路が、常に適切とは限りません。動的コンテンツの高速化サービスは、ネットワーク機能に応じて別の中継経路を選び、混雑や非効率な経路の影響を抑えられる場合があります。

Cloudflareの スマートルーティングに関する資料 は、現在のネットワーク状況に応じて通信経路を選ぶ製品の一例を説明しています。経路は改善対象になり得ますが、「DDoS対策CDN」と呼ばれるすべてのプランに同じ仕組みがあるわけではありません。

米国のオリジンについては、エッジ拠点から実際のデータセンターまでの接続品質を確認してください。エッジ拠点が中国本土に近い香港にあるというだけでは判断できません。

オリジン接続を再利用して、繰り返しのハンドシェイクを減らす

新しい接続の確立には通常、追加のネットワーク往復が必要です。越境経路が長いほど、TCP接続やTLSハンドシェイクを繰り返すコストが無視できなくなります。

CDNが適切な条件で確立済みのオリジン接続を再利用できれば、後続のリクエストでそのコストを一部削減できます。Amazon CloudFrontの カスタムオリジン接続に関する資料 でも、持続的な接続によって後続リクエストでのTCP接続とTLSハンドシェイクの時間を省けると説明されています。

効果を得るには、オリジンとプロキシ双方の設定が重要です。オリジンが頻繁に接続を閉じる、タイムアウトの設定が合わない、接続プールが逼迫しているといった状態では、効果が制限されます。接続再利用の方式も製品によって異なります。

接続再利用で減らせるのは接続確立のコストです。米国で処理する必要があるリクエストは、必要なデータを米国に送り、結果を戻す必要があります。

攻撃中にオリジンへの不要な負荷を減らす

動的APIは経路の問題だけでなく、不正なリクエストによっても遅くなります。ログイン、検索、処理負荷の高い照会APIへのアクセスが続くと、オリジンの待機キューが伸び、正規ユーザーも待たされます。

DDoS対策CDNと適切なアプリケーション保護を組み合わせれば、不正なトラフィックの一部をオリジンに到達する前に減らし、正規リクエストを処理しやすくできます。これは攻撃の影響を抑えるもので、すべての正規リクエストが一定の割合で速くなるという意味ではありません。

APIごとに 不正なAPI利用の防止とアクセス制御 を考慮してルールを設計します。ブラウザーページ、モバイルAPI、決済コールバックにはそれぞれ異なる対応が必要です。すべてにブラウザー認証画面を適用することはできません。

香港経由で米国のAPIにアクセスすると、速くなる場合と遅くなる場合があるのはなぜか？

中国本土のユーザーが香港を経由して米国のオリジンに接続しても、必ず速くなるわけではありません。2区間の通信とプロキシ処理を合わせて、直接接続より良い結果になる必要があります。

ユーザーからエッジまでが安定し、エッジから米国のデータセンターへの経路も良ければ、中継によって混雑や遅延のばらつきを減らせる可能性があります。一方、エッジまでは速くても米国のオリジンへの経路でパケットロスが多ければ、後半で待たされます。プロキシを1段追加すると、処理やキューでの待ち時間が増える場合もあります。

次の3点を個別に確認します。

• 主なユーザーの地域からエッジ拠点までの経路は安定しているか。
• エッジ拠点から米国の対象データセンターまでの経路は安定しているか。
• 通常時とピーク時に、プロキシやオリジンで待機が発生していないか。

香港のエッジ拠点へのPingが低くても、そこからオリジンへの通信やアプリケーション処理にかかる時間は分かりません。エッジへのPing値をAPI全体の応答時間として扱わないでください。

CDN07では、用途に応じてエッジ拠点、帯域幅、セキュリティポリシーを設定できます。米国のオリジンに接続する場合は、ユーザーの地域と米国のデータセンターの両方を考慮して DDoS対策CDNの構成 を評価し、動的APIの実測結果に基づいて設定を選んでください。

測定方法：同じAPIで直接接続とCDN経由を比較する

業務を代表する読み取り専用APIを選びます。例えば、公開されている商品カテゴリの照会です。「OK」だけを返すヘルスチェックでは基本的な疎通しか確認できず、データベース照会や認証後のAPIを代表しません。

テスト対象のAPIはCDNキャッシュを明示的にバイパスし、オリジンやアプリケーションのログで毎回オリジンに到達したことを確認します。ランダムなクエリパラメータを追加するだけでは、キャッシュを確実に回避した証拠にはなりません。

まずCDN経由の各段階の所要時間を測る

次のコマンドはcurlをインストールしたLinuxまたはmacOSのターミナルで実行します。例のドメインとパスを、自社の読み取り専用APIに置き換えてください。

curl --noproxy '*' --http1.1 -sS \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'code=%{http_code}\nremote=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://api.example.com/api/catalog

この例ではHTTP/1.1を指定し、新しいHTTPS接続で行う1回のリクエストについて各段階を確認します。実際のブラウザー通信は、使用するプロトコルで別途測定してください。 --noproxy '*'は環境内のプロキシが比較結果に影響するのを防ぐための指定です。直接インターネットに接続できるテスト環境で実行してください。

curlの公式マニュアル によると、これらの時間の単位は秒で、多くはリクエスト開始からの累積時間です。すべてを足し合わせないでください。

ここでの ttfb - tlsは「オリジンの処理時間」ではありません。クライアント側の数値だけでは、CDNからオリジンへの通信とアプリケーション処理を分離できません。

あわせて codeと応答内容も確認します。403、CAPTCHAのHTML、ログイン画面へのリダイレクトがすぐに返っても、APIが高速化されたとはいえません。接続失敗やタイムアウトが発生した場合、完了していない段階のゼロ値を「速い」と解釈しないでください。

許可されたテスト環境でオリジンへの直接接続と比較する

オリジンがテスト元からのアクセスを許可している場合は、同じURLのまま --resolveでオリジンのIPアドレスを指定できます。

curl --noproxy '*' --http1.1 -sS \
  --connect-timeout 10 --max-time 30 \
  --resolve 'api.example.com:443:192.0.2.20' \
  -o /dev/null \
  -w 'code=%{http_code}\nremote=%{remote_ip}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://api.example.com/api/catalog

192.0.2.20はドキュメント用の例示アドレスです。自社のオリジンIPアドレスに置き換えてください。このコマンドではURLのホスト名がHostヘッダー、SNI、証明書の検証に使われます。オリジンはそのホスト名でHTTPSを提供する必要があります。

IPアドレスを指定しているため、この直接接続テストでは通常のDNS検索が省かれます。接続やリクエスト経路の比較には役立ちますが、2つの合計時間の差をそのまま本番ユーザーの正確な改善幅とみなすことはできません。

測定のためにオリジン全体をインターネットに公開したり、ホスト名や信頼チェーンの問題を隠すために証明書の検証を無効にしたりしないでください。オリジンがCDNからのアクセスしか受け付けない場合は、許可されたテスト用の入口を使うか、技術担当者の協力を得て比較します。

クライアントとオリジンの測定結果を突き合わせる

少なくともテスト時刻、地域、通信事業者、リクエストパス、ステータスコード、対応するリクエストIDを記録します。オリジンのログやAPMでは、同じリクエストのキュー待ち、アプリケーション処理、依存サービスへの呼び出しを確認できるようにします。

開発者は、管理されたテスト環境で Server-Timing応答ヘッダー を使い、バックエンドの計測値を示すこともできます。例えば次のように設定します。

Server-Timing: app;dur=120, db;dur=35

これは説明用の数値で、 durの単位はミリ秒です。指標の名前と計測範囲はアプリケーションが定義します。 dbが appに含まれている場合、両者を足し合わせてはいけません。このヘッダーが自動的にバックエンドを計測するわけではなく、アプリケーションや監視システムが値を生成する必要があります。また、機密性の高い内部情報を公開しないようにしてください。

比較には地域、通信事業者、夜間のピーク時間帯の違いも含めます。新規接続と連続アクセスの双方を観察してください。curlのプロセスを毎回起動する方法では、ブラウザーによる接続再利用を再現できません。

動的APIの導入で起こりやすい設定ミス

すべてのGET APIを公開コンテンツとしてキャッシュする

GETはリクエストのメソッドであり、結果をユーザー間で共有してよいことを意味しません。プロフィール、残高、注文の照会は、GETであっても個人情報を返す場合があります。

保存すべきでない応答については、オリジンから次のヘッダーを返せます。

Cache-Control: private, no-store

以下の RFC 9111のキャッシュ規則 によると、フィールド名を指定しない privateは共有キャッシュによる応答の保存を禁じ、 no-storeは対応するリクエストと応答を保存しないようキャッシュに指示します。 no-cacheは再利用前の検証を求めるもので、保存の禁止とは異なります。

CDN側の設定も確認し、強制キャッシュのルールがアプリケーションの意図と矛盾しないようにします。異なるアカウント間で同じ非公開の結果が返らないことも検証してください。

キャッシュヒットを増やすために認証情報や必要なパラメータを削除する

動的リクエストの転送では、アプリケーションに必要なCookie、Authorizationヘッダー、クエリパラメータ、リクエストボディを保持する必要があります。商品ID、言語、テナント、署名に関するパラメータを誤って削除すると、誤ったデータが返ったり認証に失敗したりします。

キャッシュキーとオリジンに転送するパラメータは別です。あるパラメータをキャッシュの区別に使わなくても、オリジンに不要とは限りません。導入後は、ドメインが開くことだけでなく、実際のアプリケーションのリクエストで検証してください。

APIのタイムアウト後に注文を自動的に再送する

ネットワークのタイムアウトは、サーバー側の操作が実行されなかったことを意味しません。注文は作成済みで、応答だけが間に合わなかった可能性があります。

RFC 9110の冪等性と再試行に関する規定 では、安全に繰り返せる操作と非冪等な操作を区別しています。決済、注文、在庫変更には、アプリケーション側の冪等キー、状態照会、重複送信への対応が必要です。プロキシの再試行回数を増やすだけでは解決しません。

通常のAPIが動くので長時間接続も問題ないと判断する

WebSocket、SSE、ストリーミングAPIは個別にテストします。接続できることは最初の一歩にすぎません。アイドルタイムアウト、切断後の再接続、継続的な転送、プロキシのバッファリングによって段階的な出力が最後にまとめて届かないかを確認してください。

CDN07の製品ページにはWebSocket対応が記載されていますが、実際のアプリケーションで必要な接続時間、タイムアウト、ストリーミングの動作は導入時に確認してください。SSEなどの対応状況も別途確認が必要です。WebSocketへの対応から推測はできません。

CDNの調整を続けるべきか、米国のオリジンを見直すべきか？

応答時間、成功率、アプリケーションの正しい動作をあわせて評価します。P95やP99は遅いリクエストの把握に役立ちますが、十分なサンプルが必要です。数回の手動テストだけで長期的な結論は出せません。

ユーザーの大半が継続的に中国本土にいて、アプリケーションが越境の直列かつ強整合性を要する読み書きに大きく依存する場合、アプリケーションやデータベースの配置も見直す必要があります。一部の読み取り専用サービスを適切な場所へ移せば通信の往復を減らせる可能性がありますが、データ同期、アクセス権、整合性もあわせて設計しなければなりません。CDNでこうした設計を代替することはできません。

プロバイダーを選ぶ際は、 動的アプリケーション向けの経路と防御の選び方 も参考にし、「Webサイトが開くか」だけでなく「ユーザーが重要な操作を安定して完了できるか」まで評価してください。

よくある質問

動的APIをキャッシュしないなら、CDNは経由する拠点を増やすだけでは？

必ずしもそうではありません。適切なオリジンへの経路と接続再利用によって待ち時間が減る場合があります。一方、経路や処理が改善しなければ、追加のコストが発生する可能性もあります。同じAPIの比較結果で判断してください。

米国西海岸のサーバーなら、中国本土から必ず速くアクセスできる？

地理的な距離だけでは判断できません。対象データセンターの通信事業者間の接続、経路、混雑、オリジン接続の設定も重要です。実際のサーバーと主なユーザーネットワークで測定してください。

香港のエッジ拠点を使えば、米国のAPI応答を数十ミリ秒にできる？

そのような保証はできません。米国でリクエストを処理する必要がある限り、越境通信とアプリケーション処理に時間がかかります。ユーザーから香港のエッジまでの遅延は、API全体の応答時間ではありません。

Pingは改善したのに、ログインが遅いのはなぜ？

Pingには、HTTPS接続、プロキシ、データベース、アプリケーション処理全体の時間は含まれません。ログインにはCAPTCHA、不正利用の判定、外部のIDサービスが関わる場合もあります。実際のログインリクエストと依存先を調べてください。

DDoS対策を有効にしたらAPIが遅くなった。保護を解除すべき？

まず認証チャレンジ、レート制限、オリジンへの接続タイムアウト、誤ったルールを確認します。サイト全体の保護を解除する前に、該当するAPIの設定を調整してください。速度の回復とあわせて、不正なトラフィックが再びオリジンへ流れていないことも確認します。

サーバーの移転を検討すべきタイミングは？

バックエンドを改善し、適切な経路を検証しても、重要な操作が越境通信の往復によって継続的に制約される場合、または長期的な費用と安定性が要件に合わない場合は、移転や地域別の配置を比較します。実際のユーザー分布とアプリケーションの依存関係を基に判断してください。

米国でホストするサービスを中国本土のユーザーに提供する場合、動的APIの改善には、不要なネットワーク待機の削減とオリジン処理時間の管理が必要です。トップページの表示速度は出発点にすぎません。ログイン、検索、注文、持続的な接続の実際の動作が、導入の価値を決めます。

テストを計画する際は、米国のデータセンターの所在地、主なユーザーの地域、代表的なAPI、ピーク時間帯を CDN07の技術相談窓口 にお知らせください。まず少数のアプリケーション経路で試し、成功率、応答時間、バックエンド負荷を比較して、用途に適した経路と保護の組み合わせを見つけてください。