SpyneがClickPipesとClickHouse Cloudを活用してCDCパイプラインを簡素化した方法

Spyne は、ディーラーがより速く販売し、よりスマートに顧客と関わることを支援する、AIネイティブの自動車小売テック企業です。同社の2つの主力製品は、ディーラー業務のワークフローの両端をカバーしています。Studio AI は、車両のRAW写真をスタジオ品質の画像、スピン、動画に変換してデジタルショールーム用に加工し、Vini AI は、常時稼働するAI営業アシスタントとして、電話やチャットへの応答、リードの選別、アポイントの予約を担います。

どちらの製品も、正確かつ最新のデータに依存しています。しかし会社が成長し、新機能が追加されるにつれ、そのデータフローを維持する担当チームは、パイプラインを流れるデータの分析よりも、パイプライン自体のメンテナンスにより多くの時間を費やすようになっていました。

2026年1月にグルガオンで開催されたClickHouseミートアップで、DevOpsエンジニアのAbhash Solanki氏は、SpyneがDebeziumとKafkaで構築した自己管理型のセットアップから、サーバーレスの ClickPipes と ClickHouse Cloud へと移行することで、CDCパイプラインをどのようにシンプル化したかを紹介しました。

インフラの運用負荷とスキーマドリフト #

Spyneの旧CDCパイプラインは、Abhash氏の言葉を借りれば「複雑な怪物、OSSツールとカスタム設定が入り組んだクモの巣」でした。

MySQLとMongoDB上のソースデータベースはDebeziumコネクタに流れ込み、Debeziumはバイナリログや操作ログから変更をリアルタイムに読み取ってKafkaクラスタにメッセージとして発行していました。Kafkaクラスタはそれらを自己ホスト型のClickHouseインスタンスに流し、Kafkaエンジンテーブル がストリームを消費して各メッセージを単一のJSONペイロードにフラット化します。そこから、(スキーマ固有の)マテリアライズドビュー がフラット化されたJSONを最終的な ReplacingMergeTreeテーブル(ClickHouseが更新を効率的に扱うための仕組み)に変換していました。

Spyneの旧CDCパイプライン:MySQL/MongoDBのソースがDebeziumコネクタ、Kafkaクラスタ、ClickHouseのKafkaエンジンテーブルとマテリアライズドビューを経由してReplacingMergeTreeテーブルへ流れる。

このアーキテクチャは機能はしていたものの、Abhash氏が言うところの相当な「運用トイル」を生み出し、常に対応が必要で貴重なエンジニアリング時間を消費していました。

最初の大きなボトルネックは、新規テーブルの追加でした。テーブルを1つ追加するたびに手作業のプロセスが発生します。DevOpsチケットの起票、MySQLやMongoDBのデータ型からClickHouse互換のDDLへのマッピング(Abhash氏が「型不一致の悪夢」と呼ぶ、手作業でエラーが発生しやすいプロセス)、Kafkaエンジンテーブルの作成、マテリアライズドビューの作成、Debeziumコネクタ設定の更新、そしてダウンタイムのリスクを伴うパイプラインの再起動、といった具合です。

「新しいテーブルを1つ追加するのに、少なくとも1時間から1時間半の手作業とマニュアルワークが必要でした」とAbhash氏は言います。「新製品のリリースや新しい分析用テーブルを追加するたびに、このサイクルを毎回繰り返す必要がありました」。

しかし、これは最大の悩みではありませんでした。Abhash氏が語る本当の問題は、「スキーマドリフトの悪夢」でした。Spyneのような変化の激しい開発環境では、ソース側のテーブルは頻繁に変更されます。新しいカラムが追加されたり、データ型が変わったりします。それが起きるとDebeziumは変更を忠実に捉え、Kafkaも配信するのですが、下流のマテリアライズドビューは元のDDLに固定されているため、新しいデータを「サイレントに無視」してしまい、データの不整合や、重要な新機能に対する可視性の欠如を招いていました。

このギャップに気づくまでに数日を要することもあり、その後の修正にはパイプラインの停止、マテリアライズドビューと最終テーブルの変更、全体の再起動、そしてしばしばテーブル全体のゼロからの再同期が必要でした。こうした手作業の介入は大きな遅延と誤りのリスクを生み出し、Abhash氏の言葉を借りれば、リリースのたびに「一発勝負のオペレーション」を強いられていたのです。

ClickPipesでシンプルさを手に入れる #

Abhash氏がより堅牢で管理しやすいソリューションを探し始めたとき、遠くまで探す必要はありませんでした。SpyneはすでにClickHouseをセルフホストしており、そのマネージドサービスである ClickHouse Cloud がネイティブの取り込みエンジン ClickPipes を提供していることを知っていたからです。「シームレスなCDC向けに設計された、フルマネージドサービスという約束は魅力的でした」と彼は語ります。

ClickHouse Cloudの効率的で使いやすいUIにより、新しいデータパイプラインのセットアップは今や「わずか数分」で完了します。旧システムでの綿密なDebezium設定やスキーママッピングに比べて、これは歓迎すべき変化でした。「テーブルを1つずつ手作業で追加してスキーマを生成していた人間からすると、それはまるで魔法のように感じました」とAbhash氏は言います。

Spyneの新しいCDCパイプライン。ソースはClickPipesを介して直接ClickHouse Cloudに流れ込む。

彼が挙げる最大の勝因は、「自動化されたスキーマ進化」です。ClickPipesはMongoDBやMySQLなどのソースにおける上流の変更を自動的に検出し、対応するClickHouseテーブルに即座に反映してくれます。手作業の介入もパイプラインの再起動も不要です。この「ゼロタッチのメンテナンス」は開発者のスピードを劇的に向上させ、機能のデプロイやデータ分析を「かつてない速度と信頼性」で行えるようになりました。

道中の課題を解決する #

ClickPipesはチームの主要な課題を即座に解決してくれましたが、Abhash氏は「マネージドサービスは常に魔法というわけではありません…それらにもそれなりのトイルはあります」と即座に付け加えます。ClickHouse Cloudのような高度なプラットフォームでも、内部の仕組みを理解し、運用方法を柔軟に変えていく姿勢が必要だと彼は指摘します。

チームがプラットフォームに習熟していくにつれて、その恩恵を最大限に享受するには、SQLパターンや運用上の注意点を進化させる必要があるようなアーキテクチャ上の細かな挙動や特性にも直面しました。「これは欠点を修正するというよりも、新しいパラダイムに合わせて我々のアプローチを最適化することでした」とAbhash氏は語ります。