트랜잭션리스, 완벽한 CDC(Change Data Capture) 시스템 구축법
November 22, 2024
서문
개인정보보호법, 전자금융거래법, 의료기록 개인정보보호법 등 개인정보를 포함한 민감한 정보의 변경사항을 기록해야 할 의무를 서비스 제공자에게 부여하는 규제와 법령은 나날이 강화되고 있습니다. 법에서 명시하고 있는 의무 사항 이외에도 실시간 모니터링 및 위협 탐지, 데이터 무결성 유지 및 사고 대응과 같은 서비스의 유지보수 및 보안을 위해서도 데이터베이스 변경사항 기록의 중요성은 개발자, 데이터베이스 관리자, 보안 전문가 모두에게 무시할 수 없는 사항입니다.
많은 서비스 제공자들은 위와 같은 요구사항을 만족하기 위해, 데이터베이스에서 발생하는 데이터 변경사항을 실시간으로 식별하고 추적하는 기술인 CDC(Change Data Capture)를 사용합니다. 데이터베이스 접근제어 기능을 제공하는 QueryPie에서도 역시 CDC를 지원합니다. 이 백서에서는 QueryPie에서 어떠한 방법을 통해 트랜잭션 없이 CDC 시스템을 구현했는지에 대해 다룹니다.
문제
트랜잭션 기반 CDC가 가지는 문제들
CDC는 기본적으로 변경이 발생했을 때 변경 이전 데이터와 이후 데이터를 기록해야 합니다. 이러한 기능을 구현하기 위해 사용할 수 있는 방법들 중 하나는 바로 데이터베이스의 트랜잭션을 활용하는 것입니다.
예를 들어 사용자가 UPDATE 쿼리를 통해 데이터를 변경하고자 할 경우, 다음과 같은 과정을 통해 변경 전후 데이터를 기록할 수 있습니다.
*쿼리 수행 이전 데이터 및 이후 데이터에 대한 다이어그램*
그러나 트랜잭션을 통해 CDC를 구현할 경우, 사용자가 대상 테이블에 변경 쿼리를 수행할 때마다 트랜잭션의 롤백을 수행해야 하는 문제가 발생합니다. 트랜잭션의 롤백은 DBMS에 부하를 가하게 되며, 대상 테이블의 크기가 크면 클수록 가해지는 부하도 증가하게 됩니다. 게다가 동일한 테이블에 대해 쿼리 수행 이전, 이후 총 두 번의 중복된 조회를 수행해야 하므로 데이터베이스 접근 효율성이 떨어집니다. 이외에도 NoSQL의 경우 트랜잭션을 미지원하거나, 지원하더라도 약한 레벨의 트랜잭션만을 지원하기 때문에 트랜잭션 기반으로 CDC를 구현하게 될 경우 지원이 어려울 수 있습니다.
트랜잭션의 롤백이 얼마나 영향을 끼치는지는 간단한 테스트 시나리오를 통해 확인해볼 수 있습니다. 테스트 시나리오 환경은 다음과 같습니다.
- MySQL 8.0 (on-premise, 8core(vcore 16), mem 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의 경우 업데이트와 롤백으로 인해 두 배 이상 시간이 소요되는 것을 확인할 수 있습니다. 즉, 사용자 입장에서는 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*에서 *CDC* 관련한 *ActionAnalyzer* 쪽의 *after row* 예측 로직 관련 다이어그램
QSI는 테이블을 직접 조회하는 대신, 사용자가 질의한 쿼리의 수행이 가져올 변경사항을 변경 전 테이블 조회 결과에 시뮬레이션하여 변경 후 테이블 결과를 전달하게 됩니다. 즉, 쿼리의 수행 결과 확인의 과정을 데이터베이스에 위임하는 것이 아니라, QSI 내에서 직접 쿼리를 수행해보고 그 결과를 제공하는 것입니다. 쿼리 시뮬레이션 기술을 사용하는 QueryPie에서는 CDC를 사용하더라도 데이터베이스에서의 트랜잭션 수행과 롤백이 발생하지 않습니다. 또한, 쿼리만 수행하면 되므로 동작을 위한 DBMS의 수정도 요구하지 않으며, QueryPie 설치 즉시 바로 사용할 수 있습니다.
기술적 설명 및 아키텍처
QueryPie의 웹 에디터나 프록시 등을 통해 QSI는 사용자가 입력한 INSERT, UPDATE, DELETE와 같이 테이블에 대한 변경이 포함된 쿼리를 입력으로 전달받게 됩니다. 분석을 위해서는 쿼리 수행 이전 데이터가 필요하므로, QSI에서는 입력값인 사용자의 쿼리를 분석하여 실제 변경이 이루어질 대상 테이블을 특정하고, 분석된 쿼리를 활용하여 대상 테이블을 조회하는 쿼리를 생성합니다. 이후 생성된 쿼리를 통해 변경 대상 테이블의 변경 수행 이전 데이터를 가져오게 됩니다.
이제 쿼리 수행 결과 시뮬레이션에 필요한 대상 테이블의 변경 수행 이전 데이터와 사용자의 입력 쿼리를 모두 확보했으므로, 시뮬레이션을 수행합니다. 쿼리 시뮬레이션에서는 변경되는 값에 대한 정보, 변경이 이뤄지는 행의 조건식, 변경 이전 데이터의 내용, 입력 쿼리의 파라미터와 같은 다양한 요소들을 고려합니다. 시뮬레이션이 이뤄지고 나면, 그 결과를 다시 가공하고 정리하여 변경 이후 데이터로 제공합니다. 이후 CDC의 결과는 csv 포맷로 변환되어 MySQL에 blob 타입으로 저장됩니다.
QueryPie CDC의 예시
예를 들어, 사용자가 actor 테이블의 first_name이 'mason'인 모든 행에 대해, last_name을 'oh'로 변경하려는 상황을 가정해 보도록 하겠습니다. 사용자는 위 작업을 수행하기 위해 아래와 같은 쿼리를 작성하여 QueryPie를 통해 실행합니다.
UPDATE actor SET last_name='oh' WHERE first_name='mason';
QueryPie에서는 위 구문을 입력받고 이를 QSI로 전달합니다. 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 솔루션과 비교했을 때 우위를 가지는 요소들에 대해 정리해 보면 다음과 같습니다.
- 성능: QueryPie CDC는 트랜잭션 기반 CDC보다 더 빠르게 동작하며, 데이터베이스에 부하를 더 적게 가합니다.
- 유연성: QueryPie CDC는 동작을 위한 DBMS의 상태 변경을 요구하지 않습니다. 즉, DBMS에 종속성을 가지지 않습니다. 덕분에 QueryPie CDC는 설치 후 DBMS를 수정하지 않고 바로 사용이 가능합니다.
- 확장성: QueryPie CDC는 DBMS에 종속적이지 않기 때문에, 새로운 종류의 DBMS를 지원해야 하는 상황에서도 동작을 위해 추가로 진행해야 하는 작업 없이 바로 해당 DBMS를 지원할 수 있습니다.
결론
트랜잭션 기반의 CDC 구현은 잦은 트랜잭션 롤백, 중복 쿼리 수행, 난해한 NoSQL 지원 등의 문제를 가지고 있으며, 기타 구현 역시 DBMS에 종속된다는 단점을 안고 있습니다. QSI를 활용한 CDC 시스템 구현을 통해 QueryPie는 DBMS에 종속되지 않으며 동시에 데이터베이스 부하를 최소화합니다. 트랜잭션 롤백을 사용하지 않고 중복된 테이블 조회를 방지하는 QueryPie만의 독자적인 쿼리 시뮬레이션 기술이 이를 뒷받침합니다.
이러한 트랜잭션 기반 CDC의 한계를 넘어, QueryPie는 성능과 유연성을 겸비한 새로운 CDC 솔루션을 제시합니다. QueryPie의 CDC를 통해 기업은 데이터의 무결성과 보안을 유지하면서도 빠르고 효율적인 운영을 실현할 수 있습니다. 앞으로 QueryPie는 CDC 기술을 더욱 발전시켜 고객이 데이터 기반의 결정을 내리고, 규제와 보안을 동시에 만족하는 혁신적인 비즈니스 환경을 구축할 수 있도록 돕겠습니다.
데이터는 미래의 핵심 자산입니다. QueryPie는 핵심 자산을 보호하며, 기업과 고객의 성공을 위하는 신뢰받는 파트너가 되겠습니다.
무엇이 있을까요?
지금 바로 확인해보세요!
아래 양식을 작성하시면 특별한 콘텐츠가 열려요!