개요
요즘은 Service를 구성 할 때에 DB의 선택은 필연적이 되고 있다. 최근 다양한 종류 혹은 스타일의 DB들이 있지만 전통적인 Relational Database를 아직까지도 많은 분야에 이용되고 있으며, 특히 Transaction 기능이 필요한 분야에서는 필수적으로 선택이 되고 있다.
AWS에서 AWS RDS라는 DB Service를 제공하고 있다. Service형태로 DB를 제공하기 때문에 이를 사용하는 입장에서 관리적인 이점이 매우 크게 다가오기 때문에 많은 기업들과 스타트업이 service형태의 DB를 사용하고 미래의 서비스를 위해서 선택하고 있다.
이글은 AWS에서 제공하는 다양한 형태의 DB중 AWS RDS(Relational Database Service)중 MySQL과 Aurora의 장단점을 비교 해보고자 한다.
Basic
MySQL
전통적인 RDB인 MySql을 Service형태로 제공한다.
Engine의 version을 선택하고, 여기에 따르는 storage type, storage의 size, IOPs(Input/Output Operation Per Second) 또한 manual로 선택할 수 있으며, storage의 scaling에 대한 조건또한 설정해 줄 수 있다.
그외에 여타의 AWS Service에서 제공하는 기능과 유사한 DB Instance의 class, availability zone의 설정, DB의 VPC, authentication 등의 설정을 제공해준다.
현재 8.0.28 engine 버전까지 지원한다.
Aurora
Amazon에서 제공하는 Rational DB 서비스의 한 종류이며, 이는 빠른 속도, 신뢰할 수 있는 DB, 최적의 효율적인 비용으로 운영할 수 있는 서비스를 기본으로 하고 있다.
Engine을 MySQL과 PostgreSQL 둘중 선택 할 수 있고, Provisoned 혹은 serverless형태로 운영되는 서비스를 선택 할 수있다.
이외에 설정들은 기존의 MySQL service와 비슷하게 제한적인 MySQL version or PostgreSQL version을 선택할 수 있고, 라서 instance의 class, availability zone, VPC, authentication method등의 설정을 제공해준다.
Performance
성능의 경우 기본적으로 MySQL에서는 IOPS, Instance등을 어떻게 설정 하느냐에 따라서 달라질 수 있으나 동급의 instance설정의 경우 Aurora가 평균 5배 높은 throughtput을 제공하고 있다.
MySQL
SSD 혹은 Magnetic 중 선택할 수 있다.
SSD의 경우 고정된 I/O 성능의 general purpose SSD와 고가용성, 확장성, 유연성등을 위한 Provisioned IOPS SSD를 선택 할 수 있다. 최대 80,000 IOPS로 설정 할 수 있고, 예상치 못한 throughtput 혹은 데이터 full로 인한 storage autoscaling을 설정할 수 있다.
Megnetic의 경우 최대 1000 IOPS의 제한된 storage를 제공하고 autoscaling의 기능은 제공하지 않는다.
Aurora
위에서 언급한 것처럼 동일 HW상에서 standard MySQL에 비해 최대 5배의 throughtput 성능을 제공한다.
MySQL Service와는 다르게 storage를 선택할 수는 없으나 Amazon에서 상황에 맞는 managed service를 제공해주기 때문에 특정 IOPS를 설정해야하는 경우를 제외한다면 크게 문제 될것은 없다.
Compatibility
MySQL
MySQL 5.7.16 부터 8.0.28 버전의 MySQL engine을 제공한다.
Aurora
MySQL 5.6 과 5.7 버전, PostgreSQL 10.11 부터 13.5 버전의 engine을 제공한다.
Storage Auto-Scaling
MySQL
최대 6TB의 storage를 제공
Aurora
자동화된 storage size를 제공하고 최소 10BG에서 최대 64TB의 auto-Scaling을 제공한다.
Replication
MySQL
최대 5개의 replica를 제공하고 manual failover 기능을 제공한다.
Aurora
최대 15개의 replica를 제공하고 replica를 생성하는데 ms단위의 매우 빠른 속도를 제공한다. 또한 data lose가 없고 자동화된 failover를 제공한다.
Backup
두 서비스 모두 자동화된 daily backup service를 제공한다.
MySQL의 경우 backup동작중 storage의 IO가 중단되는 단점이 있지만 Aurora의 경우 DB performance에 영향을 주지 않는 Backup service를 제공해준다.
Cost
Aurora가 MySQL대비 평균 20% 정도 절감된 비용을 제공한다. 다만 이는 어디까지나 평균적인 수치일 뿐이고, 사용하는 usecase에 따라서 달라질수 있다.
예를 들어 최초 MVP 모델의 service를 제공하는 경우 Aurora Serverless를 이용한 서비스 제공은 비용절감에 매우 큰 도움을 줄 수 있다. 하지만 추후 enterprise 급의 서비스를 제공하는 경우 serverless형태 보다는 provisoned된 서비스가 비용절감에 도움이 될 수 있고, 고정적인 IOPS를 필요로 하는 서비스의 경우 Aurora보다는 MySQL service를 사용하는 것이 유용 할 수 있다.
요약
항목 | AWS MySQL | AWS Aurora |
Basic | - Suporte MySQL engine up-to 8.0.28 | - 빠르고 안정된 RDB service의 제공 - Provisoned 혹은 Serverless service제공 |
Performance | - IOPS, SSD Storage, autoscaling 선택 가능 | - 동일 HW상에서 Standard MySQL보다 최대 5배 빠른 성능 제공 - 상황에 맞는 IOPS 제공 |
Compatibility | - 5.7.16 부터 8.0.28 버전 | - MySQL 5.6 혹은 5.7 |
Storage Auto-Scaling | - 최대 6TB의 auto-scaling | - 10GB에서 최대 64TB의 auto-scaling |
Replication | - 최대 5개 - manual failover |
- 최대 15개. - ms단위의 매우 빠른속도의 replica생성 - data-lose가 없는 자동화된 failover 제공 |
Backup | - daily backup service 제공 - backup동작시 storage의 IO는 중단됨 |
- daily backup service 제공 - performance에 영향을 받지 않는 backup service 제공 |
Cost | - MySQL 대비 평균 20% 낮는 가격 |
Basi
'개발 > backend' 카테고리의 다른 글
[Backend] 쿠버네티스(K8S)를 시작해보자(2) - minikube & kubectl 설치 (0) | 2022.03.16 |
---|---|
[Backend] 쿠버네티스(K8S)를 시작해보자(1) - 이론편 (0) | 2022.03.06 |
[Backend] 공유 스쿠터 서비스 - 플라워로드 시스템 아키텍처 : AWS Architecture (0) | 2022.02.24 |
[Backend] 공유 스쿠터 서비스 - 플라워로드 시스템 아키텍처 사용 기술들 (0) | 2022.02.23 |
[Backend] 공유 스쿠터 서비스 - 플라워로드 시스템 아키텍쳐 데이터 FloW (0) | 2022.02.23 |