#deployment (2)

問題

wrangler r2 object put で R2 にファイルをアップロード → 確認したら何も入っていない。

原因

wrangler は デフォルトでローカル R2（miniflare）にアップロードする

実際の Cloudflare R2 に送るには --remote フラグが必須。

解決方法

# NG：ローカル R2 にのみアップロード
wrangler r2 object put my-bucket/document.md --file ./document.md

# OK：実際の Cloudflare R2 にアップロード
wrangler r2 object put my-bucket/document.md --file ./document.md --remote

確認方法

# ローカル R2 の内容確認（デフォルト）
wrangler r2 object list my-bucket

# リモート（実際）の R2 の内容確認
wrangler r2 object list my-bucket --remote

ベストプラクティス

自動同期スクリプト（GitHub Actions等）では 必ず --remote を指定 する。

# GitHub Actions での R2 アップロード例
- name: Upload to R2
  run: |
    wrangler r2 object put leango-docs/docs.md \
      --file ./dist/docs.md \
      --remote

デバッグ Tips

アップロード後の検証：

# リモート確認
wrangler r2 object list my-bucket --remote

# ダウンロード確認
wrangler r2 object get my-bucket/document.md --remote

デフォルトで悩むのは一度で終わらせよう。

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