[DB] maxscale 전환시 read/write 스트레스 테스트

maxscale 은 DB 프록시로 로드밸런서의 역할을 한다. 이거는 mysql 과는 상이한 프로그램으로 플러그인이라늗가에 포함되지 않고 DB 와 완전히 별개의 프로그램으로 동작한다. 전 글을 참고해도 좋을 것 같다.

 

maxscale 상속 과정

maxscale 은 master 로 write 쿼리가 들어가고 동기화 설정으로 인해 slave 까지 해당 변화가 넘어간다. (이때 주의해야 할 점은 maxscale 은 mysql 에 소속되어 있지 않기 때문에, 동기화 작업은 DB 단에서 이루어진다!) read 쿼리는 slave 로 넘겨주거나 분산해서 받거나 하는 식으로 너무 많을 경우 분산해서 받을 수 있다. maxscale 은 master 가 있고 master candidate 를 설정할 수 있는데 이 후보들은 master 가 죽은 경우 master 를 이어 받아서 master 가 하던 역할을 그대로 수행할 수 있다.

 

write 쿼리 스트레스 테스트

그렇다면 이 전환 과정에서 write 쿼리가 거대하게 들어온다면? 어떻게 될것인가? 해당 부분의 쿼리는 잘 처리가 될 것인가? 에 대한 의문이 들어서 테스트를 진행하게 되었다. 결론적으로 말하자면 완전하지는 않다. 해당 테스트는 VirtualBox 와 ubuntu live 20.04 LTS 로 진행을 하였고, 4중화되어 있는 서버에 테스트를 진행하였다. 초당 write 를 쏜 횟수는 10회 - 50회 정도 진행하였다. 당연하게도 쿼리는 DB 프록시인 maxscale 포트로 쐈다.(mysql 에 직접 write 쿼리를 쏘면 그 순간 동기화가 깨진다) 테스트는 결론적으로 말하자면 종료되었던 master 가 다시 켜지는 시점에깨진다. 

 

동기화가 깨지는 시나리오

1번이 master 였고 원래 write 쿼리를 받고 있었다. 근데 1번이 종료가 된다면 master candidate 인 2번이 master 로 전환하는데 10초간의 시간이 걸린다. 그 사이에 쿼리는 session time out 이 나며 전송되는데 실패한다. 10초가 지나고 server 2 가 master 로 올라오면 그때부터는 server2 가 write 를 잘 받는다. 그렇지만 server 1 이 다시 켜진다면? 이때 server 1 에 write 이 들어가면서 동기화가 깨진다. 동기화가 깨지는 원인은 자세히는 모르겠지만, server 1이 slave 로 세팅되기 전에 master 로 인식된 쿼리가 캐시되어 남아있던게 처리되며 mysql 에 직접 write 를 쏴서 그런게 아닌가... 라는 의심을 한다. 아 read 쿼리로는 아무 문제가 없다. read 쿼리는 어디에 쏴지든 상관이 없기 때문이다. 

 

이 문제를 해결하기 위해 관리 서버에 DB 동기화를 할 수 있는 UI 를 추가하거나, k8s 를 도입하거나 하는 방식으로 진행을 해야 할 것 같다. 클라우드에 대한 좋은 실험이었던 것 같다.