サーバーをシンガポールや米国に設置している場合、中国本土のユーザーがトップページを開く速度はそれほど遅くないのに、ログイン、検索、注文照会などでは長時間待たされることがあります。通常は問題なくアクセスできても、夜間のピーク時間帯や攻撃を受けた際にタイムアウトが頻発するケースもあります。エッジロケーションや公称の緩和容量だけを見ていては、適切な高防CDNを選ぶのは難しいでしょう。

速度と防御性能の両方を評価するには、中国本土のユーザーからCDNエッジまでの経路と、エッジから海外のオリジンサーバーまでの経路を分けてテストする必要があります。そのうえで、キャッシュ、動的API、攻撃発生時の正規ユーザーの可用性まで確認します。 高防CDNはコンテンツ配信とセキュリティを改善できますが、データベースの最適化に代わるものではなく、CDNを経由せずに到達できるオリジンの入口を自動的に保護することもできません。

海外向け高防CDNを選ぶ前に、まずどの区間がボトルネックになっているかを確認しましょう

CDN（Content Delivery Network）は、エッジノードを通じてユーザーからのリクエストを受け取ります。オリジンサーバーは、Webサイトのアプリケーションが実際に動作し、元のコンテンツが保存されているサーバーです。「オリジンフェッチ」とは、エッジノードがオリジンからコンテンツを取得する処理を指します。

中国本土外でホスティングされているWebサイトでは、少なくとも2つのネットワーク区間を分けて評価する必要があります。1つは中国本土のユーザーからCDNエッジへの接続、もう1つはCDNエッジから海外のオリジンへの接続です。キャッシュヒットした場合、エッジは再利用可能なコンテンツを直接返せます。一方、リアルタイム処理が必要なリクエストでは、通常、オリジンへのアクセスとアプリケーション側での処理が必要です。

これらの現象はトラブルシューティングの出発点にはなりますが、それだけで原因を特定できるわけではありません。たとえば、APIのタイムアウトはクロスボーダー接続が原因の場合もあれば、データベースのクエリが遅いことが原因の場合もあります。基準値となる測定データがない場合は、まずWebサイトへのアクセスが遅い場合の原因調査方法を参考に、接続時間、サーバーの応答時間、リソースのダウンロード時間を切り分けてから、購入すべきサービスの種類を判断してください。

中国本土のユーザーが実際に体感する速度を反映するには、ネットワーク経路をどのように比較すべきでしょうか？

エッジの所在地だけでなく、配信経路全体を確認する

中国本土からのアクセスを評価する際には、香港のエッジロケーションもテスト対象に含める価値があります。ただし、「香港にある」こと自体が高速性を保証するわけではありません。ユーザーが利用する通信キャリア、キャリア間の接続、ピーク時の混雑、エッジからオリジンまでの経路などが、最終的なパフォーマンスに影響します。

たとえば、ユーザーが広州、CDNエッジが香港、オリジンが米国にあるとします。キャッシュ済みの画像であれば香港のエッジから直接返せる可能性があります。一方、オリジンフェッチが必要な注文照会では、香港のエッジと米国のオリジン間の通信に加えて、バックエンドでの処理時間も待つ必要があります。これはネットワーク経路の一例であり、特定のサービスプロバイダーによる実測結果を示すものではありません。

そのため、「CN2」「ダイレクト接続」「最適化された経路」といった説明を見た場合は、さらに具体的に確認する必要があります。どの区間が最適化されるのか、どの通信キャリアが対象なのか、購入予定のプランに適用されるのか、混雑や障害が発生した場合にどのように切り替わるのかを確認してください。ある区間で最適化された経路が利用されていても、すべてのユーザー、すべてのリクエストで同じ効果が得られるとは限りません。

サービスを測定地点の数ではなく、実際のユーザー分布に基づいてテストする

既存のアクセスログから主要なユーザー地域を特定し、その地域のChina Telecom、China Unicom、China Mobileのネットワークをカバーします。モバイルからのアクセスが多いサービスでは、モバイルネットワークでのテストも含めてください。

実際に比較する方法としては、代表的な省を選び、通常の業務時間、夜間のピーク時間、サービス自体のトラフィックピーク時にテストを繰り返します。ネットワーク、時刻、URL、キャッシュ状態、エラー、サンプル数を記録してください。同じデータセンターから100回リクエストしても、100種類の実際のアクセス環境を代表することにはなりません。

