CDNとは？ Cloudflareが有力なプロバイダーになった理由

CDNとは

コンテンツデリバリーネットワークは、アプリケーションのオリジンサーバーより利用者に近い拠点からコンテンツを配信する、分散したサーバー群です。オリジンは正しい情報の元となる場所で、ネットワークの端にあるCDNサーバーは再利用できるレスポンスを保存し、接続を終端し、アプリケーションが必要なリクエストを転送します。

こうしたエッジサーバーは、一般にPoPと呼ばれるポイントオブプレゼンスに配置されます。PoPには多数のマシンがあり、地域のインターネットプロバイダー、携帯電話事業者、クラウドネットワーク、ほかのトランジットネットワークへ直接接続できます。CDNは通常、単に地理的に最も近い場所ではなく、ネットワークの状態に応じて訪問者を適したPoPへ誘導します。

CDNがなければ、すべてのリクエストはオリジンまたはそのロードバランサーに到達します。オリジンの近くにいる訪問者なら、すぐにレスポンスを受け取れるかもしれません。別の大陸にいる人はより多くのネットワークを通過し、接続の確立やアプリケーションとの往復ごとに遅延が加わります。どれほど高速なサーバーでも、信号が長距離を移動する時間まではなくせません。

たとえば、アプリケーションが有用なコンテンツを表示するまでに、順番に3回のやり取りを必要とするとします。往復時間が90ミリ秒なら、転送と処理の前に約270ミリ秒がかかります。接続先を往復20ミリ秒のエッジ拠点に移せば、その流れから約210ミリ秒を減らせます。正確な結果は、ルーティング、混雑、プロトコルの再利用、要求されたレスポンスがすでにキャッシュされているかどうかに左右されます。

CDNは、完全な小型Webサイトを複製した集まりではありません。あるエッジには人気の画像が保存され、別のエッジにはコピーがないこともあります。公開文書を1時間キャッシュする一方で、認証済みAPIリクエストはすべて転送することもあります。キャッシュは、リクエストの属性、レスポンスヘッダー、設定したルール、利用可能な容量に基づいて保存、更新されます。

CDNはWebホスティングとも異なります。ホスティングは元のアプリケーションを実行し、正しいデータを保存し、レスポンスを生成します。CDNはそのインフラの前に置かれるリバースプロキシです。一部のプロバイダーは現在、エッジコンピューティングやストレージも提供しているため、アプリケーションの一部をネットワーク上で動かせます。ただし、それだけでデータベースや残りのバックエンドが移るわけではありません。

この違いがCDNの中心的な価値を説明します。CDNは、避けられる距離とオリジンでの繰り返し作業を減らします。非効率なアプリケーションのプログラムを高速にしたり、遅いデータベースクエリを直したり、キャッシュできないリクエストがあるたびに過負荷のオリジンを補ったりはできません。

CDNが各リクエストを処理する仕組み

CDNは、エッジ拠点で利用者の接続を受け付け、そこで有効なレスポンスを返せるか確認し、必要なときだけオリジンへ接続します。通常、DNSとAnycastルーティングは、キャッシュの判断より前にトラフィックをプロバイダーのネットワークへ導きます。

一般的なリクエストは、次の5段階で進みます。

1. DNSはオリジンを直接公開せず、CDNに関連付けられたアドレスを返します。
2. ネットワークは接続を利用可能なエッジ拠点へルーティングし、CDNがそこでTLSとHTTPプロトコルをネゴシエートします。
3. エッジは、スキーム、ホスト、リクエスト先、クエリパラメーター、選択されたヘッダーなどからキャッシュキーを計算します。
4. 新しい一致があればキャッシュヒットです。ミス、バイパス、または期限切れのエントリーがあると、エッジは上位キャッシュ層またはオリジンへ接続します。
5. CDNは利用者へレスポンスを送り、後のリクエストに備えて条件を満たすコピーを保存することがあります。

Anycastでは、多数の施設が同じアドレス範囲を広告します。インターネットのルーティングは、接続を到達可能な広告へ運びます。通常は利用者を近くの施設へ導きますが、ルーティングポリシーやピアリングにより、地理的に最も近い施設以外の方が良い性能を出す場合もあります。

キャッシュの新鮮さは、主にHTTPレスポンスヘッダーとCDNルールで決まります。オリジンは次のように返すかもしれません。

Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=60
ETag: "build-4821"

この例では、ブラウザーはレスポンスを5分間再利用でき、共有キャッシュは1時間新鮮だと見なせます。指定された再検証期間中、対応するキャッシュは更新版を確認している間に古いコピーを返せます。ETagによる条件付き検証では、コンテンツが変わっていなければレスポンス全体を転送せずに済みます。

