Part 5-2. Prometheusのハイアベイラビリティ・リテンション戦略 ​

導入部 ​

Part 5-1 で性能チューニングの方法を習得しました。このセクションでは、Prometheus 環境を本番レベルで継続して稼働させるためのハイアベイラビリティ構成とリテンション戦略を解説します。

メトリクスデータは監視基盤の生命線です。障害が発生してもデータが失われず、長期的に安定して保管できる体制は、本番運用において欠かせません。HA構成の選択、適切なリテンション設定、バックアップ計画を段階的に実装することで、データ保護と運用継続性を大きく向上させられます。

HA構成パターン比較 ​

Prometheus を冗長化する方法はいくつかあります。環境規模と要件に応じて最適なパターンを選択することが重要です。

パターン 1：Prometheus 複製構成 ​

最もシンプルな高可用性手法です。複数の独立した Prometheus インスタンスが同じターゲットをスクレイプします。

メリット：構成が単純、運用負荷が低い、各インスタンスの管理が独立している

デメリット：各インスタンスがディスク容量を消費する、長期データ保存が非効率、クエリ結果が重複

推奨シーン：中規模環境（100～500 ターゲット）、単純な冗長性のみが要件の場合

実装例：Prometheus の起動フラグは通常と同じですが、異なるポート番号で起動します。

bash
# インスタンス 1（ポート 9090）
prometheus --config.file=/etc/prometheus/prometheus.yml \
  --web.listen-address=:9090

# インスタンス 2（ポート 9091）
prometheus --config.file=/etc/prometheus/prometheus.yml \
  --web.listen-address=:9091

クエリル（Nginx など）は、複数インスタンスに負荷分散します。ただし、クエリ結果の統合はクライアント側で実装する必要があります。

パターン 2：Thanos を使用した HA 構成 ​

大規模環境や長期データ保存を考慮する場合、Thanos は推奨アーキテクチャです。Prometheus インスタンスに Sidecar を附与し、ローカルストレージを外部ストレージ（AWS S3、Google Cloud Storage など）に自動バックアップします。Query コンポーネントが複数の Prometheus インスタンスを統一的にクエリします。

メリット：データを統一的に管理、長期保存が容易、複数 Prometheus インスタンス間のクエリが透過的、古いデータの自動圧縮

デメリット：構成が複雑、外部ストレージ（S3 など）の運用が必須、初期構築に時間がかかる（1～2 週間）

推奨シーン：大規模環境（500 ターゲット以上）、長期データ保存、複数データセンター間の統合、クラウド環境

最小構成の実装例：

Thanos Sidecar を Docker Compose で起動する例です。

yaml
services:
  prometheus:
    image: prom/prometheus:latest
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus

  thanos-sidecar:
    image: quay.io/thanos/thanos:latest
    command:
      - sidecar
      - --tsdb.path=/prometheus
      - --prometheus.url=http://prometheus:9090
      - --objstore.config-file=/etc/thanos/objstore.yml
    volumes:
      - prometheus_data:/prometheus
      - ./objstore.yml:/etc/thanos/objstore.yml

  thanos-store:
    image: quay.io/thanos/thanos:latest
    command:
      - store
      - --data-dir=/thanos
      - --objstore.config-file=/etc/thanos/objstore.yml
    volumes:
      - ./objstore.yml:/etc/thanos/objstore.yml
      - thanos_store:/thanos

  thanos-query:
    image: quay.io/thanos/thanos:latest
    command:
      - query
      - --store=thanos-sidecar:10901
      - --store=thanos-store:10901
      - --web.listen-address=:9091
    ports:
      - "9091:9091"

volumes:
  prometheus_data:
  thanos_store:

objstore.yml（S3 アクセス設定）：

yaml
type: s3
config:
  bucket: my-prometheus-bucket
  endpoint: s3.amazonaws.com
  access_key: XXXXXXX
  secret_key: XXXXXXX

パターン 3：VictoriaMetrics（オルタナティブ） ​

Prometheus の代替として、スケーラビリティと高速性を重視する場合の選択肢です。

メリット：Prometheus より高速（10 倍以上のスケーリング）、チューニング不要で大規模対応可能、ディスク容量がより効率的

デメリット：エコシステムが Prometheus より限定的、PromQL の非標準拡張がある、学習コストがある

推奨シーン：超大規模環境（1,000 ターゲット以上）、高頻度スクレイプ（1 秒以下）、Prometheus のパフォーマンス限界に達した場合

構成パターン比較表：

パターン複雑度導入期間運用負荷ディスク効率推奨シーン
Prometheus複製低1～2日低低（重複）中規模、単純冗長性
Thanos（推奨）高1～2週間中高大規模、長期保存
VictoriaMetrics中3～5日中高超大規模、高速処理

リテンション設定ガイド ​

Prometheus のメトリクスデータをどの程度保持するかは、ビジネス要件とストレージコストのバランスで決まります。

時間ベース vs 容量ベースの選択 ​

時間ベース設定 (--storage.tsdb.retention.time=30d)

メトリクスを一定期間（例：30 日）保持します。

bash
prometheus --storage.tsdb.retention.time=30d
  • メリット：運用予測が立てやすい（30 日なら 30 日保持）、規制対応が明確
  • デメリット：ディスク容量が予測しにくい、スクレイプ量が増えると期間が短縮されない
  • 推奨：規制対応（監査ログ保存が法律で定められている）、標準的な本番環境

容量ベース設定 (--storage.tsdb.retention.size=100GB)

ディスク容量を上限に設定し、満杯になると古いデータから削除されます。

