Dzmitry Lazerka、VictoriaMetrics共同創業者 – インタビューシリーズ

Dzmitry Lazerka、VictoriaMetricsの共同創業者は、機械学習、大規模データシステム、可観測性、インフラストラクチャに深い専門知識を持つベテランソフトウェアエンジニア兼テクノロジーリーダーです。2018年にVictoriaMetricsを共同設立する前は、LyftのLevel 5自律走行車部門で機械学習エンジニアとして勤務し、実世界の走行シナリオを認識・分析するシステムの開発に携わっていました。それ以前は、Spire Globalで機械学習とデータインフラストラクチャのプロジェクトを主導し、Bellgramのエンジニア共同創業者として、またEPAM Systemsを通じてDuetto ResearchやGoogleでデータ・分析システムに取り組みました。キャリアを通じて、Lazerkaは自律走行、海上予測、検索、分析、分散データ処理、そして高スケーラビリティを持つバックエンドシステムにわたるプロジェクトを構築・リードしています。

VictoriaMetricsは、運用データの収集、保存、クエリ、分析のためのツールを提供するオープンソースの可観測性企業です。その技術は、スケーラビリティ、迅速なクエリ、効率的なストレージ、低い運用負荷を実現する高性能時系列データベース兼モニタリングソリューションであるVictoriaMetricsから始まり、現在ではVictoriaMetrics、VictoriaLogs、VictoriaTracesを通じてメトリクス、ログ、分散トレースをカバーする包括的な可観測性スタックへと拡大しています。同社はエンタープライズ向けおよびフルマネージドのクラウドデプロイも提供し、時系列データに機械学習を適用した異常検知機能も備えています。プラットフォームはOpenTelemetry、Prometheus互換ワークフロー、Grafana、Kubernetesなどの技術をサポートし、組織が既存の可観測性環境にVictoriaMetricsを柔軟に統合できるようにしています。

VictoriaMetricsを共同設立する前、Google、Spire Global、Lyftの自律走行部門、その他のスタートアップで大規模データ、分析、機械学習システムに取り組んできました。最終的にVictoriaMetricsを創業しようと思ったきっかけは何ですか？また、これらの以前の役割で直面したどのような課題が、モニタリングと可観測性には根本的に異なるアプローチが必要だと確信させたのでしょうか？

私はキャリアを通じて大量のデータを扱ってきました。Google、Spire、Lyft、その他の企業では、ある規模でうまく機能するものが別の規模になるとコストがかかったり運用が難しくなったりすることをすぐに実感します。モニタリングもまさに同じ問題を抱えています。

インフラが拡大するにつれて、メトリクスが増えます。サービスやインスタンス、ラベルを増やすうちに、いきなりモニタリングシステム自体が大量のインフラを必要とするようになり、私たちにとっては納得できませんでした。プロダクション環境を監視するために設計されたシステムが、より複雑で高コストになるべきではありません。

これは、共同創業者のAliaksandr ValialkinとRoman Khavronenkoが直接目にしたことです。彼らはPrometheusの運用経験があり、メモリ制限に直面したことがあります。Thanosのようなシステムを追加すればスケーリングの問題の一部は解決しますが、同時にコンポーネントが増え、運用の複雑さも増します。また、InfluxDBでは、ライセンス変更が技術への投資が進んだ後のエンジニアリング判断にどのように影響するかを目の当たりにしました。

そこでVictoriaMetricsの背後にある考えは実用的でした。はるかに少ないリソースで同じ仕事をこなし、運用がシンプルな時系列データベースを構築できないか、ということです。

私たちは大規模な可観測性企業を作る計画から始めたわけではありません。エンジニアリング上の課題を解決することから始めました。

それをオープンソースにしたのもその一環です。エンジニアはVictoriaMetricsをダウンロードし、実際の本番ワークロードを掛けて自分で結果を比較できます。私たちが「速い」や「効率的」だと伝える必要はありません。彼ら自身が測定できるのです。

これがインフラソフトウェアを構築する最良の方法です。技術が優れていれば、エンジニア自身がそれを実証できるはずです。

可観測性のコストは、企業のクラウド料金のかなりの部分になることがあります。これらのコストが通常どこで制御不能に陥り、エンジニアリングチームが最も頻繁に間違えるアーキテクチャ上または購入上の決定は何でしょうか？

まずカーディナリティを見るべきです。

たとえば、妥当なメトリクスから始め、ラベルに可能な値を追加すると、突然1つのメトリクスが数千、数百万ものユニークな時系列になることがあります。システムは取り込むデータ、インデックス、保存、クエリが増え、CPU、メモリ、ストレージが多く必要になります。

