VictoriaLogs vs Loki - ベンチマーク結果

TL;DR – 500GB/7日間のワークロードで並行テストを行った結果、VictoriaLogsはクエリのレイテンシを 94 %、ストレージを ≈40 %削減し、Lokiに以前割り当てていたCPUとRAMの50%未満しか使用しませんでした。この記事では なぜ 私たちが切り替えたのかを説明します。

背景と要件

Truefoundryは、開発者がKubernetes上でマルチテナントのMLワークロードを実行するのを支援しています。
開発者には以下のものが必要です。

• 高速なアドホック検索
• 良好な 取り込み レート
• ライブテーリング デバッグのために。
• 運用オーバーヘッドを最小限に抑える – シングルバイナリでのデプロイが望ましい。
• リソース効率が高い での動作 4 vCPU / 16 GiB RAM ノード
• 高い 圧縮 率（保存されたログに対して）
• ブロックストレージ  > S3よりも推奨（オーバーヘッドとレイテンシを削減するため）。+ レイテンシ

Lokiは当初は問題なく機能していましたが、データ量が増えるにつれて、検索レイテンシが30秒を超え、I/O増幅も高くなるという問題が発生しました。これがVictoriaLogsの評価を開始するきっかけとなりました。

Gartner Hype Cycle for Platform Engineering 2026

Access Full 2026 Report

Lokiとは？

Loki は、Grafana Labsのログ集約システムで、ログを圧縮されたチャンクで保存し、 ラベル （キーと値のペア）から構築されたインデックスを伴います。クエリは LogQL で表現され、ラベルフィルタとそれに続くラインフィルタに大きく依存します。

• 強み： Grafanaとの密な連携、低コストなインデックス、水平スケーラブル。
• 当社にとっての制約： ラベルのみのインデックスは、コストのかかるフルスキャン正規表現検索、高いチャンク圧縮I/O、高取り込み時のGo GCオーバーヘッドを意味します。

VictoriaLogsとは？

VictoriaLogs はVictoriaMetricsチームが開発したログデータベースです。カラム型 LSM形式 ストレージと、フィールドごとのインデックス、SIMDアクセラレーション検索、そして SQLライクなLogSQL 構文を採用しています。

• 強み： 全トークンに対する全文インデックス、シングルバイナリ、非常に低いメモリフットプリント、高速なコールドキャッシュスキャン。
• トレードオフ： エコシステムが小さく、組み込み統合が少ない（データは Vectorを経由してパイプしています）。

ベンチマーク手法

クエリスイート

1. 統計 – 過去24時間における、あるフィルターの総行数。
2. 干し草の山の中の針 – 3～4行の静的なログ [UNIQUE-STATIC-LOG] ID=abc123 XYZ ログが大量に存在するネームスペースで、7日間にわたって。
3. ネガティブ – 文字列が しない 存在する (フルスキャンを強制) 7日間にわたって。

🔍 クエリパフォーマンス

1. 統計クエリ (24時間以内のログ数)

目的: からの総ログ行数 app="servicefoundry-server"

2. 干し草の山から針を探すクエリ (7日間、約500 GB)

目的: 内で一意の静的ログ行を検索 truefoundry ネームスペース

3. アプリ再起動ログの一致 (7日間) (ステップ2を検証するための追加クエリ)

目的: 既知の再起動パターンを検索 :3000 ログの小さなサブセット内で (単一のシャードを対象とする)
結果セットは同一であることが確認されました。

4. ログの非存在マッチ (7日間)

目的: 存在しないログを検索し、全データ検索をトリガーする
結果セットは同一であることが確認されました。

500GBの処理データにおいて、Lokiは奇妙な挙動を示しました。リソースが逼迫し、クエリ応答が停止しました。

Loki vs VictoriaLogs: 結果の概要

私たちの評価は、プラットフォームエンジニアにとって日常的に重要な3つの側面に焦点を当てました。

1. どれだけ速く答えを得られるか？
2. その速度を実現するために、どれくらいのリソースが必要か？
3. 実際の負荷状況下で、エクスペリエンスはどれくらい安定しているか？

クエリパフォーマンス

‍

なぜこのギャップが生じるのか？ VictoriaLogsはトークンごとのインデックスを保持しているため、正規表現のようなスキャンでもインデックスが利用されます。対照的にLokiは、ラベルクエリの後に1行ずつフィルタリングを行うため、ラベルセットが広範囲にわたる場合、総当たりスキャンに陥ります。

🌪️ · 取り込みパフォーマンス

また、120のレプリカを使用して取り込みのストレステストも行いました。  flog ジェネレーター。
結果は目を見張るものでした。

Loki:

Lokiは3～4 vCPUに急上昇し、8 GiBの制限に迫り、同じワークロードでスロットリングが見られました。

VictoriaLogs:

👉 主なポイント: VictoriaLogsは達成しました 3倍の取り込み速度 一方で、消費するCPUは 72%削減 そして メモリは87%削減 Lokiと比較して。