bash
prometheus --storage.tsdb.retention.size=100GB
  • メリット：ディスク容量を厳密に制御、ストレージコスト最適化
  • デメリット：保持期間がメトリクス増加に応じて短縮、予測困難
  • 推奨：ディスク容量が限定的な環境、クラウドインスタンス（VM スペック固定）

両方指定した場合：先に達した方が優先されます。

bash
prometheus \
  --storage.tsdb.retention.time=30d \
  --storage.tsdb.retention.size=100GB

リテンション設定の意思決定フロー ​

Docker Compose での実装例 ​

Prometheus 起動時に以下のフラグを指定します。

yaml
services:
  prometheus:
    image: prom/prometheus:latest
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=15d'
      - '--storage.tsdb.retention.size=100GB'

環境別推奨値：

  • 開発・検証環境：1～3 日（素早い反復対応）
  • 本番環境（標準監視）：15～30 日（トレンド分析対応）
  • 本番環境（長期分析）：60～90 日（規制対応やビジネス分析）

バックアップ戦略 ​

メトリクスデータの消失は致命的です。3 つのバックアップ戦略を比較し、環境に応じた選択をしましょう。

方法 1：ローカルバックアップ（定期的なスナップショット） ​

Prometheus データディレクトリを定期的にコピーし、圧縮・保管します。

bash
#!/bin/bash
# Prometheus を一時停止
systemctl stop prometheus

# バックアップ実行（日付付き）
BACKUP_FILE="/backup/prometheus-$(date +%Y%m%d_%H%M%S).tar.gz"
tar -czf "$BACKUP_FILE" /var/lib/prometheus/data

# Prometheus 再起動
systemctl start prometheus

# 7日以上前のバックアップを削除（ストレージ節約）
find /backup -name "prometheus-*.tar.gz" -mtime +7 -delete
  • メリット：実装が単純、復旧が高速（数分）
  • デメリット：ストレージコストが高い、遠隔拠点への保存が困難
  • 推奨：開発環境、小規模本番環境（< 100GB）

方法 2：リモートストレージへのバックアップ（継続的） ​

Thanos Sidecar で AWS S3 や Google Cloud Storage へ自動アップロードします。

  • メリット：継続的で安全、遠隔拠点への自動保存、スケーラビリティ高い
  • デメリット：構成複雑度高、ストレージ料金がかかる（月数万円～）
  • 推奨：大規模本番環境、重要度高いデータ、規制対応必須

実装は Part 5-2 の Thanos 構成例を参照してください。

方法 3：復旧テスト手順 ​

バックアップを定期的に別環境で復旧テストします。

  • [ ] 月 1 回、別サーバーでバックアップを復旧
  • [ ] データの完全性を確認（メトリクス数、タイムスタンプが同じか）
  • [ ] 復旧時間（RTO）を測定し、ビジネス要件を満たしているか確認
  • [ ] ロードバランサー経由でクエリが正常に動作するか確認
  • [ ] アラートルールが復旧後に正常に再評価されるか確認

復旧テストは面倒ですが、実際に問題が発生した際の対応時間を大幅に短縮します。

バックアップ戦略比較表：

戦略複雑度初期投資月額コストRTO推奨シーン
ローカル低小0円数分開発・小規模本番
Thanos+S3高中数万円10分大規模本番・重要度高
ハイブリッド中中数千円10分中規模本番・バランス型

データ量予測と容量計画 ​

スクレイプするメトリクス数の増加を見込んで、事前に容量計画を立てることで、ストレージ追加タイミングを予測できます。

月間ディスク使用量の計算式 ​

月間ディスク使用量（GB）= メトリクス数 × スクレイプ間隔（秒）× 30日秒数 × 1.5バイト / 10^9

具体例として、以下の環境を想定します。

  • ターゲット数：100
  • ターゲットあたりメトリクス数：300
  • スクレイプ間隔：15 秒
  • メトリクス総数：30,000

計算手順：

1. メトリクス総数：100 ターゲット × 300 メトリクス = 30,000
2. 月間サンプル数：30,000 × (30日 × 86,400秒 / 15秒) = 5.184 億サンプル
3. 推定容量：5.184 億 × 1.5 バイト / 10^9 = 約 7.8GB / 月

したがって、15 日保持の場合は約 3.9GB、30 日保持の場合は約 7.8GB のディスク容量が必要です。

グロースシナリオごとの見積もり ​

環境の成長に応じて、複数パターンで予測します。

保守的シナリオ：月 20% 成長を想定

現在: 30,000 メトリクス
6 ヶ月後: 30,000 × 1.2^6 ≈ 64,800 メトリクス
必要容量（30d）：約 23.3GB

標準シナリオ：月 35% 成長を想定

現在: 30,000 メトリクス
6 ヶ月後: 30,000 × 1.35^6 ≈ 110,000 メトリクス
必要容量（30d）：約 47.2GB

積極的シナリオ：月 50% 成長を想定

現在: 30,000 メトリクス
6 ヶ月後: 30,000 × 1.5^6 ≈ 177,000 メトリクス
必要容量（30d）：約 88.8GB

各シナリオから、ディスク増設のタイミングを判断します。

データ保持期間と容量の関係図 ​

次のステップへ ​

このセクションで HA 構成とリテンション戦略が理解できました。次の Part 5-3「トラブルシューティング集」では、本番環境で実際に遭遇する問題と、その診断・対処方法を詳しく解説します。メモリ不足、ディスク満杯、クエリ遅延などの課題に対する実践的な対応フロー、デバッグ手法を習得できます。

前のセクション: Part 5-1. Prometheusの性能チューニング

次のセクション: Part 5-3. トラブルシューティング集（来週公開予定）