#dns (2)

計画フェーズ: 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に戻す

.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） → 低トラフィック時間帯に実施