トランザクションレス、完璧なCDC（Change Data Capture）システム構築法
November 22, 2024
はじめに
個人情報保護法、電子金融取引法、医療記録個人情報保護法など、個人情報を含む機密情報の変更履歴を記録する義務をサービス提供者に課す規制や法律は、日々強化されています。これらの法律が明示する義務事項に加えて、リアルタイムモニタリングや脅威検知、データ整合性の維持、事故対応など、サービスの維持管理やセキュリティにおいても、データベース変更履歴の記録は開発者、データベース管理者、セキュリティ専門家にとって見逃せない重要な課題です。
多くのサービス提供者は、このような要件を満たすために、データベースで発生するデータ変更をリアルタイムで識別し追跡する技術であるCDC（Change Data Capture）を活用しています。データベースアクセス制御機能を提供するQueryPieも、CDCをサポートしています。本ホワイトペーパーでは、QueryPieがどのような方法でトランザクションを使用せずにCDCシステムを実現したのかについて説明します。
課題
トランザクションベースCDCの課題
CDC(Change Data Capture)は、データベースの変更前後のデータを記録する必要があります。この機能を実現する方法の1つとして、データベースのトランザクションを利用する方法があります。
例えば、ユーザーがUPDATEクエリでデータを変更する場合、以下のようなプロセスを経て、変更前後のデータを記録します。
*クエリ実行前後のデータ図*
しかし、トランザクションを使用してCDCを実装する場合、ユーザーが対象テーブルに対して変更クエリを実行するたびに、トランザクションのロールバックを行う必要があります。このロールバック処理はDBMSに負荷をかけ、対象テーブルのサイズが大きくなるほどその負荷も増加します。さらに、同じテーブルに対してクエリの実行前後に2回の重複したデータ取得を行う必要があるため、データベースアクセスの効率が低下します。また、NoSQLの場合、トランザクションをサポートしていないか、サポートしていても限定的なレベルでしかトランザクションを提供していないため、トランザクションベースのCDCを実装するのは困難です。
トランザクションのロールバックがどの程度影響を与えるかは、簡単なテストシナリオを通じて確認できます。テストシナリオの環境は以下の通りです。:
- MySQL 8.0 (オンプレミス、8コア(vcore 16)、メモリ256GB)
- 100,000件のレコード
- 以下のDDLを持つ
actorテーブル - ネットワークのボトルネックを無視できるほど高速な環境
CREATE TABLE actor (
actor_id int NOT NULL AUTO_INCREMENT,
first_name varchar(255) NOT NULL,
last_name varchar(255) NOT NULL,
last_update timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (actor_id)
);
このテーブルのすべてのレコードに対して、first_nameをすべて'Christopher'に変更するシナリオを想定してみます。トランザクションのロールバック機能を使用する場合、以下のようなクエリをすべて実行する必要があります。
mysql> SET AUTOCOMMIT=0;
Query OK, 0 rows affected (0.06 sec)
mysql> SELECT * FROM actor;
...
100000 rows in set (0.42 sec)
mysql> UPDATE actor4 SET first_name='Christopher' WHERE 1;
Query OK, 100000 rows affected (1.54 sec)
Rows matched: 100000 Changed: 100000 Warnings: 0
mysql> ROLLBACK;
Query OK, 0 rows affected (0.85 sec)
mysql> UPDATE actor4 SET first_name='Christopher' WHERE 1;
Query OK, 100000 rows affected (1.58 sec)
Rows matched: 100000 Changed: 100000 Warnings: 0
mysql> COMMIT;
Query OK, 0 rows affected (0.04 sec)
動作に要する時間を表に簡略化すると、以下の通りです。実際の動作に必要なテーブルの参照および更新以外に、CDCのために追加された動作は黄色で強調されています。
| 動作 | 所要時間 |
|---|---|
| テーブルクエリ | 0.42s |
| テーブル更新 | 1.54s |
| トランザクションロールバック | 0.85s |
| テーブル更新 | 1.58s |
| トランザクションコミット | 0.04s |
| 合計所要時間 | 4.43s |
| ユーザークエリ動作の合計所要時間 | 2.04s |
| 追加された動作の合計所要時間 | 2.39s |
ご覧の通り、トランザクションロールバックに基づくCDCの場合、更新とロールバックにより所要時間が2倍以上に増加することが確認できます。つまり、ユーザー視点では、CDCを使用することで50%のパフォーマンス低下を経験することになります。
その他のCDC実装が抱える問題点
さらに、テーブルにトリガーを作成してデータの変更を追跡する方法、modified_atなどの変更時刻やタイムスタンプを記録し、定期的にクエリを実行する方法、あるいはMySQLのbinlogのようなログファイルを活用してCDCを実現する方法もあります。それぞれの実装には長所と短所がありますが、共通してCDCの動作のためにDBMSを変更する必要があり、CDCの動作がDBMSに依存するという欠点を共有しています。つまり、新たにDBMSインスタンスを追加するたびに、関連する設定を追加する必要があるということです。
では、DBMSに負荷をかけず、DBMSへの依存性を排除しながら効果的にCDCを実現するには、どのような方法を採用すればよいのでしょうか？
目標設定
DBMSに負荷をかけないためには、CDCを実装する際にトランザクションを使用せず、同時に同一テーブルへの重複したクエリを実行しない必要があります。また、DBMSとの依存性を防ぐため、CDCの動作のためにDBMSを改変することも避けるべきです。
QueryPieではこれらの要件を満たすため、クエリ実行後のデータを直接データベースから取得するのではなく、社内クエリ分析ライブラリであるQSI(Query Structure Interface)を活用してデータを取得しています。では、テーブルを直接参照することなく、どのようにしてクエリ実行後のデータを取得するのでしょうか？
ソリューション概要
<QSIの**ActionAnalyzer**におけるCDCの**After Row**予測ロジック関連図>
QSIは、テーブルを直接参照するのではなく、ユーザーが実行するクエリがテーブルに加える変更をシミュレートし、変更後のテーブル結果を提供します。つまり、クエリ実行結果の確認をデータベースに依存させるのではなく、QSI内で直接クエリをシミュレートし、その結果を返す仕組みです。QueryPieのクエリシミュレーション技術を活用することで、CDCを利用してもデータベースでのトランザクション実行やロールバックは発生しません。また、必要なのはクエリの実行のみで、DBMSの修正は求められません。そのため、QueryPieをインストールした直後からすぐに利用を開始することができます。
技術的説明およびアーキテクチャ
QueryPieのウェブエディタやプロキシを通じて、QSIはユーザーが入力したINSERT、UPDATE、DELETEなど、テーブルに対する変更を含むクエリを受け取ります。分析を行うためには、クエリ実行前のデータが必要になるため、QSIは入力されたユーザークエリを解析し、実際に変更が行われる対象テーブルを特定します。さらに、解析結果に基づいて対象テーブルを照会するためのクエリを生成します。この生成されたクエリを使用して、変更対象テーブルの変更前のデータを取得します。
クエリ実行結果のシミュレーションに必要な対象テーブルの変更前データとユーザーが入力したクエリが揃ったところで、シミュレーションを実行します。シミュレーションでは、変更される値、変更が行われる行の条件式、変更前データの内容、入力クエリのパラメーターなど、さまざまな要素を考慮します。シミュレーションが実行されると、その結果を再加工し、整理して変更後データとして提供します。その後、CDCの結果はCSV形式に変換され、MySQLのBLOB型として保存されます。
QueryPieCDCの例
たとえば、actorテーブルにおいて、first_nameが'mason'であるすべての行について、last_nameを 'oh'に変更しようとするシナリオを想定します。ユーザーは以下のようなクエリを作成し、QueryPieを通じて実行します。
UPDATE actor SET last_name='oh' WHERE first_name='mason';
QueryPieはこのクエリを受け取り、QSI(Query Structure Interface)に送信します。QSIは入力されたクエリを解析し、変更対象となるテーブルを確認するためのクエリを生成します。この生成されたクエリを実行して得られた結果は、CDCにおける「変更前データ」として使用されます。生成されたクエリの内容は以下のとおりです。
SELECT last_name FROM actor WHERE first_name='mason';
次に、ユーザーの入力クエリと取得した「変更前データ」を基に、クエリシミュレーションを実行します。具体的には、first_nameが'mason'であるすべての行について、last_nameを'oh'に変更する操作を、actorテーブルの「変更前データ」にシミュレーションします。このシミュレーションの結果は、CDCにおける「変更後データ」として使用されます。
これらの一連のプロセスを通じて、CDCに必要な「変更前データ」と「変更後データ」の両方を取得しました。取得したデータを内部DBMSに保存することで、CDCの処理が完了します。
限界点
すべての環境でシミュレーションを実行できるわけではありません。関数呼び出しのように、呼び出し時点によって結果が異なる場合、クエリ実行前に結果を特定することができないため、値のシミュレーションが不可能です。しかし、QueryPieが主に使用される運用環境におけるデータベース変更は、主に値の補正を行うものであり、この補正の際には関数呼び出しではなくリテラル値を使用することが一般的です。そのため、この制約が実際の運用で問題になることは少ないと考えられます。なお、将来的には関数呼び出しなどの複雑なシミュレーションへの対応も計画されています。
期待効果
QueryPie CDCを使用することで、問題点で述べた処理時間のオーバーヘッドを排除できます。特に、QSIのクエリシミュレーション段階は、DBMSにテーブル更新やトランザクションロールバックの負荷をかけない点が注目に値します。
| 動作 | 実行時間 |
|---|---|
| テーブルクエリ | 0.42s |
| テーブル更新 | 1.54s -> 0s |
| トランザクションロールバック | 0.85s -> 0s |
| QSIクエリシミュレーション | 1.62s |
| テーブル更新 | 1.58s |
| トランザクションコミット | 0.04s |
| 合計処理時間 | 3.66s |
| ユーザークエリ処理時間 | 2.04s |
| 追加動作の合計処理時間 | 2.39s -> 1.62s |
QueryPie CDCを活用することで、トランザクションベースのCDCと比較して35%高速な処理が可能となります。また、DBMSに直接クエリを実行しないため、テーブル更新やトランザクションロールバックを省略し、DBMSへの負荷を大幅に軽減できます。
QueryPie CDCの3つの強み: パフォーマンス、柔軟性、拡張性
QueryPie CDCが他のCDCソリューションと比較して優れているポイントを以下の3つにまとめました。
- パフォーマンス: QueryPie CDCはトランザクションベースのCDCよりも高速に動作し、データベースへの負荷を大幅に軽減します。
- 柔軟性: QueryPie CDCは動作にあたりDBMSの状態変更を必要としません。すなわち、DBMSに依存しません。そのため、QueryPie CDCはインストール後にDBMSを修正することなく即座に使用可能です。
- 拡張性: QueryPie CDCはDBMSに依存しないため、新しい種類のDBMSをサポートする必要が生じても、追加の作業を行うことなく即座に対応可能です。
結論
トランザクションベースのCDC実装は、頻繁なトランザクションロールバックや重複クエリの実行、NoSQLサポートの難しさなど、多くの課題を抱えています。また、他の実装方法にもDBMSへの依存性という制約があります。QueryPieは、QSIを活用したCDCシステムを構築することで、DBMSに依存せず、データベースへの負荷を最小限に抑えることを実現しました。トランザクションロールバックを使用せず、重複したテーブル参照を防ぐQueryPie独自のクエリシミュレーション技術がこれを支えています。
これにより、QueryPieはトランザクションベースのCDCの限界を超え、優れた性能と柔軟性を兼ね備えた新たなCDCソリューションを提供します。QueryPieのCDCを活用することで、企業はデータの整合性とセキュリティを維持しながら、迅速かつ効率的な運用を実現できます。今後もQueryPieはCDC技術をさらに進化させ、顧客がデータに基づいた意思決定を行い、規制遵守とセキュリティを同時に満たす革新的なビジネス環境を構築できるよう支援していきます。
データは未来の重要な資産です。QueryPieは、その資産を保護し、企業と顧客の成功を支える信頼できるパートナーであり続けます。
気になりますか？
魔法を明かしましょう！
限定コンテンツをアンロックするには、フォームにご記入ください！