2社のサービスを比較する場合は、同じバージョンのアプリケーション、同じオリジン、同程度のセキュリティポリシーを使用してください。各社がサポートする実際のドメインの接続方法を利用して、本番に近い環境で検証します。テスト用サブドメインを使用する場合は、Cookie、クロスオリジンルール、ログインコールバックも確認し、テスト環境の違いをCDNの性能差と誤認しないようにしてください。

一方のサービスでキャッシュを事前にウォームアップした画像と、もう一方のサービスで初回のオリジンフェッチが発生する画像を、同じ速度ランキングに入れて比較してはいけません。

所要時間、失敗率、実際の業務結果を同時に記録する

TTFB（Time to First Byte）は、リクエスト開始からレスポンスの最初の1バイトを受信するまでの待ち時間を示します。ブラウザのナビゲーションにおけるTTFBには、DNS名前解決、接続確立、TLSネゴシエーション、リダイレクト、レスポンス待ち時間などが含まれる場合があります。そのため、TTFBが高いからといって、サーバー自体の処理が遅いとは限りません。測定方法についてはGoogle web.devのTTFBに関する説明を参照してください。

CDNを選定する際には、少なくとも次の4種類の結果を記録することを推奨します。

1. 通常時と遅いリクエストの所要時間。 中央値のP50とP95の両方を確認します。P95は、約95%のサンプルがその時間以内に収まることを示す値で、平均値よりも遅いリクエストの問題を把握しやすくなります。
2. 失敗とタイムアウト。 全試行回数に対する失敗回数の割合を個別に記録します。失敗したサンプルを除外して、成功したリクエストだけの速度を表示してはいけません。
3. 実際のページ読み込み。 トップページのHTMLが高速に返ってきても、ファーストビューの画像、スクリプト、サードパーティリソースまで高速に読み込まれるとは限りません。
4. 重要な業務操作の結果。 ログインを完了できるか、検索結果が正しいデータを返すか、コールバックが正常に受け付けられるかといった点は、低いレイテンシを示すスクリーンショットよりも実際の業務目標に近い指標です。

すべてのWebサイトに適用できる単一の「合格ライン」となるミリ秒値は存在しません。まず現在のパフォーマンスを記録し、ユーザーが許容できる待ち時間を基準に目標を設定してください。ログインや決済などの重要なフローについては、個別に受け入れ基準を設定することを推奨します。

静的キャッシュと動的APIは、それぞれどのように最適化すべきでしょうか？

安全に再利用できるコンテンツをキャッシュし、不要なオリジンフェッチを減らす

画像、スタイルシート、スクリプト、公開ダウンロードファイルなどは、更新頻度に応じてキャッシュポリシーを設定できます。ここでいう「キャッシュヒット」とは、既存のキャッシュレスポンスを利用できることを意味し、すべてのリクエストが海外のオリジンへのアクセスを避けなければならないという意味ではありません。

キャッシュを確認する際は、コンテンツを共有キャッシュできるか、どの程度の期間キャッシュできるか、実際にキャッシュヒットしたかを同時に確認します。Cache-Control: no-storeはレスポンスを保存すべきではないことを意味します。フィールド指定のないprivateは共有キャッシュにレスポンスを保存すべきではないことを意味します。no-cacheはレスポンスの保存を許可しますが、再利用する前に検証が必要です。そのため、「まったくキャッシュしない」という意味ではありません。これらの意味はHTTPキャッシュ標準 RFC 9111で定義されています。

アカウント、注文、残高など、ユーザーごとに異なるデータを含むコンテンツについては、キャッシュヒット率を高める目的だけでサイト全体のキャッシュを適用すべきではありません。また、CDNのルールがオリジン側の設定を上書きし、あるユーザーのレスポンスが別のユーザーに返されることがないかも確認してください。

導入時には、新しいバージョンを公開した際にどのようにキャッシュをパージするのか、初回アクセスをどのように処理するのか、キャッシュウォーミングなどの機能が購入予定のプランに含まれているのかも確認してください。誤ったキャッシュ更新によって古い価格や古いページが配信されることも、業務上の障害につながります。

リアルタイム処理が必要なリクエストでは、オリジンへの経路とアプリケーションを重点的に確認する

動的リクエストは、ページをエッジにコピーするだけでは高速化できません。ただし、より適切なネットワーク経路、コネクションの再利用、トラフィック制御などによって改善できる場合があります。実際の効果はネットワーク経路とサービスの実装によって異なるため、自社のAPIを使って検証する必要があります。

少なくとも一連の公開された読み取り専用APIを選定し、テスト環境でログイン、注文、コールバックのフローを検証してください。静的リソースの速度が大幅に改善したにもかかわらず、動的APIが依然として遅い場合は、エッジからオリジンへの接続時間、バックエンド処理時間、データベース負荷をさらに確認します。

CDNは遅いデータベースクエリを解消することはできず、遠隔地にあるリアルタイムデータを通信なしで返すこともできません。インタラクティブ性の高いサービスでオリジンフェッチが継続的なボトルネックになる場合は、アプリケーションの配置場所、データアクセス方式、リージョナルサービスのアーキテクチャもあわせて評価する必要があります。

比較可能な測定記録をコマンドラインから取得するには？

以下のコマンドは、curlをインストールしたLinuxまたはmacOSのターミナルで使用できます。例示しているURLは、自分がテストする権限を持つ公開ページまたは読み取り専用APIに置き換えてください。注文の作成、SMSの送信など、副作用のあるAPIを繰り返し測定することは避けてください。

curl -sS --connect-timeout 10 --max-time 30 \
  -D - -o /dev/null \
  -w '\nhttp_code=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls_ready=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  'https://www.example.com/'

このコマンドは1回のGETリクエストを実行し、レスポンスヘッダーと所要時間を表示したうえで、レスポンス本文を破棄します。10秒の接続タイムアウトと30秒の総タイムアウトはあくまで例示であり、サービスの合格基準ではありません。各フィールドの定義についてはcurl公式ドキュメントを参照してください。

主な項目は次のように読み取ります。

• http_codeはHTTPレスポンスのステータスを確認するための項目です。200であっても認証ページや検証ページである可能性があるため、ブラウザやレスポンス本文とあわせて確認してください。000はHTTPレスポンスコードを取得できなかったことを示すため、curlのエラー情報を確認します。
• dns、connect、tls_readyは、計測開始からそれぞれの段階が完了するまでの累積時間です。これらを単純に足し合わせてはいけません。
• ttfbには最初の1バイトを受信するまでの待ち時間が含まれます。totalは今回の転送が完了するまでにかかった総時間であり、その後ブラウザが行う他のリソースのダウンロードやページのレンダリング時間は含まれません。
• remote_ipは今回の接続で使用されたリモートIPアドレスを示します。アクセス経路の確認には役立ちますが、IPアドレスの所在地だけから、すべてのトラフィックがどのデータセンターを経由したかを判断することはできません。

このコマンドはリダイレクトを自動的には追従しません。301または302が返された場合は、まずLocationを確認して最終URLを特定し、そのURLを個別に測定してください。転送に失敗した場合は、すでにHTTPステータスコードを取得できていたとしても、エラー記録を残しておきます。

レスポンスヘッダーはキャッシュ状況の判断にも役立ちますが、キャッシュステータス用のフィールドをサービスプロバイダー間で同じ意味として扱ってはいけません。たとえばCloudflareのCF-Cache-Status: HITは、対象リソースがCloudflareのキャッシュから見つかったことを示します。一方、MISSは、キャッシュ可能なリソースがキャッシュに存在せず、オリジンから取得されたことを示します。これはCloudflare独自のキャッシュステータス定義です。他のサービスについては、それぞれのプロバイダーのドキュメントを確認してください。

1回のcurlリクエストから分かるのは、ある時点、あるネットワーク、あるリソースのパフォーマンスだけです。 前述の方法を選定した地域や時間帯で繰り返し、ブラウザでの測定結果やアプリケーションログと組み合わせて、導入判断に利用できるデータにしてください。

「攻撃は防げたが、正規ユーザーもアクセスできない」という事態を避けるため、防御性能をどのように検証すべきでしょうか？

緩和帯域幅とアプリケーションの処理能力を分けて評価する

分散型サービス拒否攻撃（DDoS）は、大量の悪意あるトラフィックやリクエストによってリソースを消費させます。中国市場で一般的に「CC攻撃」と呼ばれるものは、通常、アプリケーション層のリクエストによるリソース消費を指します。これらの異なる負荷を、単一の「何Gbpsの攻撃に耐えられるか」という数値だけで評価すべきではありません。

Gbpsは帯域幅の規模、ppsは1秒あたりのパケット数、QPSは1秒あたりのクエリ数またはリクエスト数を表します。同じリクエスト数であっても、キャッシュされた画像を取得する場合と、複雑なデータベースクエリを実行する場合では、オリジンにかかる負荷は大きく異なる可能性があります。

見積もりを依頼する際は、具体的に質問してください。公称の防御容量はプラットフォーム全体の容量なのか、それとも1顧客あたり利用可能な容量なのか。正規トラフィックの帯域幅、リクエスト量、同時接続数にはどのような制限があるのか。合意した上限を超えた場合、レート制限、追加料金、あるいはブラックホール（対象宛てのトラフィックを一時的に破棄する措置）が発生する可能性があるのか。サービス復旧の条件は何か。こうした点を確認します。

