Memory 사용량은 ProSync 사용에 있어서 가장 민감한 부분 중 하나이다. 제품 설계 에서 보았듯이 데이터를 추출하는 쪽에선 크게 데이터를 저장할 일이 없지만 데이터를 받는 쪽에선 트랜잭션 단위로 데이터가 모여야 데이터를 peer쪽에 반영할 수 있기 때문에, 이 데이터들을 모아놓는 데에 있어서 많은 양의 메모리가 사용된다.

본 장에선 대표적으로 메모리가 사용될만한 부분을 Sender (Extract / Llob ) 와 Receiver(Apply) 로 나누어서 설명한다.

Sender(Extract, Llob) 측의 메모리 사용

Extract 프로세스는 Non-Blocking I/O로 데이터를 전송한다. 대기 없이 데이터를 전송하려면 반드시 수신측에서 빠르게 데이터를 처리해 줘야 한다. TCP 의 수신버퍼에 데이터가 비워지지 않으면 Sender쪽은 Blocking이던 Non-Blocking이던 데이터를 처리하지 못한다. 이 경우 보내지 못한 데이터는 Queue에 쌓이게 되는데, 이때 메모리 사용량이 늘어나게 된다.

ProSync는 네트워크 지연 상황 발생 시 512MB 이상의 데이터가 Queue에 쌓일 경우 데이터를 보내지 않고 대기하게 된다. 이 크기는 기본값이며 히든 파라미터로 조절은 가능하다. (_MSG_LIST_SIZE_TO_PAUSE) 하지만 지연 상황에서 이 크기 때문에 속도가 달라지는 경우가 거의 없어 히든 파라미터로 처리되고 있고, 사용자는 이 사실만 알고 있으면 메모리 사용량이 올라가는 이유를 쉽게 추측할 수 있다.

Llob 프로세스의 경우 동작이 살짝 다른데, 데이터를 보내고 받을 때 64k 단위로 데이터를 주고받게 되어 있으며, 각 데이터가 Llob 과 Apply 프로세스간 송수신이 완료되어야 다음 데이터를 요청하도록 짜여져 있다. 따라서 Blocking 여부와 상관없이, Llob 에서 사용하는 최대 Thread 개수를 따라가고, 이 크기 자체가 미미하다.

Receiver(Apply) 측의 메모리 사용

TCP 를 통한 데이터 Receive에서 중요한 부분 중의 하나는 Kernel의 Receive Buffer를 빠르게 비워주는 동작이다. 이게 늦어지면 Window Size에 여유가 없어져서 결국 Sender쪽에선 아무 데이터를 보낼 수 없는 상태가 된다. 따라서 ProSync의 Apply Process는 수신을 대기하는 file descriptor(Socket)에 데이터가 감지되면 가장 먼저 데이터를 Memory로 복사하는 동작을 수행한다.

복사된 데이터들은 자연스럽게 Apply쪽에 쌓이게 된다. 쌓인 데이터는 Apply 프로세스가 사용하는 일련의 파이프 라인에 의존하여 관리된다. 여기서 해당 내용을 자세히 다루진 않고, 와 해당 문서 하단의 에서 더 상세하게 다루도록 한다.

간단하게 요약하면, 메모리 내에 데이터가 너무 많으면 파일로 내리는 내용이고 파일로 내릴 수 없는 데이터들이 많이 쌓이게 되면 Socket 자체로부터 들어오는 데이터를 읽지 않는다. 이렇게 되면 앞서 설명한 Sender 쪽의 Non-Blocking 동작에 의해 알아서 읽기 동작을 멈추게 된다.

지원 Database

Source Database

• Tibero (Single/TAC/TAS/TSC) 6 이상

• Oracle 11g

• Oracle 12c

• Oracle 19c

• PostgreSQL 15

• PostgreSQL 16

• Tibero

• Oracle 11g

• Oracle 12c

• Oracle 19c

트랜잭션 단위의 동기화를 지원한다.

테이블에 대한 INSERT, UPDATE, DELETE 작업을 동기화한다.

아래 대상은 동기화를 지원하지 않는다.

• 실체화 뷰(Materialized View)

• Clustered Table

• Indexed Organized Table(IOT) (Source DB가 Oracle인 경우)

• 대상 테이블에 Interval Partitioning이 적용된 경우, DB가 동적으로 생성한 Partition에 포함된 데이터는 동기화되지 않을 수 있다.

을 참고한다.

DDL 동기화는 DB 단위로 지원한다.

지원 컬럼 타입은 사용하는 DB에 따라 다르므로, 을 참고하여 DB별 지원 컬럼 타입 및 매핑 정보를 확인한다.

• Tibero ➔ Tibero

