CloudflareのLogpushサービス内で、Transformers機能が一般提供となった。これにより、チームはログを最終的な宛先へエクスポートする前に処理できる。ユーザーはSQLクエリを記述し、ログのフィルタリング、機密データの一部のマスキング、フィールドの追加、名前変更、削除、ネスト構造内での整理を行える。
この機能は、Cloudflareのログをセキュリティ情報・イベント管理（SIEM）システム、分析プラットフォーム、オブジェクトストレージへエクスポートする監視・セキュリティチームを対象としている。ログが到着した後に別のサービスを実行して処理する代わりに、Logpushはエクスポート経路そのものの中で変換を実行する。
実際に何が変わるのか？
ユーザーは、Logpush内の特定のデータセットに対してカスタムTransformerを定義する。WHERE句で不要なログを除外し、SELECT句でエクスポートされるログに表示するフィールドを指定する。結果は元のログと同じくNDJSON形式で保存され、この機能はシリアライゼーション形式自体を変換するツールではない。
例えば、ヘルスチェックのリクエストや内部トラフィックを除外し、IPアドレスの末尾部分をマスキングし、複数のCDNプロバイダー間でフィールド名を統一し、プロバイダー名やサーバーエラーを示すインジケーターなどの固定フィールドを追加できる。エクスポート前にフィルタリングを行うことで、チームがエクスポート、受信、保存の費用を負担した後に廃棄するデータ量を削減できる。
エクスポート経路内での実行
Cloudflareは、外部のネットワークサービスに依存するのではなく、配信サービスBufstream内でクエリを実行する方式を選択した。同社によると、Cloudflare Workersを介してWebAssemblyを実行すると、Logpushの経路にネットワーク接続が追加され、配信時間とスループットに影響するタイムアウトや再試行が発生する可能性がある。
Transformersは、Rustで記述されたApache DataFusionエンジンと、メモリ内でデータをtypedな列として表現するApache Arrowを使用する。Cloudflareが5,000件の合成http_requestsログからなるバッチで実施したテストでは、事前設定済みのTransformerの実行に単一のGoスレッドで約3ミリ秒を要し、毎秒約160万件のログに相当した。
Bufstreamは圧縮されたLogpushバッチを受け取り、対象となるログをArrow RecordBatchに変換した後、Arrow IPCとGo・Rust間のバインディングインターフェースを介してDataFusionへ渡す。クエリの実行後、サービスは結果をNDJSONに戻し、まとめて圧縮し、指定された宛先へアップロードする。
障害時の制御と管理
Transformersはフェイルクローズの原則に従って動作する。変換を実行できない場合、Bufstreamはバッチを未加工の形式で送信せず、配信先への引き渡しも行わない。その代わりに段階的に再試行し、エラーを報告する。また、長時間にわたって失敗状態にあるジョブを停止する場合があり、正常なジョブのリソースを消費しないようにする。
変換は、CloudflareのダッシュボードにあるTransformer StudioまたはAPIを通じて作成、プレビュー、管理できる。更新のたびに新しいバージョンが作成され、Transformer Health画面では、成功・失敗した変換、処理前後のデータ量、実行時間に関する指標が提供される。
なぜこのニュースが重要なのか？
基本的な価値は、単にログサービスへSQLを追加したことではなく、データの削減、統一、マスキングに関する判断をエクスポート前の段階へ移したことにある。これにより、チームが専用の処理レイヤーに依存する必要性は軽減される可能性があるが、クエリのテストとデータスキーマの確認が不要になるわけではない。特に、Transformerが失敗すると、未処理のコピーを通すのではなく、バッチの送信自体が阻止されるためだ。
Transformersは、Free、Pro、Business、Enterpriseの各プランで利用できる。設定の詳細と料金は、Cloudflareの最新のドキュメントに従う。