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氏は語ります。

課題 #1: 「スナップショット」ブロック #

稼働中の ClickPipe に新しいテーブルを追加すると、新しいテーブルのスナップショットを取る間、パイプ全体が CDC ストリーミングを一時停止してしまいます。新しいテーブルを頻繁に追加する Spyne では、これが分析ダッシュボードの遅延やリアルタイムデータフローの中断につながっていました。

解決策は、ClickPipes を慎重に設計することでした。Abhash とチームは、常時リアルタイム分析が必要な大規模な履歴テーブル(最重要のもの約10個)を専用の ClickPipes に切り分けました。新規テーブルや優先度の低いテーブルは別グループにまとめることで、スナップショットによる停止が発生しても本番の分析には影響が及ばないようにしたのです。

課題 #2: ReplacingMergeTree の「一貫性の罠」 #

ClickPipes は効率的なデータ取り込みと重複排除のために、ClickHouse の ReplacingMergeTree エンジンを利用しています。強力な仕組みではあるものの、結果整合性(eventual consistency)という概念が持ち込まれ、Abhash によればチームは当初これに戸惑ったといいます。

これはつまり、行が更新されると、バックグラウンドのマージによって解決されるまでの間、新旧2つのバージョンが一時的に共存するということです。Spyne のセルフホスト環境では、このプロセスが1分以内に完了するように調整されていました。しかし、ClickHouse Cloud のようなマネージド環境では、そこまでの制御はできません。

チームの解決策は、下流のクエリに FINAL を追加し、バックグラウンドのマージを待つのではなくクエリ時点で重複排除を強制することでした。Abhash が指摘するように、トレードオフはオンデマンドの重複排除による ClickHouse クラスタの CPU 使用率増加ですが、最も重要なダッシュボードで正確な結果が得られることが保証されます。

課題 #3: 「オール・オア・ナッシング」なリカバリのリスク #

ソースデータベースの障害(例: AWS RDS のフェイルオーバー)によってバイナリログが失われると、Abhash が「悪夢のシナリオ」と呼ぶ状況が発生します。すなわち、binlog にギャップが生じて CDC チェーンが切断され、レプリケーションスロットが無効化されてデータフローが停止するのです。

セルフマネージドの Debezium であれば、チームは障害発生の前後の期間のデータのみを再取り込みする、ターゲットを絞った部分的な再同期を実行できました。しかし ClickPipes では、そうした細かなリカバリ制御は利用できません。多くの場合、テーブル全体の再同期が必要になり、Spyne にとってはテラバイト規模のデータの再取り込みを意味し、ingress コストとレイテンシの両方を押し上げることになります。

計画的なダウンタイムであれば、メンテナンスウィンドウの開始前に ClickPipe を一時停止することで binlog ギャップの発生を防げます。ただし計画外の障害(マネージドサービスでは稀だと彼は指摘します)については、きれいな解決策はありません。「それに適応するしかありません」と彼は言います。

エンジニアリングの労力を減らし、データ分析により多くの時間を #

移行全体を通じて、Abhash はトレードオフについて明確に語っています。「セルフマネージドのパイプラインの管理は緻密な制御を可能にしましたが、ClickHouse へのデータ取り込みは非常に手作業的でした」と彼は言います。「ClickPipes への移行によって、運用の労力が解消されました。」

ClickHouse Cloud によって、Spyne は Debezium 設定、Kafka、複雑なスキーママッピングを管理するエンジニアリングの労力を見事に取り除きました。ClickPipes によってスキーマ進化を自動化し、開発速度とデータ整合性を劇的に向上させたのです。さらに、ReplacingMergeTree に合わせてクエリを最適化する方法を習得し、ClickHouse Cloud の従量課金モデルのもとで戦略的にコストを管理する術も身につけました。

Abhash はこう語ります。「Spyne のデータパイプラインで実現できた安定性の向上と大幅な速度改善を考えれば、トレードオフは間違いなくその価値がありました。」