遠くの一か所から届けない。CDNが「近くに置く」だけで速くなる理由
Webサイトやアプリが遅いとき、つい「サーバーの性能が足りないのかな」と考えてしまいます。CPUを強くする、メモリを増やす、処理を軽くする。もちろん、それで改善することもあります。
ただ、どれだけ速いサーバーを用意しても、そのサーバーが利用者から遠い場所に一台だけ置かれているなら、別の問題が残ります。
データそのものが、遠くからやってくることです。
そこで使われるのがCDNです。Content Delivery Network。日本語では「コンテンツ配信ネットワーク」と呼ばれます。
名前だけ聞くと、少し大げさな仕組みに見えます。でも、考え方の中心にあるものは驚くほど単純です。
遠くの一か所から毎回届けるのではなく、利用者の近くにも置いておく。
それだけで、Webの体感速度はかなり変わります。
初めましての方も、いつも読んでくださっている方も、ありがとうございます。
Haloと申します。
活動内容や、これから取り組みたいことをプロフィール記事にまとめました。
▼プロフィール
また、IT・AI・教材などをもう少し深く楽しめるメンバーシップ「Halo Lounge」も運営しています。
▼メンバーシップ詳細
▼SHOKANOWA放送局
気になるものがあれば、ぜひ覗いてみてください。
サーバーが速くても、「距離」はなくならない
Webサイトを見るとき、ブラウザはどこかに置かれているサーバーへリクエストを送ります。
「このHTMLをください」「この画像をください」「このCSSをください」とお願いして、サーバーから返ってきたデータを使いながら画面を組み立てています。
ここで少し厄介なのが、通信には時間がかかることです。
インターネットは、こちらのパソコンとサーバーを一本の線で直接つないでいるわけではありません。通信は複数のネットワーク機器や経路を通りながら目的地へ向かい、返事もまたネットワークを通って戻ってきます。
サーバーが遠くなれば、それだけ通信経路が長くなりやすく、往復に必要な時間も増えます。実際、MDNもCDNについて、利用者に近いサーバーからデータを提供することで距離による遅延を減らす仕組みとして説明しています。
もちろん、「東京から札幌だから何ミリ秒」「日本から米国だから必ず何秒」というほど単純ではありません。通信経路、混雑状況、回線品質なども影響します。
それでも、遠くにあるサーバーと何度も通信するより、近い場所から受け取れるほうが有利になりやすい。
CDNは、ここに手を入れます。
サーバーそのものをひたすら高速化するのではなく、届ける場所を変えるわけです。
この考え方は、技術の話として見るより、物流に置き換えたほうが分かりやすいかもしれません。
全国から注文が入る商品を、北海道にある一つの倉庫から毎回発送するとします。
北海道のお客さんには比較的早く届けられるでしょう。一方、九州のお客さんへ届けるには距離があります。
それなら東京、大阪、福岡にも商品を置いておけばいい。注文のたびに北海道まで取りに行く必要はありません。
CDNも、かなり乱暴に言えばこれに近いことをしています。
「コピーを近くに置く」がCDNの中心にある
CDNでは、世界中や各地域に「エッジ」と呼ばれる配信拠点があります。
Webサイトの画像、CSS、JavaScript、動画などのコンテンツを、そうした場所へキャッシュとして保持しておきます。
利用者からリクエストが来たとき、毎回オリジンサーバーへ取りに行くのではなく、近いエッジ側に目的のデータがあれば、そこから返します。
Cloudflareは、キャッシュを地理的に分散したデータセンターへ保存し、利用者に近い場所から提供することで、オリジンサーバーの負荷と表示時間の両方を減らせると説明しています。Amazon CloudFrontも同様に、利用者に近いエッジロケーションからキャッシュを返すことで、レイテンシーとオリジンへの負荷を減らす仕組みになっています。
ここでいう「近い」は、必ずしも地図上で一番近いという意味ではありません。
ネットワークとして応答しやすい場所へ振り分けられることもあります。CloudFrontも、利用者のリクエストを通常はレイテンシーの観点で近いエッジロケーションへルーティングすると説明しています。
このあたりはCDN事業者によって仕組みが少しずつ違いますが、利用する側から見ると考え方は同じです。
「本店まで毎回取りに行かない」。
これがかなり効きます。
たとえばWebページの中に、同じロゴ画像が使われているとします。
利用者Aが最初にアクセスしたとき、そのエッジに画像がなければ、CDNはオリジンサーバーから画像を取得します。そして、そのコピーをエッジ側へ保存します。
次に同じ地域の利用者Bが同じ画像を要求したとき、キャッシュがまだ有効なら、今度はオリジンまで取りに行かずエッジから返せます。
これが「キャッシュヒット」です。
反対に、エッジ側に目的のデータがなく、オリジンへ取りに行く必要がある状態は「キャッシュミス」と呼ばれます。
CDNを入れた瞬間、すべての通信が魔法のように近距離になるわけではありません。
最初は取りに行く必要があります。
ただ、一度持ってきたものを近くに置いておけば、同じものを何度も遠くへ取りに行かなくて済む。その積み重ねが大きいのです。
速くなるのは「転送速度」だけの話ではない
CDNを考えるとき、「近くからダウンロードするから速い」という説明だけでも、だいたい意味は通じます。
でも実際には、もう少し面白いところがあります。
Webでは、一回の巨大なデータをひたすら流し続けているだけではありません。
ページを開くと、HTMLを取得し、そこから必要なCSSやJavaScript、画像などを見つけ、さらにリクエストします。通信方式によって動きは違いますが、「お願いして、返ってくる」という往復が何度も発生します。
この一往復にかかる時間が長いと、小さな待ち時間が積み上がっていきます。
つまりCDNによる「近さ」は、単純なファイル転送時間だけではなく、こうした通信の往復にかかる待ち時間を減らす方向にも働きます。
ここは、仕事のやり取りにも少し似ています。
毎回確認が必要な相手が同じ部屋にいる場合と、時差のある海外拠点にいる場合では、一回の確認に必要な情報量が同じでも、やり取り全体の進み方はかなり違います。
情報の中身を変えなくても、往復にかかる時間が短くなるだけで、全体は軽くなります。
CDNも、コンテンツ自体を小さくしたわけではないのに速く感じることがあります。
「処理能力を上げる」以外に、「距離を短くする」という性能改善がある。
この考え方は、CDNを知ったときに面白いところだと思います。
オリジンサーバーも少し楽になる
CDNが効くのは、利用者側の速さだけではありません。
同じ画像を1万人が見るとして、1万人全員がオリジンサーバーへ直接取りに来たら、そのサーバーは1万人分のリクエストに対応する必要があります。
ところがCDN側でキャッシュを返せるなら、その一部はオリジンまで届きません。
Amazon CloudFrontのドキュメントでも、エッジキャッシュから提供できるリクエストが増えるほど、オリジンサーバーが直接処理するリクエストを減らせると説明されています。
これは地味ですが大きいです。
Webサイトにアクセスが集中するとき、「一台のサーバーをもっと強くしよう」と考えるだけではなく、そもそもそのサーバーへ届く仕事を減らすこともできます。
全部を本社で処理しない。
各地で済ませられることは各地で済ませる。
こう考えると、CDNは単なる高速化装置というより、仕事の分散にも見えてきます。
しかも、キャッシュに向いているデータほど、この分散がやりやすい。
ロゴ、画像、CSS、JavaScriptのように、多くの人へ同じ内容を渡すものなら、一度コピーして近くに置いておく価値があります。
一方で、ログイン後に表示される個人情報や、その瞬間に計算された結果など、利用者ごとに内容が変わるものは話が違います。
何でもかんでもCDNへ置けばいいわけではありません。
Cloudflareでも、画像やCSS、JavaScriptなどの静的コンテンツは標準でキャッシュ対象になりやすい一方、動的なHTMLなどは設定によって扱いが異なります。
「近くにコピーする」という単純な考え方だからこそ、何をコピーしてよいかが重要になります。
ここを間違えると、古い情報を返したり、本来キャッシュしてはいけない内容を扱ったりする問題につながります。
「近くに置く」には、古くなる問題もある
CDNの考え方を聞くと、全部キャッシュしておけばいいようにも見えます。
でもコピーを持つと、必ず一つ困ることが出てきます。
元のデータが更新されたときです。
オリジンサーバーに新しい画像を置いたのに、CDN側には古い画像が残っている。それを利用者へ返してしまえば、「更新したのに変わらない」という状態になります。
そこでCDNでは、キャッシュをどのくらい保持するかを設定します。
短くすれば新しい内容へ切り替わりやすくなりますが、オリジンへ取りに行く回数は増えます。長くすればキャッシュから返せる可能性は高くなりますが、更新内容が反映されるまで時間がかかることがあります。
CloudFrontでも、キャッシュ保持期間を長くするとエッジから直接返せる可能性が高まり、性能とオリジン負荷の面で有利になる一方、期限が切れたあとは最新状態を確認する仕組みになっています。
結局ここにも、少し設計が要ります。
速さだけを最大化したいなら、長く置いておきたい。
新しさだけを優先したいなら、すぐ確認したい。
その間で、「このデータはどれくらい古くても困らないのか」を考えることになります。
ニュースの速報と、会社ロゴでは事情が違います。
商品の在庫数と、背景画像でも違います。
CDNは「近くに置けば速い」という分かりやすい仕組みですが、実際に使うところでは、その中身の性質を見る必要があります。
遠くにあることを前提に、仕組みを変える
Webの高速化という話になると、つい「もっと強いサーバー」「もっと速い回線」の方向へ考えが向きます。
もちろん、それも必要です。
ただCDNは少し違う方向から問題を見ています。
遠いなら、遠い場所との通信を頑張って速くするだけではなく、そもそも近くに置けばいい。
毎回同じものを取りに行っているなら、途中に置いておけばいい。
一か所へリクエストが集中するなら、そこで全部受けなくてもいい。
やっていることは、思っている以上に素朴です。
ただ、その素朴さが強い。
システムの世界では、複雑な処理を追加して速くする方法もありますが、問題の置き方そのものを変えることで軽くなることもあります。
CDNの「近くに置く」という考え方は、その一つなのだと思います。
遠くの一か所から、何度も同じものを届け続けない。
必要な場所の近くへ、必要なものを置いておく。
技術用語を外してしまえば、それだけの話です。
そして、それだけの話だからこそ、Webのかなり大きな部分を支えています。
──────────────
📚 こんな有料記事も書いています
「AIにうまく頼めない人のための、仕事で使えるプロンプト設計」
AIへの頼み方を、感覚ではなく仕事で再利用できる形に整理しています。指示がうまく伝わらないときの見直しにも使えます。
「新人教育がうまくいかないとき、教える側が見直したい10のこと」
新人側の努力だけに任せず、教える側の環境や伝え方をどう整えるか。現場で見直したいポイントをまとめています。
──────────────
最後まで読んでくださって、ありがとうございました。