VictoriaLogsは、インジェストのバースト時でも、4 vCPU / 8 GiBの制限を余裕を持って下回っています。

2 · リソース使用量（7日間保持）

Loki

メモリ使用量: 常に6～7GBのRAMを使用
CPUピーク: 3 vCPU

‍

VictoriaLogs

メモリ使用量: 800 MB - 900 MB
CPU使用率のピーク: 1.1 vCPU

3 · 実環境負荷 (Locust 2分間実行 @ ユーザー10名 & ランプアップ2)

クエリは同様で、ランダムな制限とランダムな時間範囲を使用し、キャッシュバーストを確実に発生させました。

Victoria Logs

Loki

📌 処理能力は向上したにもかかわらず 36%高いRPS、VictoriaLogsはp95%とテールレイテンシーが低く—そのインデックスモデルが負荷がかかる状況でも機能することを証明しました。 3.6倍 高速化 p99%ile

‍このテストは私たちの決定を裏付けるものでした。VictoriaLogsは理論上速いだけでなく、本番環境のようなワークロードで負荷がかかる状況でも、より優れたスケーラビリティを発揮します。

数値の要約

• 70～94%高速化 一般的な検索パターン全体で。
• 約40%削減 同じ保持期間でディスク上の容量を。
• 計算リソースを半分に削減し、最小ノードで1つのvCPUと約1～2 GiBのRAMを解放。

結論として、ログが多く検索中心のユースケースにおいて、VictoriaLogsはインフラコストを削減しつつ、数分かかっていた質問に数秒で答えられるようにしてくれました。

主な調査結果

1. 全文インデックスが効果を発揮 – VictoriaLogsのトークンごとのインデックスにより、総当たり的な行フィルタリングが不要になります。
2. ストレージレイアウト – カラム型 + LSMにより、ディスク上のサイズとディスクシークが大幅に削減されます。
3. メモリ効率 – ノードあたり約2 GiBのRAMを解放し、より高密度なスケジューリングを可能にしました。
4. 運用の簡素さ – どちらもシングルバイナリですが、VictoriaLogsは 一切 特別な調整なしでこれらの数値を達成できました。

結論

アドホックなテキスト検索が多いワークロードプロファイルにおいて、VictoriaLogsは 桁違いに 高速なクエリと大幅なコスト削減をもたらしました。Lokiは、Grafanaとの緊密な統合とラベル優先のクエリが主流である場合には優れた選択肢であり続けますが、高インジェストで開発者中心のクラスターにとって、VictoriaLogsは今や私たちのデフォルトとなっています。

参考文献

• Loki ドキュメント
• VictoriaLogs ドキュメント
• Promtail ドキュメント
• Vector ドキュメント
• Alloy ドキュメント
• Grafana Alloy コンフィギュレーター

よくある質問

VictoriaLogs と Loki の主な違いは何ですか？

VictoriaLogs と Loki の主な違いは、VictoriaLogs の高度なトークンごとのインデックス作成とカラム型ストレージにあります。これにより、Loki のラベルのみのインデックス作成と比較して、クエリパフォーマンスが大幅に向上し、リソース使用量が著しく削減されます。Loki の場合は、フルスキャン検索が遅くなり、ログ管理の運用オーバーヘッドが高くなることがよくあります。

VictoriaLogs は Loki より高速ですか？

はい、厳密なベンチマークテストにおいて、VictoriaLogs は Loki と比較して優れた速度を示しました。VictoriaLogs と Loki の比較では、VictoriaLogs はクエリレイテンシを 94%削減し、複雑なクエリの検索時間を 12 倍高速化しました。また、取り込みパフォーマンスも 3 倍向上させ、大幅な効率化を実現しています。

VictoriaLogs のデフォルトポートは何ですか？

VictoriaLogs と Loki を評価する際、セットアップの詳細を知ることは役立ちます。VictoriaLogs は通常、デフォルトの HTTP API およびスクレイピングエンドポイントにポート 8428 を使用します。このポートにより、ログデータベースへのアクセスと操作が可能になります。当社のブログはパフォーマンスに焦点を当てていますが、デフォルトポートのようなデプロイの基本を理解することは、システム構成にとって非常に重要です。

VictoriaLogs と Loki のベンチマーク結果はどうですか？

VictoriaLogs と Loki を比較したベンチマークでは、VictoriaLogs が優れたパフォーマンスを発揮しました。クエリレイテンシを 94%削減し、ストレージ使用量を約 40%削減し、割り当てられた CPU と RAM の 50%未満しか消費しませんでした。VictoriaLogs はまた、取り込みスループットが 3 倍高く、非常に効率的であることを示しました。

VictoriaLogs と Loki のどちらが優れていますか？

VictoriaLogs と Loki のベンチマークでは、VictoriaLogs が優れていることが証明されました。クエリレイテンシを 94%削減し、ストレージを 40%削減し、CPU/RAM の使用量を 50%以上削減しました。米国の TrueFoundry は、ML ワークロード管理におけるパフォーマンスと効率の向上を理由に VictoriaLogs を選択しました。