TTLは判断の一部にすぎません。privateまたはno-storeが付いたレスポンスは共有キャッシュに入れるべきではありません。認証情報を持つリクエストやセッションCookieを設定するレスポンスも、慎重に扱う必要があります。個人向けHTMLを共有の識別子でキャッシュすると、ある利用者のコンテンツが別の利用者に見えてしまうおそれがあります。

キャッシュキーは、どのリクエストが同じ保存済みレスポンスを再利用できるかを決めます。すべてのトラッキングパラメーターを含めると、同じコンテンツのコピーが大量に作られ、ヒット率が下がります。レスポンスを変えるパラメーターを無視すると、誤ったコンテンツが返る可能性があります。言語、端末種別、テナントID、選択したCookie、圧縮対応は、サーバーが返す内容を変える場合にだけ識別子に含めるべきです。

パージは、通常の有効期限より前に保存済みコピーを削除します。緊急修正には役立ちますが、頻繁にグローバルパージを行うと温まったキャッシュエントリーが失われ、オリジンの負荷が増えます。デプロイにはバージョン付きアセット名の方が安全です。新しいHTMLから新しいアセット名を参照し、古い不変ファイルはクライアントから要求されなくなるまでキャッシュしたままにできます。

キャッシュミスは失敗ではありません。新しい、期限切れの、まれな、または意図的にキャッシュ不可のコンテンツでは普通に起きます。良いCDN設定は、安全で価値のあるレスポンスをキャッシュすることを目指します。すべてのリクエストを無理に保存することが目的ではありません。

CDNが改善することと、直せないこと

CDNは、設定がアプリケーションに合っていれば、配信時間、オリジンの効率、回復力、境界での防御を改善します。効果の大きさは、利用者の場所、コンテンツの再利用、キャッシュポリシー、バックエンドに届く処理量に左右されます。

最も分かりやすい改善は、接続遅延の低下です。TLSネゴシエーションは訪問者の近くで行われ、再利用できるコンテンツはオリジンへの往復を避け、持続接続は繰り返しの接続確立を減らします。最新のプロトコルは、損失や接続状態の変化があるモバイルネットワークでも有利になることがあります。こうした効果は最初のバイトが届くまでの時間を短縮し、ページ体験の指標を改善できます。ただし、表示を妨げるスクリプト、過大なクライアントバンドル、レイアウトシフト、遅いブラウザー実行までは解消しません。

オリジンからの負荷を減らすことで、インフラとデータ転送の費用を下げられる場合があります。毎月8TBのキャッシュ可能なファイルをオリジンから送るサービスを考えてみましょう。CDNがそのバイトの92%をエッジストレージから配信するなら、通常のミスによるオリジン転送量は、再検証トラフィックと運用上のオーバーヘッドの前で約640GBです。金額は、ホスティングプロバイダーの送信料金、CDNプラン、リクエスト料金、変換料金、有料ルーティング機能に左右されます。

分散ネットワークは、フラッシュクラウドが起きても、同じファイルへの繰り返しリクエストを1台のサーバーへすべて送らずに吸収できます。不健全なエッジ施設を避けて利用者を誘導することもできます。設定されていれば、オリジンフェイルオーバーは対象トラフィックを予備のバックエンドへ送れます。データベースが停止した場合、両方のオリジンが同じ依存先を共有する場合、すべてのリクエストにリアルタイムのアプリケーション処理が必要な場合には、これらで可用性が保証されるわけではありません。

リバースプロキシはセキュリティの境界を作ります。大量攻撃トラフィックを捨て、ファイアウォールやレートルールを適用し、通常のDNS回答からオリジンアドレスを隠せます。ただし、古いDNSレコード、メールヘッダー、直接アクセス用のホスト名、第三者サービスがオリジンを明かし、そのファイアウォールが任意のインターネットトラフィックを受け入れているなら、この境界は機能しません。

アプリケーションのセキュリティは、引き続き所有者の責任です。CDNだけでは、壊れた認可、安全でないデータアクセス、公開されたシークレット、脆弱な依存関係、ビジネスロジックの悪用を修正できません。管理型ファイアウォールルールは一般的な攻撃トラフィックを減らしますが、誤検知やアプリケーション固有の脅威の見逃しを避けるには監視と調整が必要です。

効果が小さいワークロードもあります。オリジンと同じ施設で使う社内アプリケーションは、すでにネットワーク遅延が低い状態です。リクエストごとに固有のレスポンスは、共有キャッシュからあまり利益を得られません。大容量アップロードは引き続きオリジンの容量を使う可能性があり、エッジプロキシが増えることで、タイムアウト、本文サイズ、ヘッダーの制限を理解すべき場所も増えます。