難しい点は、これは誰かが一つの悪い判断をしたから起きるわけではないということです。徐々に起こります。サービス、K8sポッド、顧客、ラベルを増やすたびにコストは倍増します。

二つ目の問題は、すべてのデータを同じ解像度で同じ期間保存することです。すべての可観測性データが同じ価値を持つわけではありません。アラートやSLOに必要なメトリクスは、インシデント時に一度だけ見る大量の診断テレメトリとは異なります。

すべてのデータを同等に扱うと、必要のないプレミアムなインフラやSaaS料金を支払うことになります。

このため、一部の企業は可観測性を購入問題として捉え、どのプラットフォームが今日の導入が最も容易かを問います。私は「テレメトリが10倍に増えたらどうなるか？カーディナリティはどう変わるか？何を保存するのか？どのくらいの期間保存するのか？そしてコストはどうなるか？」といった質問をします。

これらの問題に対するエンジニアリング的解決策があります。たとえば、ストリーミング集計を使えば、すべての生の時系列を保存して後で集計する代わりに、保存前にメトリクスを集約できます。高カーディナリティのワークロードをビジネスクリティカルな監視から分離することも可能です。また、データの価値に応じて保持期間や解像度ポリシーを使い分けることができます。

目的はできるだけ少ないテレメトリを収集することではありません。システムが何をしているかを理解するために十分な情報が必要です。

目的は、追加の価値をもたらさない形でデータを収集、処理、保存するためにリソースを費やすことを避けることです。

可観測性はエンジニアリングシステムです。そのコストもエンジニアリングで設計すべきです。

GrammarlyはVictoriaMetricsを使った概念実証でAWSの請求額が10倍削減されたと述べています。企業がその規模のコスト削減を実現した場合、背後で実際に変化しているのはデータ圧縮、計算リソース要件、ストレージアーキテクチャ、運用の複雑さ、あるいはこれらの要素の組み合わせのどれでしょうか？

それらは組み合わせですが、圧縮とリソースフットプリントが主に働きます。VictoriaMetricsは時系列データ専用の圧縮を使用しているため、同じメトリクスでも汎用データベースに比べてディスク容量のごく一部で済みます。その上、同等の取り込みレートであればPrometheusの4〜5倍軽いRAM使用量、ディスク使用量は最大10倍軽くなります。Grammarlyが概念実証を行った際、AWSの請求額に直接反映されました。なぜなら、単にデータを少なく保存しただけでなく、少数かつ小規模なインスタンスで処理できたからです。

運用の複雑さも重要ですが、より間接的です。多くのチームは可観測性コストを見積もる際、ストレージとコンピュートの項目だけを見て、5コンポーネントからなるThanosスタックを運用するエンジニア時間と、単一バイナリを運用する時間の差を見落としがちです。これは実際の金銭であり、数値化は難しいですが確かにコストです。

Prometheusはクラウドネイティブ監視の基盤となっていますが、組織がスケーラビリティや運用上の制限に直面することがあります。通常、企業が従来のPrometheus展開から別の選択肢を検討し始めるきっかけは何で、VictoriaMetricsが論理的な代替となるのはどのような時ですか？

Prometheus は、単一ノードのスクレイプとアラートエンジンとして構築された目的においては非常に優れています。チームは主に 2 つの壁にぶつかります。1 つは、カーディナリティが単一の Prometheus インスタンスがメモリに保持できる上限を超える場合、もう 1 つは長期保持と複数クラスタにまたがるグローバルクエリが必要になる場合です。これらは Prometheus が単体で実現するように設計されていません。その結果、Thanos や Cortex を追加することになりますが、ここからが運用上の痛みが始まるところです。1 つのバイナリを実行していたのが、コンパクタ、クエリサーバ、ストアゲートウェイなど多数のコンポーネントを持つ分散システムへと変わり、深夜 3 時に障害が発生することもあります。

VictoriaMetrics が論理的な次のステップになるのは、再設計ではなくドロップイン置換であるためです。チームは既存の Prometheus スクレイプ設定を VictoriaMetrics に向けるだけで、すでに作成したすべての Grafana ダッシュボード、アラート、レコーディングルールをそのまま利用できます。移行は設定変更でありプロジェクトではなく、5 つもの新コンポーネントを追加せずにスケールを得られます。

エンジニアリングチームが、大規模でフルマネージドな可観測性プラットフォームが本当に必要か、あるいはオープンソースコンポーネントでより効率的なスタックを構築できるかを再考し始めています。これを可観測性市場全体の構造的シフトと捉えるべきでしょうか？また、オープンソースが従来の価格モデルにどれほど圧力をかけていると考えますか？

これは構造的な変化であり、一時的な予算不足への反応ではありません。可観測性ベンダーはこれまで、取り込みボリュームやホスト数で価格を設定してきましたが、そのモデルは顧客のビジネスが成長するほど支払いが増えるという逆効果をもたらします。企業が成功すればするほど支払額が増え、価格と提供価値に実質的な関係がありません。エンジニアリングチームは自ら計算を始め、自己ホスト型で効率的なオープンソーススタックが方程式を根本から変えることに気付いています。これは、コストがベンダーが管理する計測式ではなく、実際に稼働しているインフラに比例してスケールするためです。

このことは既存ベンダーの価格設定に実質的な圧力をかけます。チームが既存のスクレイプ設定をオープンソース代替に切り替え、機能を失わずに 60〜80% コストを削減できれば、社内での議論は容易です。ホスト単位やカスタムメトリック単位で課金し続けるベンダーは、こうした計算を行わない顧客を失い続けるでしょう。

AI インフラは、GPU という異常に高価な新リソースを方程式に加えます。AI のトレーニングや推論を行う企業は、基本的な GPU 利用率以外に何を監視すべきでしょうか？また、より良い可観測性が直接 AI インフラコストの削減に結びつくポイントはどこでしょうか？

GPU の利用率だけでは十分な情報が得られません。

ダッシュボードで 90% の利用率が表示されても、すべてが順調だと誤解しがちです。実際に知りたいのは「GPU が何をしているか」です。

さらに深く見る必要があります。どの CUDA カーネルが実行されているか？GPU メモリはどのように割り当てられているか？計算ではなくメモリ転送に費やす時間はどれくらいか？必要なときに Tensor Core が使用されているか？GPU がボトルネックなのか、別の場所からのデータ待ちなのか？

GPU は高価な資産です。小さな非効率が数百、数千台の GPU にわたって繰り返されれば、莫大な金額になります。

例えば、データパイプラインが十分に速く供給できず GPU が待機状態になる場合、GPU を増やしても問題は解決しません。ボトルネックを特定する必要があります。メモリでも同様です。ワークロードが非効率にメモリを割り当てている場合、可視性が向上すればエンジニアはバッチサイズを調整したり、同一ハードウェア上でより多くのワークロードを走らせることが可能になります。

ここで AI インフラにおける可観測性が面白くなるのです。単に何かが壊れていることを検知するだけでなく、どこで計算資源を無駄にしているかを示すことができます。

この監視自体が可観測性の課題を生み出すこともあります。GPU は大量かつ高カーディナリティなテレメトリを生成します。すべてを収集して高価な SaaS プラットフォームに直接送ると、GPU コストは削減できても、監視データの保存にその分のコストが再びかかります。これは適切な最適化とは言えません。

OpenTelemetry や OpenLIT といったプロジェクトを活用すれば、GPU ワークロードの可視性をはるかに深められます。その上で VictoriaMetrics を使えばデータを集約し、不要な次元を除去し、エンジニアが本当に必要とする情報だけを効率的に保持できます。

有用な質問は「GPU の利用率はどれくらいか？」ではありません。

それは「支払っている GPU からどれだけ有用な作業が得られているか？」です。

この問いに答えられれば、エンジニアリングやコストに関するより良い意思決定が可能になります。

AI エージェントは、従来のソフトウェアとは全く異なる可観測性課題を生み出します。単一のリクエストがモデル呼び出し、ツール使用、ベクトルデータベースクエリ、ハンドオフ、さらには長い自律的アクションチェーンを引き起こす可能性があるからです。エンタープライズアプリケーションがエージェント指向に進むにつれ、可観測性はどのように進化すべきでしょうか？

従来の可観測性は、リクエストがインフラを比較的予測可能な経路で通過すると想定しています。エージェント指向のワークロードはそうではありません。単一のエージェントがモデルを呼び出し、次にツールを呼び出し、さらに別のモデルを呼び出して 3 回リトライした後に初めて結果を返すことがあります。その各ステップに対して個別の可視性が必要です。

失敗モードも異なります。従来のサービスは正しく応答するかしないかの二択ですが、エージェントは成功応答でも結果が間違っていたり、遅かったり、コストが高すぎたりすることがあり、これらは稼働率向上用のダッシュボードに典型的なエラーとしては現れません。

