반응형

대부분의 시중은행은 ‘Oracle DB’라는 제품을 이용해서 데이터, 즉 고객의 돈을 관리한다. 

Oracle DB는 안정성과 성능은 이미 인정받았다. 하지만 비용이 비싸서 큰 회사가 아니면 사용하기 힘들다.


특히, Oracle DB를 쓰는 가장 큰 이유는 RAC(Real application clusters)라는 기능 때문인데, 

RAC는 간단히 말하면 하나의 DB를 여러 서버가 공유하는 기술이다.


하나의 DB를 여러 서버가 공유하기 때문에 서버 하나가 장애가 나도 데이터 정합성이 유지된다. 

즉, 서버 장애 때문에 고객의 돈이 사라지지 않는다는 의미다.



그러나 MySQL은 서버들이 DB를 공유하지 않고 서버마다 다른 DB가 있다. 

이 때문에 MySQL은 마스터와 슬레이브라는 구조의 시스템을 운용한다. 

마스터 서버로 시스템을 운용하면서 슬레이브 서버는 마스터 서버의 데이터를 특정 시점마다 복제한다. 

마스터에 장애가 나도 복제된 데이터를 가지고 있는 슬레이브로 대체해서 운용하면 된다는 이론이다.



그러나 마스터와 슬레이브가 완전 동기화 되지 않는 것이 문제다. 

마스터 서버에서 데이터가 발생한 후 슬레이브에 복제되기 전에 장애가 발생한다면 그 데이터는 유실된다. 

은행의 경우 데이터는 돈이기  때문에 고객의 돈이 사라진다. 은행이 MySQL과 같은 DB를 사용하지 않는 이유다.


카카오뱅크는 MySQL을 사용하면서 이 문제를 해결했다.

슬레이브가 마스터의 데이터를 비동기 방식으로 복제해도 데이터가 유실될 가능성을 막았다는 것이다.



카카오뱅크는 로스리스 리플리케이션(Lossless Replication)이라는 기능과 MHA(Master High Availability)라는 기능을 조합해 데이터 무손실을 유지한다.


로스리스 리플리케이션은 마스터에 변경이 생기면 ‘릴레이 로그’라는 것을 슬레이브에 남긴다. 

슬레이브가 마스터를 복제하기 전에도 릴레이 로그가 남는다. 

이는 마스터가 슬레이브에 데이터를 넘기기 전에 셧다운 된다고 해도, 슬레이브에 남아있는 릴레이 로그를 활용해서 마스터와 똑같은 데이터를 생성할 수 있다는 것이다.

MHA는 이를 기반으로 재빨리 복구하는 역할을 한다.


참고할 레퍼런스가 턱없이 부족함에도 불구하고, 금융업에 MySQL을 도입하였다는 것 자체가 신기한 도전인 것 같다.

반응형