実際の判断基準は、CDNが料金と運用の複雑さ以上に、遅延、転送量、リスクを減らせるかどうかです。どの分散ネットワークもすべてのアプリケーションを改善すると考えず、実トラフィックで測定してください。

現代のアプリケーションでCDNが使われる場所

CDNは、多くの利用者が再利用可能なコンテンツを要求する場所や、近くの接続先による利点がある場所で使えます。静的Webサイトは最も単純な例ですが、ソフトウェアダウンロード、API、メディア配信、SaaSアプリケーション、モバイルクライアント、接続デバイスでも、エッジネットワークはさまざまな形で使われています。

一般的な導入パターンは次のとおりです。

• 静的サイトのアセット: 画像、フォント、スタイルシート、スクリプト、文書などの公開ファイルを、長い有効期間とバージョン付きの名前でキャッシュします。
• Webアプリケーションのシェル: 初期HTMLとフロントエンドバンドルをエッジから配信し、アカウントデータは認証済みサービスから取得します。
• API: クライアントの近くでTLSを終端し、上流への接続を再利用し、不正な呼び出し元をレート制限し、明示的に公開されたレスポンスまたは安全に分離されたレスポンスだけをキャッシュします。
• 動画と大容量ファイル: 人気のセグメントやダウンロードを視聴者の近くに保存し、公開やライブイベントでオリジンが飽和しないようにします。
• モバイルとデバイスへの配布: 署名済みアプリケーションパッケージ、ファームウェア、地図、メディアを、更新の検証を維持しながら効率よく配信します。

動的トラフィックは、静的ファイルより注意が必要です。GETとHEADのレスポンスは、公開データを含み、明確な新鮮さのルールを定めていればキャッシュできることがあります。変更を伴うリクエストは通常、アプリケーションに到達させるべきです。認証済みレスポンスは、エントリーを意図的に分離し、IDが衝突しないことを証明できない限り、共有ストレージを通さないようにします。

GraphQLなどのAPI形式では、1つのエンドポイントが非常に多くの異なるレスポンスを生成できるため、一律のキャッシュは難しくなります。永続化された操作、正規化したリクエスト本文、アプリケーションが生成するサロゲートID、専用のAPIキャッシュが役立つこともありますが、認可と無効化の挙動が明確になってから検討すべきです。

ストリーミングは、1つの巨大な動画転送ではなく、小さなメディアセグメントとアダプティブビットレートのバリエーションに依存します。人気のセグメントはイベント中に高く再利用されます。まれな録画には、ソースからの繰り返し取得を避けるため、上位キャッシュ層または永続的なCDNストレージが必要になるかもしれません。権利の管理、署名付きアクセス、地域制限、プレーヤーの挙動は、別途設計すべき課題です。

複数リージョンに展開するSaaS製品では、アプリケーションシェルと公開リソースにCDNを使い、トラフィックマネージャーがリアルタイムデータ用のアプリケーションリージョンを選ぶことがよくあります。エッジは接続コストを減らせますが、あるリージョンの利用者が別の場所にあるデータを問い合わせる場合、データベースまでの距離はなくせません。データの配置と整合性が、対話操作の遅延の多くを決め続けます。

Koder.aiプロジェクトでは、公開するReactバンドル、フォント、メディアをキャッシュし、Goサービスは引き続きリクエストを認可し、PostgreSQLはアプリケーション層の背後に置く構成が実用的です。Flutterのアプリケーションパッケージも、リリース署名と更新管理を保てばCDN配信を使えます。CloudflareをKoder.aiの独自ドメインの前に置く場合は、ホスティング設定で必要なDNS構成を確認し、本番トラフィックを移す前にテストしてください。ソースコードをエクスポートすれば、チームが管理するインフラへデプロイした後にも同じパターンを使えます。

キャッシュが最も効果を発揮するのは、アプリケーション開発者がレスポンスの意味を定義するときです。CDN運用者が、レスポンスが公開可能か、有効期間はどれくらいか、どのリクエスト属性が内容を変えるかを推測する必要があってはいけません。

CDNプロバイダーの測り方

CDNプロバイダーは、アプリケーションの利用者の場所、トラフィックの種類、信頼性の目標、セキュリティ要件、運用モデルに照らして測るべきです。プロバイダーごとに地域、通信事業者、プロトコル、キャッシュ状態、機能設定が異なるため、単一のベンチマークで普遍的な首位を決めることはできません。

有用な比較では、次の5つの観点を扱います。

