CPU 요구사항

CPU는 64bit 명령어 집합을 사용하는 CPU가 요구된다. 32bit 명령어 집합을 사용하는 CPU 상에서 사용되는 시나리오는 현재 고려되고있지 않다.

ProSync는 대체로 CPU를 많이 점유하는 프로그램은 아니다. 일련의 데이터 스트림을 전송하고, 이를 쿼리형태로 변환하여 peer쪽의 저장장치에 저장 명령을 내리는 동작을 하기 때문에, 저장하고자 하는 소프트웨어(RDBMS)나 하드웨어의 영향을 많이 받는다.

ProSync가 CPU를 점유할만한 시나리오는 크게 2가지가 있다.

• 데이터 송신 부분에서 발생하는 여러 처리과정으로 인한 부하

• 데이터 수신 부분에서 트랜잭션 병렬처리를 위해 발생하는 병렬 확인 부분

각각에 대해 설명을 하면 아래와 같다.

데이터 송신 부분

ProSync는 TCP 스택에 데이터를 전송하기 전에, 자체 프로토콜을 사용하여 데이터를 직렬화한다. 데이터를 전송하는 입장에선 당연히 자체 프로토콜을 저장할 데이터 버퍼가 필요하고, 이 버퍼에 데이터를 쓴 뒤 Non-Blocking으로 데이터를 전송해주어야. 대기 없이 다음 데이터를 처리할 수 있다.

또한 데이터는 네트워크 환경에 따라서 압축이 될 수도 있고, 암호화가 되어 전송이 될 수도 있다. 이런 경우에 데이터 송신 전에 전처리할 작업들이 많아져서 CPU 점유량이 높아질 수 있다.

데이터 수신 부분

송신 부분에서 설명한 것과 마찬가지로, 수신부분에서도 소켓으로부터 데이터를 받은 뒤, 복호화 작업이나 압축된 데이터에 대한 해제과정이 필요하다. 이 부분에서 CPU 점유량을 사용할 수 있다.

데이터 병렬화 부분

하지만 CPU가 가장 많이 사용되는 부분은 역직렬화된 트랜잭션 데이터들에 대한 중복 확인 과정이다. CDC 제품 특성상 데이터 정합성을 위해선 Change Data 들에 대한 시간 순서를 엄밀히 지켜주어야 한다. 이 때문에 N명의 사용자가 데이터를 생산했다 하더라도, 별도의 처리 없인 시간 순으로 데이터를 처리하는 1개의 프로세스만이 존재하게되어 많은 성능 손실이 야기된다.

ProSync는 이에 대한 처리를 위해 Change Data 각각에 대해 서로가 같은 데이터를 건드린 건지에 대한 확인을 하게된다. 트랜잭션 단위의 ACID만을 지켜주면 되기 때문에, 두 트랜잭션 내에 있는 모든 Change Data(=레코드, DML, ...) 들이 서로 다른 데이터를 건드렸다면, 병렬로 반영해도 아무런 문제가 없다.

이에 대한 처리를 위해서 ProSync는 자체 자료구조를 사용하여 이를 검사하게된다. 트랜잭션이 처리하는 데이터량이 많다면 이에 대한 처리도 많아지고, 그만큼 자료구조를 탐색하는 시간도 길어지게 된다. 따라서 이 부분을 탐색하는 비용에서 ProSync는 CPU 사용량이 많아지게 된다.

파일 I/O 관련

ProSync는 수많은 로그가 사용된다. 프로그램의 로그를 포함하여, SAM(Sequential Access Method) 파일을 내리는 기능이나 Error가 발생한 DML을 확인하는 기능 등이 대표적이다. 이들은 Blocking I/O로 되어있어서, Disk의 write 동작을 반드시 대기하고 다음 작업을 수행한다. 따라서 로그 레벨이 높거나 작성할 로그 파일이 많아지면 CPU동작이 그만큼 지연될 수 있다.

뿐 만 아니라 ProSync는 특정 시점마다 이력정보를 저장한다. 대표적인 경우가 RDBMS의 Redo Log Switch (이하 Log Switch) 이다. Log Switch가 발생하면 이력정보와 관련된 데이터를 모두 Disk로 write하게 되는데, 이 때도 마찬가지로 지연이 발생할 수 있다.