「大規模攻撃に対応可能」という一般的な説明よりも、防御範囲、上限超過時の対応、アラート方法、インシデント対応手順を明確に記載した説明のほうが、導入判断には役立ちます。

誤検知もテストに含める

Webアプリケーションファイアウォール（WAF）は、不審なWebリクエストを検査・処理するためのもので、Bot管理は自動化されたアクセスの識別と管理に重点を置きます。適切なポリシーはアプリケーションによって異なります。「より多くチャレンジする」「より多くブロックする」ことが、そのまま優れた防御性能を意味するわけではありません。

ブラウザページ、アプリAPI、決済コールバック、検索クローラー、長時間維持されるWebSocket接続については、それぞれ互換性を確認してください。特に決済コールバックでは、署名検証などの業務上必要な認証を維持する必要があります。誤検知を懸念してすべての検証を削除してはいけません。

WAF、Bot管理、DDoS防御を連携させる方法も参考にしながら、正常なリクエストがどのルールにマッチしたかを記録し、その適用範囲と例外条件を検討してください。

攻撃シミュレーションや負荷テストを実施する場合は、まずテスト対象となるCDN、オリジン、ネットワークサービスプロバイダーから許可を取得してください。テスト強度、実施時間、停止条件、正規トラフィックの監視方法を事前に合意します。このようなテストを実施していない場合は、提案されたソリューションや既存ログを評価することはできますが、攻撃耐性が実証されたと主張することはできません。

オリジンへの入口を防御対象外に残さない

ドメインをCDNに接続した後も、過去のDNSレコード、プロキシされていないサブドメイン、同じシステム上で稼働する別サービスなどによって、オリジンIPアドレスが露出する可能性があります。攻撃者がCDNを迂回してオリジンに直接接続できる場合、エッジ側の防御がその経路を自動的に保護することはありません。

オリジンで公開されているポートを確認し、サービスプロバイダーが提示するオリジンIPアドレスの範囲と認証方式に基づいてWebアクセスを制限します。また、管理、監視、証明書検証などに必要なトラフィックについては、確認済みの経路を確保してください。共有されたオリジンIPの許可リストを設定しただけでは、自分のアプリケーションだけがアクセスできることにはなりません。可能であれば、オリジン認証も組み合わせてください。

Cloudflareのオリジン保護に関するドキュメントでも、過去のIPアドレスの露出、アクセス制限、オリジン認証がそれぞれ個別に説明されています。そこで説明されている具体的な機能はCloudflareに固有のものであり、他のサービスについては同等の実装があるか個別に確認する必要があります。

ホスト側のファイアウォールで不要なリクエストを拒否することはできますが、攻撃によってオリジンまでの上流帯域幅がすでに飽和している場合、ホスト上のルールだけではその帯域幅を回復できません。その場合は、上流側のトラフィックスクラビングやサーバー側の防御も評価してください。さらに入口を確認する方法については、露出したオリジンIPアドレスを特定して隠す方法を参照してください。

高防CDNを導入する際、要件をどのように検証可能なソリューションに落とし込むべきでしょうか？

まず、価格を比較する前に必須条件を明確にしてください。これにより、トライアル後になって必要なプロトコルがサポートされていない、動的APIと互換性がないといった問題が発覚するリスクを減らせます。

CDN07の高防CDNサービスは、中国本土からのアクセス最適化とDDoS防御を1つのソリューションに組み合わせ、エッジ、帯域幅、セキュリティポリシーについてカスタマイズ可能な構成を提供しています。中国本土外にサーバーを設置し、中国本土からのアクセス性能と攻撃防御の両方を必要とするWebサイトでは、まずCDN07の高防CDNソリューションから適合条件を確認し、ユーザー分布、オリジンの所在地、動的APIまで含めて評価してください。

このような組み合わせにより、ネットワーク経路とセキュリティポリシーを一体として検討しやすくなります。ただし、実際にどの程度改善するかは、アプリケーションを使ったテストによって確認する必要があります。エッジのカバレッジ、対応プロトコル、プランの上限、サービス条件は、購入予定のソリューションに明記されていることを確認してください。

コストを比較する際は、通常のトラフィックまたは帯域幅、リクエスト数、ドメイン数、防御容量、追加機能、海外オリジン自体の送信トラフィック料金など、同じ基準で比較してください。月額料金だけを比較したり、「無制限」と表示された1つの項目を見て他の項目まで無制限だと判断したりしてはいけません。まず高防CDNの料金構成を確認し、同じ利用条件を使って見積もりを依頼するとよいでしょう。

