Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 1.3秒の勝負

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

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

CDNの誕生 — Akamaiが1998年に解こうとした問題
anycastルーティングの内部 — 「どうして同じIPが世界中のどこからでも近い場所に届くのか」
キャッシュ階層の戦略 — tiered、shielded、push
キャッシュ無効化の難題と実践パターン
DDoS防御 — L3/L4/L7の3層の盾
エッジコンピューティングの意味と主要3製品(Lambda@Edge、Cloudflare Workers、Fastly Compute)
画像/動画変換のエッジ処理
Zero Trust — Cloudflare AccessでVPNを置き換える
実戦の障害事例3つ

前回の記事 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進化

1999: Akamai商用化、静的アセットキャッシュ
2004: CloudFrontの前身であるLimeLight
2008: AWS CloudFront開始
2009: Cloudflare創業、無料プランを導入
2011: Fastly — Varnishベースの高性能
2017: Cloudflare Workers — エッジコンピューティングが一般化
2019: Fastly Compute@Edge(Wasmベース)
2022: CDNがZero Trust、DDoS、Bot防御までを吸収
2025: Cloudflare/FastlyがAI推論までエッジへ

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

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

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

限界:

再帰リゾルバーのIPから位置を推定するため不正確(EDNS Client Subnetで改善)
TTLが切れるまで経路変更不可
多くのIPを維持する必要がある

anycast — BGPレベルの魔法

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

動作原理:

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

anycastの利点

DNSレベルのチューニングが不要
1つのPoPがダウンしてもBGPが自動的に次に近いPoPへ再ルーティング(秒単位のフェイルオーバー)
単一IPで全世界にサービス提供

anycastの落とし穴

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

解決策:

多くのCDNはBGP経路を十分に安定化させている
QUIC/Connection IDベースのマイグレーション(前回の記事参照)
セッション親和性: L7セッションはanycast入口の後に内部のunicastへ切り替え

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

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

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

各階層の役割:

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

Hit Ratioの経済学

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

エッジのヒット率95% -> originに届くのは50GBだけ -> 帯域コストの大幅削減
Cloudflareの帯域は顧客に無料、AWS S3は $50〜100/TB。エッジによって数倍のコスト削減になる。

Cache-Controlヘッダーの解釈

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

public — 中間キャッシュを許可
max-age=31536000 — ブラウザキャッシュ1年
s-maxage=86400 — CDNキャッシュ1日
immutable — 検証リクエストすら送るな(reload時も)

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

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

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

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

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

モバイル vs デスクトップ(画像解像度)
言語/地域
認証状態

ヘッダーベースの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(即時削除)

CDN APIの呼び出しでURLを削除
Cloudflare: 1秒あたり10万件以上の処理が可能
コスト: プランによって無料〜有料

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

レスポンスに Surrogate-Key: product-42 cat-electronics ヘッダー
「cat-electronicsタグをすべて削除」で数千のURLを一括無効化
Fastlyがこのパターンを先導、由来はVarnish

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

ファイル名にハッシュ: main.abc123.js
デプロイごとに新しいURL -> 無効化不要、古いファイルは失効で自然消滅
React/Next.js/Viteのデフォルト

現実 — 組み合わせ

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

CSS/JS: versioned URL
APIレスポンス: 短いTTL + surrogate key
画像: 長いTTL + 必要に応じてpurge
HTML: stale-while-revalidate

5. DDoS防御 — 3層の盾

攻撃タイプ別の対応

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

anycastによる分散吸収
ネットワーク境界機器が異常パターンを遮断
2024年史上最大: Cloudflare基準で3.8Tbpsを防御

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

Rate Limiting(IP/パス/クッキー単位)
Challenge(CAPTCHA、Turnstile)
Bot Management(行動指紋、JS challenge)

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

WAF(ModSecurity、Cloudflare WAFルール)
キャッシュによるorigin保護
Circuit Breaker

Scrubbing Centerアーキテクチャ

伝統的なDDoS保護:

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

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

モダンCDN: 吸収ベース

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

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

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

AWS Lambda@Edge(2017)

CloudFrontイベントベース(Viewer Request/Response、Origin Request/Response)
Node.js、Pythonランタイム
コールドスタート: 数百ms
リージョンが限定的(すべてのPoPではない)
最大実行時間: Viewerは5秒、Originは30秒
メモリ: 128〜10,240MB

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

Cloudflare Workers(2017)

V8 Isolate ベース(Wasmも追加可能)
JavaScript/TypeScript/Rust(Wasm経由)
コールドスタート: 約5ms
300以上の都市、すべてのPoPで実行
制限: 10ms CPU(Free)、最大30秒(有料)
Durable Objects — 強整合な状態

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

Fastly Compute@Edge(2019)

Wasm/WASIベース
Rust、JavaScript、Go(TinyGo)、AssemblyScript
コールドスタート: 約35マイクロ秒
Fastlyのすべてのpop
実行時間に実質的な制限なし(現実的な範囲で)

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

3製品の比較

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

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

なぜ重要か

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

現代の画像フォーマット

JPEG — 依然としてベース、圧縮率はOK
WebP — Chrome 2010、すべてのモダンブラウザが対応
AVIF — WebPよりさらに+30%の圧縮、Safari 16+で対応
JPEG XL — Safari 17+、徐々に採用

エッジでの画像変換

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)

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

240p at 400kbps
480p at 1000kbps
720p at 2500kbps
1080p at 5000kbps

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

HLS(HTTP Live Streaming、Apple)

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

LL-HLS(Low Latency)

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

セグメント内のpartial segment
HTTP/2 push
Preload hint

WebRTC — 超低遅延

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

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

なぜVPNは限界なのか

「内部ネットワークへのアクセス=信頼」という前提が古い
侵害された内部アカウントがすべてを持ち出せる
リモートワークの大規模化でVPNがボトルネック化

Zero Trustモデル

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

構成要素:

ユーザーID(SSO)
デバイスの状態(MDM経由で検証)
ネットワーク位置
リクエストコンテキスト

エッジベースのZero Trust

Cloudflare Access、Google BeyondCorp、Zscalerなど:

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

利点:

内部アプリにパブリックIPが不要
DDoS防御が自動的
ユーザーログが中央集約

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が応答したか

ログストリーミング

Cloudflare Logpush -> S3/GCS/Splunk
Fastly Real-time Log -> S3/Kinesis
CloudFront -> S3 + Athena

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

Prometheusで収集、Grafanaで可視化:

Hit ratio per origin
P99 edge latency per PoP
4xx/5xx 比率
Bandwidth to origin

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

原則1: Hit Ratioを上げる

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

Cache-Controlを明示
クッキー/クエリパラメータを正規化
Origin Shieldを有効化

原則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項目

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

次回予告 — Chaos Engineering

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

NetflixのChaos Monkeyの誕生(2010)
Chaos Engineeringの4 Pillars
Game Day — 実戦シミュレーション訓練
NetflixのSimian Army — Chaos Monkey/Gorilla/Kong
LitmusChaos / Chaos Mesh — Kubernetes向けのchaos
AWS Fault Injection Simulator
Observability + Chaos の組み合わせ
組織文化への拡張 — 非難なきポストモーテム
chaos実験の設計手法

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

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