概要
時に西暦2025年11月、インターネットインフラ企業Cloudflareで大規模障害が発生し、少なくない数のウェブサイトが数時間ほどCloudflareの Internal Server Error 画面を表示していました
普段見慣れたサイトの豹変に驚いた人も多いことでしょう
これをきっかけにCloudflareがCDN (ウェブサイトのコンテンツをユーザに最寄りのサーバから配信すること) を実現する仕組みに興味を持ったので調査をしました
Cloudflareが世界中に展開するエッジネットワークと、ルーティングプロトコルの一種であるBGPの仕様を利用した手法がシンプルで美しいと感じたので、私なりの理解と調査の過程を共有します
CloudflareとCDN
CDNとは何か
Cloudflareはウェブサイトを高速かつ安全に動かすためのインターネットインフラを提供する米国の企業です
世界中のデータセンタ（以下、DC）に張り巡らされたエッジネットワークを使用してCDN（Content Delivery Network) やDDoS対策、Bot対策といったセキュリティを提供しています
CDNはウェブサイト上のコンテンツを最寄りのキャッシュサーバから配信するためのネットワークです
ユーザがCDNを使用していないウェブサイトの上のコンテンツにアクセスするとします
ユーザとサーバが地理的に離れている場合は遅延が大きくなりますし、複数のユーザから大量のアクセスがあるとサーバの負荷が増加してしまいます
CDNを導入すると、キャッシュサーバが定期的にオリジンサーバにコンテンツを取得しに行き、ユーザは最寄りのキャッシュサーバからコンテンツを取得するようになります
CDN導入前よりユーザとサーバの地理的距離が近づくことによる遅延防止が期待できます
また、オリジンサーバの負荷低減とオリジンサーバを収容しているネットワークの負荷低減が期待できます
CloudflareはどのようにCDNを実現しているのか
ユーザはウェブサイトがCDNを利用していることなど知るはずもないので、世界中から同じURLを指定してサービスにアクセスしてきます
ユーザは同じURLを指定してアクセスしてくるのに、なぜ最寄りのキャッシュサーバが応答することができるのでしょう
詳細については後述しますが、
Cloudflareは世界中に展開するエッジネットワークと、BGPの仕様を利用してAnycast動作を実装することでCDNを実現しています
CDNの実現方法はベンダーごとに異なります
この記事の内容はCloudflareのCDNについてのものです
Cloudflare CDNで利用されるAnycastアドレス
CloudflareはCDNを実現するためにAnycastアドレスを使用しています
Anycastはネットワーク上で複数の機器が同一のIPアドレスを共有していて、ユーザから最寄りの機器が応答するものです（Anycastを実現する仕組みについては後述します）
ユーザがAnycastアドレスにアクセスすると、東京のユーザには東京付近のキャッシュサーバが、ボストンのユーザにはボストン付近のキャッシュサーバがコンテンツを返します
Anycast動作の観察
Anycastの仕組みについて説明をする前に、実際にCloudflareでAnycast動作を観察してみましょう
PixivがCloudflareを使っているそうなので、Anycastの観察にPixivのIPアドレスを使わせていただきます
www.pixiv.net を名前解決すると返ってくるIPアドレス104.18.42.239, 172.64.145.17はCloudFlareが管理していて、pixivサービスで使用されているAnycastアドレスです
stodo@TDRK:~$ nslookup www.pixiv.net
Server: 10.255.255.254
Address: 10.255.255.254#53
Non-authoritative answer:
Name: www.pixiv.net
Address: 104.18.42.239
Name: www.pixiv.net
Address: 172.64.145.17
www.pixiv.net からコンテンツを取得しようとする場合、ユーザの地理的位置にかかわらず104.18.42.239か172.64.145.17にアクセスすることになります
名前解決の結果はユーザの地理的位置に依存しません
名前解決の結果をユーザの地理的位置によって変化させることによってCDNを実現する手法もあります
CDNの老舗であるAkamaiでは上記の手法でCDNを実現しているそうです
PixivのIPアドレスを使ってCloudflareのAnycast動作を観察していきます
異なる地理的位置からAnycastアドレスにアクセスしてみたいので、VPNを使用してアクセス元を変化させながら観察します
次の3つの方法で観察しながら理解を深めていきます
1. traceroute コマンドで通信経路を見る
tracerouteは目的地までに経由するルータを表示するコマンドです
アクセス元の地域によって経由するルータが異なることを確認します
2. cdn-cgi/trace エンドポイントを叩いて応答しているDCを確認する
cdn-cgi/traceはCloudflareを使用しているドメインに自動で作成されるエンドポイントです
どのDC上のサーバが応答しているかを教えてくれます
アクセス元の地域から近いデータセンタ（以下、DC）上のサーバが応答していることを確認します
3. Looking glassでルータのBGPテーブルを見る
Anycastを実現する仕組みについては後述しますが、ルーティングプロトコルの一種であるBGPの仕様を利用しています
仕組みについて説明をした後に、日本と北米のように地域に離れた2つのAS内にあるルータのBGPテーブルを比較して、Cloudflareが管理している同一のAnycastアドレスの学習元が異なることを確認します
ルータのBGPテーブルが異なるということは、別のAS配下のユーザが同一のAnycastアドレスにアクセスする場合に応答するサーバが変わるということです
traceroute コマンドで通信経路を見る
CloudflareのCDNに使用されているAnycastアドレスにアクセスすると、アクセス元から地理的に近いDC上のサーバが応答を返すことが期待されます
VPNを利用して、アクセス元を切り替えながらAnycastアドレスに向けてtracerouteを実行します
今回はアクセス元を東京とボストンにしています
東京からtraceroute
目的地のAnycastアドレス104.18.42.239に到達する直前に103.22.201.129を経由しています
直前に経由したIPアドレスの地理的位置を見ると、東京にあるようです
https://iptoolskit.com/ip/103.22.201.129
stodo@TDRK:~$ traceroute -A -q 1 104.18.42.239
traceroute to 104.18.42.239 (104.18.42.239), 30 hops max, 60 byte packets
1 TDRK.mshome.net (172.24.112.1) [*] 1.050 ms
2 *
3 93.118.40.21 (93.118.40.21) [AS58325] 16.845 ms
4 ae10.5.rt0-tky.jp.as58325.net (93.118.40.16) [AS58325] 8.976 ms
5 101.203.90.97 (101.203.90.97) [*] 15.280 ms
6 103.22.201.129 (103.22.201.129) [AS13335] 9.439 ms
7 104.18.42.239 (104.18.42.239) [AS13335] 8.808 ms
ボストンからtraceroute
目的地のAnycastアドレス104.18.42.239に到達する直前に162.158.61.111を経由しています
直前に経由したIPアドレスの地理的位置を見ると、ニューアークにあるようです
https://iptoolskit.com/ip/162.158.61.111
stodo@TDRK:~$ traceroute -A -q 1 104.18.42.239
traceroute to 104.18.42.239 (104.18.42.239), 30 hops max, 60 byte packets
1 TDRK.mshome.net (172.24.112.1) [*] 3.008 ms
2 *
3 145.79.196.124 (145.79.196.124) [AS136787/AS212238] 185.287 ms
4 vl201.bos-mark-core-1.cdn77.com (185.156.45.196) [AS60068] 185.359 ms
5 *
6 be3471.ccr41.jfk02.atlas.cogentco.com (154.54.40.154) [AS174] 184.905 ms
7 be2236.rcr21.ewr02.atlas.cogentco.com (154.54.45.6) [AS174] 184.692 ms
8 *
9 162.158.61.111 (162.158.61.111) [AS13335] 184.281 ms
10 104.18.42.239 (104.18.42.239) [AS13335] 184.228 ms
これらの情報から、地理的に離れた位置ユーザーが同じCloudflareのAnycastアドレスにアクセスしているつもりでも、実際には異なる場所にあるサーバが応答していることが推測できます
どの地域のDC上のサーバが応答しているかをより直接的な方法で確認してみたいので、cdn-cgi/traceエンドポイントの情報を見てみましょう
ASとはインターネット上で1つの組織が一貫した方針で運用するネットワークの単位です
各ASは固有の番号（ASN）を持ち、BGPというプロトコルで他ASと経路情報を交換します
cdn-cgi/trace エンドポイントを叩いて応答しているDCを確認する
cdn-cgi/traceってなに？
CloudFlareを利用しているドメインで自動的に生成されるエンドポイントです
ユーザからのアクセスに対して応答しているサーバがどのDCに置かれているか、といった情報を返してくれます
DCの場所は空港コードで教えてくれます
The three-letter code in the data center name is the IATA code of the nearest major international airport. Determine the Cloudflare data center serving requests for your browser by visiting: http://
_www.example.com_/cdn-cgi/trace.
Pixivの場合は下記URLが/cdn-cgi/trace エンドポイントです
https://www.pixiv.net/cdn-cgi/trace/
VPNでアクセス元を変更しながらこのエンドポイントを叩いてみます
東京からのアクセス
成田 (NRT)のサーバが応答を返しています
stodo@TDRK:~$ curl https://www.pixiv.net/cdn-cgi/trace/ | grep colo=
colo=NRT
ボストンからのアクセス
ニューアーク (EWR)のサーバが応答を返しています
stodo@TDRK:~$ curl https://www.pixiv.net/cdn-cgi/trace/ | grep colo=
colo=EWR
ここまでで、同じAnycastアドレスにアクセスしているつもりでも、クライアントの地理的位置によって応答するサーバが変わることを観察できました
しかし、traceroute やcdn-cgi/traceの情報から「Anycast動作の観察」はできても「Anycastどのように実現しているか」までは分かりせん
ここで、いったんは観察を中断してAnycastを実現する仕組みについての自分なりの理解を共有します
CloudflareがAnycastを実現する仕組み
CloudflareがAnycastを実現する仕組みを理解するためには、インターネットの構造とBGPについての知識が必要です
インターネットはASが結びついて形成されている
インターネットはAS(Autonomous System)というネットワークどうしが結合してネットワークを形成し、お互いに経路情報（このIPアドレス帯はこっちにあるよという情報）を交換し、ルーティング（経路情報をもとにトラフィックを適切な方向に導く）をすることで形成されています
ASとはインターネット上で1つの組織が一貫した方針で運用するネットワークの単位です
ASそれぞれIPアドレス帯の割り当てを受けており、自身の管理下にあるIPアドレス帯（プレフィックス）への経路を広告しています
ASごとに番号の割り当てを受けていて、CloudflareはAS 13335となっています
BGPによる経路広告
インターネットを通じて情報をやりとりするためには、他のASの管理下のIPアドレス帯への経路を知らなければなりません
ASはBGP（Border Gateway protocol）を使って経路情報を配信します
経路情報を配信することを広告すると呼びます
広告には経路情報とパス属性が含まれます
パス属性はいくつかありますが、今回はBGPの解説がメインではないのでAS_PATHという属性のみ扱います
AS_PATHはその広告が通過してきたAS番号を並べたものです
ルータが最適な経路を選択する
広告を受け取ったルータは受け取った経路情報に含まれるパス属性に従って最適な経路（ベストパス）を選択します
今回の図で場合は、20.0.0.0/8への経路をAS222とAS333の2つのASから学習しているので、AS111は20.0.0.0/8へのベストパスがAS222方面とAS333方面のどちらにあるか判断をする必要があります
AS_PATHは広告がASを通過するたびに追加されるので、AS_PATHが長いということはその経路は多くのASを経由する必要がある経路だと考えられます
そのため、AS_PATHが短い経路が優先され、AS111は20.0.0.0/8がAS222方面にあると判断することになります
BGPの基本的な経路選択手順は共通ですが、LocalPrefの設定やASのポリシーにより実際の優先順位は変わります
また、AS間の契約形態や接続ポリシーにも影響を受けます
ASが配下のユーザのパケットをルーティングする
仮にユーザが契約しているISPがAS111だとすると、ユーザはAS111配下からインターネットにアクセスすることになります
ユーザが20.1.1.1にアクセスしたいとすると、A111はAS222方面にパケットをルーティングします
世界中のAS13335(Cloudflare)からAnycastアドレスを広告する
ここまでで、簡略化はしていますがBGPの経路選択の仕組みを説明しました
ここからは、CloudflareがBGPの経路選択の仕組みを利用してAnycastを実現する仕組みについて説明します
世界中のASに接続して経路をアナウンスするCloudflare
Cloudflareは世界中にエッジネットワークを持つ強みをいかして、世界中のASに接続しています
https://www.cloudflare.com/ja-jp/peering-policy/
Cloudflare AS13335 operates a global anycast network, spanning over 330 cities, in more than 125 countries. We have an open peering policy, and will peer with networks that have a presence in mutual locations, in accordance with the policies described below. Exceptions to these policies may be granted.
そして、各地域のデータセンターから同じプレフィックスをBGPでアナウンスしています
https://www.cloudflare.com/resources/assets/slt3lc6tev37/3pQctgV8XEdU93aBlWTm6Q/969abc3a9fdd2078d411369437b3beaf/Cloudflare-Magic-Transit-Reference-Architecture.pdf
BGP Announcement from every Cloudflare Point of Presence
各ASはIX経由でBGPによってAS13335への経路を複数受け取りますが、その中で最も近くにあることが期待されるAS13335から学習した経路をルーティングテーブルへ格納します
ASがAnycastアドレスへの経路を決定する
Cloudflareは世界のデータセンタから同一のAnycastアドレスへの経路情報を広告するだけで、あとは各ASがBGPの経路選択にしたがって最良の経路を選択します
結果として、クライアントからのAnycastアドレスへのトラフィックは地理的に近いCloudflareのデータセンタに吸い込まれる可能性が高くなります
私たちがCDNを使用する際の具体例
私たちは通常はISPと契約してインターネットを使用します
私たちがISP配下からAnycastアドレスにアクセスしようとすると、ISPのルータは自身のルーティングテーブルに従って、最寄りと期待されるAS13335への誘導されます
最寄りと期待されるAS13335にあるキャッシュサーバはオリジンサーバからキャッシュしているコンテンツを返します
このような仕組みによって、クライアントは何も考えずとも地理的に近いキャッシュサーバからコンテンツを受け取ることが期待されます
各ASが実際にどのような基準で経路を選択するかはブラックボックスです
AS_PATH、ローカルポリシー、ピアリング状況、負荷・トラフィック状況など多くの要素が絡みあって決定されています
BGP自体は地理情報を考慮しませんが、CDN事業者が世界中のIXでピアリングし同一prefixをAnycastでアナウンスすることで、結果的にクライアントは地理的に近いノードに誘導されやすくなります
Looking glassを使ってAS内部のルータでBGPテーブルを見る
Anycastを実現する仕組みについて共有したところで観察にもどりましょう
実際にBGPテーブルを覗き見る
実際にAS内部にあるルータのBGPテーブルを見て、地理的に遠い2つのASが同一のAnycastアドレスに対して経路情報の学習元が異なることを確認してみましょう
これまでの観察と整合性をとるならtracerouteに登場したASのルータについてBGPテーブルを見たいところですが、すべてのASがLooking-glassを公開しているわけではありません
なので、アクセス元から地理的に近く、かつLooking glassを公開しているASでBGPテーブルを見て比較してみましょう
下記サイトで公開されている東京のASとボストンのASのBGPテーブルを見ることにします
地理的に遠いASでは別々のCloudflareデータセンタから経路を学習している
このサイトを使って、東京のASとボストンのASそれぞれで、CloudflareのAnycastアドレス104.18.42.239への経路がどのように学習されているかを表示してみました
文字が小さくて見にくいでしょうが、1行目がベストパスとなっているので、その列のNext Hop列とLearnedが特に重要です
- Next Hopは、「
104.18.42.239に行くためには次にどのルータに行けばいいか」を意味しています - Learnedは、「誰からその情報を教わったか」を意味しています
東京のAS(Equinix Tokyo TY2)が学習している経路情報
core2.tyo1.he.net> show ip bgp routes detail 104.18.42.239
Number of BGP Routes matching display condition : 10
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED
E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH
S:SUPPRESSED F:FILTERED s:STALE x:BEST-EXTERNAL
RPKI State V: Valid I: Invalid N: Not found ?: Undefined
1 Prefix: 104.18.42.0/24, Rx path-id:0x00000000, Tx path-id:0x01d40001, rank:0x00000001, Status: BMEx, Age: 22d8h41m29s
NEXT_HOP: 101.203.88.62, Metric: 0, Learned from Peer: 101.203.88.62 (13335)
LOCAL_PREF: 100, MED: 0, ORIGIN: igp, Weight: 0, RPKI State: N, GROUP_BEST: 1
AS_PATH: 13335
COMMUNITIES: 6939:7319 6939:8392 6939:9003
ボストンのAS(One Summer Boston)が学習している経路情報
core2.bos1.he.net> show ip bgp routes detail 104.18.42.239
Number of BGP Routes matching display condition : 32
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED
E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH
S:SUPPRESSED F:FILTERED s:STALE x:BEST-EXTERNAL
RPKI State V: Valid I: Invalid N: Not found ?: Undefined
1 Prefix: 104.18.42.0/24, Rx path-id:0x00000000, Tx path-id:0x00930001, rank:0x00000001, Status: BEx, Age: 38d7h8m44s
NEXT_HOP: 206.108.236.61, Metric: 0, Learned from Peer: 206.108.236.61 (13335)
LOCAL_PREF: 100, MED: 0, ORIGIN: igp, Weight: 0, RPKI State: N, GROUP_BEST: 1
AS_PATH: 13335
COMMUNITIES: 6939:7342 6939:8840 6939:9001
東京ASでは「104.18.42.239は101.203.88.62(AS 13335)を経由した先にあるよ」という情報を101.203.88.62 (AS13335)から教わっています
一方で、ボストンASでは「104.18.42.239は206.108.236.61(AS 13335)を経由した先にあるよ」という情報を206.108.236.61 (AS 13335)から教わっています
上記の観察結果から次のことが確認できました
- Cloudflare（AS13335）が同一プレフィックスを複数の接続点からアナウンスしている
- 東京とボストンでは Next-Hop が異なり、ASのルータはそれぞれ別のCloudflareルータを経由する経路を学習している
Conclusion
CloudflareのCDNは、Anycast + BGP というインターネットの基盤技術を巧みに活用することで、ユーザに最も近いエッジサーバが応答する仕組みを実現しています
同一のAnycastアドレスを世界中のデータセンタから広告し、Anycastアドレスへのアクセスに対してどのサーバが応答するかはインターネット内でルーティングの自律分散的な仕組みに任せるという設計はシンプルで美しいです
実際にtracerouteや/cdn-cgi/traceを用いてアクセス元を変えながら観察することで、同じAnycastアドレスにアクセスしてもアクセス元地域によって異なるデータセンタ上のサーバが応答している様子を確認できました
また、BGPテーブルを比較することで、Cloudflare（AS13335）が同一プレフィックスを複数の接続点からアナウンスしていることと、ASごとに異なるCloudflareルータから経路を学習していることを確認できました
参考資料
BGPについての解説
https://www.nic.ad.jp/ja/newsletter/No35/0800.html
Anyycat BGPで最寄りのデータセンタにルーティングされること
https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/
1.1.1.1へのBGPハイジャック
https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/
クラウドフレアは世界中のASとIXを介して接続されている
https://www.cloudflare.com/ja-jp/peering-policy/
複数のPoPから同一のプレフィックスが広告されている
https://www.cloudflare.com/resources/assets/slt3lc6tev37/3pQctgV8XEdU93aBlWTm6Q/969abc3a9fdd2078d411369437b3beaf/Cloudflare-Magic-Transit-Reference-Architecture.pdf