ネットの大規模障害が起きた「CDN」って何？実際にアクセスして確かめてみた

図1：CDNがない場合のアクセス

　2021年6月8日に発生したFastlyの大規模障害によって、国内でも様々なメディア系のサイトがアクセス困難な状況に陥った。普段はあまり意識することがない「CDN」とは何なのか？実際に手を動かして確認してみよう。

分散配置されたリバースプロキシサーバー

　CDNは「Content Delivery Network」の頭文字を取ったもので、インターネット上でやり取りされるデータの流れをスムーズにする役割を担うサービスだ。例として身近なのは、やはりWebサイトでの利用だろう。

　普段、我々が目にするWebサイトのデータは、インターネット上のWebサーバーに保管されており、このWebサーバーから記事や画像などのデータを取得することでブラウザにWebページを表示することができる。

　しかし、グローバルにサービスを展開するサイトや人気のあるサイトでは、本家本元のWebサーバーにのみアクセスが集中すると、サービスの品質が低下する恐れがあったり、遠い地域からアクセスする場合にページを読み込むまでに時間がかかったりしてしまう(図1の状態)。

　このような状況を改善できるのがCDNだ。

　普段、あまり意識することはないが、今回のFastlyの障害でも分かるように、CDNは様々なサイトが利用している。CDNを簡単に説明すると、様々な地域に分散配置されたリバースプロキシサーバーだ。

図2：リバースプロキシサーバー

　企業などでも使われているプロキシサーバーは、特定の発信元から不特定多数の宛先に対しての通信に利用されるが、リバースプロキシサーバーは、この逆で、不特定多数の発信元からの通信を特定のサーバーへと転送するために利用される。

　より具体的には、DNSの仕組みを使って、本来のアクセス先に対する通信をCDNサーバーへと転送する。

　例えば、図3にあるように、Webページを見ようとPCからブラウザで「https://www.example.com」と入力すると、その返答として、このサーバーのIPアドレスを返すのではなく、「●●●.map.fastly.net(fastlyの場合)」のようなCDNサーバーの名前(CNAME)が返される。

図3：DNSサーバーとCDNサーバー

　これにより、PCは、本来のWebサーバーではなく、CDN事業者が所有するサーバーへとアクセスすることになる。

　そして、CDNサーバーにキャッシュがあれば(以前ほかのユーザーがアクセスしたデータが残っていれば)、キャッシュからWebページを送信し、キャッシュがなければ本家本元のWebサーバー(オリジンサーバー)へと転送。そのデータを改めてキャッシュするという仕組みとなる。

　CDNは、Webサーバーで利用されるのが一般的だが、アプリ配信、動画ストリーミング、更新プログラム配信など、様々なデータで利用することが可能で、インターネット上では欠かせないサービスとなっている。

　主な事業者は、Akamai、Amazon CloudFront、Cloudflare、CDNetworksなどがある。

　今回話題になったFastlyは2011年創業の比較的新しいサービスだが、オープンソースのVarnishをベースに構築された機能性の高さが注目されており、国内では同社Webページで公表されているだけでも、日本経済新聞社、メルカリ、クックパッド、一休などの大手サイトで利用されている。

大規模になりがちな近年のCDN障害

　CDNには、パフォーマンス(トラフィック軽減)、可用性(過剰なトラフィックや障害に強い)、セキュリティ(DDoS攻撃対策など)、インテリジェンス(CDN事業者が収集したデータの解析)などのメリットがあり、障害対策としての側面も持つサービスである。

　しかし、今回のFastlyに限らず、障害の種類によっては、その影響が大規模になる傾向がある。例えば、直近のCDN関連の障害で大規模なものに発展したものとしては、今回のFastlyの障害も含め、以下のようなものがある。

実際にCDNの動作をチェックしてみよう

　と言っても、CDNは普段存在を意識することがないため、ピンと来ない人の方が多いはずだ。そこで本稿では、実際にCDNがどのように動作しているのかを、手元のWindows PCを使って確認してみることにする。

　まずは、CDNを使っているWebサイトのDNS情報を確認してみよう。例としてFastlyのWebページで利用が公表されていて、今回の大規模障害での影響もあったメルカリのDNS情報をチェックしてみる。

　コマンドプロンプト(後でcurlを使うのでPowerShellではなくコマンドプロンプトを推奨)を起動し、nslookupを実行後、「set d2」で詳細なデバッグモードに切り替えてから、「www.mercari.com」の情報を表示する。

　すると、上の画面のように「www.mercari.com」の「CNAME(canonical name:別名)」として「mercari.map.fastly.net」が表示される。つまり、www.mercari.comにアクセスしようとすると、これがFastlyのCDNサーバー(mercari.map.fastly.net)へと転送されていることが分かる。

　サービスによって異なる場合もあるが、一般的なCDNでは、サービスのコントロールパネルにWebサーバーなどを登録すると、その転送先として設定するCNAMEの情報が表示されるので、これをドメイン管理サービスなどのDNS設定として登録することでCDNを利用できるようになっている。

　続いて、curlを使って、キャッシュの状況を見てみよう。

　同じくコマンドプロンプト(PowerShellだと別のcurlが起動するので注意)から次のコマンドを実行する。これは、FastlyのWebサイトに掲載されているプレスリリースのページを取得するコマンドだ。

curl -svo /dev/null https://www.fastly.com/press/press-releases/fastly-announces-first-quarter-2021-financial-results

　データが読み込まれた後、最後の部分に「X-Cache:」と「X-Cache-Hits:」という項目が表示される。以下の画面では、それぞれ「MISS」、「0」となっているので、CDNサーバーのキャッシュではなくオリジンサーバーからコンテンツを取得していることが分かる。

　続けて、まったく同じコマンドをもう一度実行する。

　今度は、「X-Cache:HIT」と「X-Cache-Hits:1」と表示されるので、CDNサーバーのキャッシュからデータを読み込んでいることが分かる。

　つまり、初回はCDNなし、2回目はCDN経由でのアクセスとなったわけだ。なお、CDNでは、どのデータをキャッシュするかを顧客が選択できる(ショッピングサイトのカートなどはキャッシュするとトラブルになる)ので、ページによってはキャッシュにヒットしない場合もある。

　Fastlyでは、より詳細な情報をデバッグモードを使って取得できるようになっているので、もう少し、詳しく見てみよう。同じくコマンドプロンプトから次のように、「Fastly-Debug:1」をヘッダーに含めてリクエストを実行する。

curl -svo /dev/null -H "Fastly-Debug:1" https://www.fastly.com/press/press-releases/fastly-announces-first-quarter-2021-financial-results

　すると、今度は「Age」や「Fastly-Debug-xxxx」のような項目がさらに追加で表示される。「Age」がキャッシュされてからの経過時間、「Fastly-Debug-Path」がキャッシュサーバー名を示し、「Fastly-Debug-TTL」は「H」がキャッシュにヒットしたこと、最後の数値がキャッシュが破棄されるまでの残存時間を示す。最後の「Fastly-Debug-Digest」がコンテンツのハッシュだ。

　このように、内部的には多くの通信がCDNを経由している。この機会に、CDNの存在を実際に自分の目で確かめてみてはどうだろうか。

この記事内で使われている図版について

この 作品 はクリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。