digコマンドとcurlコマンドで理解するCDNの仕組み

これは、FORCIA Advent Calendar 2021の12日目の記事です。

はじめに

「CDN」という仕組みをご存知でしょうか。

インターネットを支える縁の下の力持ち的な存在ですが、実際に意識することは少ないかもしれません。
ここでは「CDN」がどのように動いているのか、digコマンドとcurlコマンドを使って理解してみようと思います。

CDNとは

「CDN」とは「content delivery network」の略称でCDN事業者のサーバを経由してコンテンツを配信する仕組みです。

ごく簡単に図で表すと以下のようなイメージになります。

CDNを使用しないで配信する場合：
[ユーザ]----HTTP(S)---->[配信元サーバ]

CDNを使用して配信する場合：
[ユーザ]----HTTP(S)---->[CDN事業者のサーバ]----HTTP(S)---->[配信元サーバ]

つまり、インターネットにアクセスした際に私たちがアクセスしているサーバは、Webサイトの運営者のサーバではなくCDN事業者のサーバであることもある、ということになります。少し意外かもしれません。

なぜ、このような構成がとられるのでしょうか。以下のようなメリットがあると言われています。

• CDN事業者のサーバにコンテンツをキャッシュすることによって、高速な配信が期待できる
• 急激にトラフィックが増えた場合に、CDN事業者のサーバでトラフィックを吸収できるので、サービスがダウンしにくい
• ユーザの接続はCDN事業者のサーバに対して行われるため、配信元サーバが直接的な攻撃にさらされにくい

ここで、以下のような疑問を持つ方もいるかもしれません。
「今どきのインターネット通信はほとんどがHTTPS通信で行われている。HTTPS通信はエンドツーエンドで暗号化されているため、CDN事業者のサーバでコンテンツをキャッシュすることなどできないのでは？」

「普通に」プロキシサーバーを立てるだけではその通りなのですが、一般的にCDNではHTTPS通信においてもキャッシュが利用可能です。

なぜなら、CDN事業者のサーバには配信元サーバと同じコモンネームのSSL/TLS証明書をインストールしてあるため、暗号化された通信の復号が可能だからです。
(逆に言えば、自身のサイトをCDN化する際にはCDN用に証明書を発行する必要があるということになります)

[ユーザ]<=>[CDN事業者のサーバ]の通信はCDN事業者のサーバにインストールされた証明書によって暗号化され
[CDN事業者のサーバ]<=>[配信元サーバ]の通信は配信元サーバにインストールされた証明書によって暗号化され
それぞれ通信が行われている、ということになります。

アクセス先を確かめてみる

では、Webサイトの運営者のサーバではなく、CDN事業者のサーバに接続されていることを確かめてみましょう。
アメリカのニュースサイトThe New York Timesは「Fastly」というCDN事業者によって配信されていますので、このサイトを例に見てみましょう。

弊社社屋からdigコマンドを実行すると以下のような結果が得られます。

$ dig www.nytimes.com
<抜粋>
www.nytimes.com.        381     IN      CNAME   www.prd.map.nytimes.com.
www.prd.map.nytimes.com. 1      IN      CNAME   nytimes.map.fastly.net.
nytimes.map.fastly.net. 30      IN      A       151.101.229.164

「CNAME」というレコードが返却されていますが、これはCanonicalName(正規ホスト名)を指すものです。
つまりこの応答を読み解くと
www.nytimes.comの正規ホスト名はwww.prd.map.nytimes.comなので引き直してください
www.prd.map.nytimes.com正規ホスト名はnytimes.map.fastly.netなので引き直してください
nytimes.map.fastly.netのIPアドレスは151.101.229.164です。
ということになります。

www.nytimes.comの最終的なCNAME先がnytimes.map.fastly.netつまりFastly社(CDN事業者)のドメイン名になっており、Fastly社が管理する権威DNSサーバによってIPアドレスが解決されていることが分かります。

また解決されたIPアドレス151.101.229.164をwhoisコマンドで引いてみると 以下のようにFastly社所有のものであることが分かります。

$ whois 151.101.229.164
<抜粋>
NetRange:       151.101.0.0 - 151.101.255.255
Organization:   Fastly (SKYCA-3)

以上のことから、ブラウザにhttps://www.nytimes.com/と入力した際の通信相手は、「The New York Times」社のサーバではなく、「Fastly」社のサーバであることが分かります。

どのように配信サーバを割り当てているか

CDN事業者はインターネット上に配信サーバを多数設置していると言われています。
Fastly社でも配信サーバを世界各地に配置しています。(日本国内にもあります)
では、どのようにして多数あるサーバの中からアクセスさせるサーバを割り当てているのでしょうか？

先ほど解決されたIPアドレス151.101.229.164にpingを打ってみると数msで返ってくることから、サーバは日本国内にあることが推測されます。

$ ping 151.101.229.164
PING 151.101.229.164 (151.101.229.164) 56(84) bytes of data.
64 bytes from 151.101.229.164: icmp_seq=1 ttl=55 time=3.38 ms
64 bytes from 151.101.229.164: icmp_seq=2 ttl=55 time=3.20 ms
<以下略>

ではDNSサーバを変えて名前解決をしてみます。 ここでは日本から遠そうなロシアの検索サービスであるyandex社のDNSサーバである77.88.8.8を使ってみます。

