ほとんどのデータエンジニアリングチームにとって、パイプラインの信頼性を管理することは、アラートを待ち、分散したジョブやクラスタにまたがる障害を手作業で追跡し、業務影響が出た後に問題を修正することを意味しがちです。エージェント型AIには、データがそこにあり、きれいで、適切なタイミングで揃っている必要があります。サイレントに失敗するパイプライン、あるいは古いデータを提供するパイプラインは、ダッシュボードを壊すだけではありません。それに依存するAIシステムそのものを壊します。
そのギャップに対して、シカゴ拠点のデータパイプライン運用スタートアップであるDefinityが取り組んでいるのが、パイプライン実行の「最中」にエージェントをSparkまたはDBTドライバ内に直接埋め込み、実行後ではなく実行中に動かすというアプローチです。Definityによれば、あるエンタープライズ顧客は導入初週に最適化の機会の33%を特定し、トラブルシューティングおよび最適化の工数を70%削減しました。同社はまた、顧客が複雑なSparkの問題を最大10倍の速さで解決できると主張しています。
「エージェント型のデータ運用には、3つの大きな要素が必要です。リアルタイムで、かつ本番を意識した“フルスタックの文脈”です。パイプラインの制御。さらに、フィードバックループで検証する能力。その3つがなければ、外から眺めて読み取り専用になってしまうだけです」──DefinityのCEO兼共同創業者であるRoy Daniel氏は、VentureBeatの独占インタビューでそう語りました。
同社は水曜日、GreatPoint Venturesがリードし、Dynatraceおよび既存投資家のStageOne VenturesとHyde Park Venture Partnersが参加するSeries Aで、1,200万ドルを調達したことを発表しました。
なぜ既存のパイプライン監視はスケールすると破綻するのか
既存のツールは、問題を実行レイヤの外側からアプローチします。たとえば昨年、データ品質モニタのMetaplaneを買収したDatadog、Databricksのシステムテーブル、Unravel DataやAcceldataのようなプラットフォームはいずれも、ジョブが完了した後にメトリクスを読み取ります。Dynatraceにも監視機能はありますが、それはDefinityのSeries Aにも参加していました。
Definityのアプローチは、ソリューションのアーキテクチャの作り方において、他の選択肢と差別化されています。Daniel氏によれば、それはつまり、監視ツールが問題を可視化した時点では、すでにパイプラインは実行されており、失敗や無駄な計算（compute）、不正確なデータといった問題は、すでに下流へ流れてしまっているということです。
「いつも事後なんです」Daniel氏は言いました。「何かが起きたと分かったときには、すでに起きているんです。」
Definityの“実行中インライン”エージェントはどう機能するか
中核となるアーキテクチャ上の違いは、エージェントが“どこに座るか”です。パイプラインの外から監視するのではなく、パイプラインの中に配置します。
インライン計測（instrumentation）。 Definityのシステムは、コード1行によってパイプライン実行レイヤの直下にJVMエージェントをインストールし、プラットフォームレイヤより下で動作しながら、実行データをSparkから直接取り出します。
実行中のコンテキスト。 エージェントは、パイプラインが走っている最中に、クエリ実行の挙動、メモリプレッシャー、データスキュー、シャッフルパターン、インフラ利用状況を取得します。また、パイプラインとテーブル間の系譜（ラインエージ）も動的に推論します。事前に定義されたデータカタログは不要です。
観察だけでなく介入する。 エージェントは実行途中でリソース配分を変更したり、悪いデータが伝播する前にジョブを停止したり、上流側のデータ状況に基づいてパイプラインを事前にプリエンプト（中断・打ち切り）したりできます。Daniel氏は、ある本番導入事例として、エージェントが上流ジョブがプリエンプトされており、書き込むはずだった入力テーブルが古い（stale）ことを検知したため、下流パイプラインが起動する前に停止し、悪いデータが依存するいかなるシステムにも到達する前に止められたケースを説明しました。
リアルタイムとは何で、何ではないのか。 検知と予防（防止）はリアルタイムです。根本原因の分析と最適化の推奨は、エンジニアがアシスタントに問い合わせたときにオンデマンドで実行されます。その際、実行のコンテキストはすでに組み立てられています。
オーバーヘッドとデータ所在。 エージェントは、1時間の実行につき約1秒分の計算オーバーヘッドを追加します。外部に送信されるのはメタデータのみで、メタデータを境界の外へ出せない環境向けにフルのオンプレミス導入も提供されています。
本番環境での「実行中インテリジェンス」とは何か
Definityプラットフォームの初期ユーザーの1つが、ネクセン（Nexxen）です。ミッション・クリティカルな広告ワークロード向けに、大規模なSparkパイプラインをオンプレミスで稼働させている広告テクノロジープラットフォームです。
Nexxenでデータエンジニアリング担当ディレクターを務めるDennis Meyer氏は、VentureBeatに対し、直面していた主要な課題はパイプラインの失敗そのものではなく、弾力的なクラウド容量で無駄を吸収できない環境において、非効率が積み重なっていくことによるコストだったと語りました。
「最大の課題は、パイプラインが壊れることではなく、ますます複雑で大規模な環境を管理することでした」Meyer氏は言いました。「オンプレミスで運用しているため、即時の“弾力性”の柔軟さはありません。そのため非効率が、直接的にコストへ影響します。」
既存の監視ツールはネクセンに対して部分的な可視性を提供していましたが、体系的に行動へつなげるには不十分でした。「既存の監視ツールは導入していましたが、ワークロードの挙動を全体として理解し、最適化の優先順位付けを体系的に行うには、フルスタックの可視性が必要でした」とMeyer氏は述べています。
Nexxenは、パイプラインのコード変更なしでDefinityを導入しました。Meyer氏によれば、チームは最初の1週間のうちに最適化機会の33%を特定し、トラブルシューティングおよび最適化にかかるエンジニアリング工数は70%減少しました。さらに、このプラットフォームによりインフラ容量が解放され、追加のハードウェア投資なしにワークロードの成長を支えられるようになりました。
「重要な転換点は、反応的なトラブルシューティングから、能動的で継続的な最適化へ移ったことでした」Meyer氏は言いました。「スケールするほど、大きなギャップはツールではなく、“実行可能な可視性”であることが多いのです。」
エンタープライズのデータチームにとって、これは何を意味するか
本番のSpark環境を運用するデータエンジニアリングチームにとって、反応型の監視から“実行中インテリジェンス”への転換は、アーキテクチャ面および組織面の双方において、検討に値する影響を伴います。
パイプライン運用（ops）が、AIインフラの問題になりつつある。これまで分析を支えてきたデータパイプラインは、今や、直接的な業務依存を伴うAIワークロードも担うようになっています。これまで単なる手間だった障害は、いまや本番のAI提供を止めてしまうような存在になっています。
トラブルシューティングにかかる時間は、回復可能なコストです。 「Definityを導入した後、Nexxenではトラブルシューティングと最適化に関するエンジニアリング工数を70%削減できました」とMeyer氏は述べています。体力の少ないチームにとって、その時間をロードマップに取り戻せることは、このカテゴリを評価するための最も直接的な近い将来の判断材料になります。
