Apply Process
Apply 프로세스에 대하여 설명한다.
Process 설명
Apply 프로세스는 제품 설계에서도 언급했듯이 Chunk 단위로 레코드를 전달 받고 해당 레코드를 트랜잭션 별로 모아준다. 트랜잭션에 Commit 이 오면 해당 트랜잭션은 실제 반영 단계에 들어가 대상이 되는 데이터베이스로 반영된다.
본 장에선, 실제 Apply 프로세스가 어떤 구조로 이루어져 있는지 조금 더 상세한 내용을 살펴본다.
Threads
Apply프로세스는 위와 같은 구조를 가지고 있다. 앞서 Inter Processes/Threads Communication 에서 ProSync 의 기본 Thread 구조를 언급한 바 있는데, Apply 도 마찬가지로 Main 이 되는 Control Thread 가 있고 이외에 Worker Thread 들이 Control Thread 하위에 달려있는 구조이다.
동기화에 필요한 Thread 는 Construct Thread 와 Replay Thread 로 크게 두 가지로, 나머지는 모두 Worker Thread 로 구분 된다.
Control Thread
Control Thread 는 다른 프로세스와 마찬가지로 모든 통신과 관련된 Multiplexing I/O 를 담당한다. 리눅스에선 epoll 을 사용하며, 플랫폼 별로 k-queue 나 pollset 등 각 운영체제에 알맞은 Mux I/O 기능을 사용하도록 설계되어있다.
Construct Thread
Construct Thread 는 Chunk 로 들어오는 레코드 데이터들에 대해 트랜잭션 으로 재조립한다. Construct 라는 말의 의미는 트랜잭션 을 다시 조립(Construct) 하기 때문에 사용된다고 생각하면 된다.
각 레코드 에는 본인이 속한트랜잭션 을 구분할 수 있는 일종의 key 값이 존재하는데, 이게 트랜잭션 의 ID 일명 (xid) 라고 불린다.
Construct 는 레코드 의 xid 값을 보고 트랜잭션 별로 재조립한다.
Replay Thread
Replay Thread 는 Commit 레코드가 도달하여 Construct 로부터 조립이 완료된 트랜잭션을 전달 받는다. 전달 받은 트랜잭션은 Commit 레코드의 DB Time (Oracle의 SCN / Tibero의 TSN / .. )에 맞게 직렬화되어 반영되거나, 트랜잭션 내 레코드 들의 의존성을 모두 체크하여 병렬로 처리되게 된다.
병렬로 처리하게될 경우 Replay Thread 의 갯수가 많아지게 되며, 각 쓰레드가 DB의 한 세션을 담당하게 된다. 병렬 처리 가능여부는 Control Thread 에서 실시간으로 판단하며, 병렬 처리가 가능할 때 여러 Replay Thread 에 일감을 부여하게 된다.
Worker Threads
Resource Thread
프로세스의 CPU / Memory 사용량을 실시간으로 수집한다. 수집된 내용은 로그상에 계속해서 남겨주게 되며, 프로싱크 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.
Stat Thread
프로세스에서 발생하는 트랜잭션 의 시간당 처리량, 일종의 Throughput 을 계산한다. 프로싱크 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.
Last updated