AWS에서의 RDBMS 운영 [구성편]

시작편에 이어서 제대로 글을 써보도록 하겠습니다.

MySQL 구성

EC2

- EC2에서의 MySQL 구성은 IDC에서 구성하는 것과 같습니다. 그럼 어디서부터 어디까지 구성을 해야 하는 것이냐? 전부 다!! everything!입니다.

- MySQL도 수동으로 설치해야합니다. 물론 자유도는 가장 높은게 EC2 구성입니다.

- EC2 설치(서버 구성)에서부터 Load Balancer도 구축해야하고 여러모로 손이 많이 갑니다. 

- 단, Load Balancer도 기존에 쓰던 Hardware L4, Hardware L3 사용이 안됩니다. 무조건 software입니다. LVS를 쓰자! 하지만 EC2는 브로드캐스팅이 되지 않습니다. 이 말을 쉽게하면 서버간의 heartbeat가 안된다는거죠. keepalived를 기존에 썼다면 구성이 불가능합니다. DR구성이나 NAT 구성모두 힙듭니다. loopback 구성이 안되기 때문이죠. 그래서 proxysql을 생각하게 되었습니다.

- 이 문제는 성능상 큰 문제가 발생할 수 있습니다. Network에서 hop이 하나 늘어나게 되고, application에서는 latency가 발생합니다. 

- 기존 DR 구성

- Proxy 구성

보이시나요?? Source IP, Destination IP가 변경되는 것을 볼 수 있습니다. 또한 거치는 hop도 하나 늘어나게 되구요. 이러한 문제가 EC2로 운영할때 생기게 됩니다.

EC2에다가 MySQL을 운영하실 예정이라면.. 전 그냥 IDC 쓰는걸 권고합니다. 개인적인 의견이지만요..ㅎ EC2가 툭하면 죽기도하고.. 이때 어떻게 컨트롤할지도 문제입니다.

EBS가 살아 있어서 EBS detach하고 다른데 attach해서 써도 되지만 DB를 그렇게 운영하고 싶은 사람은 아무도 없을 것 같네요.

EC2로 MySQL을 구성하는 것은 그만큼 어려운 미션이 될 것 같습니다.

EC2로 MySQL을 구성하는 것을 간단히 결론지으면 가용성 확보가 너무나도 어렵다! 정도가 되겠네요.

RDS MySQL

- RDS MySQL은 MySQL open source를 그대로 사용합니다. 그럼 EC2와 다른 것은 무엇일까요? 좀 더 사용하기 쉽게 자동화가 되어 있습니다. 어떤 부분이?

- Click, Click으로 서버가 추가됩니다. 서버에 직접 들어가서 mysql을 설치할 필요가 없다는 것이죠.

- Backup, Restore 같은 부분이 기능으로 제공됩니다. Pin point restore(5분단위)도 가능합니다.

- 그렇다면 가용성은? RDS MySQL의 경우엔 Active Master를 생성하면 Standby Master가 자동으로 다른 zone에 생성됩니다. 하지만 접속 불가능입니다.

- 그림으로 보면 이런 느낌이라고 해야할까요?ㅎ 하나가 죽으면 자동으로 다른 zone에 있는 Server로 접근이 가능하지만 접속이 불가능합니다.

- 그렇다면 Read Replica(Slave) 서버들이 있는 경우엔 가용성을 어떻게 확보하게 될까요?

- RDS MySQL 같은 경우에는 Read Replica(Slave) 들에 대한 Load balancer가 없습니다. 그렇다면? 따로 Load balancer를 구성해서 붙여야 한다는 거죠. 불편...;;

- 또한 문제가 되는 부분은 모니터링입니다. OS단에 대한 모니터링은 cloudwatch를 통해서 봐야합니다. 하지만 이것도 1분에 하나씩 밖에 안보여주죠.

- OS에 대한 모든 모니터링이 안되고 서버가 죽어도 왜 죽었는지를 모릅니다. AWS에 Support Case를 열어서 확인하는 수 밖에요. DBA의 영역이 좁아지는 걸 느낍니다..

