RDS MySQL의 몇가지 문제점

이전에 RDS MySQL과 Aurora의 차이점을 간단히 살펴봤습니다.

이번 글에서는 RDS MySQL의 몇가지 문제점에 대해서 써보려고 합니다! AWS를 사용하면서 정말 많은 문제점들이 있지요.. 왜 써야하는지 의문이 들때도 있습니다.

RDS MySQL의 구조를 한번 더 보도록 할까요?

Aurora와는 다르게 각각의 Instance에게 Disk가 할당되어 있고 그것을 가지고 서비스를 하게 됩니다. 이로 인함 문제점들이 여러가지 발생할 수 있습니다.

1. Replication Delay

- 가장 먼저 생각나는게 Replication Delay입니다. MySQL을 운영해보신분들이라면 다들 아시겠지만 MySQL의 경우 Replication이라는 것을 이용해서 Master-Slave 구성을 합니다. 이 방식을 통해 HA 구성이 가능하며 장애가 생겼을때 여러가지 방식을 통해 복구하고 서비스를 재개할 수 있죠. 이 유용한게 그럼 왜 문제가 될까요??? 궁금하시겠죠??ㅎ

- MySQL의 Replication을 간단히 방식을 설명하면 총 3가지의 Thread를 가지고 동기화를 진행합니다. Binlog Dump Thread, I/O Thread, SQL Thread.

(https://dev.mysql.com/doc/refman/5.6/en/replication-implementation-details.html)

- Binlog Dump Thread : Master에서 Slave로 Binary Log를 전송하기 위한 Thread 입니다. Slave에 대한 정보를 모르며 요청하는 대로 데이터를 넘겨줍니다.

- Slave I/O Thread : Slave에 존재하는 Thread이며 Master로부터 어디까지 데이터를 전달받아서 Relay Log에 저장했는지를 알고 있는 Thread입니다.

- Slave SQL Thread : I/O Thread가 Relay Log에 저장한 것을 실제로 MySQL Server에 반영시키는 Thread입니다. 반영한 이후에는 Relay Log를 삭제합니다.

- 세 개의 Thread가 체계적으로 움직이지만 위험한 것은 단일 Thread 라는 것입니다.(MySQL 5.6 Version 기준)

- 만약에 Master에서 많은 트래픽을 받아도 Master에서 Slave로 데이터를 옮겨주는 것은 하나의 Thread라는 것입니다. MySQL의 특징이기 때문에 RDS MySQL 뿐만아니라 EC2에서 MySQL을 운영할때, IDC에서 MySQL을 운영할때 모두 동일한 문제가 발생할 수 있습니다. Disk Performance를 통해 좋은 성능을 낼수 있지만 원천적인 문제 해결은 아닙니다.

- 또한 RDBMS의 특징 중 하나가 정규화된 데이터이죠?? 그래서 우리가 Join을 사용하는 이유도 그렇고 정합성을 따지기도 쉽습니다. 그리고 필요한 경우엔 Alter를 하는데요. 이 DDL이 문제가 될 수 있습니다. 하나의 Thread 반영되기 까지 10시간이 걸린다면..? Thread는 다른것은 받지 못하고 하나만 10시간동안 반영합니다. 다음 thread는 10시간동안 대기하게됩니다. 주문을 한 데이터가 Master에 들어가고 Slave에서 조회를 해야하는데 10시간뒤에야 제가 주문한 내용을 받을 수 있다는 거죠. 아주 큰 문제입니다.

- 이 문제를 Aurora에서는 공유 스토리지를 사용하면서 해소했지만 RDS MySQL은 기존 MySQL 로직을 따르기 때문에 불가능합니다. pt-online-schema-change나 go-host 같은 schema change 툴이 있지만 오래걸리고 부하가 올라가기 때문에 문제가 될 수 있습니다.

- IDC에서는 sql_log_bin을 세션별로 비활성화하는 방식으로 진행할 수 있지만 RDS MySQL의 경우 parameter Group을 GLOBAL과 SESSION별로 설정할 수 없기 때문에 해당 방법을 사용할 수 없습니다.

2. Failover

- 서비스를 위해서는 Single Point of Failure를 피해야하고 HA 구성이 굉장히 중요한데요. RDS MySQL은 이를 위한 방법으로 Failover 기능이 있습니다.

- 수시로 Heartbeat를 날려서 Master에 문제가 있으면 앞단에서 Master를 바꿉니다. 이 과정에서 문제가 발생합니다.

- RDS MySQL이 어떤 방식으로 Master Change를 하는지 모르겠지만 보통 Failover 과정은 2분정도 소요되며 Connection 연결이 안되는 것은 1분정도 소요됩니다.

- 또한 기존에 Connection을 맺었던 connection은 zombie session이 되고 새로운 세션을 열었을떄만 접속이 됩니다. 즉 rollback이 제대로 안될 수 있다는 것입니다.

- AWS Support Case의 답변은 Application에서 isAlive를 확인해서 처리해야한다는 것인데 아무래도 불안할 수 있습니다. HA 구성에 대한 의구심은 2016년이나 현재나 동일합니다.

3. Load Balancing

- RDS MySQL의 Master는 Multi-AZ 구성을 기본적으로하고 문제가 생기면 Failover 할 수 있습니다.

- 하지만 Read Replica의 경우 문제가 생겼을때 Load Balancing이 되지 않습니다. 2대의 Read Replica가 있을 경우 이를 묶어주는 Load Balancer가 없습니다.

- 물론 jdbc에서 여러개의 instance를 바라보게끔 replication 구성을 할 수 있지만 read replica을 추가할때마다 또는 문제가 생겨서 제거해야할때마다 재배포를 할 수 없기 때문에 이에 대한 문제가 존재합니다. Route 53을 이용하거나 Proxy를 이용하는 방식이 있지만 Network 적으로 봤을때 Hop이 하나 더 생기는 것이기 때문에 latency가 증가할 수 밖에 없습니다.

여기까지가 RDS MySQL의 문제점인데요. 저도 이런 문제점 때문에 회사에서 RDS MySQL을 잘 사용하지 않습니다. 정말 Failover 했을때 문제가 발생해도 되는 서비스들에만 적용하고 있지만 언제 이 서비스가 중요해질지는 모르는 상태이기 때문에 이에 대한 모니터링도 분명히 해야합니다. 성능이 Aurora보다 떨어진다는 것은 분명한 사실이지만 비용적인 측면에서 어떤 것이 유리한지는 따져봐야합니다.

개인적인 의견으론 RDS MySQL보단 Aurora가 손이 덜가고 편합니다. 그래서 AWS에서는 EC2+RDMBS or NoSQL 조합 또는 Aurora를 고민하게 되는 것 같습니다.

AWS에서는 RDS에 대한 지원이 Version 지원밖에 없는 것 같아서 아쉽습니다.