• 到達性と相互接続: 実際の利用者の近くにある施設、そのネットワークとのピアリング、オリジンへの接続性、必要な国への対応を確認します。
• パフォーマンス: 最初のバイトが届くまでの時間、ダウンロード時間、キャッシュの動作、接続エラー、複数のパーセンタイルでのページ体験を測定します。
• 信頼性: サービス保証、障害履歴、トラフィック誘導、オリジンフェイルオーバー、コントロールプレーンの動作、サポートの応答を確認します。
• セキュリティとコンプライアンス: DDoS対策範囲、ファイアウォール制御、ボットとレート制御、ログ、証明書管理、データ所在地、監査要件を比較します。
• 運用と費用: 設定、自動化、可観測性、サポート、移行作業、追加機能、リクエスト料金、オリジン送信費用を考慮します。

施設数だけでは、パフォーマンスを十分に測れません。プロバイダーがある都市で運用していても、自社の顧客が使う通信事業者と十分にピアリングしていないことがあります。別のプロバイダーは施設数が少なくても、重要なネットワークへの経路が優れているかもしれません。リクエストを処理する場所も、混雑やメンテナンス中に変わることがあります。

合成テストと実ユーザー監視を両方使ってください。Catchpoint、ThousandEyes、WebPageTestのような合成システムは、管理された場所から再現可能なテストを提供します。ブラウザーの測定では、実際の訪問者が経験する端末、通信事業者、電波状況、ページの挙動が分かります。SpeedCurveや自社のブラウザーテレメトリーでこの情報を集められます。W3TechsやBuiltWithの導入レポートは、プロバイダーの利用頻度を示しますが、速度テストではありません。

評価は管理された試行として行います。

1. リージョン、端末クラス、コンテンツ種別、トラフィック期間ごとに、オリジンのみの基準値を記録します。
2. 各候補に、比較可能なキャッシュ、TLS、圧縮、セキュリティポリシーを設定します。
3. コールドミス、ウォームヒット、再検証、動的レスポンス、大きなオブジェクト、アップロードを分けてテストします。
4. 本番データを危険にさらさず、不健全なオリジンと急なトラフィック増加をシミュレートします。
5. 測定された効果を、月額の総費用と各選択肢の運用に必要なエンジニアリング時間と比較します。

中央値の遅延は、最も悪い体験をしている利用者を隠します。サンプル数が十分であれば、p50、p75、p95、p99を追跡してください。遅いバックエンドをCDNのせいにしないよう、エッジ時間とオリジン時間を分けます。初回訪問と再訪問を比較し、キャッシュ可能なバイトとリクエスト数を区別します。

キャッシュヒット率にも2つの見方が必要です。リクエストヒット率は、エッジがオリジンを使わずに応答する頻度を示します。バイトヒット率は、エッジがどれだけの転送を引き受けるかを示します。少数の大きな動画でバイト比率が高くなっても、何千もの小さなAPIリクエストはバックエンドに届き続けることがあります。

信頼性の測定には、エッジエラー、オリジンエラー、DNS障害、TLS障害、タイムアウト、正常なフェイルオーバーを含めるべきです。障害中にダッシュボードが使えなかったり、設定変更の反映に時間がかかりすぎたりするなら、公称の稼働率だけではほとんど意味がありません。

セキュリティ比較には、ワークロード固有のテストが必要です。正当なクライアントがレート制限を通過できること、管理ルールが実際の購入やAPI呼び出しを遮断しないこと、ログに調査に十分な証拠があること、オリジンへの直接アクセスが閉じていることを確認してください。コンプライアンス認証は、契約したサービスと構成したデータフローが対象範囲に入る場合にだけ意味を持ちます。

このプロセスにより、「リーダー」という言葉に実用的な意味が生まれます。特定のアプリケーションにとっての有力なプロバイダーとは、許容できるコストと運用リスクで測定目標を満たすプロバイダーです。

Cloudflareが有力なプロバイダーと考えられる理由

Cloudflareが有力なCDNプロバイダーと考えられるのは、広いネットワーク到達性、高い導入実績、利用しやすい入門プラン、セキュリティサービス、プログラム可能なアプリケーション配信を1つのネットワークで組み合わせているためです。その地位は、この組み合わせによるものであり、すべてのワークロードで実証できる1位という意味ではありません。

Cloudflareは2010年に、不要なトラフィックをフィルタリングし、Webサイト配信を改善するサービスとして始まりました。キャッシュとDDoS防御は同じリバースプロキシアーキテクチャを共有していたため、顧客はオリジンに機器を設置せずにパフォーマンスと保護を得られました。その後、同社はネットワークをDNS、アプリケーションセキュリティ、プライベートアクセス、開発者向けコンピューティング、ストレージ、メディアサービスへ広げました。

