#infrastructure (4)

計画フェーズ: TTL事前短縮

TTL（Time To Live）とは

DNSレコードが世界中のDNSサーバーにキャッシュされる秒数。

• TTL 3600秒: 1時間キャッシュ保持
• TTL 300秒: 5分キャッシュ保持

なぜ事前に下げるか

問題発生時のロールバック速度を確保するため。

旧TTL（3600秒）のままIP切替すると、問題発生→即戻しでもキャッシュ有効期間中はユーザーが新サーバーにアクセスし続ける。最大1時間のエラー継続リスク。

ベストプラクティス

• DNS切替の24〜48時間前にTTLを300秒に短縮
• 切替後、安定稼働を確認したら元のTTL値（3600以上）に戻す

TTL短縮を忘れた場合

1. 最も安全: TTLを300に変更→1時間待機（旧キャッシュ完全消滅）→作業開始
2. 妥協案: TTLを300に変更→すぐ作業開始（大半は5分で浸透、一部残留リスク）
3. リスク高: TTL 3600のまま作業開始（ロールバック時に最大1時間の影響）

実行フェーズ: DNS切替

DNSレコードを新サーバーのIPアドレスに変更する。浸透には最大48時間かかるため、初期段階でのトラフィック不足は正常。

監視フェーズ: 切替後のダッシュボード確認

正常な状態

• 5xx: 0 / 4xx: 少数（正常範囲） / CPU: 低い（2%程度） / メモリ: 低い（24%程度） / 2xx: トラフィックに応じて増加

問題ありの兆候

指標	状態	対応
5xx ≥ 1	SSR/APIに問題	ログ確認、深刻ならロールバック
4xx 急増	ルーティング/リダイレクト設定ミス	旧パスの404を調査
CPU > 50%	SSR過負荷	ページ最適化/スケール調整
メモリ > 80%	メモリリーク等	プロセス調査
2xx = 0	DNS未浸透 or SSL未発行	dig domain.com A で確認

監視フロー

1. 切替後30分〜1時間: 継続的にダッシュボード監視
2. 最初1〜2日間: TTLを300秒のまま維持（即ロールバック可能に）
3. 安定確認後: TTLを3600に戻す

背景

フルスタック Web 開発では「どのバックエンド使うか」という選択肢が多い。

• Firebase Cloud Functions
• AWS Lambda
• Google Cloud Functions
• Cloudflare Workers
• Vercel Functions
• 自社 VM / Kubernetes

アンチパターン

単なる Slack webhook POST → Firebase Cloud Functions + GCP VM

課題

1. 過剰エンジニアリング: インフラの複雑さが実装の 10 倍
2. 学習曲線: Firebase SDK の理解 / GCP コンソール操作
3. 運用コスト: 監視、ログ、スケーリング設定
4. 冗長性: 単純な処理に高可用性インフラは不要

原則：逆算発想

1. 必要な処理は何か？
   → Slack Webhook 1 行の POST

2. どのくらいのスケールか？
   → コーポレートサイト、月 100 件程度の問い合わせ

3. どのインフラがそれに適切か？
   → API Gateway / Edge Function で十分
   ❌ Firebase（学習コスト高い）
   ❌ Cloud Run（常時起動 VM）
   ✓ CF Pages Functions（エッジで即実行、無制限）

判断表

必要な処理	推奨インフラ	理由
Webhook POST / メール送信	CF Functions / Vercel API	単発実行、低レイテンシ
CRUD API + DB	Supabase / Firebase Realtime	リアルタイム必須
バッチ処理 / 長時間実行	Cloud Tasks / Temporal	スケジュール・リトライ
リアルタイム双方向通信	WebSocket (Vercel KV / Durable Objects)	ステートフル
機械学習推論	Lambda / Cloud Functions	計算量多い

移行ケース

Before（過剰）

Next.js (GCP App Engine)
  ↓
Firebase Cloud Functions
  ↓
Slack Webhook

• 起動: gcloud app deploy（数分待ち）
• 監視: GCP コンソール + Firebase console
• コスト: 月 $10-50（Free tier外）

After（最小化）

Astro static (CF Pages)
  ↓
CF Pages Functions（同一プロジェクト）
  ↓
Slack Webhook

• デプロイ: wrangler deploy（秒単位）
• 監視: CF dashboard 一箇所
• コスト: 月 $0（Free 10万req/日）

チェックリスト：この技術は必要か？

• 実装なしに同じ結果を得られないか？（No = 必要）
• 学習コストは実装メリットに見合うか？
• 運用オーバーヘッド（監視、スケーリング、ログ）は将来的に必要か？
• チーム全体が使いこなせるスキルセットがあるか？
• 本番環境での障害時の対応ができるか？

1 つでも No なら、もっと単純な選択肢を検討する。

学び

「機能しているから」という理由で複雑性を受け入れない。 移行時が技術選定を見直すベストタイミング。

背景

Enterprise フレームワークからエッジコンピューティングへの移行時、既存の Firebase Cloud Functions の必要性を再評価。

発見

Firebase Cloud Functions で実装していた sendMail の実体は単なる Slack Incoming Webhook への POST。

// Firebase Cloud Functions の実体
export const sendMail = httpsCallable(async (data) => {
  return fetch('https://hooks.slack.com/services/...', {
    method: 'POST',
    body: JSON.stringify({ text: message })
  });
});

問題点

• GCP インスタンス起動、スケーリング、ホスト、監視の複雑さ
• コールドスタート遅延
• 固定コスト（Active プロジェクト課金）
• 学習コスト・運用オーバーヘッド

解決策

エッジ関数（CF Pages Functions）で同じ処理を 1 行で実装。

// CF Pages Functions (functions/contact.ts)
export const onRequest: PagesFunction = async (context) => {
  const { name, email, message } = await context.request.json();

  await fetch('https://hooks.slack.com/services/...', {
    method: 'POST',
    body: JSON.stringify({ text: `${name}: ${message}` })
  });

  return new Response('OK');
};

学び

インフラの複雑さは必要性から逆算すべき。 単純な webhook 処理には GCP VM より CF Functions の方が適切。デプロイも自動。

移行メリット

• デプロイが簡単（functions/ に置くだけ）
• コールドスタートなし
• 従量課金（Free 10万req/日）
• 監視・スケーリング不要

.jpドメインとCloudflareの制約

• .jp / .co.jp はCloudflare Registrarに移管不可（非対応TLD）
• できるのはNS変更（DNS管理のみCFへ） のみ
• .jp のNS変更はJPRS経由のため反映に24〜72時間かかる（.comは数時間）
• 問題発生時の切り戻しも同様に遅い

CF Pages vs Firebase App Hosting（ドメイン設定の差）

ホスティング	ドメイン設定方法	リスク
CF Pages	NS変更が必須（CF DNS経由のみ）	メール不達・ダウンタイムリスクあり
Firebase App Hosting	Aレコード2つ + TXT追加のみ	ほぼゼロ

判断基準

• 既にFirebase資産（Firestore, Functions）を使っているなら、Firebase App Hostingの方がドメイン移行コストが圧倒的に低い
• CF Pagesを使う明確な理由（Workers活用、プレビューデプロイ重視等）がなければ、.jpドメインではNS変更を避けた方が安全
• NS変更する場合のチェック: TTL事前短縮 → 全レコード目視確認（特にMX/SPF/DKIM） → 低トラフィック時間帯に実施