ClickPipes の MySQL CDC コネクタが一般提供 (GA) を開始

私たち ClickHouse は、適材適所でツールを使い分ける考え方を大切にしています。ClickPipes に初のネイティブな Change Data Capture (CDC) コネクタ (Postgres) をリリースした直後から、分析ワークロードに MySQL では追いつかなくなったユーザーへ同じ体験を届ける取り組みを始めました。OLTP はミッションクリティカルな業務ワークロードの処理に専念させ、複雑な分析クエリ、レポート、ビジネスインテリジェンスのワークロードは OLAP へ移して ClickHouse の速度で処理する、という形です。

難しいのは、まったく異なるソースデータベース向けに新しい CDC コネクタを作るのに決まった型がないことです。機能を揃えて安定させるには、時間だけでなく本番環境での実績も必要になります。数百の本番ユーザーのために1 PB を超えるデータを移した今、MySQL CDC コネクタの一般提供 (GA) 開始を発表します。

「Kit にとって ClickHouse は、他を大きく引き離す最速のデータベースでした。では、アプリケーションが MySQL で動いている場合はどうするか。1 年かけて ETL パイプラインを作り、その後ずっと保守し続けることもできます。あるいは、ClickPipes でボタンを 1 回押せば、本番データに対する分析ワークロードが ClickHouse の速度で動き始めます。副次的な効果として、監査ログとソフトデリートも追加の手間なく手に入ります。」

— Kim MacCormack 氏、Kit シニアエンジニアリングマネージャー

新機能 #

並列スナップショットによる初回ロードと再同期の高速化 #

スナップショットの取得は、CDC パイプラインでデータの整合性を保証するために欠かせない処理ですが、本番インスタンスから数百 GB を処理して取り込むことも珍しくありません。早く稼働を始め、障害からも速く復旧できるようにスナップショットは速く終えたい一方で、上流への影響はできるだけ小さく抑えたいものです。

当初の実装でスナップショットを速くするには、並列処理に乗せる論理パーティションキー列を、特定の型 (数値または日時) から手で選ぶ必要がありました。それ以外のケースは低速なシングルスレッドのスキャンにフォールバックしていました。これはもう過去の話です。ClickPipes はテーブルの主キーから適切な論理パーティションキーを自動的に検出し (文字列型と UUID 型にも対応しました)、処理を分散して既定でスナップショットを速くします。私たちのベンチマークでは、シングルスレッドで 1 日以上かかっていた 1 TB のスナップショットが、32 ワーカーに分散すると約 1 時間で完了しました。

本番環境向けの安全な既定値 #

CDC は繊細な仕組みで、障害モードも多く、完全な再同期をしないとレプリケーションを再開できない状況に容易につながります。このリスクを減らすため、MySQL CDC ClickPipes では次の設定を必須にしました。

• GTID ベースのレプリケーション: MySQL CDC ClickPipes の当初の実装ではこの設定は任意でしたが、新規の ClickPipes では既定になりました。変更の理由は次のとおりです。ファイル位置ベースのレプリケーション は MySQL の旧来の仕組みで、再開位置を特定のサーバー上の (binlog file, offset) に結び付けるため、フェイルオーバー時に壊れ、手作業での対処が必要になります。MySQL v5.6.5 (および MariaDB 10.0.2) からは、グローバルトランザクション識別子 (GTID) に基づく、より信頼性が高くトポロジーに依存しない仕組みが使え、フェイルオーバー後もレプリケーションを自動的に再開できます。

• (最低) 72 時間の binlog 保持: MySQL CDC ClickPipes がレプリケーションを再開できるのは、最後に処理した GTID を含む binlog (バイナリログ) のセグメントがまだパージされていない場合に限られます。障害や長い一時停止の間に binlog が早期にローテーションされ、パイプの再開に必要なセグメントがパージされてしまうことがあります。そのために復旧不能となったエラーを、私たちは数多く観測してきました。ローテーションが起きていなければ避けられたものです。最低 72 時間保持しておけば、セグメントがパージされて完全な再同期を強いられる前に、ClickPipe には最悪ケースの障害から復旧したり、ClickHouse 側のバックプレッシャーを処理したりする余裕が生まれます。

どちらの要件もパイプ作成時に ClickPipes が検証します。新しい ClickPipe を作る前に、ソース側の設定をこれに合わせておく必要があります。稼働中の MySQL CDC ClickPipe でファイル位置ベースのレプリケーションを使っている場合は、GTID ベースのレプリケーションへ移行し、新規の ClickPipes は、新しい既定である GTID ベースで作成することを強くお勧めします。なお、GTID を設定しても、旧来の仕組みを使っている既存のパイプには影響しません。両者は共存できます。