そのネットワークは125か国以上、330以上の都市に到達し、13,000以上の他ネットワークと相互接続しています。この広がりにより、Cloudflareはアクセスプロバイダーの近くでトラフィックを交換する機会を多く持ちます。Anycastにより、チームがリージョンごとに別々の公開エンドポイントを作らなくても、同じ顧客向けサービスアドレスを各施設で運用できます。

利用しやすさも導入を後押ししました。小規模なサイトは無料プランから始められ、大規模組織は有料の制御機能、サポート、契約上の保証、専門的なネットワークサービスを購入できます。ダッシュボードとAPIは、DNS、プロキシ、証明書、キャッシュ、トラフィックルール、セキュリティポリシーを1つの運用モデルにまとめます。

共有ネットワークでは、リクエストが1つのエッジで複数の機能を通過できます。Cloudflareは、TLSを終端し、セキュリティポリシーを評価し、キャッシュを確認し、アプリケーションロジックを呼び出せます。各段階で無関係なベンダーネットワークを経由する必要がありません。統合は連携作業を減らせますが、同時に1社の設定と可用性への依存も高めます。

測定方法を定めずにCloudflareを世界一のCDNと呼ぶのは、根拠を強く言いすぎです。大規模なメディア配信やエンタープライズ配信ではAkamaiが選ばれることがあります。AWSと深く結び付いたアプリケーションではCloudFrontが自然な選択肢になるかもしれません。Fastlyは経験豊富なチームに詳細な配信制御を提供します。利用者が特定地域に集中していれば、地域プロバイダーがグローバルベンダーを上回る場合もあります。

Cloudflareは、多くの評価項目で信頼でき、規模の異なる組織が使えるため、有力な選択肢に入ります。最終決定には、ワークロードテスト、契約の確認、プロバイダー障害への明確な計画が必要です。

現在のCloudflareキャッシュの仕組み

Cloudflareは、プロキシされたDNSレコード上の条件を満たす静的リソースを自動でキャッシュします。一方、HTML、JSON、個人向けアプリケーションレスポンスには明示的なポリシーが必要です。新しい構成ではCache Rulesを使い、オリジンヘッダーをアプリケーション契約の一部として扱うべきです。

プロキシ済みとしてマークされたDNSレコードは、対応するWebトラフィックをCloudflare経由で送ります。DNSのみのレコードは設定済みオリジンへ解決され、そのレコードではCDNキャッシュ、HTTP DDoSフィルタリング、エッジファイアウォール処理を受けません。一部のホスト名だけがプロキシ状態で、ほかがそうでない場合、この違いを見落としがちです。

Cloudflareの既定のキャッシュ動作は、メソッド、ファイル拡張子、ステータスコード、クエリ文字列、レスポンスヘッダー、Cookie、認可などを考慮します。静的ファイル種別は通常、対象になります。HTMLとJSONは既定ではキャッシュされません。制限的なキャッシュディレクティブ、Set-Cookieヘッダー、特定の認証済みリクエストがあるレスポンスは、通常ストレージを通りません。

Cache Rulesでは、対象かどうか、エッジとブラウザーでの有効期間、キャッシュ識別子、クエリ処理、レスポンスステータスによる動作を変えられます。現在のルールは重ねて適用できるため、複数のルールが1つのリクエストに一致し、後の競合する設定が優先されることがあります。これは古いPage Rulesとは異なります。既存のPage Rulesは慎重に移行する必要がありますが、新しい設計ではキャッシュ、リダイレクト、オリジン選択、構成のための専用ルール製品を使うべきです。

Tiered Cacheは、オリジンへ接続するエッジ施設の数を減らします。下位層でミスしたとき、ソースからオブジェクトを取得する前に上位層を確認します。Cloudflareは標準プランでTiered Cacheとスマートトポロジーを提供していますが、グローバル、リージョン、カスタムのトポロジーは利用条件が限られます。選ばれた上位層にミスを集約すると、再利用を改善し、オリジンへの同時接続を減らせます。

Cache Reserveは、通常のキャッシュ階層より上に永続ストレージを追加します。これは、有効期間が長いキャッシュ可能オブジェクト向けの、従量課金の有料オプションです。保存したオブジェクトもキャッシュポリシーに従って古くなり、オリジンへの再検証が必要になる場合があります。保持と新鮮さは別です。保持は保存済みコピーが利用可能かを決め、新鮮さはCloudflareがソースを確認せずに送れるかを決めます。