• Oracle ➔ Tibero

• Tibero ➔ Oracle

• Tibero ➔ PostgreSQL

ProSync가 Disk로 저장하는 데이터들은 크게 다음과 같다.

• Log File

• TX Hash File

• Part File

위 세 파일은 파라미터로 관리되거나 자동으로 ProSync가 삭제하는 동작을 통해서 관리된다.

본 문서에서는 위 파일들에 대해 간단하게 소개하고 어떤 방식으로 관리되고 있는지 설명한다.

Log File

ProSync의 로그 파일은 프로그램 로그나 SAM(Sequential Access Method) 파일, Discard와 같은 에러 발생 시 사용되는 로그 파일들이 있다. 어떤 파일이든 ProSync 로그는 같은 방식으로 처리가 되고, 이 부분만 기억하면 Disk 사용량을 쉽게 예측할 수 있다.

ProSync의 로그들은 일정 크기까지 데이터를 쓰고, 임계치를 넘어가면 새 파일에 데이터를 쓰며 기존 데이터는 Backup 위치로 이관시킨다. 이관된 위치에는 데이터가 영구적으로 쌓이게 될 수 있는데, 이를 위해 제공되는 파라미터를 통하여 Backup 위치 내에서 파일 개수를 동일하게 유지시킬 수 있다.

이 설정은 모두 파라미터로 관리되고 있으며, 해당 내용을 참고하여 설정하면 좋다.

Apply 프로세스에서만 사용되며 상세한 내용은 에서 자세히 설명하며, 본 장에서는 간략히 언급한다.

TX Hash File은 수신 이후 데이터들이 쌓이는 공간이며, 이력 저장 주기(RDBMS의 Log Switch) 마다 데이터 전체가 Disk에 작성된다. 작성된 데이터는 Log File과 마찬가지로 파라미터를 통해 특정 개수 혹은 특정 용량까지만 이력을 보관하도록 설정할 수 있다.

Part File은 Transaction의 크기가 클 때 메모리에서 Disk로 내려가는 파일로, 반영쪽에 데이터가 반영되고 나서야 제거가 될 수 있다. ProSync 동작 특성 상 Part File의 용량이나 개수를 제한하기가 어렵기 때문에, 사용자가 추출하고자 하는 데이터의 양상에 맞게 Disk를 여유있게 준비해야 한다. 예를 들어 10억건의 DML을 넣는 Transaction이 자주 발생하는 환경이라면, 유사한 크기의 Part File이 생길 수 있음을 인지하고 Disk 관리를 해주어야 한다.

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 사용량이 많아지게 된다.

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

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

postgres 언어 설정 필요

영어 또는 한국어로 설정한다.

libpq 라이브러리 설정 필요

libpq 라이브러리 관련 패치들이 모두 반영되지 않아 다음 중 하나를 적용하여 우회해야 한다.

• SCRAM-SHA-256 인증을 지원하도록 수동 빌드한 libpq 사용

• SCRAM-SHA-256 인증을 지원하는 최신 libpq 라이브러리 사용

• SCRAM-SHA-256 인증을 사용하지 않도록 postgresql.conf의 password_encryption을 md5로 변경한 뒤 ProSync 재설치

numeric 타입 길이 제약

길이 65532 이상 numeric data의 경우 에러로그 출력 후 skip 처리한다.

설치 시, apply config파일에 REPLAY_THREAD_CNT=1 파라미터가 추가된다.

영어소문자와 숫자만 사용 가능하다.

postgresql의 제약사항으로 인해 문자열은 null 이후 종료된다.

PostgreSQL의 object는 기본적으로 소문자로 생성되기 때문에, MAP 파라미터 사용 또는 "TABLE_NAME" 과 같이 "를 사용하여 명시적으로 대문자 테이블 생성이 필요하다.

PostgreSQL의 제한(한 row의 최대 크기는 1GB)과 ProSync 동기화 방식의 제약사항으로 인해 BYTEA 컬럼에 대해서는 500MB - 2 바이트(postgresql에서 붙이는 접두사 \x)까지 동기화 가능하다.

ProSync는 On-Line 으로 운영되는 프로그램으로 혹시 모를 중단이나 비정상 종료가 발생하면 안 된다. 이 때문에 프로그램 사용자는 하드웨어 요구사항에 대해서 어느 정도 이해하고 있는 것이 좋다.

본 장에서는 CPU와 Memory 그리고 Disk 요구사항을 차례대로 살펴볼 것이다. 기본 값으로 사용해도 동기화하는 데에는 문제가 없지만, CPU나 Memory가 어떤 부분에서 많이 사용되는지, Disk는 어느 정도 사용하는지 등에 대해 대략적인 정보를 정리한다.