- MySQL을 그대로 쓰는 만큼 replication lag도 동일하게 발생합니다.

RDS MySQL을 정리하자면 EC2보다는 쉽게 설치가능하고, Backup & Restore에 대한 관리를 하지 않아도 되지만 AWS에 의존하는 만큼 불편한 점이 생긴다는 겁니다.

RDS Aurora MySQL

- RDS Aurora의 경우엔 앞에서 말씀드렸던 것처럼 open source인 mysql을 AWS에서 custom해서 사용하는 것입니다. 이때, MySQL의 버전은 5.6.10입니다.

- RDS MySQL과 비교했을때 가장 큰 차이점은 Shared Storage를 사용하는 것입니다.

- 가용성을 높히기 위해 shared Storage를 사용하게 되었고, 총 6개의 영역에 데이터를 저장합니다. 블럭단위로 데이터를 저장합니다.

- 또 다른 차이점은 RDS MySQL은 Standby Master가 자동으로 생성되고 접속이 불가능했지만 Aurora는 자동 생성이 아니며, 접속이 가능합니다.

- Aurora에서 Active Master는 Writer, Active Master가 아닌 다른 서버들은 Reader라고 부릅니다.

- 구조는 아래와 같습니다.

- Aurora는 Write Endpoint(Cluster endpoint라고도 합니다)와 Read Endpoint가 존재합니다. Writer에 대한 load balancer와 Reader에 대한 load balancer가 있다는 거죠.

- 이 load balancer도 운영을 하다보면 문제가 많긴한데요. aurora version 1.12에서 개선이 된 부분이지만 1.12 이전에는 한쪽으로 커넥션이 몰리는 현상이 있었습니다.

  aurora engineer와 말을 해봤을때 문제가 있었다고 하더군요.

- 그럼 aurora로 가면 무조건 다 해결이 될까요? 구조적 특성때문에 오는 게 성능입니다. 병렬처리는 빠르지만 bulk data에 대한 문제가 발생합니다.

- 추후에 좀 더 디테일하게 쓰겠지만 간단히 말하면 aurora는 shared storage 위에 instance가 있는 구조인데 이 사이에 api 통신을 하게 되어 있습니다.

- 일정 요청이 있을 때까지 대기를 하다가 요청이 모이면 api 통신을 해서 데이터를 가져오게 되는데요. 이 양이 채워지지 않으면 동작이 제대로 안됩니다.

- 또한 6개의 영역에 데이터를 분산해서 저장하기 때문에 reader에서 데이터를 가져올 때 6개의 영역에서 대용량의 데이터를 끌어다 쓰면 당연히 느리겠죠?

- 실제로 실험을 해보면 bulk 데이터 select시 RDS MySQL보다 Aurora가 현저히 느렸습니다.

- shared Storage라서 replication lag은 30ms seconds 내외로 상당히 적습니다만.. application에서 writer에 insert 후 reader에서 select하는 경우 데이터가 차이날 수 있습니다. 실제로 application에서 데이터를 잘 못받는 경우도 생기구요. 이런경우엔 그냥 writer에서 모든 것을 처리하도록 권고를 하는 답변을 받았습니다. IDC에서는 이러지 않았는데..

- 쓰면 쓸수록 왜 써야 하는지 모르겠는 Aurora이기도 하구요 ㅋㅋㅋ 이러말 하면 안되지만..;;ㅎ IDC에서 운영할때보다 확실히 불편하긴 합니다.

Aurora를 정리하자면 편하다! 하지만 믿을 수 없다! 정도가 되겠네요 ㅎㅎ 편한만큼 많이 경험해보고 써야합니다. 무조건 AWS 믿는 것은 추천하지 않습니다.

Aurora Deep Dive하는 것은 해당 글에서 하지 않았는데요. 추후 Deep Dive해서 쓰도록 하겠습니다. 이슈가 많은 아이라서요.

다음 글은 AWS에서의 RDBMS 구성에 이어서 Backup & Restore에 대한 것을 간단히 쓰겠습니다.

질문은 언제나 환영입니다!