Argo Smart Routingは、Cloudflareのネットワーク上をオリジンへ向かう必要があるトラフィックに対し、ネットワーク観測を使ってより良い経路を選ぶ別の有料機能です。動的リクエストやミスに役立つことがありますが、遅いアプリケーション処理を直す代わりにはなりません。

HTTP/3は、エッジ証明書が有効なら標準プランでCloudflareへの訪問者接続に利用できます。この設定によって、CloudflareからオリジンへのHTTP/3接続が作られるわけではありません。有効の切り替えだけを改善の証拠と見なさず、モバイルネットワークでプロトコルの結果をテストしてください。

TLSには、訪問者からCloudflareへの接続と、Cloudflareからオリジンへの接続があります。Full strictモードでは、オリジンが要求されたホスト名に一致する有効期限内の正しい証明書を提示することを検証します。Flexible暗号化はエッジからオリジンまでの区間を暗号化しないため、オリジンでHTTPSを利用できる本番アプリケーションでは使うべきではありません。

安全なキャッシュポリシーは、次の5つの原則に従います。

• 公開かつ再利用可能なレスポンスをキャッシュし、アカウント固有のコンテンツは既定でバイパスします。
• バージョン付きアセットには長い有効期間を設定し、文書には公開頻度に合う短い期間を設定します。
• 無関係なトラッキングパラメーターは、レスポンスを変えないことを確認してから除外します。
• キャッシュキーを変える前に、Cookie、認可、言語、端末、テナントの挙動をテストします。
• 修正時は狭い範囲でパージし、その結果のオリジン負荷を監視します。

高いヒット率だけが目標ではありません。正確さ、プライバシー、新鮮さ、予測可能な無効化を優先してください。

Cloudflareがキャッシュ以外に提供するもの

CloudflareはCDNに加え、アプリケーションセキュリティ、オリジン保護、エッジコンピューティング、メディア処理、プライベートアクセスサービスを提供します。これらの製品はインフラと管理画面を共有しますが、制限、課金モデル、プランでの利用可否は異なります。

主なサービス群は次のとおりです。

• アプリケーションセキュリティ: DDoS緩和、管理型およびカスタムファイアウォールルール、レート制限、ボット制御、API保護、証明書サービス。
• オリジン保護: プロキシアドレス、ネットワーク許可リスト、認証済みオリジンプル、ヘルスチェック、ロードバランシング、外向きのCloudflare Tunnel接続。
• 開発者プラットフォーム: Workersコンピューティングと、KV、D1、Durable Objects、R2、Queuesなどのストレージ、メッセージング製品。
• メディアサービス: 画像ストレージと変換、自動フォーマット選択、動画の取り込み、エンコード、ストレージ、アダプティブ配信。
• プライベート接続: Zero Trustアクセス、セキュアWebゲートウェイ機能、従業員、拠点、インフラ向けのネットワークサービス。

DDoS保護は標準CDNプラン全体で利用できますが、ファイアウォールルールの容量、管理型保護、ボット機能、分析データの保持、サポートレベルは異なります。レート制限では、不正な自動化と、アプリの起動、決済、Webhook配信、モバイルクライアントの再試行のような正当な急増を区別する必要があります。

レコードをプロキシすると、通常の訪問者からオリジンアドレスを隠せますが、すでに別の場所で公開された情報までは消せません。トラフィックを確認した後、オリジンのファイアウォールを許可済みの送信元に制限してください。認証済みオリジンプルは、リクエストがCloudflare経由で来たことを証明書ベースで検証します。Cloudflare Tunnelは、サービスの運用モデルに合う場合、外向き接続を作ることで公開ルーティング可能なオリジンアドレスを不要にできます。

Workersは軽量なV8 isolateを使い、Cloudflareのネットワーク全体でリクエスト処理コードを実行します。リダイレクト、認証確認、実験、パーソナライズ、APIの組み合わせ、アプリケーション機能全体を処理できます。可変メモリーがリクエスト間で保持されることや、2つのリクエストが同じisolateに到達することを前提にプログラムしてはいけません。状態を伴う連携は、適切なストレージサービスに任せるべきです。

Cloudflare Imagesは、リモート画像をエッジで変換したり、有料プランで元画像を保存したりできます。無料のImages層には、ユニークな変換の月間枠があります。より多くの変換やホスト済み画像の配信には別の課金指標が使われます。異なるソースと変換の組み合わせごとに利用量へ影響するため、無制限のサイズや品質値は不要なバリエーションを増やす可能性があります。

Cloudflare Streamは、ライブおよびオンデマンド動画の取り込み、保存、エンコード、アダプティブ配信を扱います。CDNを有効にするだけで無料になる機能ではなく、別サービスです。既存の動画ワークフローを置き換える前に、アクセス制御、再生時間、保存期間、ソースの権利、対応するエンコード出力を確認してください。