本番環境へ切り替える前に、証明書、オリジンHostヘッダー、セキュリティルール、実際のクライアントIPの転送、重要な業務機能を確認してください。その後、導入計画に従って限定的な検証を行います。元の設定とロールバック経路を保持し、どのようなエラーやパフォーマンス低下が発生したらトラフィック移行を停止するかを事前に決めておきます。DNSの変更を、すべてのユーザーが瞬時に切り替わる仕組みだと考えてはいけません。

よくある質問

海外サーバーを高防CDNに接続すると、中国本土からのアクセスは必ず速くなりますか？

必ずしもそうとは限りません。改善するかどうかは、ユーザーからエッジまでの経路、エッジからオリジンまでの経路、キャッシュ、アプリケーション処理などに左右されます。新しいエッジが主要ユーザーにとってより適切な位置にあり、不要なオリジンフェッチを減らせる場合は改善する可能性があります。一方、ボトルネックがデータベースやサードパーティAPIにある場合は、その問題自体を解決する必要があります。

香港の高防CDNは、他の地域のサービスより常に高速ですか？

そのようには判断できません。地理的な位置は1つの条件にすぎず、通信キャリア間の接続、トラフィック制御、混雑状況、オリジンまでの経路もパフォーマンスに影響します。中国本土のすべてのユーザーを、1つの都市で1回だけ行ったテストで代表させるのではなく、実際のユーザーが利用するネットワークとピーク時間帯を優先して比較してください。

高防CDNは、ログインや注文照会などの動的APIも高速化できますか？

ネットワーク部分の所要時間を短縮できる可能性はありますが、通常、共有キャッシュによってリアルタイム処理を置き換えることはできません。オリジンへの経路とバックエンド処理を個別にテストし、ユーザー固有のデータが誤ってキャッシュされないことを確認する必要があります。静的画像の速度が大幅に改善したからといって、動的APIでも同じ効果が得られるとは限りません。

CC防御を有効にした後にAPIでエラーが発生した場合、すぐに防御を無効にすべきですか？

まずエラーレスポンス、セキュリティイベント、オリジンログを確認し、セキュリティルールによる誤検知が原因かどうかを判断してください。互換性の問題であれば、対象API、呼び出し元、認証方式に合わせてポリシーを調整し、正常な業務処理が復旧したことを確認します。すべての防御を無効にすると、元々存在していたリスクを再び露出させる可能性があります。

すでに高防CDNを利用している場合でも、高防サーバーは必要ですか？

オリジンの露出状況、上流側の防御、利用しているプロトコルによって異なります。オリジンに直接アクセスできる状態が残っている、過去のIPアドレスが露出している、CDNを経由していない別サービスが存在するといった場合は、それらの入口を別途評価する必要があります。WebサイトをCDNに接続したからといって、基盤となるサーバーのすべてのポートが自動的に保護されるわけではありません。

ゲーム関連のサービスでも、Webサイト向けの高防CDNをそのまま購入できますか？

「ゲームサイト」という名称だけを基準に選ぶべきではありません。ゲーム公式サイト、ログインAPI、WebSocket接続、ネイティブTCP/UDPによるゲーム通信では、接続方式や要件が大きく異なる場合があります。プロトコル、ポート、クライアント側の改修要件、レイテンシ目標を提示したうえで、Webサイト向けCDN、ゲームセキュリティSDK、サーバー側のソリューションのどれが適しているかを判断してください。

次のステップ：自社のアプリケーションで速度と防御性能を検証する

中国本土のユーザーを対象とする海外サーバーでは、CDNを選定する際に次の4点を意識してください。

• アクセス性能は、ユーザーからエッジまでとエッジからオリジンまでの両方の経路で評価する。
• 静的リソース、動的API、実際の業務フロー全体をそれぞれ個別に検証する。
• 防御性能だけでなく、正規ユーザーが正常にアクセスできるか、オリジンへの迂回アクセスが残っていないかも評価する。
• 導入時には、テスト基準、課金範囲、障害発生後の対応方法を明確にする。

主要ユーザー地域、通信キャリアの分布、オリジンの所在地、主要なテストURL、過去の攻撃記録を準備すれば、より具体的なサービス比較を開始できます。CDN07を評価している場合は、これらの情報を高防CDN導入相談から提供し、まずネットワーク経路、オリジンへの接続、セキュリティポリシーについて相談したうえで、合意したテスト結果に基づいて構成を決定できます。