Webサイトを海外に設置し、利用者の多くが中国本土にいる場合は、表示速度と攻撃対策をあわせて考える必要があります。サーバーを数台借りてCDNを自社構築する方法と、ICP登録なしのドメインに対応するDDoS対策CDNを利用する方法では、どちらが適しているでしょうか。

自社構築は制御の自由度が高い一方、ネットワーク経路、防御、運用を自分たちで整える必要があります。DDoS対策CDNを購入する場合は、契約で定められた範囲のエッジ運用とセキュリティ対策をサービス事業者が担います。

技術チームと安定したリソースがあれば、自社構築を活かせます。一方、継続的な攻撃を受けていてネットワーク運用の専任者がいないサイトには、実績のあるマネージドサービスのほうが導入しやすいでしょう。

まず、言葉の意味を分けて考える必要があります。「自社構築」は構築・運用の方法、「DDoS対策」は防御能力を指します。自社構築のCDNにもDDoS対策を組み込めますが、そのためのリソースと保守を誰かが担わなければなりません。

「ICP登録不要」「自社構築」「DDoS対策」の意味を整理する

ここでいう「ICP登録不要のCDN」は、一般に、中国本土でのICP登録を済ませていないドメインでも利用できる、中国本土以外のエッジ拠点を使うサービスを指します。重要なのはサービス提供地域と導入条件です。「中国本土の利用者向けに高速化する」からといって、エッジ拠点が中国本土にあるとは限りません。

例えば、Alibaba Cloudの ESAのサービス提供地域に関する説明 では、中国本土のエッジ拠点を含む地域と含まない地域が分けられ、ICP登録の要件も異なります。実際に使う地域や登録可能なドメインは、各サービス事業者の規定で確認してください。

本記事でいう「自社構築CDN」は、利用者自身がエッジサーバーを購入または借用し、リバースプロキシ、キャッシュ、トラフィックの振り分け、監視を導入して保守する方式です。

事業者が自社のプラットフォームやエッジ網を「自社構築」と紹介することもあります。しかし、それは顧客が自分でCDNを構築することとは異なります。顧客が購入するのはマネージドサービスであり、エッジ障害、セキュリティポリシー、プラットフォームの更新を事業者が担う場合もあります。

DDoS対策CDNは、コンテンツ配信とプロキシに、DDoS攻撃や悪意あるHTTPリクエストへの対策を組み合わせたサービスです。保護するプロトコル、対応できる攻撃、プランの範囲を超えた場合の扱いは、個別の製品で確認する必要があります。

用語を整理すると、二つの方式の違いが見えてきます。

この表で比較している中心は、責任の分担です。自社構築なら必ず速いという意味でも、「DDoS対策」を掲げる製品なら必ず安定しているという意味でもありません。

自社構築の魅力は、用途に合わせて細かく設計できること

画像やダウンロードファイルが中心で、利用地域が限られ、すでに適切な海外サーバーを持つサイトを考えてみましょう。キャッシュ用のエッジを設け、繰り返し要求されるコンテンツをそこで返せば、オリジンへのトラフィックを減らしつつ、キャッシュをより柔軟に制御できる可能性があります。

NGINXの リバースプロキシとキャッシュに関するドキュメント には、リクエストの転送、キャッシュキー、キャッシュのバイパス、オリジンへの接続に関する設定が示されています。これらを組み合わせて自社配信基盤を作れますが、エッジ間の管理や障害時の振り分けは別途設計が必要です。

細かく制御できる分、結果にも責任を持つ

どのパスをキャッシュするか、どのパラメーターをキャッシュキーに含めるか、ファイルをどれだけ保持するか、新版の公開後にどう無効化するかを、用途に合わせて決められます。

独自のリリース手順があり、社内システムとの連携が必要なチームには、この制御権が役立ちます。既存のサーバー、監視基盤、運用担当者を活用できれば、追加費用も管理しやすくなります。

ただし、設定の自由度には責任が伴います。

公開画像と利用者の請求書に同じキャッシュルールは使えません。ログイン後のページ、認証情報を含むAPI、決済状況などには、明確なキャッシュ境界が必要です。誤ったルールが全エッジに展開されると、表示速度だけでなくデータの正確性にも影響します。

自社構築が適しているかは、ソフトウェアをインストールできるかだけでは決まりません。設定をレビューし、変更を反映し、必要なときに迅速に切り戻せるかも重要です。

エッジがリクエストを転送できるだけでは、構築は終わらない

長期運用では、次のような保守作業が発生します。

• あるエッジの証明書が更新されず、一部の利用者にエラーが出る。
• サイトを更新しても、エッジごとに異なる版のファイルが返る。
• エッジのプロセスは正常でも、そこへのネットワーク経路で深刻なパケットロスが発生する。
• ログが増えてディスクを圧迫し、キャッシュやプロキシに影響する。
• エッジの更新時に、既存の長時間接続をどう扱うか判断が必要になる。

