データパイプラインを大規模に運用していると、ある種の問題が表面化します。サービス停止や明らかな障害ではなく、より静かに進行する問題です。

例えば、レプリケーションの途中でスキーマが変更され、新しいカラムに NULL が入り続けていても数週間気づかれないことがあります。事業部門ごとのわずかな違いに対応するためにパイプラインを 6 つに複製すれば、保守の負荷も 6 倍になります。長時間実行したジョブがエラーで終了しても、どのテーブルが成功し、どのテーブルが失敗したのかは分かりません。

CData Sync はまさにこの種の問題に焦点を当てています。今回のリリースでは、本番環境レベルのパイプラインを運用するチームにとって最も重要な 3 つの領域（プロセスをどこまで制御できるか、実行中に何が見えるか、データをどこへ同期できるか）で機能が拡充されました。以下に今回のリリース内容とその重要性を説明します。

プロセスをどこまで制御できるか

この領域こそ、レプリケーションプラットフォームの真価が問われる部分です。このセクションで紹介する機能は、単純なポイントツーポイントのジョブを超えた規模に成長したパイプラインを管理するチーム向けに設計されています。具体的には、複数のデータソース、変化し続けるスキーマ、依存関係のあるワークフロー間のオーケストレーション、そして本番環境で稼働して初めてその挙動が明らかになるソースシステムなどに対応しています。

パイプライン変数：複雑さを伴わないパラメータ化

パイプラインのパラメータ化をサポートするデータ統合ツールの多くは、必要以上にその操作を複雑にしてしまっています。機能自体は備わっているものの、独自の式言語や複雑な設定階層、あるいは独自の学習コストを伴う独立したオーケストレーション層の背後に隠れがちです。

CData Sync 26.3 ではよりシンプルなアプローチを採用しています。変数はパイプラインレベルで定義します。{pipeline:variablename} という構文を使えば、REPLICATE クエリや変換処理内を含め、そのパイプライン内のどこからでも参照できます。また、実行時にはパイプライン ID、名前、実行開始日といった読み取り専用のシステム属性も自動的に利用可能です。追加の設定も、式ビルダーも、習得すべき別の設定レイヤーも一切必要ありません。

その結果、個々のジョブに値をハードコーディングすることなくパイプラインをパラメータ化し、環境や事業部門をまたいで再利用できるようになります。開発、テスト、本番の各環境間のわずかな差異や、スキーマ名が異なる地域ごとの事業部門に対応するために別々のパイプラインを維持してきたチームは、その作業を大幅に集約できます。

CDC のデータソース対応強化：本番環境で実際に起きることへの対応

変更データキャプチャ（CDC）は安定した環境下ではうまく機能します。しかし、ソースデータベースが実環境において通常行う動作（レプリケーションの途中でスキーマが変更されたり、テーブルの再編成が行われたり、すでにキャプチャ対象となっているテーブルに新しいカラムが追加されたりといった動作）が発生すると、複雑さが表面化します。こうした状況は必ずしも目立った兆候を伴って現れるわけではありません。その結果、新しいカラムに数週間 NULL が入り続けたり、同期先で行が欠落したり、再編成後に重複データが蓄積されたりします。いずれの場合もエラーは発生しません。

バージョン 26.3 では、このカテゴリに該当するシナリオに対処するためデータソース固有の 3 つの改善が行われました。

SQL Server CDC は、データベース管理者がダウンタイムゼロのスキーマ変更に使用する「2 つのキャプチャインスタンス」パターンに対応するようになりました。このパターンでスキーマ変更が適用される場合、最初のキャプチャインスタンスが削除される前に 2 つ目のキャプチャインスタンスが作成されます。CData Sync はこの 2 番目のインスタンスを検出し、古いインスタンスに残ったデータを処理し終えたうえで自動的に読み取り先を切り替えます。以前はジョブの再同期が必要で、ソーステーブルが大きい場合は多大なコストがかかる可能性がありました。

Db2 for i CDC ではマージキーとして RRN（相対レコード番号）にフォールバックする前に、条件を満たす一意インデックスの有無を確認するようになりました。RRN は保存された識別子ではなく、ファイル内での行の物理的な位置を表します。テーブルの再編成が頻繁に行われる環境では、行の位置が変更されて RRN が再割り当てされます。その結果、エラーが発生しないまま同期先に重複した行が書き込まれたり、ファントム削除（実際には削除されていない行が削除済みとして扱われる現象）によって行が消失したりする可能性があります。安定した一意のインデックスが存在する場合、CData Sync は代わりにそれを使用します。利用できない場合は RRN にフォールバックし、警告をログに出力します。

SAP HANA CDC はソーステーブルでスキーマ変更が検出されると、トリガーを自動的に再生成するようになりました。以前はレプリケーションの途中で HANA ソーステーブルにカラムが追加された場合、タスクを手動で再作成するまでそのカラムは同期先で NULL として扱われていました。現在ではスキーマ変更は人手による介入なしに伝播されます。

SnapshotMode：ブール値から 3 つの選択肢へ

