제품 설계

Prosync 제품 이해를 위한 기본적인 설계 자료를 안내한다.

ProSync Architecture

그림1. ProSync Architecture

ProSync는 위와 같은 설계를 가지고있다. 전체 설계에 대한 간단한 요약을 하면 아래와 같다.

Extract 프로세스는 SRC DB 에 해당하는 추출 데이터베이스( SRC DB ) 에서 Redo Log 를 추출한다. 추출은 각 DBLog Reader Library 를 통해 진행하며, 필요한 경우, 각 DB 별로 제공하는 별도의 로그 분석 기능을 통해 추출을 진행하기도 한다. 추출된 데이터는 Apply 프로세스로 전달된다.

데이터는 보통 레코드 단위 (쉽게 말해 DML 단위)로 남게되며, 해당 데이터는 Apply 프로세스에서 트랜잭션 별로 취합해 반영해주어야 한다. 따라서 Apply 프로세스는 레코드 들을 전달받아 트랜잭션 별로 모아둔다. commit에 해당하는 레코드 가 오게되면, 트랜잭션을 반영시킨다.


Data Flow

그림2. ProSync DataFlow

ProSync의 Data Flow를 기준으로 살펴보면 조금 더 상세한 과정을 볼 수 있다.

Extract 프로세스는 레코드chunk 단위로 모아 Apply 프로세스로 전달한다. 전달받은 Apply 프로세스는 각 레코드 들을 트랜잭션 단위로 모아준다. commit 레코드가 올 경우 반영 데이터베이스(TAR DB) 로 반영하게 된다.

참고

더욱 상세한 내용은 'Memory Control' 를 참고한다.


Inter Processes/Threads Communication

ProSync는 프로세스간 통신은 TCP 통신을 사용하고, 쓰레드간 통신은 Pipe 를 사용하여 통신한다.

그림3. Inter process & Inter thread communication in Prosync.

어떤 종류의 프로세스건, Main 쓰레드는 반드시 존재하고 (ProSync에선 CTH 혹은 Control Thread 라고 부른다.) 해당 쓰레드가 다른 쓰레드와의 통신을 모두 담당한다. 즉, A라는 쓰레드에서 B라는 쓰레드와 직접 통신하는건 불가능하고, 반드시 Main 쓰레드를 거쳐서 통신을 하게 되어있다.

또한 프로세스간 통신에선 TCP 로만 통신을 진행하게되며, 이에 대한 소켓의 connectaccept 는 모두 각 프로세스의 Main 쓰레드가 담당한다.


ProSync Processes

전체 프로세스들의 기능과 구조를 간단하게 설명한다.

참고

각 프로세스에 대한 내용은 '운영 가이드' 를 참고한다.

Data Flow 를 기준으로 설명했던 프로세스는 주로 Extract 프로세스와 Apply 프로세스이다. 물론 이 두 프로세스가 ProSync의 핵심 프로세스이긴 하지만, 프로세스 전체를 관리하고, 데이터를 수집하여 모니터링 툴에 전달해주는 등의 기능을 해주는 Agent 프로세스나, Long 혹은 Lob 데이터 처리를 위해 별도로 구성된 Llob 프로세스, Agent 프로세스를 통해 실제 프로세스에 명령을 내리는 Admin 프로세스에 대한 구성을 알아야 이후에 나올 내용들에 대한 이해가 쉽다.

전체 구성을 보면 아래와 같다.

그림4. Prosync Processes

각 프로세스에 대한 역할은 아래와 같다.

Admin Process

Agent 프로세스를 통해 다른 프로세스에게 명령을 내린다. 명령어 목록은 Admin 쪽 메뉴얼을 참조하길 바라며, Agent 에게 내린 명령과 리턴을 터미널에서 출력한다고 생각하면 된다.

Agent Process

프로세스 관리에 들어가는 다양한 업무를 여기서 모두 수행한다. 대표적으로 아래와 같은 작업들이 있다.

  • 프로세스 기동 / 종료

  • 프로세스 별 리소스 모니터링

  • 프로세스 설정 변경

이외에도 관리에 해당하는 작업은 모두 이곳에서 작업을 수행해준다.

Extract Process

CDC 에 있어서 변경 데이터를 캡쳐하는 프로세스이다. 현재는 RDBMS의 리두로그를 보고 데이터를 추출하는 작업을 수행한다.

Apply Process

변경된 데이터를 peer쪽에 반영하는 작업을 수행한다.

Llob Process

RDBMS에서 사용되는 Long 혹은 Lob 과 같은 큰 단위의 데이터는 변경분의 데이터도 크다. 따라서 데이터가 리두에 남는다 하여도, 트랜잭션 말미에는 데이터가 삭제가 되거나 혹은 크게 변경될 가능성이 있다.

트랜잭션 단위로 봤을 땐, 마지막 형상의 데이터만 알아도 ACID를 유지하는 데에는 아무 문제가 없다. 모든 변경분의 데이터를 추적하지 않아도 ACID가 유지가 된다는 말은 굳이 힘겹게 Throughput을 손해보면서 프로세싱을 할 필요가 없다는 이야기가 된다.

Llob 프로세스에서 주로 수행하는 일은 Commit 이 들어온 시점에 Flashback 쿼리를 수행하여 해당 시점 즉 트랜잭션이 종료되는 시점에서의 데이터만 조회하여 Apply 에서 발생하는 데이터 처리량을 줄이고, 전체 동기화 과정에서의 부하를 줄여주는 프로세스이다.

Last updated