個人サービスのストレージ見直し: R2 → GCS のバックアップをイベント駆動に、冷たいデータは DB から出す
60 万記事・60 万画像を抱える個人サービス「しずかなインターネット」での見直し例。日次の一括同期をアップロードごとのコピーに変え、アクセス頻度の低いデータは DB からオブジェクトストレージへ移してコストを下げる。
1. バックアップを「日次一括」から「アップロードごと」に
- 旧: 1 日 1 回、rclone で R2 → GCS に差分同期（データが増えるほど実行時間が伸びていた）
- 新: R2 に画像をアップロード → Workers をトリガー → GCS にコピー
- データ量に比例して重くなる定期ジョブを、イベントごとの小さな処理に分解する考え方。
2. アクセス頻度の低いデータを DB から出す
- 背景: PlanetScale のプランのベース料金に従量課金が加わったので、DB に置くデータを減らしたい。
- 記事本文のうち、エディタ用の JSON はアクセス頻度が低く多少の遅延も許容できるので、常に GCS に置いて必要なときだけ取り出す。
- さらに削るなら、変換済み HTML も GCS に置き、アクセスの多いものだけ Redis でキャッシュする。
- 注意点として、エクスポート機能などで記事ごとの JSON にまとめてアクセスする処理は面倒になる。
3. S3 ならライフサイクルルール
大量の画像・動画を扱うサービスが、ライフサイクルルールで日数ごとにストレージクラスを移して S3 のコストを抑えていた、という話。ストレージクラスの設計は侮れない。