青い雲のマークと「安全性を確認しています」という数秒の待ち時間。
あるいは、真っ白なページに残された三桁の数字と、Cloudflareという文字列。
名前だけは異様なほど頻繁に目に入るのに、それが何をしている会社なのかを説明できる人は、驚くほど少ない。
セキュリティの会社なのか、それとも配信の会社なのか。
無料で使えるという話は本当なのか、本当だとしたらどこで儲けているのか。
この記事は、その疑問に正面から答えます。
扱うのは二つです。
ひとつは、この会社がインターネット上でどんな位置に立ち、なぜあれほど多くの機能を無料で配れるのかという、事業の構造そのもの。
もうひとつは、その土台にあるCDNという技術が、いったい何をどうやって速くしているのかという原理です。
個々の製品名を覚える前に、この二つを押さえておくと、あとから出てくる機能がすべて一本の線の上に並んで見えるようになります。
なお、以下の本文は、Cloudflareを一冊にまとめた解説書の完全版から、冒頭部分を抜き出したものです。
Cloudflareとは何者か──インターネットの前に立つ会社
誰も頼んでいないのに、そこにいる
この会社を理解するうえで、最初に飲み込んでおくべき事実があります。
あなたが訪れようとしたサイトの運営者が、あなたの知らないところでこの会社と契約しており、その結果としてあなたの通信は、目的地に着く前にいったんこの会社の設備を経由している、という構造です。
利用者であるあなたは、そこを通ることに同意した覚えがありません。
それでも通っています。
創業は2009年7月。
Matthew Prince、Michelle Zatlyn、Lee Holloway の三名が立ち上げ、本社は米国カリフォルニア州サンフランシスコに置かれています。
現在はニューヨーク証券取引所に上場しており、Matthew Prince が最高経営責任者として、また取締役会の共同議長として経営を率いています。
出自として興味深いのは、この会社が「攻撃を観測する研究プロジェクト」から派生している点です。
迷惑メールの送信元やスパムの発生源を追跡するという、どちらかといえば地味な観測活動が土台にありました。
守るためには、まず何が起きているかを見なければならない。
この順序は、のちに世界中のトラフィックを観測する立場を得たことで、そのまま強力な競争力へと転化していきます。
「一枚の板」という設計思想
技術的な特徴を一言で表すなら、ネットワークが徹底して均質である、という点に尽きます。
多くの事業者は、機能ごとに専用の設備を用意します。
攻撃を防ぐ装置はここ、キャッシュを配る装置はあちら、といった具合に役割を分けるやり方です。
この会社が採ったのは、まったく逆の発想でした。
世界中に置いたすべてのサーバーに、すべての機能を載せる。
どの拠点に到着した通信であっても、防御も、キャッシュも、コードの実行も、その場で完結させる。
この均質性が生む効果は、単なる設計の美しさにとどまりません。
新しい機能を作ったとき、それを世界中の全拠点へ一斉に配れば、翌日には全顧客が使える状態になります。
機能追加の速度が、設備投資の速度から切り離されるのです。
ただし、ここには影の側面があります。
全拠点が同じソフトウェアを走らせているということは、そのソフトウェアに欠陥があれば、全拠点が同時に倒れるということでもあります。
強みと弱みが同じ根から生えている、という点は、本書を通じて繰り返し立ち返る論点になります。
なぜ無料で配るのか
初めて触れる人が最も不思議に思うのが、無料プランの気前のよさです。
帯域の上限がなく、攻撃を受けても追加請求が来ない。
証明書も無料で発行される。
慈善事業ではないかと疑いたくなるほどですが、もちろん違います。
無料で配ることには、少なくとも三つの合理的な理由があります。
第一に、規模そのものが商品だからです。
配信網の性能は、拠点の数と、そこを通るトラフィックの量に比例して向上します。
無料利用者が世界中に何百万といれば、通信事業者との相互接続で有利な条件を引き出せます。
利用者が増えるほど原価が下がる構造では、無料配布は費用ではなく投資になります。
第二に、データが手に入るからです。
膨大なサイトを守っているという立場は、そのまま「世界中の攻撃を最も早く観測できる場所」を意味します。
あるサイトへの新種の攻撃を検知したら、その知見を即座に全顧客の防御へ反映できる。
守る対象が多いほど賢くなる仕組みであり、これは後発の競合が資金だけでは埋められない差になります。
第三に、単純な販売経路として機能します。
個人が趣味のブログで使い始め、やがて転職先の会社で「あれを使いましょう」と提案する。
この流れは、営業担当者を何人雇っても再現できません。
つまり無料プランとは、規模の経済と、データの優位と、販売経路の三つを同時に買うための支出だということです。
製品群を貫く一本の軸
この会社の製品一覧を初めて眺めると、脈絡のない寄せ集めに見えます。
コンテンツ配信、名前解決、攻撃防御、ストレージ、データベース、社内ネットワーク、人工知能の推論基盤。
一見すると、流行を追って手当たり次第に手を広げているようにも映ります。
しかし、ひとつの軸を当てると全体が整列します。
その軸とは、「利用者と目的地のあいだに立っているのだから、そこでできることは全部やる」という考え方です。
通信が必ず通過する場所に陣取っているなら、その場で攻撃を弾ける。
その場でキャッシュを返せる。
ならば、その場でコードを実行してもいいはずだ。
その場でデータを保存してもいいはずだ。
その場で人工知能に推論させてもいいはずだ。
製品の追加とは、この「その場でできること」を一つずつ増やしてきた歴史にほかなりません。
したがって、個々の製品名を暗記しようとするのは効率が悪い覚え方です。
通信の流れを一本の線として思い描き、その線のどこに、どの機能が挿し込まれているのかを把握する。
この地図さえ頭にあれば、新しい製品が出てきても「ああ、あの位置に足したのか」と即座に理解できます。
本書の章立ては、この地図を左から右へ辿る順序で組まれています。
収益は、どこから来ているのか
無料で配る理由は述べました。
では、実際の収益はどこから上がっているのでしょうか。
ここを誤解している人が、非常に多い。
多くの人は、個人利用者が少額の月額を払うことで成り立っている、と想像します。
実際には、まったく違います。
収益の柱は、大企業との契約です。
そして、その契約は、月額数千円といった規模ではありません。
本書で扱った機能群を、組織全体で、統合された形で導入する。
その規模の契約が、事業を支えています。
この構造を理解すると、製品戦略の意味が見えてきます。
なぜ、社内ネットワークの製品を作ったのか。
なぜ、人工知能への通り道を押さえにいったのか。
それは、既存の大企業の顧客に対して、より多くのものを売るためです。
すでに配信と防御を任せている企業に対して、「社内のネットワークも、うちで置き換えませんか」と提案する。
新規の顧客を獲得するより、既存の顧客に追加で売るほうが、はるかに容易です。
本書の章立てが辿ってきた流れは、実のところ、この会社が顧客に対して製品を売り広げてきた歴史の順序と、ほぼ一致しています。
そして、この構造が、無料プランの持続可能性を担保しています。
個人利用者は、収益源ではありません。
規模を作り、データを供給し、そしていつか組織の意思決定者になる存在です。
無料で使い続けても、罪悪感を抱く必要はありません。
あなたは、彼らの設計どおりに振る舞っているだけです。
誰と、何を争っているのか
競合の構図も、独特です。
配信網としては、古参の専業事業者と争っています。
計算基盤としては、巨大な総合事業者と争っています。
社内ネットワークの領域では、企業向けの専業事業者と争っています。
つまり、領域ごとに、まったく異なる相手と戦っている。
どの領域でも、単独では最強とは限りません。
それでも競争力を保てているのは、統合されていることの価値によります。
配信も、防御も、名前解決も、社内の接続も、すべて一つの管理画面で完結する。
個々の機能では他社に劣る部分があっても、繋ぎ合わせる手間が消えることの価値は大きい。
運用する人間の数には、限りがあるからです。
単機能で最良のものを求めるなら、必ずしもここではありません。
全体として運用しやすいものを求めるなら、有力な候補になります。
どちらを求めているのかを、自問してください。
この会社を使うということの意味
最後に、本書全体を通じて手放さないでいただきたい視点を述べておきます。
この基盤を使うという判断は、技術的な選択であると同時に、依存の選択でもあります。
名前解決を預け、証明書を預け、防御を預け、やがてコードとデータまで預けたとき、あなたのサービスの生死は一社の運用品質に握られます。
それは必ずしも悪い判断ではありません。
自前で同等の防御網を構築する費用を考えれば、多くの組織にとって合理的な選択です。
ただし、合理的であることと、無防備であってよいことは別です。
どこまでを預け、どこからは自分の手元に残すのか。
その線引きを意識的に行った組織だけが、障害の日に慌てずに済みます。
便利な道具の説明書として本書を読むこともできますし、依存のリスクを測るための地図として読むこともできます。
できれば、その両方として読んでいただきたいと考えています。
CDNの仕組み──Cloudflareはなぜ速くなるのか
ここまでで、この会社が「利用者と目的地のあいだに立つ」という位置を取っていること、そしてその位置から、できることを一つずつ増やしてきたことを見てきました。
では、その位置取りが最初に生んだ仕事とは、具体的に何だったのでしょうか。
すべての出発点になった、最も古く、最も基本的な機能から見ていきます。
距離ではなく、往復の回数
前章で見た「均質なネットワーク」が実際に何をしているのか、その最も古く、最も基本的な仕事から見ていきます。
コンテンツ配信網、いわゆるCDNと呼ばれる仕組みです。
これは日本語に直せば「内容を配るための網」であり、世界各地に配置した拠点に、あらかじめコンテンツの写しを置いておく技術を指します。
説明としてよく使われるのは「利用者に近い場所から配るから速い」という言い方です。
間違いではありませんが、これでは半分しか説明できていません。
本質は距離そのものではなく、往復の回数にあります。
たとえば東京の利用者が、米国西海岸に置かれたサーバーへ接続する場面を考えてみましょう。
物理的な距離による遅延は、光の速さで決まる下限があります。
片道でおよそ数十ミリ秒、往復すればその倍です。
問題は、この往復が一度では済まないことにあります。
接続を確立するための手続きで往復し、暗号化の鍵を交換するために往復し、そのうえでようやくデータの要求を送って、応答を待つ。
一枚のページを表示するまでに、この往復が何度も積み重なります。
つまり遅延とは、距離に往復回数を掛け算したものなのです。
配信網が効くのは、この掛け算の両方の項を小さくできるからです。
利用者の近くに拠点があれば、一回あたりの往復時間が縮みます。
さらに、拠点から本来のサーバーまでの区間は、あらかじめ接続を維持しておく、経路を最適化しておくといった手が打てるため、往復の負担そのものを減らせます。
近いから速いのではなく、近い拠点で手続きを済ませてしまえるから速い、というのが正確な理解です。
キャッシュされるもの、されないもの
配信網を導入したのに体感が変わらない、という相談は非常に多く聞かれます。
その原因のほとんどは、キャッシュが効いていないという一点に集約されます。
ここでいうキャッシュとは、拠点が保持しているコンテンツの写しのことです。
写しが手元にあれば、拠点は本来のサーバーに問い合わせることなく、即座に応答を返せます。
これを命中と呼び、手元になくて本来のサーバーへ取りに行くことを失敗と呼びます。
命中率が低ければ、配信網はただの遠回りにしかなりません。
では、何が写しとして保持され、何が保持されないのか。
初期状態で写しの対象になるのは、拡張子から明らかに静的だと判断できるものに限られます。
画像、スタイルシート、スクリプト、フォント、動画ファイルといった類です。
逆に、初期状態では写しを取らないものがあります。
記事のページ、商品一覧、検索結果といった、いわゆる本文にあたる応答です。
理由は単純で、それらが利用者ごとに違う内容を返す可能性があるからです。
ログイン中の利用者に他人の名前が表示されたら大事故ですから、初期状態は安全側に倒してあります。
ここに、性能改善の最大の余地が眠っています。
多くのサイトにとって、本文のページは実のところ誰が見ても同じ内容です。
その場合、本文まで写しの対象に含めれば、劇的な改善が得られます。
ただし、その判断を下す前に、必ず確認しなければならない条件があります。
写しを取ってよいかを決めるもの
その条件を握っているのは、応答に付随する制御用の情報です。
ここは設定の主戦場であり、理解の有無が結果を分けます。
中核になるのが、有効期限を指示する情報です。
サーバーが「この応答は一時間そのまま使ってよい」と宣言すれば、拠点はその期間、写しをそのまま配ります。
逆に「毎回確認しろ」と宣言されていれば、写しは保持されません。
初期状態では本文が写しの対象にならない、と先ほど述べましたが、実際にはサーバー側がそう宣言しているからそうなっている、という場合が少なくありません。
つまり、まず疑うべきは配信網の設定ではなく、自分のサーバーが何を宣言しているかなのです。
もうひとつ、見落とされがちな要素があります。
利用者を識別するための小さなデータが応答に含まれていると、それだけで写しの対象から外れます。
個人ごとに違う可能性があると見なされるためです。
アクセス解析の道具を入れた途端に命中率が落ちた、という現象の正体はここにあります。
このように、写しを取れない理由の多くは、配信網側ではなく自分の側にあります。
まず自分の応答を点検し、不要な識別情報を外し、適切な有効期限を宣言する。
この作業を済ませてから設定に手を入れるのが、遠回りに見えて最短の道です。
写しをどうやって捨てるか
写しを持つということは、古い内容を配り続ける危険を抱えるということでもあります。
記事を修正したのに古い文章が表示され続ける、という事態は避けなければなりません。
対策の柱は二つあります。
ひとつは、有効期限を短く設定して自然に入れ替わるのを待つ方法です。
単純ですが、期限を短くするほど命中率は下がるため、性能との綱引きになります。
もうひとつは、更新のたびに明示的に写しを捨てる方法です。
管理画面から操作することもできますし、更新処理の中から自動で指示を出すこともできます。
実務でよく採られるのは、両者を組み合わせる形です。
有効期限は長めに取り、内容を更新したときだけ該当する部分の写しを捨てる。
こうすれば、高い命中率と、更新の即時反映を両立できます。
なお、ファイル名に内容の指紋を埋め込んでしまう、という古典的な手法も依然として有効です。
内容が変わればファイル名が変わるため、そもそも古い写しが参照されなくなります。
写しを捨てる必要がなくなるのですから、これが最も堅牢です。
それでも、写しが効かない場合
ここまでの手を尽くしても、命中率が上がらないことがあります。
その場合、疑うべきは住所の形です。
広告や解析の道具は、住所の末尾に識別用の文字列を勝手に付け足します。
利用者ごとに、その文字列は異なります。
拠点から見れば、それらはすべて別々の住所です。
中身は同じページなのに、写しが一つも共有されない。
命中率は、限りなくゼロに近づきます。
対処は、写しを探す際に、その識別用の文字列を無視するよう指示することです。
末尾に何が付いていようと、同じページとして扱う。
これだけで、命中率が跳ね上がることがあります。
ただし、注意が必要です。
末尾の文字列が、表示内容を実際に変える場合もあります。
検索結果のページや、絞り込みの条件を指定するページがそれにあたります。
これらを一律に無視すると、まったく違うページが配られてしまう。
無視してよい文字列と、無視してはいけない文字列を、区別して指定してください。
一律の設定は、常に危険です。
拠点同士で、写しを融通する
ここまでの説明には、意図的に省いた要素があります。
世界中に拠点があるということは、写しもまた、拠点の数だけ別々に存在するということです。
東京の拠点が持っている写しを、ロンドンの拠点は持っていません。
すると、何が起きるか。
ロンドンの利用者が初めてそのページを求めたとき、ロンドンの拠点は、あなたのサーバーへ取りに行きます。
シンガポールの利用者が求めれば、シンガポールの拠点も、あなたのサーバーへ取りに行く。
拠点の数だけ、あなたのサーバーへの問い合わせが発生するわけです。
これは、無視できない負荷になります。
拠点が増えるほど、あなたのサーバーは忙しくなる。
配信網を入れたのに、サーバーの負荷が下がらない、という逆説的な事態が起こりえます。
この問題への対処が、写しを階層化することです。
すべての拠点があなたのサーバーへ直接取りに行くのではなく、いったん上位の拠点へ問い合わせる。
上位の拠点が写しを持っていれば、そこから配られます。
持っていない場合にだけ、あなたのサーバーへ取りに行く。
すると、あなたのサーバーが受ける問い合わせは、劇的に減ります。
世界中の拠点からではなく、限られた上位の拠点からしか来なくなるからです。
この仕組みは、あまり知られていません。
しかし、訪問者が世界中に散らばっているサイトでは、効果が極めて大きい。
命中率を上げる工夫と並んで、検討する価値があります。
帯域で課金しない、という異常
最後に、料金体系について触れておきます。
配信網の業界において、料金とは伝統的に「配ったデータ量に応じて払うもの」でした。
転送量が増えれば請求も増える。
これは当然の商慣行として、長らく疑われることがありませんでした。
この会社は、その前提を捨てました。
無料プランを含め、転送量そのものには課金しないという方針を掲げています。
突然の人気でアクセスが殺到しても、あるいは攻撃で膨大な通信が発生しても、それだけで請求書が跳ね上がることはない、という設計です。
この方針が持つ意味は、単なる値引きにとどまりません。
運営者にとって、転送量課金は常に恐怖の対象でした。
サイトが話題になることは喜ばしいはずなのに、請求書が怖くて素直に喜べない。
攻撃を受ければ、被害に加えて課金という二重の打撃を受ける。
この恐怖を取り除いたことが、多くの運営者を引き寄せた最大の要因です。
出ていくデータに課金しないという発想は、この会社の思想的な背骨のひとつだと考えてよいでしょう。
まとめ──Cloudflareの無料プランを、どう捉えるか
ここまでの内容を、三つに畳んでおきます。
第一に、この会社の正体は「間に立つ者」です。
セキュリティ会社でも配信会社でもなく、通信が必ず通過する場所に陣取り、そこでできることを片端から実装してきた会社だと捉えると、脈絡がないように見える製品群が一本の線に並びます。
新しい機能が発表されたときも、「通り道のどの位置に挿し込まれたのか」と問えば、たいてい理解できます。
第二に、無料は慈善ではありません。
規模そのものが商品であり、観測されるデータが資産であり、個人の利用者が販売経路になる。
この三つが噛み合うからこそ、無料で配ることが投資として成立しています。
構造を知らずに使うことと、知って使うことのあいだには、決して小さくない差があります。
第三に、速さの正体は距離ではなく往復です。
拠点が近いから速いのではなく、近い拠点で手続きを済ませられるから速い。
そしてキャッシュが効いていなければ、配信網はただの遠回りにしかなりません。
導入したのに変わらない、という悩みのほとんどは、この一点に集約されます。
まずは自分の設定を、この三つの視点から点検してみてください。
この記事の先にあるもの──完全版で扱うテーマ
ここまで読んでいただいた内容は、Cloudflareを一冊に体系化した解説書の完全版から、その冒頭にあたる部分を抜き出したものです。
つまり、土台にあたる考え方と、最も基本的な技術の原理までを扱ったところで、この記事は終わっています。
完全版では、この土台の上に積み上がる領域を順に扱っています。
たとえば、名前解決とネットワークの設計、暗号化と証明書の選択、攻撃をどう防ぐか、エッジでコードを動かすという発想、社内ネットワークをゼロトラストで組み直す方法、そして人工知能をめぐる最新の動き。
さらに、この基盤が実際に大規模な障害を起こしたときに何が起きたのか、エラーの数字はどこを見て切り分けるのか、そして「通り道に過ぎない」という立場が法廷でどう扱われたのかといった、避けて通れない主題にも踏み込んでいます。
さらに深掘りし、Cloudflareの全てを網羅した『完全版』
コメント