一つひとつは難しくなくても、継続して見守る担当者が必要です。

特に注意したいのがフェイルオーバーです。監視で異常を見つける、振り分けシステムで接続先を変える、利用者が新しい接続先を使い始めるという工程は別々です。予備IPを用意しただけでは、既存の接続が途切れず移行することも、全利用者がすぐに切り替わることも保証できません。

自社構築CDNの利点は、こうした継続的な運用能力があってこそ活きます。サーバー数台のレンタル費用だけを見れば、その後の作業を過小評価しがちです。

サイトが攻撃を受けると、何が変わるか？

通常のアクセスが少ないときは、簡易的なプロキシも本格的な防御基盤もページを配信できるかもしれません。攻撃時には、ソフトウェアがリクエストを処理できるかに加え、正規のアクセスを運ぶネットワーク容量が残っているかが問題になります。

リクエストのレート制限と上流側でのトラフィックスクラビングは役割が違う

アプリケーション層への異常なリクエストは、アクセスルール、レート制限、利用者の識別によって影響を抑えられます。例えば、NGINXの リクエストのレート制限モジュール では、指定したキーごとに処理速度を制限し、バースト時の扱いも設定できます。

ただし、サーバー上のレート制限が働くのは、トラフィックがそこに届いた後です。エッジの上流回線が先に埋まれば、正規のリクエストさえ安定して到達できません。アプリケーションの設定を調整しても、使い切ったネットワーク容量は回復しません。

DDoS対策にネットワークリソースも必要なのはこのためです。AWSの DDoS耐性に関するアーキテクチャの解説 では、エッジ網の容量、トラフィックの分散、攻撃緩和システムを一体として扱っています。サーバー上のルールだけに防御を還元していません。

自社構築でも、DDoS対策付きのエッジ、トラフィックスクラビングサービス、冗長な回線を調達できます。ただし、費用比較にはそれらも含めなければなりません。一般的なサーバーにファイアウォールを入れた構成と、上流側の防御を備えたエッジは、同じリソースとして比較できません。

防御容量だけでなく、攻撃中も正規の利用者が使えるかを見る

攻撃中にページが開くだけでは、十分とはいえません。

ECサイトではログイン、注文照会、決済が必要です。ゲームでは入室、接続の維持、再接続が必要です。AI中継APIなら、認証と継続的な出力が正常に動き、妥当な時間内にリクエストが完了する必要があります。

あらゆる異常に対して認証を厳しくするだけでは、別の障害を招くことがあります。攻撃トラフィックは減っても、正規の利用者が操作を完了できなくなるからです。

例えば、一つの出口IPを複数の利用者が共有している場合があります。IP単位のレート制限を低くしすぎると、まとめて制限してしまいます。ブラウザーで表示できる認証ページも、APIクライアントが処理できるとは限りません。

DDoS対策CDNを購入する際は、リクエストの特性、通常時のピーク、重要なAPIを伝え、実際のトラフィックに合うポリシーを設定してください。自社構築でも同じ作業が必要ですが、ルール設計、誤検知の分析、継続的な調整を主に自社チームが担います。

どちらの方式でもオリジンの入口を守る

オリジンは、Webサイトのアプリケーション、データ、サービスが実際に稼働するサーバーです。前段にCDNを置いても、もともとの公開入口が自動的に閉じるわけではありません。

古いホスト名、過去のDNSレコード、見落としたIPv6アドレス、別のサービスがオリジンを指したままだと、攻撃者はCDNを迂回できます。実際の構成に合わせてオリジンへのアクセスを制限し、想定したプロキシからのリクエストか確認してください。

アクセス制御と帯域の保護も区別が必要です。ファイアウォールでリクエストを拒否しても、攻撃トラフィックが上流回線を占有しないわけではありません。すでに露出していてネットワーク側の防御がないオリジンでは、公開入口の変更や上流側の防御追加も検討してください。

自社構築でもサービスを購入する場合でも、オリジン保護を導入作業に含めるべきです。

中国本土の利用者向けの速度は、通信経路全体で測る

海外に設置したサイトのCDNを選ぶとき、「香港のエッジは何拠点あるか」から聞きたくなるかもしれません。

拠点の位置は重要ですが、利用者のアクセスは通信事業者のネットワーク、国境を越える回線、エッジの接続先、エッジからオリジンへの経路を通ります。地理的に近くても、夜間のピーク時に混雑するエッジなら、体感は良くないことがあります。