チームが予想外に直面するのはカーディナリティです。単一のエージェントワークフローは、特定のユーザー、プロンプト、ツール呼び出しに紐づくメトリクスを生成し、その量は特に再帰ループで同じツールを何度も呼び出す場合に急速に増加します。エージェント指向ワークロードを観測するシステムは、コスト曲線が急上昇しないようにその規模に耐えなければなりません。これが私たちが解決しようとしている課題です。メトリクス、ログ、トレースは依然として正しい構成要素ですが、変えるべきはそれらのボリュームとコストモデルです。

VictoriaMetrics は異常検知に機械学習や AI 補助ワークフローも導入しています。現在、AI が本当にモニタリングやインシデント対応を向上させられる領域はどこで、どこまでが人間の判断に依存すべきだと考えますか？

アイデアの創出、実装の指揮、結果の検証に人間を関与させ続けることが重要です。言い換えれば、従来のワークフローと本質的に変わっていません。変わったのは、解決策を生成する能力が増幅されたことです。誰でもソフトウェアを作れるようになりましたが、受け入れ基準を下げるべきではなく、むしろ大幅に引き上げるべきです。

AI が真に役立つのは、ノイズの中で人が見落としがちな外れ値やトレンドを浮き彫りにする点です。VictoriaMetrics ではシンプルな社内 AI ポリシーを持っています。従業員は好きなようにワークフローを自動化できるが、最終結果に対しては責任を負う。これは顧客の本番環境での異常検知に適用する基準とほぼ同じです。モデルがフラグを立てても、意味と対処は人が判断しなければなりません。

VictoriaMetrics はオープンソースを維持し、従来のベンチャー資金調達型インフラスタートアップモデルではなく、自己資金・顧客資金で運営しています。このアプローチは製品開発、価格設定、どの技術をオープンソースに残すかの判断にどのような影響を与えましたか？

自己資金で運営することは、想像以上にインセンティブ構造を変えます。特定の四半期までに ARR を達成しなければならない取締役会がいないため、通常伴うトレードオフ、例えばオープンソース版を意図的に機能制限して有料プランへ誘導したり、InfluxDB や HashiCorp がクラウドプロバイダーからの収益保護のためにライセンスを変更したようなことを迫られることがありません。VictoriaMetrics の OSS は現在 Apache 2.0 ライセンスで提供されており、変更する計画はありません。

オープンソースとして残すものの判断基準はシンプルです。エンジニアが本番データを信頼して預けられるコアエンジンはオープンなままにします。規模が大きくなり、責任ある体制が必要になった企業向けには、マルチテナンシー、エンタープライズ認証、コンプライアンスサポート、CVE SLA、そしてサポートキューではなくコードを書いたエンジニアへの直接アクセスといった機能に対して課金します。顧客資金で運営しているため、ロードマップは実際に本番で直面している課題に基づいて決まり、ピッチデックで資金調達できるかどうかでは決まりません。

メトリクス、ログ、トレース、AI アプリケーションのテレメトリ、GPU 監視、そして自動異常検知がますます統合されていく中で、今後数年でオブザーバビリティスタックはどのようになると考えますか？また、プラットフォームに求められるエンジニアリングチームの期待は何でしょうか？

スタックは単一製品として統合される前に、運用面で収束します。この違いは重要です。多くのチームは、すべてを一つの UI でロックするモノリシックなプラットフォームを望んでいません。求めているのは、メトリクス、ログ、トレースが同一の運用モデル、同一ベンダー、同一ライセンス体系で動作し、必要に応じて各シグナルを個別に運用できることです。これが VictoriaMetrics が目指す方向です。すべてを単一バイナリに詰め込もうとしているわけではなく、3 つのシグナルが同じエンジンと同等の効率特性を共有することを目指しています。そのため、2 番目や 3 番目のシグナルを追加しても、別々の運用上の負担を増やすことにはなりません。

継続的に価値を保つプラットフォームは、AI テレメトリや GPU 監視を同一モデルに取り込み、コスト曲線が崩れないものです。AI ワークロードは、従来のメトリクス単位やホスト単位の価格設定では想定されていなかった大量のテレメトリを生成します。その結果、チームは必要なデータの収集をやめるか、オブザーバビリティ費用が AI 投資額を上回って増大してしまいます。エンジニアリングチームは、ワークロードが拡大するたびに再設計や再交渉を求められることなく、インフラ全体と同様にスケールできるプラットフォームを期待するでしょう。

素晴らしいインタビューをありがとうございました。詳しく知りたい読者は VictoriaMetrics をご覧ください。