#edge-computing (1)
従来アーキテクチャ(GCP VM)
User Request
↓
GCP Cloud Run / App Engine VM ← コールドスタート / スケーリング遅延
↓
HTML 生成 / SSR
↓
レスポンス
問題
- コールドスタート: 初回実行時 500ms 以上
- スケーリング: 同時アクセス増加時に自動スケール待ち
- 往復レイテンシ: 物理的な距離(地理的に離れたデータセンター)
- 固定コスト: インスタンス維持費
新アーキテクチャ(Astro → CF Pages CDN)
User Request
↓
CDN エッジ(地理的に近い)← 99.99% はキャッシュヒット
↓
静的 HTML / JS / CSS 返却(ミリ秒単位)
↓
レスポンス
メリット
- ゼロレイテンシ: キャッシュは世界 200+ のエッジロケーション
- スケーリング不要: CDN が自動的に分散
- コールドスタート無し: ファイルサーバーなので即座に返却
- 従量課金: 無制限の静的配信(Free)
実測値の例
| 指標 | GCP Cloud Run(SSD ストレージ) | CF Pages CDN |
|---|---|---|
| TTFB(東京から) | 150-300ms | 20-50ms |
| キャッシュヒット率 | N/A(毎回生成) | 99.9% |
| スケール対応 | 数秒待ち | 即座 |
| 月額コスト | $10-50 | $0(Free) |
Astro + CF Pages が強い理由
ビルド時生成
# yarn build
astro build
↓
dist/ に静的 HTML/CSS/JS を生成
↓
Pages が自動的に CF CDN に配置
Edge Functions は必要な時だけ
// Pages Functions(エッジで実行、スピン不要)
export const onRequest: PagesFunction = async (ctx) => {
return fetch('https://api.example.com/data');
};
動的処理はエッジ関数で即座に実行。サーバーVM起動なし。
チューニングのポイント
- キャッシュキー: 静的アセットに
Cache-Control: max-age=31536000(1年) - Stale-While-Revalidate: ISR 相当(バックグラウンド再生成)
- 圧縮: CF が自動的に Brotli 圧縮
// wrangler.toml でのキャッシュ設定
[env.production]
routes = [
{ pattern = "/static/*", cache_control = "public, max-age=31536000" },
{ pattern = "/*", cache_control = "public, max-age=3600, stale-while-revalidate=86400" }
]
移行判断基準
- 静的コンテンツ 80% 以上 → Astro + CDN(この場合)
- ユーザーごとの動的生成 → SSR 維持(Next.js)
- リアルタイム更新 → SPA + API(React)
結論: 静的配信できるなら CDN エッジが最高パフォーマンス。サーバーレス関数は webhook/API にのみ使う。