Posted inDatabase

VictoriaMetricsの導入・活用ガイド：Prometheusの代替となる高効率な時系列データベース

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Prometheusが高負荷に陥った際のアプローチ

現場でのモニタリング運用において、Prometheusのリソース肥大化は誰もが直面する典型的な課題です。メモリ使用率は85〜90%で高止まりし、500GBのNVMe SSDもメトリクス収集開始からわずか3週間で枯渇。さらに、Grafanaで誰かがレポート用に30日間の時間範囲を指定すると、ダッシュボードのローディングが回り続け、最終的にタイムアウトしてしまいます。

アクティブな時系列（active time series）が200〜300万系列に達したとき、アーキテクチャの抜本的な見直しが迫られます。一般的には、次の3つの選択肢が検討されます。

  • Prometheusのスケールアップ（垂直スケーリング）： サーバーのRAMを32GBから64GB、さらには128GBへと増設し、高価なSSDを追加します。同時に、データ保持期間（retention）を30日から7〜14日程度へと大幅に切り詰める妥協が必要になります。
  • ThanosまたはCortex / Mimirの導入： メトリクスをAWS S3やMinIOなどのオブジェクトストレージへ退避させます。ただし、Sidecar、Store Gateway、Compactor、Querierといった多数のコンポーネントで構成されるクラスタの運用が新たに発生します。
  • VictoriaMetricsへの移行： remote_writeメカニズムを活用し、VictoriaMetricsを長期保存用バックエンド（Long-term storage）として配置します。さらにシステムを簡素化したい場合は、スクレイプエンジン自体をvmagentへ置き換えることも可能です。

3つのスケーリング手法を徹底比較

各アプローチには、インフラコストと運用負荷の観点から明確なトレードオフが存在します。

1. Prometheus単体（垂直スケーリング）

  • メリット： 構成がシンプルで中間コンポーネントがなく、従来通りの使い慣れた設定のみで運用可能。
  • デメリット： 水平スケーリングに対応していません。メトリクス量の増加に伴いサーバー費用が急増します。また、データ圧縮時やヘビークエリ実行時にOOM（Out-of-Memory）によるプロセスダウンが頻発します。

2. Thanos / Cortex / Mimirエコシステム

  • メリット： 安価なオブジェクトストレージを利用することで、ほぼ無制限の容量拡張が可能です。複数のKubernetesクラスタからメトリクスを集約し、単一のエンドポイントから横断検索（Global Query View）できます。
  • デメリット： 多数のマイクロサービスで構成されるためアーキテクチャが極めて複雑です。インフラチームはSidecar、Store、Querier、Compactorの運用保守に追われます。また、Memcached等のキャッシュ層がない場合、S3経由での過去データのクエリ応答が遅くなりがちです。

3. VictoriaMetrics（Single-nodeおよびCluster構成）

  • メリット： Prometheusの5〜7倍に達する卓越したデータ圧縮性能を誇ります。同等負荷におけるRAMおよびCPUの消費量は約1/4に抑制されます。PromQLおよびPrometheus APIとの完全な互換性を備えています。
  • デメリット： Single-node版では単一マシンのディスク容量に依存します。Cluster版を運用する場合は、vmstorage、vminsert、vmselectの3つの独立したコンポーネントを管理する必要があります。

VictoriaMetrics Single-node版を選択すべきケース

アクティブな時系列が200万系列未満、かつ書き込みレートが毎秒50万サンプル未満の規模であれば、VictoriaMetrics Single-node版が最適な選択肢となります。単一のバイナリまたはDockerコンテナを1つ起動するだけで動作し、外部のMySQL/PostgreSQLや複雑なS3バケットの設定も一切不要です。運用負荷を最小限に抑えられます。

実運用のベストプラクティスとして、既存の環境をいきなり破棄してはいけません。現在のPrometheusクラスタをそのまま稼働させつつ、remote_writeを有効にしてメトリクスの複製をVictoriaMetricsへ並行送信します。この状態で1〜2週間テスト運用を行い、RAM消費の劇的な低減とGrafanaクエリの500ms未満での高速応答を確認した上で、完全移行へ踏み切るのが確実です。

VictoriaMetricsの実践デプロイ手順

ステップ1：Docker ComposeによるVictoriaMetricsの起動

Ubuntu環境でサービスを立ち上げるには、Docker Composeを利用するのが最も迅速かつ確実です。以下のdocker-compose.ymlファイルを作成します。