Zero Trust製品は、公開コンテンツ配信とは別の問題を解決します。利用者や端末が、プライベートアプリケーションまたはインターネットに到達する方法を制御します。サービスが同じネットワーク上で動いていても、CDNの購入によりすべてのプライベートアクセス機能が含まれるわけではありません。

統合分析では、エッジトラフィック、キャッシュ結果、セキュリティイベント、Workerの実行を関連付けられます。保持期間と詳細度はプランや製品によって異なります。障害調査や監査ポリシーでより長い記録が必要な場合は、重要なログを組織の監視システムへエクスポートしてください。

CloudflareとほかのCDNプロバイダーの比較

Cloudflareは導入しやすさと、1つのネットワークで利用できるサービスの幅で目立ちます。一方、特定のクラウド、配信の記述方法、メディアワークフロー、エンタープライズの運用モデルには、ほかのプロバイダーの方が合う場合があります。比較ではベンダーの世界平均ではなく、アプリケーションに焦点を当てるべきです。

Cloudflareのフルゾーン設定では通常、権威ネームサーバーが変わります。1社でDNSとプロキシを管理する場合には便利です。別の権威DNSサービスを維持しなければならない組織は、部分構成の利用可否とプラン要件を確認する必要があります。この違いは、パフォーマンステストを始める前に移行設計を決める場合があります。

コンテンツがすでにAWSストレージにあり、アプリケーション権限でAWS IDを使っているなら、CloudFrontは連携作業を減らせます。Fastlyは、リクエストの近くで詳細な配信ロジックを表現したいチームに合うことがあります。Akamaiは厳しいエンタープライズおよびメディアプログラムで長年の経験があります。地域CDNは、特定の国に焦点を置くサービスに対し、より良い現地サポート、支払い条件、通信事業者との関係を提供するかもしれません。

2つのCDNを使うと、1つのエッジネットワークへの依存を減らせますが、構成のずれ、一貫しないキャッシュ無効化、証明書の連携、重複するセキュリティルール、別々のログ、より難しい障害診断を招きます。可用性または地域パフォーマンスの要件が、その運用コストを上回る場合に、マルチCDNアーキテクチャは正当化されます。無関係な公開テストで2社が速そうに見えるだけで追加すべきではありません。

したがってCloudflareは有力な既定候補ですが、自動的な勝者ではありません。最も関連性の高い代替案との短い試行は、機能数の比較より良い判断をもたらします。

Cloudflareの料金と総費用

Cloudflareの料金は固定の標準プランから始まり、ワークロードに応じて従量課金の製品とカスタム契約が加わります。公開されているNetworkおよびCDNの層は次の価格です。

• Freeは月額0ドルで、ビジネスクリティカルではない個人または趣味のプロジェクト向けです。
• Proは年払いで月額20ドル、月払いで25ドルです。
• Businessは年払いで月額200ドル、月払いで250ドルです。
• Enterpriseサービスは、ミッションクリティカルなアプリケーション向けのカスタム年額契約です。

基本の層にはCDN配信、権威DNS、Universal SSL、DDoS保護が含まれますが、すべてのCloudflare製品が無料になるわけではありません。Argoルーティング、ロードバランシング、高度な証明書オプション、Workersの利用量、画像処理、動画配信、永続キャッシュストレージ、ログアクセス、専門的なセキュリティ機能には、別料金または契約条件が発生する場合があります。

総費用は実際のトラフィック区分で見積もります。キャッシュ可能なバイト、動的リクエスト、画像バリエーション、動画時間、コンピューティング呼び出し、ログ量、DNSクエリ、ソース転送を分けます。そのうえで、少ない月、通常の月、ピークの月をモデル化します。設定、監視、障害対応、ポリシー保守にかかるスタッフ時間も含めてください。

オリジンの節約も同じ計算で重要です。有料CDN機能により、より大きなクラウド送信費用を減らせたり、ソースサーバー群を小さくできたりする場合があります。反対に、地域のトラフィックが少ないサイトでは、無料層でセキュリティや接続処理が改善しても、金銭面の利点は小さいかもしれません。

料金はアーキテクチャにも影響します。チームは、人気のファイルには通常のエッジキャッシュ、取得コストが高い少数のソースオブジェクトには永続ストレージ、まれなコンテンツにはオリジンからの直接配信を選ぶかもしれません。すべてのトラフィックにすべての選択肢を適用するより、こうした方が安くなることが多いです。

Cloudflareを安全に判断、導入する方法

Cloudflareは、公開Webサイト、アプリケーション、APIが分散した利用者に提供され、グローバルなプロキシネットワークを自前で構築せずに、エッジ配信、トラフィック保護、証明書管理を求めるチームに適しています。導入は、有効化した設定の寄せ集めではなく、測定可能な目標と元に戻せる試行から始めるべきです。

プロキシマシンを完全に自社所有しなければならない場合、既存ベンダーの契約がすでに要件を満たしている場合、アプリケーションが未対応のプロトコルを使う場合、データ処理を厳密に定められた法域内にとどめる必要がある場合は、適合度が低いことがあります。Cloudflareには地域およびエンタープライズ向けの制御がありますが、契約した構成が組織の法的、技術的要件に合うか確認しなければなりません。

安全な導入は、次の5段階で進められます。

1. 遅延、ページ指標、エラー率、オリジン負荷、転送量、現在のDNS値の基準を記録します。
2. ドメインを追加し、取り込まれたすべてのDNSレコードを確認し、DNSのみのままにすべきメールまたは検証用レコードを特定します。
3. 低リスクのホスト名または一部のトラフィックで試行し、証明書、リダイレクト、リクエスト本文、アップロード、アプリケーションのコールバックを確認します。
4. Full strict暗号化を有効にし、オリジンへの直接アクセスを制限し、可能な限り監視モードでセキュリティポリシーを導入します。
5. 範囲を絞ったCache Rulesを追加し、ミスとバイパスを観察してから、認証済みおよび個人向けの挙動がテストに通った場合だけ拡大します。

ネームサーバーの変更は、リゾルバーに反映されるまで時間がかかることがあります。移行前に関連するDNSの有効期間を短くすれば切り替えを短縮できますが、既存のキャッシュ済み回答が期限切れになるだけ早く実施する必要があります。新しいサービスが代表的なトラフィック期間を通して安定するまで、以前のプロバイダー構成を維持してください。

トラフィックがCloudflareに到達したら、CF-Cache-Statusレスポンスヘッダーを確認します。HITはCloudflareがキャッシュ済みレスポンスを返したことを示します。MISSは利用可能なコピーがなく、上流から取得したことを意味します。DYNAMICは、リクエスト時点でキャッシュ対象と見なされなかったことを示します。BYPASSは通常、保存を妨げたルールまたはオリジンレスポンスを表します。UPDATINGは、バックグラウンドで再検証を行う間に古いコンテンツを返すときに現れることがあります。Ageヘッダーは、直近の検証または再取得以降、配信したキャッシュエントリーが保存されている時間を示します。

広い展開の前に、次の5つの結果を確認してください。

• ログイン済みの利用者が別の利用者のコンテンツを受け取らず、ログアウトや権限変更が正しく反映される。
• パージとバージョン付きデプロイにより、変更されたリソースが必要な新鮮さの期間内に置き換わる。
• オリジンが意図したCloudflareトラフィックを受け入れ、許可されていない直接接続を拒否する。
• ファイアウォールとレートポリシーが、実際のブラウザー、API、Webhook、検索クローラー、アクセシビリティツールを許可する。
• 監視により、エッジ障害、ソース障害、アプリケーションエラー、遮断されたセキュリティイベントを区別できる。

同じパーセンタイルと似たトラフィック期間で、試行結果を基準値と比較します。最初のバイトが届くまでの時間、largest contentful paint、エラー率、ソースCPU、オープン接続、転送バイトの変化を確認してください。中央値が速くなってもp95遅延が悪化しているなら、喜ぶ前に調査が必要です。

キャッシュの有効期間は徐々に延ばしてください。長い値は再利用を改善しますが、無効化の誤りによる影響も大きくします。公開されたバージョン付きアセットは長期保存に耐えます。頻繁に編集するHTMLには、管理された再検証または信頼できるパージ自動化が必要です。アカウントページは、分離キャッシュ用に特別に設計しテストしていない限り、共有ストレージの外に置くべきです。

問題なく動いた後も、障害を想定して計画してください。ソース証明書を更新可能な状態に保ち、プロキシを止める手順を文書化し、インフラ構成をバージョン管理に保存し、購入した場合はオリジンフェイルオーバーをテストします。DNS、キャッシュポリシー、セキュリティルール、請求アラート、障害時の連絡について責任者を決めます。

Cloudflareが適切な選択かどうかは、この測定された導入で、許容できる総費用で意味のあるパフォーマンス、信頼性、セキュリティの改善が得られるかで決まります。広いネットワークと統合製品は有力な選択肢にする要因ですが、実際にアプリケーションを改善するかは、規律ある設定にかかっています。