Tech Learning Daily

ドメインを向けた瞬間に何が変わるのか ―― 権威 DNS という入口

ブラウザがドメイン名から IP アドレスを引くとき、問い合わせは再帰リゾルバ（キャッシュがなければルート → TLD → 権威サーバーの順に辿る）を経由し、最後にそのドメインを管理する権威 DNS サーバー（authoritative nameserver、ドメインの正式な DNS レコードを持つサーバー）から答えが返る。ドメインのレジストラでネームサーバーを Cloudflare のものに変更すると、以後この権威 DNS サーバーの役割を Cloudflare が担うことになる。

ここで効いてくるのが、レコードごとの「プロキシ状態」という切り替えだ。プロキシを無効（グレークラウド）にしたレコードは通常の DNS と同じく origin サーバーの IP をそのまま返す。一方プロキシを有効（オレンジクラウド）にすると、DNS が返す IP は origin ではなく Cloudflare 自身の anycast IP に変わる。この 1 つのトグルが、CDN・WAF・DDoS 対策をまとめて有効化するスイッチになっている。

anycast とリバースプロキシ ―― なぜ「一番近い拠点」が自動で選ばれるのか

通常の IP アドレスは 1 台のサーバーに紐づくが、anycast は世界中の複数拠点が同一の IP アドレスを同時に経路広報する方式だ。利用者からの通信は、BGP（インターネットの経路情報を交換するプロトコル）上でその利用者に一番近い経路を持つ拠点へ自動的にルーティングされる。特別な設定をしなくても、東京からのアクセスは東京近郊の拠点へ、ロンドンからのアクセスはロンドン近郊の拠点へ届く。

その拠点で動いているのがリバースプロキシ（クライアントに代わって origin へリクエストを仲介するサーバー）だ。キャッシュに目的のコンテンツがあればそのまま返し、なければ origin まで転送する。TLS の暗号化解除もこの拠点で行われるため、origin 側は復号処理を肩代わりしてもらえる。そして origin の IP アドレスはクライアントから見えなくなるので、DDoS 攻撃はまず拠点側で受け止められることになる。

ブラウザ
  │ DNS で example.com を問い合わせ
  ▼
Cloudflare 権威DNS
  │ 同じ anycast IP を返す
  ▼
BGP 的に一番近い edge 拠点
  ├─ cache hit    → 即応答
  ├─ Workers 実行 → その場で生成
  └─ cache miss   → origin へ転送

Workers ―― サーバーを増やすのではなく isolate を増やす

一般的なサーバーレス実行環境は、リクエストのたびにコンテナや VM を起動するコールドスタートのコストを抱えやすい。Cloudflare Workers は V8（Chromium や Node.js が使う JavaScript エンジン）が提供する isolate という軽量な実行単位を使う。公式ドキュメントによれば、isolate は Node.js プロセスをコンテナや VM で起動するのに比べておよそ 100 倍速く起動でき、1 つのランタイム上に数百〜数千の isolate を、互いのメモリ空間を分離したまま同居させられる。この起動コストの低さのおかげで、リクエストが来るたびに新しい実行環境を用意しても待ち時間がほぼ発生しない。

Workers は基本設定では 1 回のデプロイでコードが Cloudflare の全拠点に配られ、利用者に一番近い拠点で実行される。ここで「一番近い拠点で動くなら常に最速のはず」と思いたくなるが、実際はそう単純ではない。Worker が特定リージョンの DB に頻繁に問い合わせるような処理では、利用者の近くで実行するほど Worker から DB までの往復が長くなり、かえって遅くなることがある。この場合は Smart Placement という設定を有効にすると、実行場所が「利用者の近く」から「アクセス先データの近く」へ切り替わり、Worker と DB 間の往復を短縮できる。

Pages と GitHub Pages、何が違うのか

「git に push すると静的サイトが公開される」という体験そのものは両者で変わらない。このサイトも GitHub Actions が生成した HTML を main ブランチへ push し、GitHub Pages がそれを配信する形で動いている。GitHub Pages は静的ファイルをそのまま配るだけで、配信後にリクエスト単位の処理を差し込む仕組みは持たない。

Cloudflare Pages は Pages Functions という機能で Workers の実行環境をそのまま使えるため、ビルド済みの静的ファイルは変えずに、リダイレクトや認証チェックのような処理を edge に追加できる。つまり両者を分けているのは「静的ファイルを配る」性能そのものより、配った後にリクエスト単位のロジックを足せるかという構造上の違いだ。

実際に乗せ替えるとなると、変わる点は 2 つある。1 つ目はドメインのネームサーバーを Cloudflare に向け直す必要があること（最初のセクションの話に戻る）。2 つ目はデプロイの主導権で、GitHub Pages は GitHub Actions からの push だけで完結するが、Cloudflare Pages は Cloudflare 側の Git 連携か、Wrangler のような CLI で直接アップロードする Direct Upload のいずれかに、デプロイの仕組みごと乗せ替えることになる。