version: '3.8'

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.99.0
    container_name: victoriametrics
    ports:
      - "8428:8428"
    volumes:
      - vmdata:/storage-data
    command:
      - "--storageDataPath=/storage-data"
      - "--retentionPeriod=12m"
      - "--httpListenAddr=:8428"
    restart: always

volumes:
  vmdata:
    driver: local

主要な設定パラメータの解説：

  • --retentionPeriod=12m：データの保持期間を12か月間に設定します。要件に応じて30dや2yのように柔軟に変更可能です。
  • --storageDataPath：ディスク上で時系列データを保持するディレクトリパスを指定します。
  • デフォルトのリッスンポート：8428。

コンテナをバックグラウンドで起動し、稼働ヘルスチェックを実施します。

docker compose up -d
curl http://localhost:8428/health

レスポンスとしてOKが返ってくれば、VictoriaMetricsのデータ受け入れ準備は完了です。

ステップ2：PrometheusからVictoriaMetricsへのデータ転送設定

既存のPrometheusでNode Exporter等をスクレイプしている場合、prometheus.ymlにremote_writeブロックを追記するだけで連携できます。

remote_write:
  - url: "http://10.0.0.10:8428/api/v1/write"
    queue_config:
      max_samples_per_send: 10000
      capacity: 20000
      max_shards: 30

プロセスを再起動することなく、Prometheusの設定を再読み込みします。

curl -X POST http://localhost:9090/-/reload

これで新規データがVictoriaMetricsへ同時に書き込まれるようになります。この段階で、Prometheus側のretentionを2dや3d程度まで短縮し、数十GB単位のディスク容量を即座に解放できます。

ステップ3：Prometheusを使わないメトリクス収集（vmagentの活用）

メモリ消費を根本から削減したい場合は、Prometheusのスクレイプ機能をvmagentに置き換えます。設定ファイルprometheus-scrape.ymlを作成します。

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['10.0.0.1:9100', '10.0.0.2:9100']

  - job_name: 'victoriametrics'
    static_configs:
      - targets: ['localhost:8428']

vmagentコンテナを起動します。

docker run -d \
  --name vmagent \
  -v $(pwd)/prometheus-scrape.yml:/etc/prometheus/scrape.yml \
  victoriametrics/vmagent:v1.99.0 \
  -promscrape.config=/etc/prometheus/scrape.yml \
  -remoteWrite.url=http://victoriametrics:8428/api/v1/write

数十ノード規模を対象としたスクレイプ処理であっても、vmagentのメモリ消費量はわずか35〜50MB程度に収まります。これは通常1〜2GBのメモリを消費するPrometheusと比較して圧倒的な軽量性を誇ります。

ステップ4：Grafanaとの接続およびクエリ実行

VictoriaMetricsはPrometheus APIと完全な互換性を持っています。Grafanaからの接続手順は以下の通りです。

  1. Grafanaにアクセスし、Administration > Data sources > Add data sourceの順に開きます。
  2. タイプとしてPrometheusを選択します。
  3. Prometheus server URLの欄にhttp://<IP_SERVER>:8428/prometheusと入力します。
  4. Save & testをクリックし、正常接続を示す緑色のメッセージ（Data source is working）が表示されることを確認します。

既存のダッシュボードはクエリを修正することなくそのまま動作します。さらに、VictoriaMetrics独自の拡張構文であるMetricsQLを使用すれば、rate_over_timeなどの便利な関数により、断続的なデータの集計処理などをPromQLよりも直感的かつスムーズに実行できます。

実ディスク圧縮性能の検証

内蔵UIにアクセスすることで、メトリクスやストレージ状況を迅速に確認できます。

http://<IP_SERVER>:8428/vmui

また、Linuxホスト側でDockerボリュームの実際の使用容量を直接確認することも可能です。

du -sh /var/lib/docker/volumes/vmdata/_data

圧縮効果の差は測定値に如実に現れます。1億データポイントのサンプルデータセットにおいて、Prometheus TSDBが通常15〜18GBのディスク容量を消費するのに対し、VictoriaMetricsではfloat64値とタイムスタンプに特化して最適化されたZSTD圧縮アルゴリズムにより、わずか2.5〜3.8GB程度で格納できます。過去1年分のモニタリングログを長期保持しつつ、インフラストレージのコストを直接60〜70%削減することが可能です。

Share:
Tags: