코로나19 때문에 집에서 한 2주를 쉬니깐(회사에서 나오지 말라고 했음), 게임만 하다가 지쳐서.. 공부를 해야겠다는 욕구가 들어 페이스북을 켰고(?), 좋은 자료를 발견하게 되어, 오랜만에 포스팅을 함.
기존에 MySQL을 운영해본 경험으로 보면, 기본 제공하는 기능만으로 절대 HA(고가용성)을 지원할 수 없는 것이 MySQL 인 것 같다.
경쟁사 제품인 MS SQL Server와 비교했을 때도, 성능 면에서라던지 여러가지 기능이 부족해보이긴 하지만, 결론적으로 사용하다보면 DBMS 자체가 다 비슷하다고 본다. 유료냐 무료냐의 차이일 뿐.
MySQL은 HA를 지원하지 않지만, Replication은 지원을 하기 때문에, 데이터가 유실될 경우 Replication 구성을 통해 복원도 가능하며, 사용자가 은근히 많아서 지원하는 툴도 많다. 유료버전을 쓰면 Cluster구성도 가능하다고 하는데, 돈주고 굳이 그렇게 쓰는사람이 몇이나 될까?
MySQL을 운영하다보면, Replication만으로 운영을 하는 것은 한계가 있다는 것을 깨닫고, 좀 더 효율적인 분산을 위해 Application 레벨에서의 Sharding도 구현을 해보고, Redis를 앞에 둬서 Cache Aside 패턴으로 DBMS의 부하를 줄이는 방법도 고려를 했다.
다만, 이 방법들은 서비스해야 하는 Application Server가 동시접속자를 10만 ~ 100만정도가 예상될 경우, DBMS에서 감당해야하는 Connection 문제가 생기게 된다.
동시접속자 100만을 받아야한다고 칠 때, Application Server하나가 동시접속자 5천을 커버하고, DBMS 하나가 2만명을 받아야 한다고 쳐보면, Application Server가 200대, DBMS가 50대 필요할 것이고, Application 레벨에서 Connection Pool을 구현해서 최소 30개의 Connection을 유지해야 한다면, DBMS가 감당해야 하는 Connection 수는 상상을 초월하게 될 것이다. (30 * 200 * 50 = 30만!)
이런 이슈를 피하기 위해, 중간에 Middle Ware 개념의 Query Dedicate Server를 만들어서 운영하는 경우도 있긴한데, 구현 및 관리하기가 어렵고, 일반적으로 자체구현한 Middle Ware가 DBMS Native Protocol을 지원하는 것은 쉽지 않으므로, 성능이슈가 생기게 된다.
이런 것들을 해결해줄만한 아래와 같은 솔루션이 있었다는 것을 최근에 알게 되었다.
이 솔루션이 해주는 역할은 명확하다.
1. Application과 DBMS 사이에서 Middle Ware역할을 해주면서, Connection Multiplexing을 제공해준다.
(Connection Multiplexing이란, 출발지에서 요청한 수 많은 커넥션이 있을 때, 그 커넥션의 성격이 비슷한 경우 하나의 커넥션으로 인식하여, 효율적으로 사용할 수 있도록 해주는 기능을 의미한다.)
2. MySQL Native Protocol을 지원하기 때문에, Application에서 MySQL 붙는 것처럼 IP정보만 교체해주면 되고, 그렇기 때문에 성능 이슈가 없을 거라고 생각됨.
3. Query를 Routing할 수 있도록 Admin기능을 제공해준다.
(ProxySQl이 제공하는 Meta Table에다가 MySQL Host들을 Seq 기반으로 등록하고, 출발지의 Connection의 정보 중 MySQL User와 MySQL DB정보를 읽어서 내가 원하는 MySQL Host로 보낼 수 있도록 제공)
3번 같은 경우는 HA Proxy와 L7을 이용해서도 충분히 만들어낼 수는 있는데, Connection Multiplexing이 안되는 것은 둘째치고, HA Proxy 설정하는 것이 만만치는 않아서, 실 서비스에 사용을 고려하진 못했었다.
좋은 솔루션을 알게 되었으니, 직접 세팅해보면서 이후에 추가로 포스팅해야겠음.
