AWS Aurora란? [1탄 - RDS MySQL과 AWS Aurora의 큰 차이점]

항상 시작만 하고 제대로 끝마무리를 짓지 못한 상태로 티스토리를 이어가는 것 같습니다. 또 오랜만의 글인데요. 이번에는 Aurora에 대한 글입니다.

 

AWS 상에서 Aurora를 구성하고 또 운영하시는 분들이 한국내에는 그렇게 많지 않은 것으로 알고 있습니다. 현재 저희회사는 굉장히 많이 쓰고 있습니다.

저의 경우에는 Seoul 리전에서 Aurora를 운영한지 2년이 다 되어 가는 것 같습니다. 1.12부터 6월에 나온 1.17.3 까지 많은 이슈를 다루어 봤는데요.

차근차근 하나씩 이야기를 풀어보려고 합니다.

 

맨 처음! Aurora는 무엇인가? 부터 시작하겠습니다. 제 사견이 많이 들어간 글임을 참고해주시기 바랍니다. 또한 MySQL에 맞춰서 글이 쓰여져 있습니다.

 

AWS Aurora란?

- AWS가 MySQL 및 Postgresql을 호환해서 만든 RDBMS라고 할 수 있습니다.

(참조 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Aurora.Overview.html)

- AWS RDS와는 또 다른 AWS만의 RDBMS로써 기존 소스들을 AWS에 맞게 고친 것이 특징입니다.

- 기존에는 MySQL 5.6 base만 지원하다가 최근에는 MySQL 5.7과 Postgresql까지 지원하고 있습니다.

 

AWS Aurora와 AWS RDS의 차이점은?

- 가장 궁금한 것이 이 부분일텐데요. 제가 느끼는 가장 큰 차이점은 스토리지입니다.

- AWS Aurora는 Shared Storage를 사용하며 MySQL의 경우 Binlog 기반의 Replication이 아닌 Storage와 Page 기반의 Replication을 사용합니다.

 

좀 더 자세한 것은 아래 그림으로 보겠습니다.

 

 

위에서 가장 큰 차이점은 스토리지라고 했습니다. 위 그림을 보시면 왼쪽은 MySQL with Replica, 오른쪽은 AWS Aurora입니다.

 

MySQL의 경우 자신의 EBS로 데이터를 쌓고 쌓은 데이터를 EBS로 미러링 한 다음 Replication을 통해 Replica로 데이터를 보내고 Replica는 받은 데이터를 자신의 스토리지로 쌓습니다.

반면 Aurora의 경우에는 4/6 쿼럼을 사용해서 스토리지에 저장하며 Replica로 보내는 것은 frm 및 redo log입니다. 그래서 network bandwidth 사용도 적으며 빠르게 변경분을 저장하고 반영할 수 있습니다. 인스턴스와 스토리지의 영역을 나눴기 때문에 이와 같은 아키텍쳐를 그릴 수 있습니다.

 

이렇게보면 Writer에 많은 DML이 들어오는 Instance의 경우 Aurora를 사용하면 적은 Replica Lag을 가지면서 서비스 운영할 수 있다는 것으로 보입니다.

이론상으로만 보면 그렇습니다. 하지만 우리는 AWS 스토리지 내부 아키텍쳐를 좀 더 보아야 합니다. 그것까지 말하면 내용이 길어 질 수 있으므로 RDS MySQL과 AWS Aurora의 차이점을 좀 더 기술해보겠습니다. Storage 아키텍쳐는 다음에 말하겠습니다.

 

RDS MySQL과 AWS Aurora MySQL의 Read Scaling

 

이전그림보다 더 심플한데요. MySQL의 경우 Read replica도 binlog를 받아서 처리해야하기 때문에 Read 뿐만아니라 Write도 같이 처리해야하는 단점이 있습니다.

AWS Aurora MySQL의 경우 Read Replica가 binlog를 읽어서 싱크를 맞추는 것이 아니라 redo log를 받아서 동기화 하기 때문에 read에만 집중할 수 있습니다.

이점은 분명히 AWS Aurora MySQL이 RDS Aurora보다 뛰어난 점이라고 말할 수 있습니다.

 

정리하자면 RDS MySQL과 AWS Aurora MySQL의 가장 큰 차이점은 Storage 및 관리주체, Read Replica의 구성 방식 세가지로 볼 수 있습니다.

- Storage : RDS MySQL은 자체 EBS로 운영하지만 Aurora MySQL은 Shared Storage를 사용한다.

- 관리주체 : RDS MySQL은 관리자가 RDS MySQL의 버전을 올리면서 사용하지만 Aurora MySQL은 AWS가 개발해서 버전 업그레이드를 주기적으로 하기 때문에 optional 또는 mandatory가 AWS에 의해 정해질 수 있다. (참조 : https://forums.aws.amazon.com/forum.jspa?forumID=60&start=0)

- Read Replica 구성 : RDS MySQL은 standby와 read replica 만들때 binlog를 사용하지만 Aurora의 경우 내부 storage 및 redo log 전송을 통해 빠른 동기화가 가능하며 bandwidth를 줄일 수 있다.

 

또한 Aurora에는 Endpoint가 4가지 있습니다. 여기서 End Point는 Client가 Database로 접근하기 위한 host 정보라고 볼 수 있죠.

- Cluster Endpoint : Writer Endpoint라는 이름으로 등장했었지만 지금은 Cluster Endpoint라고 합니다. 이게 더 헷갈리는 것 같아요. Aurora는 Single Write Cluster이기 때문에 Writer Instance만 접근 되는 endpoint이므로 Failover 되면 해당 Endpoint에 맵핑되는 Instance가 달라집니다.

- Reader Endpoint : Aurora Read Replica 들을 그룹화 한 Endpoint 입니다. 라운드 로빈으로 커넥션을 맺는 것으로 알고 있습니다.

- Instance Endpoint : 각 Aurora Instance 하나하나 들어갈 수 있는 Endpoint 입니다.

- Custom Endpoint : 등장한지 얼마 안된 Endpoint인데요. Route53이랑 비슷한 역할을 합니다. 관리요소에 따라 Endpoint를 여러개 만들 수 있습니다.

 

이렇게 정리하면 RDS MySQL을 사용하지말고 무조건 AWS Aurora MySQL을 사용해야할 것처럼 보이지만 앞으로 기술할 많은 Aurora의 문제점을 생각하면 달라질 수 있습니다.