AI News HubLIVE
サイト内リライト3 分で読了

Cloudflareのデータプラットフォームとその上のAIエージェントの構築方法

Cloudflareは毎秒10億以上のイベントを処理するが、データは分散してアクセスが困難だった。そこで、統合分析プラットフォーム「Town Lake」と、自然言語で質問し監査可能な回答を得られるAIエージェント「Skipper」を構築した。本記事では、プラットフォームのアーキテクチャ、ガバナンス(デフォルトクローズ)、AIエージェントの仕組みを詳述する。

ソースCloudflare AI Blog著者: Brian Brunner

Cloudflareは毎秒10億以上のイベントを処理し、120か国以上の330以上の都市にネットワークを展開しています。すべてのHTTPリクエスト、Worker呼び出し、R2読み取り操作の背後には、大量のデータが存在します。しかし、長年にわたり、このデータへのアクセスは容易ではありませんでした。データは数十の本番データベース、ClickHouseクラスター、Kafkaストリーム、Google Cloudストレージバケット、BigQueryデータセット、そして多数のパイプラインに分散していました。「今日登録されたドメインのうち、トラフィック上位100位に入るのはいくつか?」といった単純な質問に答えるために、アナリストはどのシステムに問い合わせるべきか、どの資格情報を使用するか、どのクエリ言語で記述するか、データがサンプリングされているか、新鮮か、7日経過しているかを把握する必要がありました。その結果、データから有益な洞察を得ることは困難でした。

この問題を解決するために、Cloudflareは2つの内部ツールを構築しました。Town Lake(統合データ分析プラットフォーム)とSkipper(その上で動作するAIデータエージェント)です。Town LakeはCloudflareが知るすべてへの単一SQLインターフェースであり、SkipperはCloudflareの誰もが平易な英語で質問し、数秒以内に正確で監査可能な回答を得る方法です。

問題の形状 データスプロールにはいくつかの典型的な症状があります。システムが多すぎる、データのサンプリング(ダッシュボードには問題ないが、請求などの領域には不適切)、内部データのための外部依存関係、データの発見困難性。さらに、データインフラは従来、ビジネスに奉仕するバックオフィス機能として扱われ、それ自体が重要なインフラとは見なされていませんでした。

私たちが望んだもの 会社内で適切な権限と知る必要性を持つ誰もが、Cloudflareに関する質問への回答を得られる単一の場所を創り出すこと。必要なクエリ(請求やセキュリティ調査など)には新鮮で正確な非サンプリングデータを、不要なクエリ(ダッシュボードや探索など)には高速なサンプリングデータを提供すること。セキュリティとガバナンスを組み込み、PIIを自動検出し、機密テーブルをデフォルトでロックし、すべてのアクセスを監査可能にし、時間制限付きの権限付与を行うこと。プラットフォームはCloudflare自身のプラットフォーム(R2、Workers、Access、Workflows)上に構築すること。そして最終的には、SQLを知らなくても利用できるインターフェースを実現すること。

Town Lakeプラットフォーム 中核となるアーキテクチャはデータレイクハウスです。クエリエンジンがオブジェクトストレージから読み取り、メタデータ層がストレージをデータベースのように動作させます。主要コンポーネントは以下の通りです。

  • クエリエンジン:Apache Trinoを採用。単一のSQLクエリでPostgresテーブル、ClickHouseテーブル、R2上のIcebergテーブルを結合可能。
  • R2データカタログ:Apache Icebergのマネージドサービス。スキーマ進化、タイムトラベル、パーティション進化、データ圧縮をサポート。
  • DataHub:メタデータカタログ。すべてのテーブル、列、所有者、血統を管理。
  • Lifeguard:アクセス制御サービス。D1にルールを保存し、ユーザーとグループのメンバーシップを動的に取得し、TrinoがHTTP経由で読み取る結合JSONポリシーを生成。
  • Skimmer:PII検出スキャナー。Workers AIを使用して列を分類し、2パス(高速分類+エージェント検証)で実行。
  • Transformer:Workflows上に構築されたELTエンジン。ユーザーはSQL変換のDAGをYAMLフロントマターで定義。
  • Ingestion:運用システムからレイクへのブリッジ。

デフォルトクローズ:設計によるガバナンス 従来のアプローチはデフォルトで開かれ、例外で制限するものでした。Town Lakeは逆のアプローチを取ります。テーブルはレビューされるまでクエリできません。新しいテーブルが接続されると、Skimmerが自動的にスキャンし、中央許可リストに「保留中」として登録します。レビュアーが承認するまでユーザーはクエリできません。また、スキーマ発見とデータアクセスは分離されており、未レビューの列はDESCRIBEやSHOW COLUMNS、SELECT *から隠されます。PIIはデフォルトでセッションごとにマスクされ、正当な理由がある場合のみ解除されます。

Skipper AIデータエージェント クエリエンジンだけでは不十分です。SQLは依然として障壁であり、どのテーブルをクエリすべきかを知るのも困難です。Skipperは、自然言語の質問から検証済みの回答に至る会話型AIエージェントです。インターフェースはチャットボックスで、ユーザーが質問すると、Skipperが適切なテーブルを検索し、スキーマと血統を取得し、SQLを記述し、Trinoに送信し、結果を表示します。フォローアップ質問にも対応し、コンテキストを保持してクエリを修正します。Skipperはチャートをダッシュボードにパッケージ化して共有することもできます。すべてのツールはWorkers AIを利用したエージェントハーネスによって提供され、MCPサーバー経由でも利用可能です。

コンテキストの層 LLMはSQLタスクで幻覚を起こす可能性があります。対策として、複数のコンテキスト層を用意しています。スキーマと使用メタデータ、人間による注釈、既知のクエリテンプレート、実行時のフィードバックなどです。将来的には、テーブル間コンテキストウィンドウ、能動的なデータ発見、事実確認の強化などを計画しています。