自社構築では、こうした経路を自分たちで調達し、組み合わせます。サービスを購入する場合は、事業者が提供できるネットワーク経路と、契約するプランで実際に利用できるリソースを確認します。

例えばCDN07の DDoS対策CDNサービス は、香港のエッジ拠点と中国本土向けのネットワーク経路を重視し、エッジの配置、帯域幅、セキュリティポリシーを要件に応じて調整できます。海外のオリジンから中国本土の利用者にサービスを提供する場合、アクセス経路と防御要件を一緒に評価できる点が比較のポイントになります。

実際の効果は、自社のアプリケーションで検証してください。特に次の二種類のリクエストは分けて測る必要があります。

キャッシュできる静的ファイルは、エッジから直接返す場合の性能を確認します。

画像、スクリプト、公開ダウンロードファイルがキャッシュにヒットすれば、オリジンへのリクエストを減らせます。

リアルタイム処理が必要な動的リクエストは、往復全体を測ります。トップページが速くなっただけでは、ログイン、注文、利用者データ、モデル呼び出しまで速くなったとは判断できません。オリジンへの経路、アプリケーションの処理、上流サービスの応答時間も影響します。

まずは実際に利用者が使うネットワークからリクエストして、基本的な値を確認できます。以下のコマンドはcurlがインストールされたLinux、macOS、WSLで使えます。サンプルのURLを自社のテストページに置き換えてください。

curl --silent --show-error \
  --output /dev/null \
  --connect-timeout 10 \
  --max-time 30 \
  --write-out 'HTTP=%{http_code}\nTTFB=%{time_starttransfer}s\nTOTAL=%{time_total}s\n' \
  'https://example.com/'

ここで`TTFB`はリクエスト開始から最初の1バイトを受け取るまでの経過時間、`TOTAL`は処理全体の所要時間を表し、単位はいずれも秒です。 curl公式マニュアルにある計測項目の定義 にもあるとおり、最初の1バイトまでの時間には接続の準備やサーバー処理も含まれます。オリジンのアプリケーション処理時間そのものではありません。

時間を比較する前に、ステータスコードと内容が想定どおりか確認します。リダイレクトする場合は、最終的なURLを使って再確認してください。403や5xxが返る場合は、原因を先に調べます。エラーページがすぐ返っても、高速化が成功したとはいえません。

このコマンドが取得するのは一つのURLだけです。ページ内の画像をすべて読み込んだり、JavaScriptを実行したりはしません。ゲームの再接続やAIのストリーミング出力も含めた体験は測れません。基本的な比較に使ったうえで、重要な操作もテストしてください。

中国本土の利用者向けには、主な省や通信事業者をカバーし、業務時間帯と夜間ピークの両方を観察します。最速の一回だけを示すより、遅いリクエスト、タイムアウト、失敗の記録を残すほうが参考になります。

インフラ費と運用費を合わせて比較する

自社構築ではサーバーと帯域の費用が目に入りやすく、DDoS対策CDNでは月額料金が目に入りやすいものです。この二つの数字だけでは、比較する範囲が揃いません。

自社構築では、エッジ、ネットワーク経路、上流側の防御、予備容量、監視とログ、ソフトウェアライセンス、保守や障害対応に必要な人員も計算に含めます。

マネージドサービスでは、プランに含まれる正規トラフィックや帯域、リクエスト数、同時接続数、ドメイン数の制限を確認します。契約上の防御範囲を超えた場合の扱いも必要です。

攻撃の緩和容量と通常のサービスに使える帯域は、別々に確認してください。

前者は特定の条件下で対応できる攻撃の範囲、後者は正規の利用者に継続して提供できる容量に関わります。大きな防御容量の数値だけでは、通常時のサービス容量を説明できません。

チームが現在どの段階にあるかも、選択に影響します。

既存リソースと運用チームがあれば、自社構築を検討する価値がある

安定したネットワーク経路があり、利用地域が比較的限られ、キャッシュ可能なコンテンツが中心で、エッジを保守できる担当者がいるなら、自社構築の設定自由度を活かせるでしょう。

こうしたチームは既存リソースを使い、アプリケーションに合わせてキャッシュと配信を調整できます。DDoS対策リソースを段階的に追加することも可能です。自社構築と専門的な防御は、二者択一ではありません。

アクセスの増加、攻撃の継続、エッジ障害が起きた場合に、現在の人員と予算で対応できるか、あらかじめ考えておく必要があります。

攻撃が続き、運用担当が少ないならマネージドサービスを検討する

別のサイトでは状況が異なります。開発者はアプリケーションの機能開発に集中し、運営者はサイト運営と顧客対応を担い、攻撃が発生してから急いでデータセンターに連絡し、ルールや接続先を変更することになります。

