S3ライフサイクル戦略（みてね）
MIXI「家族アルバム みてね」のSREチームが実践するAmazon S3のコスト最適化・データ保護戦略。2500万ユーザー・131億件以上の写真・動画データを扱う大規模サービスにおいて、S3バージョニング・ストレージクラス移行・HLSファイル管理の3軸でコスト削減とUXの両立を実現。
背景と課題
- 写真・動画を無制限保存するサービス特性上、S3に膨大なデータが蓄積する
- データ量の増加に伴いストレージコストが増大し続ける
- ユーザーの大切な思い出データの誤削除は絶対に避けなければならない
戦略1: S3バージョニングによるデータ保護
仕組み
S3バージョニングを有効にすると、オブジェクトの削除・上書き操作が行われても過去バージョンが保持される。誤操作によるデータ損失リスクを大幅に低減できる。
みてねの運用ルール
特別な理由がない限り、全てのS3バケットでバージョニングを有効化する
コスト上の落とし穴
- 過去バージョンも現行バージョンと同様にストレージコストが発生する
- ユーザーが削除操作をしても「論理削除（削除マーカー）」になるだけでコストは減らない
対策: 旧バージョン自動削除ルール
ライフサイクルルールで「一定期間経過後の旧バージョン削除」を設定することで、安全性を維持しつつコストの過剰な増加を抑制する。
戦略2: ストレージクラスとライフサイクルルールによるコスト最適化
S3ストレージクラスの選択基準
S3にはレイテンシ・可用性・料金が異なる複数のストレージクラスが存在する。アクセスパターンを分析して最適なクラスを選択することがコスト削減の鍵。
参考: https://aws.amazon.com/jp/s3/storage-classes/
みてねの写真・動画のアクセスパターン分析
| フェーズ | アクセスの特性 | 理由 |
|---|---|---|
| アップロード直後（0〜30日） | アクセス頻度が最も高い | ユーザーアクセス・端末保存・解析処理・月1回フォトブック/写真プリント自動提案 |
| 30日以降 | 極端にアクセス頻度が低下 | — |
採用したストレージクラス設計
| 期間 | ストレージクラス | 選定理由 |
|---|---|---|
| 0〜30日 | S3 Standard | 取り出し料金が発生しない。フォトブック月次提案で1ヶ月間アクセスが続く |
| 30日〜 | Glacier Instant Retrieval | アクセス頻度は低いが、リアルタイムアクセス（ミリ秒レベル）が必要なため即時取得可能なGlacierクラスを選択 |
30日間のライフサイクルルールで S3 Standard から Glacier Instant Retrieval へ自動移行することで、UXを損なわずにコストを削減する。
Glacier Instant Retrieval の特性
Glacier Flexible Retrieval（旧 Glacier）は取り出しに数分〜数時間かかるが、Glacier Instant Retrieval はミリ秒レベルで取り出しができる。アクセス頻度は低いが即時性が必要なアーカイブに適している。
戦略3: 動画配信（HLS）のライフサイクル活用
HLS（HTTP Live Streaming）の採用
みてねはアプリ上の動画再生にHLSを採用している。
- HLSデータがS3に存在する場合: S3から配信
- HLSデータがS3に存在しない場合: リアルタイムに生成してから配信（EC2コストが発生）
HLSファイルの保存期間トレードオフ
| 設定 | ストレージコスト | EC2（再生成）コスト |
|---|---|---|
| 保存期間を長くする | 増加 | 低下 |
| 保存期間を短くする | 低下 | 増加 |
最適化アプローチ
- 動画再生ログを元にアクセスパターンを分析
- 保存期間ごとに再生成コストをシミュレーション
- ストレージコスト + EC2コストの合計が最も低くなる保存期間を算出してライフサイクルルールに設定
全体のまとめ
S3ライフサイクル戦略の3本柱
├── 1. S3バージョニング（全バケット適用）
│ └── ライフサイクルルールで旧バージョン定期削除
├── 2. ストレージクラス移行（アクセスパターン分析ベース）
│ └── Standard（0〜30日）→ Glacier Instant Retrieval（30日〜）
└── 3. HLSファイル期間管理（ログ分析→シミュレーション→最適化）
アクセスパターンを分析し、ライフサイクルルールを柔軟に活用することで、UXとコスト最適化を両立する。（fanglang）
適用可能なユースケース
- 写真・動画の長期保存サービス
- アップロード直後のアクセス集中が想定されるメディアサービス
- データ誤削除リスクを最小化したいサービス（バージョニング活用）
- 動画変換・エンコード結果をキャッシュするアーキテクチャ
関連ページ
- 「家族アルバム みてね」を支えるS3ライフサイクル戦略 — 元ソース（SpeakerDeck）
- fanglang — 戦略の設計・登壇者
- MIXI — みてねの運営組織