SnapshotMode は従来の SkipSnapshot というブール値に代わる設定で、標準ジョブと CDC ジョブの両方に適用されます。選択肢は 3 つです。Incremental は、設定された差分チェックカラムの範囲を使用して初期スナップショットの範囲を限定します。Full は、追加の条件を指定せずに単純な SELECT を実行します。Skip はスナップショットを完全にバイパスします。各オプションは UI 上で直接説明されており、従来のブール値フラグも引き続き機能しますが非推奨となっています。

この変更は SkipSnapshot に関する実用上の問題に対処するものです。SkipSnapshot は状況によって異なる意味で使われており、単一のオン/オフ切り替えではそれらの違いを明確に表現するには不十分でした。3 つの名前付きオプションにより、チームは設定時および後日のジョブ設定の確認時に意図をより正確に伝えられます。

パイプラインステップの並列実行

パイプライン内のステップを並行して実行できるようになりました。別々のデータソースと同期先を持ち、共有状態のない独立したジョブがパイプラインに含まれている場合、それらのステップは前のステップの完了を待たずに同時実行するよう設定できます。パイプラインの総実行時間は、互いに依存関係のないステップの数に比例して短縮されます。

ジョブ設定時のスキーマ管理

CData Sync ではジョブを実行するために同期先スキーマが事前に存在している必要がなくなりました。ジョブ作成時にソーススキーマの構造を同期先で保持するか、すべてを単一の同期先スキーマに統合するかを選択できます。スキーマが存在しない場合、CData Sync は実行時にそれを作成します。多数のスキーマにまたがる多くのジョブを管理するチームにとっては、見落としやすく、見逃した際の診断が困難だったセットアップ手順が不要になります。

実行中に何が見えるか

エラーなしで完了したレプリケーションジョブと、正しく完了したレプリケーションジョブは同じではありません。バージョン 26.3 での 2 つの変更により、実行中および実行後にその違いがより明確になります。

より正確な実行結果と自動再試行

タスクが大量のデータを処理し、その一部が完了して残りが失敗した場合、実際に処理されたデータ量に関わらず結果は単一の「ERROR」としてまとめられていました。そのため、すべてを再試行すべきか、それとも一時的な問題として処理して先に進むべきかを判断するのが困難でした。

新しい「PARTIAL_SUCCESS」ステータスはこの結果を区別し、何が完了して何が完了しなかったかを正確に示します。そのタスクで再試行が設定されている場合は、失敗した部分に対して自動再試行をトリガーします。単に「何かがうまくいかなかった」ではなく、何が起こったのかを具体的に示す結果が得られます。

実行中のレコード数をリアルタイム表示

「影響を受けたレコード数」がタスク画面にリアルタイムで表示されるようになりました。データが同期先に到着するたびに更新され、ページの再読み込みは不要です。以前のリリースでは、長時間実行されるタスクの進行中のフィードバックが限られていました。このカウントは継続的に更新されるため、タスクが完了するのを待つことなく処理の進行状況をその場で確認できます。

データをどこへ同期できるか

CData Sync はすでにデータベース、クラウドウェアハウス、ファイルシステムにわたる幅広い同期先をサポートしています。バージョン 26.3 での 2 つの追加機能により、その範囲がさらに拡大しました。

Kafka：セットアップの障壁を解消

Kafka は以前から CData Sync でサポートされている同期先でしたが、26.3 までは接続を設定する前にスキーマレジストリの導入が必須でした。この要件は現在オプションとなっています。スキーマレジストリの設定は、選択したメッセージ形式で実際に必要とされる場合にのみ表示されます。

さらに 26.3 では、データが Kafka にどのように格納されるかを制御する機能が追加されました。トピックルーティングは設定可能で、すべてのテーブルを単一のトピックに送信する、テーブルごとに 1 つのトピックを割り当てる、{schema} および {table} 変数を使った命名テンプレートを適用する、といった方法を選べます。パーティショニングも設定可能で、ラウンドロビン、主キー、カスタムカラム式などのオプションが利用できます。すべてのメッセージは Kafka ヘッダーに運用メタデータを保持します。ソーススキーマ、ソーステーブル、操作タイプ、コミットタイムスタンプなどが含まれるため、後続のコンシューマーはメッセージ本文を解析せずにフィルタリングやルーティングを行えます。

Apache Doris に新規対応

Apache Doris が CData Sync でサポートされる同期先として追加されました。チームで Doris を OLAP レイヤーとして運用している場合、MySQL 互換の接続を経由することなく Doris へ直接データをレプリケートできます。このコネクタは Doris 固有のデータ型や SQL 構文をネイティブに処理します。

CData Sync 26.3 のご案内

その他の改善や修正を含む変更点については、リリースノートをご覧ください。

すでにご利用中の方：アップグレードをご希望の場合は、テクニカルサポートまでお問い合わせください。

これから導入を検討される方：ぜひ無償トライアルをお試しください。

※本記事は CData US ブログ What's New in CData Sync 26.3 の翻訳です。