その場合、事業者が問題の特定や防御設定の調整を支援し、費用と対応範囲を明確に説明できるかが、復旧の効率に影響します。

CDN07の ICP登録なしのドメインに対応するDDoS対策CDN は、DDoS攻撃とHTTPフラッドへの対策を提供し、WebSocketへの対応も明記しています。公開されている導入案内には、本人確認不要の登録とUSDT決済の選択肢もあり、こうした登録・決済条件を求める海外プロジェクトでは確認する価値があります。

こうしたチームが比較すべきなのは、一つのサービスでネットワーク経路、防御、日常のサポートをまかなえ、複数のリソースを個別に調整する負担を減らせるかです。長期契約の前に実際のアプリケーションで試し、通常時のアクセス、長時間接続、ポリシーの誤検知、請求の範囲を確かめてください。

サービスを導入しても、自社の認証、データベース、アプリケーションの容量、バックアップは引き続き管理が必要です。双方の担当範囲を明確にすると、運用も進めやすくなります。

既存の構成と組み合わせることもできる

自社構築のキャッシュやゲートウェイが稼働していても、DDoS対策サービスを導入するためにすべて撤去する必要はありません。

役立っているアプリケーション固有の設定を残し、前段にDDoS対策の入口を置く方法や、一部のドメインだけをマネージドサービスに移す方法があります。プロキシを二層にする場合は、キャッシュルール、実際のクライアントIPの引き継ぎ、証明書の検証、タイムアウト設定を再確認し、層間の競合を避けてください。

各層を残すかどうかは、それぞれが実際に担う機能で判断します。作業の重複を減らし、障害箇所を特定しやすい構成のほうが、長く保守しやすくなります。

よくある質問

ICP登録なしのドメイン向けにCDNを自社構築すれば、DDoS対策サービスは不要ですか？

一概にはいえません。自社構築はエッジとプロキシ基盤を誰が作るかの問題です。防御力は上流ネットワーク、エッジのリソース、セキュリティポリシーによって決まります。すでにDDoS対策のインフラを持つチームなら自社で組み込めますが、一般的なエッジサーバーでは攻撃への耐性を別途評価する必要があります。

ICP登録不要のDDoS対策CDNは、自社構築CDNより必ず速いですか？

決まった答えはありません。速度は実際のネットワーク経路、利用者の分布、キャッシュの効果、オリジンへの接続品質で変わります。適切に設計した自社構築CDNも高速になり得ます。同じアプリケーションを、同じネットワークと近い時間帯で比較してください。

地域の異なるサーバーを数台用意すれば、CDNとして運用できますか？

複数拠点のプロキシや配信基盤は作れます。ただし、長期運用にはトラフィックの振り分け、ヘルスチェック、キャッシュ管理、証明書の更新、監視、障害対応も必要です。エッジの台数は条件の一つにすぎません。

ゲームやAI APIに、通常のWebサイトと同じ防御設定を使えますか？

そのまま流用するのは適切ではありません。Webサイトのファイル、API、長時間接続では通信の特性が異なるため、認証やレート制限を個別に設計します。ゲームで独自のTCPまたはUDPプロトコルを使う場合は、対象の製品が対応しているか確認してください。HTTP CDNがWebSocketに対応していても、すべてのゲームプロトコルを保護できるとは限りません。

DDoS対策CDNを購入した後も、オリジンIPを隠す必要がありますか？

はい。オリジンが露出する経路を減らし、CDNを迂回するアクセスを制限する必要があります。CDNが保護するのは、その防御経路を通るトラフィックです。オリジンに残る公開入口、古いDNSレコード、別のサービスは個別に確認してください。

選ぶ前に、サイトの継続稼働を誰が担うか決める

二つの方式にはそれぞれ適した条件があります。判断するときは、次の四点を押さえてください。

• 自社構築は制御の自由度が高い一方、保守の責任もすべて負います。
• DDoS対策にはネットワークリソースとセキュリティポリシーの両方が必要です。プロキシソフトウェアの導入は、その一部にすぎません。
• 中国本土の利用者に提供する場合は、アクセス経路、オリジンへの接続品質、夜間ピーク時の性能を一緒に確認します。
• 費用は、通常時のサービス容量、攻撃対応、人件費を同じ条件で比較します。

チームとリソースがあるなら、小規模な自社構築から検証できます。すでに攻撃を受け、ネットワークと防御の維持負担を減らしたい場合は、CDN07のようにICP登録なしのドメインに対応するDDoS対策CDNも試用候補に加えてください。

主な利用者の地域、オリジンの設置場所、使用プロトコル、通常時のピークトラフィック、過去の攻撃記録を伝えて相談しましょう。「料金はいくらで、何Gbpsまで防御できますか」とだけ聞くより、長期利用に合う構成を選びやすくなります。