Prometheusのストレージ容量不足を防ぐ！データ保持期間（Retention）と容量試算の極意
こんにちは！今日もシステム運用と監視の現場、本当にお疲れ様です。
監視システムを運用していて、「気づいたらPrometheusがディスクフルで停止していた…」という苦い経験はありませんか？ システムの健全性を監視するためのツール自身が、ストレージ溢れによって倒れてしまっては元も子もありませんよね。
Prometheusは非常に高速で強力な時系列データベース（TSDB）を備えていますが、デフォルトの設定のまま運用を続けると、データは際限なく増え続け、最終的には必ずストレージを使い果たします。
ですが、心配はいりません！
この記事では、Prometheusのストレージの仕組み（TSDB）を解剖し、「正確な容量試算の計算式」から「Retention（保持期間・サイズ）の最適な設定手順」、そして「ThanosやCortexといった長期保存ソリューションへの移行タイミング」までを徹底解説します。
これをマスターすれば、毎日の容量おびえ作業から解放され、安定したオブザーバビリティ基盤を自信を持って運用できるようになりますよ。それでは、一緒に学んでいきましょう！
—
第1章：Prometheusを支える「TSDB」の超効率的な仕組み
まずは、Prometheusがどのようにデータをディスクに保存しているのか、その内部構造（TSDB: Time Series Database）を覗いてみましょう。仕組みを知ると、なぜ容量管理が重要なのかがすんなり理解できます。
1-1. メモリとディスクを駆使するブロック構造
Prometheusは、時系列データを「2時間ごとのブロック（Block）」という単位にまとめてディスクへ書き出します。
/data (Prometheus TSDB Directory)
├── 01F8MEA551D0B515… (2時間分のデータブロック)
│ ├── chunks (圧縮されたメトリクス本体)
│ ├── index (ラベル検索用のインデックス)
│ └── meta.json (ブロックのメタ情報)
├── 01F8MEB661E1C616… (次の2時間分のデータブロック)
├── wal (Write-Ahead Log: メモリ上の未保存データ)
└── queries.active
内部では主に次のような挙動をしています。
1. Head Block（メモリ領域）:
スクレイプ（収集）された最新のデータは、まずメモリ上の「Head Block」に保持されます。
2. WAL (Write-Ahead Log):
クラッシュ時のデータ喪失を防ぐため、メモリに載せると同時にディスクの `wal` ディレクトリへ即座に書き込まれます。
3. 2時間の永続化（Blockの生成）:
データが2時間分たまると、メモリ上のデータは圧縮され、`01F8…` のような新しいブロックディレクトリとしてディスクへ永続化（フラッシュ）されます。
4. Compaction（ブロックの結合）:
バックグラウンド処理により、古い小さなブロック（2時間単位）は、効率的な検索と削除のために大きなブロック（例えば10時間分など）へ自動的に結合されます。
1-2. なぜPrometheusは爆速でデータが軽いのか？
PrometheusのTSDBは、1サンプルあたり平均わずか1.3〜2バイトという驚異的な効率でデータを圧縮します（Gorillaフェッチング／デルタエンコーディング技術）。
しかし、どれほど圧縮率が高くても、「スクレイプ対象の増加」や「ラベルの過剰な付与（高カーディナリティ）」が起きると、データ量は爆発的に跳ね上がります。そのため、適切な保持期間の設定と容量試算が不可欠なのです。
—
第2章：一発で算出！失敗しないストレージ容量の見積もり計算式
「結局、うちの環境だとDiskは何GB必要なの？」
この疑問に答えるための公式があります。公式ドキュメントでも推奨されている計算式を、現場で使える形に落とし込みました。
2-1. 容量試算の基本計算式
必要なディスク容量は、以下の式で算出できます。
$$\text{必要な容量 (Bytes)} = \text{保持期間 (秒)} \times \text{1秒あたりの収集サンプル数} \times \text{1サンプルあたりのバイト数}$$
公式や実績値に基づき、1サンプルあたりのバイト数（$\text{Bytes per sample}$）は「1.5 Bytes〜2.0 Bytes」として計算するのが安全です（余裕を見て2.0 Bytesで計算するのがプロのコツです）。
—
2-2. 実際に計算してみよう（実践シミュレーション）
例えば、次のような環境を想定してみましょう。
- 監視対象（アクティブタイムシリーズ数）: 50,000 個
- スクレイプ間隔（`scrape_interval`）: 15秒（＝1分間に4回）
- データ保持期間（Retention）: 30日間（＝2,592,000秒）
Step 1: 1秒あたりの収集サンプル数（Ingestion Rate）を求める
$$50,000 \text{ 個} \div 15 \text{ 秒} \approx 3,333.33 \text{ サンプル/秒}$$
Step 2: 30日間の総サンプル数を求める
$$3,333.33 \text{ サンプル/秒} \times 2,592,000 \text{ 秒} = 8,640,000,000 \text{ サンプル}$$
Step 3: 容量を計算する（1サンプル＝2 Bytesと仮定）
$$8,640,000,000 \text{ サンプル} \times 2 \text{ Bytes} = 17,280,000,000 \text{ Bytes} \approx \mathbf{17.28 \text{ GB}}$$
さらに、WAL領域やインデックスオーバーヘッド、一時的なCompaction用の作業領域として1.3倍〜1.5倍の安全係数を掛けます。
$$17.28 \text{ GB} \times 1.5 \approx \mathbf{25.92 \text{ GB}}$$
したがって、この環境では約26 GBのディスク容量を確保すれば安全ということが分かります！
> 💡 先輩からのワンポイントアドバイス：高カーディナリティ（Label Explosion）に注意！
> ユーザーIDやタイムスタンプ、ランダムなHashなどをメトリクスの「ラベル」に付与してしまうと、タイムシリーズ数が数百万単位に跳ね上がり、計算の前提が崩壊します。「カーディナリティ爆発」を防ぐことが、最大の容量節約術です。
—
第3章：データ保持期間（Retention）の実践的な設定変更と確認
Prometheusのデフォルトのデータ保持期間は「15日間」です。これを自分の環境に合わせて変更する方法を解説します。
Prometheusでは、「時間制限（Time）」と「サイズ制限（Size）」の両方を指定できます。「どちらか一方に達した時点で古いデータから削除される」という挙動になるため、両方を設定するのがベストプラクティスです。
3-1. 設定パラメータ（フラグ）の種類
PrometheusのRetention設定は `prometheus.yml` ではなく、Prometheusプロセスの起動オプション（CLIフラグ）として渡します。
- `–storage.tsdb.retention.time`: 保存期間（例: `30d`, `2w`, `6h`）
- `–storage.tsdb.retention.size`: 最大保存容量（例: `50GB`, `500GiB`）
—
3-2. 実践セットアップ（Docker Compose & Systemd）
それでは、実際の環境で設定してみましょう！
パターンA: Docker Compose を使用する場合
`docker-compose.yml` の `command` セクションにフラグを追加します。
version: ‘3.8’
services:
prometheus:
image: prom/prometheus:v2.47.0
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
command:
- ‘–config.file=/etc/prometheus/prometheus.yml’
- ‘–storage.tsdb.path=/prometheus’
# ▼▼ データ保持期間とサイズの制御設定 ▼▼
- ‘–storage.tsdb.retention.time=30d’ # 30日間保持
- ‘–storage.tsdb.retention.size=40GB’ # 最大40GBまで（溢れる前に自動削除）
# ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲
ports:
- “9090:9090”
restart: always
volumes:
prometheus_data:
パターンB: Linux (systemd) で直接動かしている場合
`/etc/systemd/system/prometheus.service` の `ExecStart` を編集します。
[Unit]
Description=Prometheus Time Series Collection and Processing Server
Wants=network-online.target
After=network-online.target
[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
–config.file=/etc/prometheus/prometheus.yml \
–storage.tsdb.path=/var/lib/prometheus/data \
–storage.tsdb.retention.time=30d \
–storage.tsdb.retention.size=40GB
[Install]
WantedBy=multi-user.target
設定変更後は `sudo systemctl daemon-reload && sudo systemctl restart prometheus` で再起動します。
—
3-3. 動作確認（HelloWorld的アプローチ）
設定が正しく反映されたか、Prometheus自身のメトリクス（自己監視機能）を使って確認してみましょう！
PrometheusのWeb UI ( http://localhost:9090 ) を開き、`Status` -> `Command-Line Flags` を選択します。
起動フラグとして指定した値が表示されていれば設定完了です。
また、PromQLを使ってメトリクスから直接確認することも可能です。検索窓に以下を入力して実行してみてください。
設定された最大ストレージバイト数を確認するメトリクス
prometheus_tsdb_retention_limit_bytes
現在のTSDBブロックが占有している実際のバイト数
prometheus_tsdb_storage_blocks_bytes
`prometheus_tsdb_storage_blocks_bytes` の値が `prometheus_tsdb_retention_limit_bytes` に近づくと、自動的に古いブロックが削除され、上限を超えないように制御される様子が観測できます。これでディスクフルの恐怖から完全に解放されましたね！
—
第4章：長期保存（Thanos / Cortex）への移行タイミングの見極め
ローカルTSDBの設定を極めても、Prometheus単体でのデータ保存には物理的な限界が訪れます。
「じゃあ、いつ外部の長期保存ソリューションに移行すべきなの？」という疑問にお答えします。
4-1. Prometheusローカルストレージの限界
Prometheusの単体運用では、次のような要件が出てきたときに限界を迎えます。
1. 数ヶ月〜数年単位の長期トレンド分析を行いたい（ローカルDiskが高価かつ巨大化しすぎる）
2. 複数のPrometheusをまとめて横断検索したい（マルチクラスタ運用）
3. Prometheusがダウンしても過去のメトリクスを閲覧したい（単一障害点の排除）
4. 長期間のデータを高速表示するための「ダウンサンプリング」がしたい
—
4-2. 移行タイミングのチェックリスト
以下の項目のうち2つ以上当てはまる場合は、Thanos や Cortex (Amazon Managed Service for Prometheus / Grafana Mimir) への移行タイミングです！
| 判断基準 | ローカルPrometheus運用 | Long-term Storage (Thanos等) へ移行 |
| :— | :— | :— |
| 保存期間 | 15日 〜 1ヶ月程度 | 3ヶ月以上〜数年単位 |
| ディスク容量 | 100GB以下でおさまる | 数百GB〜数TB以上に達する |
| Prometheusの数 | 1〜2台程度 | 多数のクラスタ／環境に分散 |
| ダウンサンプリング | 不要（生の粒度のみでOK） | 必要（5分/1時間単位に集約して長期描画を高速化） |
—
4-3. 代表格「Thanos」のアーキテクチャ概要
長期保存の最も一般的な解であるThanosは、既存のPrometheusに Thanos Sidecar を添える形で簡単に導入できます。
[ Prometheus ] <---> [ Thanos Sidecar ]
|
| (2時間ごとにブロックを転送)
v
[ S3 / GCS (オブジェクトストレージ) ]
^
| (長期保存・ダウンサンプリングデータの参照)
[ Grafana ] <------ [ Thanos Query ]
- 高コスト効率: メトリクスデータを安価なクラウドストレージ（Amazon S3やGoogle Cloud Storage）へ自動でアップロードします。
- 無制限の保持期間: オブジェクトストレージの容量制限がないため、何年分でもデータを保持可能です。
- 透明性: PromQLの互換性が保たれるため、Grafana側のダッシュボードの設定を変更せずにそのまま長期データへアクセスできます。
まずはPrometheusのローカルRetentionを「7日〜14日」程度と短めに設定し、それより古いデータはThanos経由でS3へ退避させる、というのが現代の最高峰のアーキテクチャパターンです。
—
まとめ：堅牢な監視基盤を手に入れたあなたへ
今回は、Prometheusのストレージ運用における最重要ポイントをお伝えしました。最後におさらいをしておきましょう。
1. TSDBの仕組み: 2時間ごとのブロック単位で圧縮・保存され、メトリクスは軽量。
2. 容量試算: `保持期間 × 1秒あたりのサンプル数 × 2 Bytes` + 余裕分でディスクサイズを試算する。
3. Retention設定: `–storage.tsdb.retention.time` と `size` の両方をフラグで明示的に指定してディスクフルを防止する。
4. 長期保存の壁: 1ヶ月以上の保存やTB級のデータになったら、無理せず Thanos や Cortex / Mimir への移行を検討する。
Prometheusのストレージ管理は、仕組みさえ分かってしまえば決して怖いものではありません。
正しく設定されたPrometheusは、あなたとチームのシステムを24時間365日、強力かつ静かに守り続けてくれます。
ぜひ今日から、ご自身の環境のPrometheusのRetention設定と容量試算を見直してみてくださいね。毎日の運用監視が、今よりもっと楽に、そして楽しくなりますよ！
それでは、良いオブザーバビリティライフを！