LabHub

ブログ

CDNとエッジコンピューティング完全解剖 — anycast、キャッシュ無効化、DDoS防御、Lambda@Edge vs Workers vs Compute

2026-04-15 · 20 分で読めます · #cdn#edge-computing#cloudflare#akamai#fastly#anycast#ddos#networking#japanese

한국어English日本語

はじめに — 1.3秒の勝負

2006年のAmazonの実験: ページロードが100ms遅くなると売上が1%下がる。2017年のGoogle: モバイルで1秒→3秒になるとバウンス率が32%上昇。

1秒を稼ぐために、インターネット企業は地球全体にサーバーを配置し、BGPを操作し、キャッシュ階層を積み上げ、さらにはサーバーレス関数をユーザーの半径100km以内に配置するまでになった。本稿では:

前回の記事 WebAssembly + WASI完全解剖 ではWasmがエッジの実行エンジンだと述べた。本稿では、そのエンジンが載る地球規模のインフラを見る。

1. CDNの誕生 — 1998年のAkamai

問題: 1997年のスーパーボウル

CBSがスポーツイベントをWebで配信しようとした。サーバーはボストン、ユーザーはカリフォルニア。1997年当時、米国大陸の往復はおよそ70ms、さらに帯域競合まで加わる。サイトはダウンした。

MITの研究チームがこれを機に起業 — Akamai(ハワイ語で「賢い/速い」)。

解法: コンテンツをユーザーの近くに複製する

世界中のISPのPoP(Point of Presence)にキャッシュサーバーを設置し、同じリクエストを近くのサーバーから応答させる。1999年、AkamaiはユーザーのDNSに対して地理的に異なるIPを返すグローバルシステムを世界で初めて商用化した。

1999〜2025のCDN進化

2. anycast — 同じIP、異なる場所

伝統的なDNSベースの地理ルーティング

1990年代のAkamai方式: ユーザーが a.akamai.net を問い合わせる → DNSがクライアントIPを見て最も近いサーバーのIPを返す。

限界:

anycast — BGPレベルの魔法

Cloudflareは1.1.1.1という1つのIPを、世界300以上の都市の数千台のサーバーに同時に割り当てる。ユーザーが1.1.1.1にパケットを送ると、BGPルーティングが自動的に最も近いサーバーへ届ける。

動作原理:

  1. Cloudflareは各PoPで同じAS番号から 1.1.1.0/24 プレフィックスをBGPで広告する
  2. 近隣のISPは複数の経路の中から最短のAS-pathを選ぶ
  3. 結果としてユーザーは地理的に近いPoPへルーティングされる

anycastの利点

anycastの落とし穴

セッション維持が難しい。初期のTCP 3-way handshakeの途中でBGP経路が変わったら? 新しいPoPはSYNしか見ておらずACKを見ていないため接続に失敗する。

解決策:

3. キャッシュ階層 — EdgeからOriginまで

ユーザーリクエストがキャッシュと出会う順序

[ユーザー] -> [エッジPoP (近い都市)] -> [リージョナルキャッシュ] -> [Origin Shield] -> [Originサーバー]

各階層の役割:

エッジPoP: ユーザーから半径50〜200km。90%以上のヒット率を目標。 リージョナルキャッシュ: 大陸/地域単位。エッジがmissのとき。 Origin Shield: Originの直前。共有キャッシュでorigin負荷を最小化。 Origin: 実際のコンテンツストア(S3、Webサーバーなど)。

Hit Ratioの経済学

月1TBのトラフィックを持つサービスを仮定:

Cache-Controlヘッダーの解釈

Cache-Control: public, max-age=31536000, s-maxage=86400, immutable

モダンなエッジは stale-while-revalidate もサポート:

Cache-Control: max-age=3600, stale-while-revalidate=86400

「1時間以内はfresh、24時間まではstaleを返しつつバックグラウンドで更新」。

Key設計 — 同じURLを別物として扱うべきとき

デフォルトのキャッシュキーはURLだが、同じURLでも以下の場合は異なる:

ヘッダーベースのcache key拡張が必要:

cacheKey:
  - url
  - header: Accept-Encoding
  - header: User-Agent(normalized)  # モバイル/デスクトップのみ

次元が増えすぎると -> カーディナリティ爆発、ヒット率が崩壊。ポリシー設計が重要。

4. キャッシュ無効化 — 2つの難題のうちの1つ

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

問題の本質

URL先のコンテンツが変わったのにCDNがまだ古いものを配信している。世界中の数百のPoPに散らばったキャッシュを「一度に」消すにはどうすればよいか?

無効化の4つの戦略

1. TTLの自然失効

2. Purge(即時削除)

3. Surrogate Key / タグベース無効化

4. Versioned URL(キャッシュバスティング)

現実 — 組み合わせ

実運用では4つを組み合わせる:

5. DDoS防御 — 3層の盾

攻撃タイプ別の対応

L3/L4(ボリューム型) — UDPフラッド、SYNフラッド、amplification

L7(アプリケーション) — HTTPフラッド、Slowloris、再帰クエリ

Target(リソース枯渇) — DBの高コストクエリ、決済への集中攻撃

Scrubbing Centerアーキテクチャ

伝統的なDDoS保護:

  1. 顧客の正常トラフィックをscrubbing centerに通す
  2. 悪性パターンを遮断し、正常分だけをoriginへ転送

問題: 顧客のorigin IPが露出すると迂回攻撃を受ける。

モダンCDN: 吸収ベース

Cloudflare/Fastlyのanycastは世界中の数百のPoPで攻撃を分散吸収する。個別のPoPがoverloadしてもBGPが別のPoPへ移す。

「Magic Transit」のような製品では、BGPで顧客の /24 プレフィックス自体をCDNが代理広告し、源流から保護する。

6. エッジコンピューティング主要3製品

AWS Lambda@Edge(2017)

用途: リダイレクト、A/Bテスト、認証検証

Cloudflare Workers(2017)

用途: アプリ全体(Remix、Next.js on Workers)、API gateway、動的な画像変換

Fastly Compute@Edge(2019)

用途: API変換、A/Bテスト、画像変換、複雑なedge logic

3製品の比較

項目Lambda@EdgeWorkersCompute@Edge
エンジンLambda(コンテナ)V8 IsolateWasm
コールドスタート約数百ms約5ms約35マイクロ秒
PoP数限定(13リージョン)300以上80以上
実行時間5〜30秒10ms〜30秒実質制限なし
言語Node、PythonJS/TS、WasmWasmターゲット全般
価格高い安い中程度

7. 画像最適化 — CDNのキラー機能

なぜ重要か

Webトラフィックの50%以上が画像。適切なフォーマット/サイズの選択だけでページロードを半分に短縮できる。

現代の画像フォーマット

エッジでの画像変換

Cloudflare Images、Fastly Image Optimizer、AWS CloudFront + Lambda@Edge:

https://cdn.example.com/photo.jpg?w=400&fm=webp&q=75

エッジがリクエスト時に実際に変換し、結果をキャッシュ。originはオリジナル1つだけを保管。

Acceptによるレスポンシブ画像

ブラウザが Accept: image/avif, image/webp, image/* を送ると、エッジがサポートフォーマットの中から最適を応答する。Vary: Accept でキャッシュキーを分離。

8. ストリーミングメディア — HLS/DASH/LL-HLS

ABR(Adaptive Bitrate)

動画を複数ビットレートであらかじめエンコード:

プレイヤーは現在の帯域に応じてセグメント単位で選択。途切れなく品質を調整する。

HLS(HTTP Live Streaming、Apple)

m3u8マスタープレイリスト -> 各解像度のプレイリスト -> 6秒の .ts セグメント。 HTTPベースなのでCDNと完璧に相性が良い。

LL-HLS(Low Latency)

標準HLSは30秒以上の遅延。LL-HLSは2秒以下を実現可能:

WebRTC — 超低遅延

ストリーミングではなくリアルタイム会話用(500ms未満の遅延)。CDNではなくSFU(Selective Forwarding Unit)が必要。

9. Zero Trust — VPNを置き換える方式

なぜVPNは限界なのか

Zero Trustモデル

すべてのリクエストを常に認証+コンテキスト評価する。内部/外部の区別はない。

構成要素:

エッジベースのZero Trust

Cloudflare Access、Google BeyondCorp、Zscalerなど:

  1. 内部アプリをエッジネットワーク経由で公開
  2. すべてのリクエストをエッジで認証
  3. 正常なものだけを内部へ転送

利点:

Cloudflare Accessには無料プランもあり、個人/スタートアップで人気。

10. 実戦の障害事例

事例1: 2021年のFastly世界規模の1時間ダウン

顧客のVCL(Varnish Config Language)設定がエッジのグローバルなバグを発火させた。世界中のPoPが同時にダウン。Amazon、NYT、Reddit、英国政府サイトが影響を受けた。教訓: CDN設定のテスト環境は必須、ベンダー多重化も検討すべき。

事例2: 2017年のCloudbleed

CloudflareのHTTPパーサーがメモリ領域を誤って読み、別の顧客のHTTPレスポンスの一部を混ぜて返してしまった。Googleのキャッシュに機微なデータが残った。7日かけて収束。教訓: メモリ安全な言語(Rust)でパーサーを書き直す。以降Cloudflareはコアコンポーネントを次々とRustへ移した。

事例3: 2022年のRogers Canada

ISP障害がDNSや緊急通報まで麻痺させた。CDNには間接的な影響。教訓: ネットワーク依存関係のマッピング、非常経路の設計。

11. ベンダー選定ガイド

Cloudflare

強み: 価格(無料プランが充実)、開発者体験、Workersエコシステム、Zero Trust。 弱み: 動画ストリーミングは専門ではない、エンタープライズカスタム対応は限定的。

Akamai

強み: 大型エンタープライズの実績、複雑なメディアワークフロー、セキュリティ監査の成熟度。 弱み: 高価、開発者UXは最新水準ではない。

Fastly

強み: 非常に高速なpurge(世界で150ms未満)、VCLカスタマイズ、Wasm Compute。 弱み: 価格がCloudflareより高く、学習コストが高い。

AWS CloudFront

強み: AWSエコシステムとの統合、低いegressコスト(AWS内部サービス宛)。 弱み: エッジ機能が限定的、開発者UXは普通。

現実 — マルチベンダー

大規模メディアはAkamai + Fastly多重、スタートアップはCloudflare単独が典型的なパターン。

12. 観測性とデバッグ

CDNレスポンスヘッダー

デバッグの味方:

CF-Ray: 123abc-ICN       # Cloudflare
Age: 3421                # 現在のキャッシュ経過秒数
X-Cache: HIT from edge   # Fastlyのキャッシュヒット有無
X-Served-By: cache-icn1  # どのPoPが応答したか

ログストリーミング

リアルタイムダッシュボード

Prometheusで収集、Grafanaで可視化:

13. コスト最適化 — 帯域はキャッシュ

原則1: Hit Ratioを上げる

90% -> 95%に上げるとorigin向けトラフィックが半分になる。チューニング:

原則2: 画像フォーマットの最適化

JPG -> WebPに変えるだけでトラフィックが30%減る。

原則3: Brotli圧縮

gzipより15〜25%多く圧縮できる。多くのCDNはデフォルトで対応。

原則4: Origin位置戦略

Cloudflare/Fastlyは多くの場合originとのegressが無料(同一CDN間)。AWS CloudFront -> AWSリージョンは安価。クロスクラウドは高価。

原則5: コミット契約

トラフィックが予測可能なら年間コミットで40%以上の割引が可能。

14. 落とし穴とアンチパターン

落とし穴1: Originにキャッシュヘッダーがない

Originが Cache-Control なしで応答 -> CDNは保守的に判断してキャッシュしない。必ず明示すること。

落とし穴2: クッキー/クエリ文字列でキャッシュを壊す

?timestamp=123 や広告トラッキングクッキーが毎回変わる -> キャッシュミス。正規化ルールは必須。

落とし穴3: 習慣的なpurge

デプロイのたびに「全体purge」をするとoriginが再爆発する。versioned URLやsurrogate keyを使うこと。

落とし穴4: anycast + 状態付きUDP

UDPセッションをanycastで走らせるとBGP変更時に壊れる。QUICのConnection IDまたはL4 stickinessが必要。

落とし穴5: Origin Shieldなしでhotイベント

バイラルトラフィックがすべてのPoPに拡散 -> 各PoPでoriginへmiss -> originがダウン。共有キャッシュ層としてShieldを使う。

落とし穴6: preview/staging URLがCDNを通らない

CDNなしでoriginを直接公開するとDDoSリスクが伴う。stagingもアクセス制御を付けてCDNの後ろに置く。

15. 実戦チェックリスト12項目

  1. Cache-Controlを明示 — デフォルトに依存しない
  2. Brotli圧縮をオン
  3. AVIF/WebPへの自動変換 — 画像サイズを50%削減
  4. Origin Shieldを有効化 — 大規模イベントに備える
  5. Purge戦略をドキュメント化 — surrogate key vs versioned URL
  6. Rate Limitingのデフォルト設定 — 特に認証エンドポイント
  7. WAF OWASP Top 10ルールを適用
  8. HTTP/3をオン — モバイルUX向上
  9. 観測性の統合 — CDNログ -> SIEM
  10. コストアラート — 予測からの逸脱を検知
  11. ベンダー多重化のPoC — 重要サービスはCDN 2本立て
  12. エッジコンピューティングの使用箇所を見直す — リダイレクト、認証、A/Bはエッジへ

次回予告 — Chaos Engineering

「インターネットが遅くなったらどうする?」「AZが1つダウンしたら?」答えは実際に壊してみること。次回は:

運用会議で「chaos engineeringの導入を検討中」と一度は聞いたことがあるはず。次回はその意味を解体する。

「障害は避けられない。障害への備えはできる。chaos engineeringはその備えをコード化する。」

原文を読む: https://www.youngju.dev/blog/culture/2026-04-15-cdn-edge-computing-anycast-cache-invalidation-ddos-lambda-workers-compute-deep-dive-guide-2025.ja

コメント

まだコメントはありません。

ログインするとコメントできます