...
사용자는 고가용성을 위해 동일 혹은 서로 다른 서비스에 대해 2개 이상의 노드로 그룹을 만들어 서비스 시스템을 구성한다.
시스템은 다음 2가지 목표를 만족해야 한다.
- 단독노드로 구성한 환경에 비해 현저한 성능저하가 발생하면 안됨.
- 장애발생으로 인한 Fail-over상황에서 최소한의 서비스 다운타임만을 허용.
...
따라서, Sender가 실제 수신노드가 반영했는지를 즉각 확인하지 않아도 지연된 형태로 확인을 하고 있기 때문에 Sender가 보내야 할 로그가 상대편에 전송되지 않는 경우는 절대 발생하지 않는다. 이는 네트웍상의 네트워크상의 장애가 발생하여도 동일하게 동작이 된다.
즉, 네트웍 네트워크 장애가 발생했음을 감지하면 Sender는 정해진 주기 단위로 네트웍을 네트워크를 검사하게 되고 정상복구가 된 것을 감지하면 상대편노드의 Receiver와 연결한 후 자신이 재전송해야 하는 위치부터 다시 보내게 되는 것이다.
...
이중화의 또 다른 문제는 상대편 노드로의 xLog전송 속도보다 송신노드의 변경 트랜잭션 로그의 누적속도가 빠를 경우, 특정시점에 송신노드와 수신노드에서의 데이터의 조회결과가 다를 수 있다는 점이다. 즉, 미처 네트웍을 네트워크를 통해 상대편 노드로 전송하지 못한 트랜잭션로그가 송신노드에 누적되어 있는 경우를 의미하며 이를 이중화의 갭(Gap)이라고 부른다.
...
● Active/Standby의 의미는 서비스기준이며 Standby의 ALTIBASE는 Altibase는 종료된 상태를 의미한다.
일반적으로 다음과 같이 구성한다.
...
이러한 HA솔루션을 이용한 구성은 네트웍을 통한 이중화를 사용하고 있지 않기 때문에 절체 상황에서 이중화에 의한 데이터의 충돌문제나 이중화의 갭 문제 등은 고려하지 않아도 된다.
데이터의 지연에 대한 고려
Altibase의 이중화는 일반적으로 1.2GHz이상이 CPU에서는 평균적으로 초당 10,000tps정도의 성능을 보인다. 즉, 초당 한 개의 노드 내에서 발생하는 변경트랜잭션이 위의 성능 이내이면 네트워크를 통한 이중화도 일정부분 지연 없이 처리가 가능하다는 계산을 할 수 있다.
...
서비스자체가 Altibase 이중화를 사용하는 서비스가 지속적인 변경만 처리하는 경우라면 데이터지연은 데이터 지연은 네트워크를 통한 이중화구성에서는 이중화 구성에서는 회피할 수 없다. 하지만, 모든 트랜잭션 내에 변경에 대한 트랜잭션 양이 트랜잭션에서 변경 Data의 용량이 이중화로 감당할 수 있는 수준이고 데이터의 일시적인 지연을 고려할만한 서비스라면 사용이 가능하다고 판단할 수 있다.
...
이와 같은 구성은 예측에 의한 것이며 전송지연을 어느 정도 감안할 경우이며 만일, 전송의 지연을 고려할 수 없는 서비스라면 이중화의 설정모드를 Eager모드로 구성하는 방법을 사용할 수 있다.
이중화동작방식 | 설명 |
Lazy | 송신노드는 로컬트랜잭션의 진행과 xLog의 전송이 서로 대기하지 않음. |
Eager | 송신노드는 로컬트랜잭션을 먼저 반영한 후 xLog를 수신노드에 전송하고 반영 후 결과까지 대기 |
...
따라서, 사용자는 업무의 사안에 따라 Lazy/Eager를 구분하여 사용하면 된다. 업무가 반드시 데이터의 지연을 고려하지 않아도 된다면 성능을 발휘할 수 있는 Lazy모드를 쓰고 지연을 고려해야 하는 업무라면 Eager를 사용하면 된다. 아울러, 세션 별로 EagerLazy/lazy를 Eager를 지정할 수 있기 때문에 세션단위로 구분하여 적용하면 된다.
업무 | 이중화의동작방식 |
계좌잔고, 예수금 | 이 업무를 수행하는 세션은 Eager모드로 수행 |
로그인 타임정보 | 이 업무를 수행하는 세션은 Lazy모드로 수행 |
...
데이터충돌은 이중화 환경에서 동시에 동일한 PK를 가진 데이터를 접근하려는 경우 발생한다. 따라서, 사용자 서비스프로그램이 동일한 PK에 접근하지 않게 원천적인 서비스구성을 하는 것을 권장한다.
구성 | 서비스구성의예1 | 서비스구성의예2 |
A노드 | 변경트랜잭션 + 조회트랜잭션 | 서울, 경기 지역의 트랜잭션 |
B노드 | 조회트랜잭션 | 충청, 전라, 경상 지역의 트랜잭션 |
...
Altibase는 데이터의 충돌에 대하여 다음의 기본적인 기능을 제공한다. 각 부분별 서비스구성에 적합한 구성을 찾는 것이 중요하다.
제공방식 | 설명 | ||
REPLICATION_UPDATE_REPLACE=1 | 수신된 xLog의 Before Value와 수신노드의 대상데이터의 값이 일치하지 않아도 Update를 수행하는 방법 | ||
Master / Slave 방식 | 각 노드를 Master, Slave로 지정하여 Conflict발생 시 아래와 같이 동작한다. | ||
트랜잭션 | Master | Slave | |
Insert | 무시 | 기존 데이터 삭제 후 반영 | |
Update | 무시 | 그대로 반영 | |
Delete | 무시 | 무시 | |
TimeStamp 방식 | 이중화에 구성되는 테이블에 Conflict 발생 시 각각의 TimeStamp를 비교하여 더 이후의 발생한 데이터로 일치시키는 방법 | ||
...
지금까지 이중화가 가지는 단점 및 해결하기 위한 몇 가지 방법/방법과 기능들을 설명하였다. 중요한 것은 업무 목적에 적합하게 각각의 기능들을 잘 조합하여 활용할 것인가에 대한 설계 부분이라 할 수 있다. 설계단계에서는 아래 2가지의 선택을 충분히 고려해야 한다.
- 이중화의 동작방식은 lazyLazy, Eager 중 어떤 방법을 택할 것인가? 혹은 혼용할 경우 어떤 업무를 각각의 방식으로 서비스 할 것인가?
- 데이터 충돌 및 지연에 대해 어떤 해결방안으로 적용하는 것이 적합한가?
...
이중화로 보내지는 것은 SQL기반이 아닌 트랜잭션로그 기반이다. 따라서, 대량의 변경작업이 수행되면 변경된 데이터의 건수만큼 트랜잭션로그가 상대편노드에 전송되어야 하기 때문에 매우 빈번한 서비스를 처리하는 Busy한 시스템의 경우에는 반영이 지체되게 된다. 따라서, 대량의 변경작업은 수행은 다음의 2가지 방법을 권장한다.
- limit절을 Limit절을 이용한 소량의 변경작업으로 나누어 수행처리.
- alter session set replication = falseALTER SESSION SET REPLICATION = FALSE; 옵션을 이용하여 모든 노드에서 동일한 변경작업을 수행 (이 옵션을 수행한 세션의 트랜잭션로그는 이중화로 보내지 않겠다는 것을 의미한다.)
...
이중화를 서비스망과 분리된 전용 라인을 사용할 것을 권장한다. 특히 네트웍 네트워크 대역폭이 1G이상의 망을 사용할 것을 권장한다. 또한, 네트웍 네트워크 장애를 대비하여 2개 이상의 이중화 전용 랜카드를 구비하여 안정성을 확보할 것을 권장한다.
...