$ dig www.nytimes.com @77.88.8.8
<抜粋>
www.nytimes.com.        500     IN      CNAME   www.prd.map.nytimes.com.
www.prd.map.nytimes.com. 120    IN      CNAME   nytimes.map.fastly.net.
nytimes.map.fastly.net. 30      IN      A       151.101.245.164

151.101.245.164に解決されました。(先ほどは151.101.229.164だったので、第3オクテットのみが異なっています)
pingを打ってみると200ms以上かかっており、日本からはネットワーク的に遠く(おそらくロシア付近)にあることが推測されます。

$ ping 151.101.245.164
PING 151.101.245.164 (151.101.245.164) 56(84) bytes of data.
64 bytes from 151.101.245.164: icmp_seq=1 ttl=51 time=269 ms
64 bytes from 151.101.245.164: icmp_seq=2 ttl=51 time=269 ms
<以下略>

つまり、同じホスト名を問い合わせているのにもかかわらず、問い合わせ元のDNSサーバによって解決するIPアドレスを変えていることが分かります。

[日本国内のクライアント]--DNSクエリ-->[日本のDNSサーバ]--DNSクエリ-->[CDN事業者の権威DNS]
=>日本からのアクセスとみなして日本国内のサーバのIPアドレスを返却

[日本国内のクライアント]--DNSクエリ-->[ロシアのDNSサーバ]--DNSクエリ-->[CDN事業者の権威DNS]
=>ロシアからのアクセスとみなしてロシア付近のサーバのIPアドレスを返却

このようにして、クライアントに対してネットワーク的に近い位置のサーバを割り当てていることが推測できます。

ECS(EDNS Client Subnet)について

ここまで読み進めてくださった賢明な読者の方なら、以下の疑問を持つかもしれません。

「あの有名なGoogle Public DNSである8.8.8.8に問い合わせたらどうなるの？」

問い合わせ元のDNSサーバのIPアドレスのみを元にして返却するIPアドレスを制御する、という仕組みには限界があり 実際に、過去にはこのようなPublicDNSを使用した場合、不適切なサーバが割り当てられる問題があったと言われています。

ただし現在はECS(EDNS Client Subnet)という仕組みで解決されています。

これは、DNSキャッシュサーバがDNS権威サーバに問い合わせる際に、DNSキャッシュサーバに問い合わせをしたクライアントのIPアドレス情報も伝達してしまう、という仕組みになります。 簡単に図で表すと以下のようになります。

[クライアント]--DNSクエリ(1)-->[PublicDNSサーバ]--DNSクエリ(2)-->[CDN事業者の権威DNS]
※この「DNSクエリ(2)」内に「DNSクエリ(1)」の発信元クライアントのIPアドレス情報が含まれている

CDN事業者の権威DNSはクライアントのIPアドレス情報を元に最適なサーバのIPアドレスを返却するため、ECSに対応しているDNSサーバであれば現在このような問題は発生しないと言えます。 (逆に言えば前述のyandex社のDNSサーバはECSに対応していないものと考えられます)

curlでアクセスしてみる

では実際にWebサイトにアクセスしてみましょう。 CDN事業者によってデバッグ用コマンドのようなものが用意してあり、キャッシュにヒットしたかどうかなどが分かるようになっています。
Fastlyの場合を例にして、curlコマンドでFastly-Debug:1をリクエストヘッダに付与して「The New York Times」のトップページに何度かアクセスしてみます。

$ curl -s --head -H "Fastly-Debug:1" https://www.nytimes.com/ -w "time_total:%{time_total}\n" | grep -e 'x-cache:' -e 'time_total:'
x-cache: MISS, MISS
time_total:1.036584

$ curl -s --head -H "Fastly-Debug:1" https://www.nytimes.com/ -w "time_total:%{time_total}\n" | grep -e 'x-cache:' -e 'time_total:'
x-cache: MISS, HIT
time_total:0.032943

x-cacheレスポンスヘッダでキャッシュにヒットしたかを確認できるので比較すると
最初のアクセスではキャッシュがない(MISS)ためレスポンスに1秒以上かかってるのに対し、
その後のアクセスではキャッシュにヒット(HIT)し0.03秒程度でレスポンスされていることが分かります。
「The New York Times」の配信元サーバはおそらくアメリカ国内にあるものと思われますが、キャッシュにヒットしない場合はアメリカ国内のサーバと通信するためレスポンスに時間がかかっているのに対し、キャッシュにヒットした場合は日本国内のサーバからレスポンスされるため非常に高速にコンテンツが取得できています。

まとめ

以上のことから分かったことをまとめてみます。

• 私たちが普段アクセスしているサーバは、Webサイト運営者のサーバではなくCDN事業者のサーバであることもある
  • CDN事業者のサーバかどうか、どのCDN事業者を使用しているかはdigコマンドで分かる
• CDN事業者のサーバは世界各地にあり、最適なサーバが割り当てられるようになっている
  • サーバの割り当てはCDN事業者の権威DNSにより問い合わせ元のIPアドレスを元に行われている
• CDN事業者のサーバのキャッシュからコンテンツが返却される場合は非常に高速である

CDNは目に見えないものなので普段意識することもあまりないと思いますが、このような仕組みでインターネットが動いているというを知っておくと何かの役に立つかもしれません。(立たないかもしれません)