トラブルシューティングを容易にするオブザーバビリティの改善 #

このコネクタは当初から ClickHouse Cloud の操作体験に完全に組み込まれていましたが、CDC ClickPipes のオブザーバビリティは十分ではありませんでした。遅い CDC パイプをデバッグするには、ある程度の推測に頼るか、サポートチケットを起票して、ボトルネックが上流の MySQL、下流の ClickHouse、その間のどこにあるのかを確かめる必要がありました。

GA に合わせて組み込みのメトリクスとモニタリングを拡張し、リソース使用率と**遅延 (ラグ)**も報告するようにしました。次のメトリクスが ClickPipes の UI と ClickHouse Cloud の Prometheus エンドポイント で利用できます。

リソース使用率 #

CDC ClickPipes のスケールが必要になりそうな状況 (例: スナップショット取得中やトラフィックの急増時) を調べる、レプリケーション遅延の根本原因がリソース飽和かどうかを切り分ける、その他の基本的なトラブルシューティングを行う、といった作業をユーザー自身でできるようになりました。

CPU 使用量 (CPU usage): サービス内の CDC ClickPipes 全体に割り当てられた枠のうち、消費しているコア数、つまり pull プロセスと push プロセスが現在使っているコンピュートの量です。

メモリ使用量 (Memory usage): サービス内の CDC ClickPipes 全体に割り当てられた枠のうち、消費しているメモリ、つまり pull プロセスと push プロセスが現在保持している RAM の量です。

ネットワーク受信帯域 (Network receive bandwidth): パイプの受信スループット、つまりソースから毎秒どれだけのデータを取り出しているかです。

レプリケーション遅延 #

データの鮮度と、レプリケーションの遅延がソース側、ClickHouse 側、その間のどこで生じているのかも把握しやすくなりました。

ソース遅延 (Source lag): pull プロセスが MySQL のライブ binlog からどれだけ遅れているか、つまり MySQL で変更が起きてから ClickPipes がそれを取り出すまでの時間です。
宛先遅延 (Destination lag): 取り出した変更が ClickHouse に到着するまでにかかる時間、つまり変更が取り出されてから宛先でクエリ可能になるまでの時間です。
エンドツーエンド遅延 (End-to-end lag): 上記のソース遅延と宛先遅延の合計、つまり MySQL で変更が起きてから ClickHouse に現れるまでの合計時間です。

Terraform と OpenAPI への対応 #

ClickOps (つまりユーザーインターフェースでボタンをクリックする運用) はオンボーディングには便利ですが、本番デプロイを扱うチームには Terraform のような標準ツールが必要です。リソースを安全に、決定論的に、バージョン管理のもとでプロビジョニングし管理するためです。他の種類の ClickPipes と同様に、MySQL CDC ClickPipes も Open API と Terraform (v3.14.0 以降) で管理できます。既存の ClickPipes をソース管理下に置きたい場合は、こちらのブログ記事 の手順に従って、これらのリソースを Terraform の state にインポートしてください。

MySQL CDC コネクタを GA 品質に仕上げた作業は、見出しを立てて紹介できるものばかりではありません。データ型の忠実な再現から細かな信頼性の修正まで、チームは数え切れない時間をかけて、コネクタを本番環境と企業利用に耐えるものにしてきました。もっと細かく知りたい方は、お使いのエージェントに PeerDB リポジトリ を読ませて、変更の全体像を確認してみてください。🤖

料金 #

GA 化に伴い、MySQL CDC ClickPipes の課金は 2026 年 9 月 1 日に開始しており、ClickHouse Cloud アカウントの次回の請求サイクルに反映されます。このコネクタの料金はデータ量に基づく予測しやすいモデルで、サービスごとの固定のコンピュート費用は、種類を問わずすべての CDC ClickPipes で共有されます。MySQL CDC コネクタは、サードパーティの ETL ツールを使うより5〜10 倍コスト効率が高くなります。ClickHouse Cloud とさまざまなデータソースをシームレスかつ手頃につなぐ選択肢として ClickPipes を提供する、という私たちの姿勢の表れです。詳しくは ClickPipes の料金ドキュメント を参照してください。

MySQL CDC コネクタを始める #

MySQL CDC コネクタは、新規・既存を問わずすべての ClickHouse Cloud ユーザーが、すべてのサービスティアで利用できます。始めるには、ClickHouse Cloud コンソールの Data Sources タブを開き、MySQL または MariaDB データベースの接続情報を設定するだけです。

手順、よくある質問、注意点については、MySQL ClickPipes のドキュメント を参照してください。