네이버페이 주문/결제 DB 전환 이슈

우리팀은 네이버페이 주문/결제에 사용중인 Oracle DB 를 nBase-T 라는 분산 DB(사내 솔루션)로 전환 하고 있다.

1. DB 전환이란?

기존 애플리케이션 서버는 Oracle DB 를 사용하고 있다.

새로운 애플리케이션 서버와 nBase-T DB 로 문제없이 전환하기 위해선 실시간 DB 복제가 이뤄져야 한다.

cf) 기존 데이터 마이그레이션은 당연히 되어 있다는 전제

cf) DB 전환할 때 꼭 새로운 애플리케이션 서버가 필요한건 아니다. 우리팀은 DB 전환 뿐만 아니라 애플리케이션도 새롭게 개발하고 있다.

 

새로운 애플리케이션 서버와 nBase-T DB 가 준비되면 사용자 요청을 스위칭해서 전환을 시작한다. 이때 역동기화 복제를 해주는데 롤백을  대비한 조치다. 

 

만약 신규 서버에 문제가 생기면 기존 서버로 롤백을 해야하는데, Oracle DB 에 데이터가 없으면 안되니까 역동기화 복제를 해주는것이다. 

 

2. 네이버페이 주문/결제 DB 전환이 어려운 이유

주문/결제 후 추가 작업들이 많이 존재한다. 핵심 테이블에 연관된 다른 테이블들이 엄청 많다는 뜻이다. 만약 위 그림처럼 스위칭하려면 연관된 모든 기능들도 한번에 같이 전환해야 한다. 하지만 한번에 DB 전환 하기엔 작업 범위가 커서 리스크도 크다. 

 

cf) 아래 그림은 주문/결제 ERD 다. 핵심 테이블과 연관된 테이블들이 거미줄처럼 얽혀있다. 

 

결국 나눠서 전환 할 수 밖에 없는데, 그렇게 되면 Write 기능에 문제가 생길 수 있다. 예를 들어 구매자가 구매한 상품을, 판매자가 발주/발송하는 기능만 새로 개발해서 nBae-T 에 Write 한다고 해보자. 부분적으로 전환했기 때문에 DB 간 복제, 역동기화 복제(롤백 위해) 는 계속 이뤄져야 한다. 이때 구매한 상품을 취소하는 요청과 구매한 상품을 발주/발송하는 요청이 거의 비슷한 시간에에 오면 데이터가 꼬일 수 있다.

 

판매자가 발송해버리면 구매자는 더이상 취소 할 수 없는게 정책이라, 그에 대한 validation check 는 존재한다. 하지만 validation check 당시에는 구매자 취소가 가능해서 통과하고 취소 상태로 변경했지만 아래 6번에 의해 발송 상태로 복제되서 엎어쳐질 수 있다. 그 반대 케이스도 마찬가지다.

 

원래 테이블에 대한 operation 이 들어오면 항상 lock 을 잡고 진행한다. 상품번호로 select for update 를 하면 transaction scope 안에서 조회할 때, 조회된 row 에 대해서 transaction 이 종료될 때 까지 lock 을 잡는다. 그런데 Write DB 가 두개가 되면서 서로 각자 lock 을 잡고 진행하니까 제어가 안된다.

 

같은 테이블에 update 하지만, 기능은 따로 분리하기 위해선 결국 같은 lock 을 사용해야 한다. 이렇게 두개의 Write DB 상태에서 각자 lock 을 잡고 들어와도 제어해야 하는게 중요한 미션이었다.

 

3. 자체 구현한 jdbc driver(Dual Write Driver)

이 문제를 해결하기 위해 복제 담당 팀원분이 jdbc driver(Dual Write Driver, 이하 DWD) 구현체를 새로 만들었다. DWD 는 Oracle, nBase-T 양쪽 모두에 커넥션을 갖고 있다. 결국 lock 을 같이 잡아야 하니까 신규서버로 Write 요청이 오면 DWD 가 Oracle 에 먼저 호출하고 성공하면 그 다음에 nBase-T 를 호출한다. 이것도 성공하면 Oracle에 commit, nBase-T 에 commit 시킨다.

 

신규서버 DWD 에서 lock 을 같이 잡고 Oracle 에 먼저 Write 를 하기 때문에 아까 같은 문제는 해결할 수 있다. 그리고 이어서 nBase-T 에 저장 하고(동기방식), 비동기로 복제를 통해 또 데이터 싱크를 맞춰준다.

 

 

그리고 DWD 의 역할이 하나 더 있다. 지금까지는 Write 기능에 대한 얘기만 했는데 Select 도 중요한 포인트다.

만약 아래 그림처럼 구매자가 요청한 Write 기능으로 바뀐 상태를 판매자가 Select 한다고 해보자. Oracle 에서 nBase-T 로 데이터 복제를 하고 있지만 복제되기전에 Select 요청이 올 수 있다(시차로 인한 문제).

 

그래서 Select 요청이 오면 더미 update(id를 똑같은 id 값으로 수정하는 쿼리) 먼저 날려서 transaction scope 안에서 lock 을 잡는다. update 하게 되면 DWD 에서 Oracle, nBase-T 양쪽에 실행시키는데, Oracle 에 commit 이 됐으면 DWD 는 nBase-T 로 복제 반영되야 하는 데이터들을 확인한다. 만약 반영이 안되어 있으면 그 데이터들부터 먼저 반영시킨다. 결국 Select 결과는 데이터가 있는게 보장된다.

 

4. 정리 

DWD, 복제, 역 동기화 복제로 인해 DB 네트워크 부하가 더 높아지는 문제는 분명 있다. DB 전환중인 과도기 시점에서 데이터 무결성과 정합성을 지키기 위한 선택이었지만, 최근들어 DB 네트워크 문제로 복제지연이 발생하기도 했다. 사용자 트래픽이 계속 증가하면서 문제가 됐고 DB 네트워크 장비 교체로 해결했지만 이러한 과도기를 빨리 끝내는게 더 중요해졌다.