CDN の仕組みと Anycast

東京のサーバーに、ブラジルから 1 秒かけてつなぐ

光の速さは変えられません。地球の反対側とやりとりすると、往復するだけで 200 ミリ秒ほど過ぎます。1 ページに数十個のファイルがぶら下がっていれば、待ち時間だけで 1 秒を超えます。サーバーをどれだけ速くしても、この分は縮みません。

縮められるのは、処理時間ではなく距離のほうです。

答えを、世界中にコピーしておく

CDN は、世界各地に置いた配信用のサーバーにファイルの写しを持たせる仕組みです。正本を持つ元のサーバーをオリジン、各地の写しを持つサーバーをエッジと呼びます。

利用者のリクエストは、まず近くのエッジに届きます。エッジがすることは 2 つのうちどちらかです。

• 写しを持っている場合 — その場で返す。オリジンは何も知らないまま終わる
• 写しを持っていない場合 — オリジンから取り寄せ、手元に置いてから返す。次の人からは 1 つ目になる

2 人目以降が全員エッジで完結するので、遠さも消えますし、オリジンに届く量も激減します。アクセスが集中したときに落ちにくくなるのは、この副作用のほうです。

裏返すと、置いてはいけないものを置くと事故になります。ログイン後の画面をうっかりエッジに残す設定にすると、次に来た別の人にその写しが配られます。誰に対しても同じ中身になるものだけを置く、というのが最低限の線引きです。人によって変わる応答は、明示的に写しを作らせない指定を付けて返します。

同じ住所が、世界中にある

近くのエッジに届く、と書きましたが、どうやって近くに届くのでしょうか。ここで使われるのが Anycast です。

普通は 1 つの IP アドレスは 1 台のサーバーを指します。Anycast では、まったく同じ IP アドレスを世界中の拠点が同時に名乗ります。経路を決める仕組みが一番近いところを選ぶので、東京から出したパケットは東京の拠点に、ロンドンから出したパケットはロンドンの拠点に届きます。同じ宛先を書いているのに、届く先が場所によって違います。

これは障害のときにも効きます。ある拠点が落ちると、その拠点への経路が自動で引っ込み、パケットは次に近い拠点へ流れます。切り替えの操作をする人も、待ち時間もありません。名前を引き直させて向き先を変える方式と違い、手元に残った古い答えに足を引っ張られないのが強みです。

直したはずのファイルが、まだ古いまま

写しを持つということは、古い写しも持つということです。CSS を直して公開したのに、利用者の画面が変わらない。これは避けようがない副作用で、対処は 2 通りあります。

1 つは、変更のたびにファイル名を変えてしまう方法です。app.4f2a91.css のように中身から作った文字列を名前に混ぜておくと、直した瞬間に別の名前になります。別の名前には写しが無いので、必ずオリジンまで取りに行きます。古い名前のほうは誰も参照しなくなるだけで、消して回る必要もありません。

もう 1 つは、CDN 側にこの URL の写しを捨ててと指示する方法です。名前を変えられない HTML などはこちらを使います。写しは長めに持たせておいて、更新したときだけ捨てる。この組み合わせにすると、エッジで完結する割合を高く保ったまま、反映も速くできます。