DB에서의 two-phase commit에 대하여

일반적으로 two-phase commit(2pc)는 소프트웨어 개발론에 주로 나오는 내용이지만 오늘은 DB와 관련돼서 얘기를 해볼 생각이다.

 

DB의 클러스터링 기법에 주로 사용되는 편인데 아마 mysql NDB cluster 라는 놈이 2pc를 쓰고 있는 것으로 안다. (국내는 GOLDILOCKS라는 놈이 있다.) 오라클은 RAC니까 안쓰겠지? 라고 생각했는데 진짜로 생각해 보니까 2pc를 쓸거 같아서 찾아보니 진짜로 쓴다고 함.

Active-Active 시스템 하에서 트랜잭션이 서로 발생할 경우 일반적인 Standalone과는 다른 트랜잭션 제어 방식이 필요하게 된다. 네트워크 지연이나 데이터 반영 속도 등등 노드간의 차이로 인해 트랜잭션의 시간선이 어긋날 경우가 상당히 많기 때문. 이건 뭐 대부분이 알 테니.

 

2pc는 그림과 마찬가지로 request-prepare-commit을 거치는데 일반적으로 commit은 prepare-commit으로 이루어진다는 걸 생각해 봤을 때 하나의 layer가 추가되었다고 할 수 있다.( 뭐 그렇다고 1 노드에서 commit할때 진짜로 prepare 과정이 명시되는건 아니지만 ) 요는 간단하다.

노드 1)야 너 커밋할 준비 됐지?

노드 2)응 그래 됐어~

노드 1)그럼 커밋하자 하나둘셋

하고 둘다커밋하는거다.

 

이 commit의 전파 과정을 Coordinator라 불리는 하나의 노드가 담당하게 됨으로서 혼선이 없어진다. 오라클으로 치면 lsn값을 coordinator 혼자서 관리하기 때문. 이 Coordinator의 결정 또한 DBMS별로 우선순위가 다른데 어느 놈을 우선으로 지정해 주느냐에 대한 이슈도 발생하게 된다. 이 optimizing 작업을 수행해서 분배해주는 DBMS도 많다.

 

눈치챈 독자도 있겠지만 Coordinator가 있는 시스템이라면 일반적으로 insert/update/delete 등 트랜잭션을 발생시키는 작업은 Coordinator에 밀어 주는게 가장 이상적이다. Coordinator가 아닌 노드라면 Commit 전파를 위해 Coordinator에 해당 작업을 요청하게 된다. 즉 commit할때마다 네트웤 코스트를 더 요구하게 되는 셈이다.

 

DBMS의 2pc 정책은 일견 명확해 보이지만 클러스터링 시스템을 구성하는 입장에선 상당한 부담이 작용하는데, 바로 commit마다 네트워크 비용이 발생한다는 점이다. 이게 LAN환경에서는 커버가 되지만 WAN환경은... 밀리초 단위의 지연이 있는데 몇만건 트랜잭션이 발생한다? 운영하는 입장에선 감당할 수 없는 시간이다.

 

확장성 측면에서는 크게 부담은 없는 셈이다. 어차피 네트워크 코스트가 들어간다면 노드가 늘어난다고 해서 그 네트워크 코스트가 비대하게 늘어나진 않는다. ( 두놈한테 핑때리나 세놈한테 핑때리나 어차피 돌아오는 시간은 가장 느린놈 기준으로 돌아갈 거고 ) 일반적으로 네트워크 비용 때문에 2node부터 지연이 발생하지 3node부터는 네트워크 지연으로 인한 문제보다는 그 외의 성능문제가 더 많이 발생한다.

 

그래서 보통은 클러스터 노드를 구성했다고 해서 WAN환경에 구성하진 않는다. 부담이 너무 크다. 테이블 partitioning이 되는 DBMS의 경우는 조금 얘기가 다른데, WAN환경에 구성한다고 해도 데이터를 나눠서 특정 데이터는 1에다 넣고 특정 데이터는 2에다 넣는 식으로 구성할 수 있다. transaction이 발생했을때 상대 노드에 접근할 필요가 없다면 네트웤 비용도 발생하지 않을거라는 식의 논리다. 모든 DBMS가 이 기능을 지원하진 않지만, 이렇게 구성하는 경우도 간혹 있다. 이렇게 구성했을 때는 개발공수가 상당히 더 들어가므로(앱단에서 지원해 줘야 하니) 개발자들은 싫어할만한 구성이다. ㅋㅋ

 

모든 서버가 죽어버리는 상황을 대비해 Cluster+DR(replication)으로 구성하는 경우도 꽤나 있다. DR은 보통은 aync로 구성됨.