[ Aurora ]

OLTP 트랜잭션 프로세싱 지원

PostgreSQL/MySQL 호환

오토스케일링

1. Compatible API for PostgreSQL/MySQL (OLTP)

2. Data is held in 6 replicas, across 3 AZ

3. Auto healing capability

4. Multi AZ, Auto Scaling Read Replicas

5. Read Replicas can be Global

6. Aurora database can be Global for DR or latency purposes

7. Auto scaling of storage from 10GB to 128TB

8. Define EC2 instance type for aurora instances

9. Same security / monitoring / maintenance features as RDS

10. Aurora Serverless - for unpredictable / intermittent(간헐적인) workloads

11. Aurora Multi-Master - for continuous writes failover

※ Use case : same as RDS, but with less maintenance/more flexibility/more performance

 

[ Aurora for Solutions Architect ]

Operations : less operations, auto scaling storage

Security : AWS responsible for OS security, we are responsible for setting up KMS, security groups, IAM policies, authorizing users in DB, using SSL

Reliability : Multi AZ, highly available, possibly more than RDS, Aurora Serverless option, Aurora Multi-Master option

Performance : 5x performance (according to AWS) due to architectural optimizations. Up to 15 Read Replicas (only 5 for RDS)

Cost : Pay per hour based on EC2 and storage usage. Possibly lower costs compared to Enterprise grade databases such as Oracle

 

반응형

[ Aurora ]

- Aurora is a proprietary technology from AWS (not open sourced)

- Postgres and MySQL are both supported as Aurora DB (that means your drivers will work as if Aurora was a Postgres or MySQL database)

- Aurora is "AWS cloud optimized" and claims 5x performance improvement over MySQL on RDS, over 3x the - performance of Postgres on RDS

- Aurora storage automatically grows in increments of 10GB, up to 64TB

- Aurora can have 15 replicas while MySQL has 5, and the replication process is faster (sub 10ms replica lag)

- Failover in Aurora is instantaneous(즉각적인). It's High Availability native

- Aurora costs more than RDS(20% more) - but is more efficient

 

# Aurora High Availability and Read Scaling

- 6 copies of your data across 3 AZ :

  -- 4 copies out of 6 needed for writes

  -- 3 copies out of 6 need for reads

  -- Self healing with peer-to-peer replication

  -- Storage is striped across 100s of volumes

- One Aurora Instance takes writes (master)

- Automated failover for master in less than 30 seconds

- Master + up to 15 Aurora Read Replicas serve reads

- Support for Cross Region Replication

 

 

[ Aurora DB Cluster ]

쓰기(Master를 통해)와 읽기(Read Replicas를 통해)는 각각의 endpoint 를 통해 수행

[ Aurora Security ]

- Similar to RDS because uses the same engines

- Encryption at rest using KMS

- Automated backups, snapshots and replicas are also encrypted

- Encryption in flight using SSL (same process as MySQL or Postgres)

- Possibility to authenticate using IAM token (same method as RDS)

- You are responsible for protecting the instance with security groups

- You can't SSH

 

[ Aurora Serverless ]

로드량이 많아지면 Aurora database 가 추가적으로 생성됨. 반대로 적어지면 줄어듬

- Automated database instantiation and auto-scaling based on actual usage

- Good for infrequent, intermittent(간헐적인) or unpredictable workloads

- No capacity planning needed

- Pay per second, can be more cost-effective

 

[ Global Aurora ]

1개의 마스터 region, 최대 5개의 서브 region, region 당 최대 16개의 read replicas

- Aurora Cross Region Read Replicas :

  Useful for disaster recovery

  Simple to put in place

- Aurora Global Database (recommended) :

  1 Primary Region (read/write)

  Up to 5 secondary (read-only) regions, replication lag is less then 1 second

  Up to 16 Read Replicas per secondary region

  Helps for decreasing latency

  Promoting another region (for disaster recovery) has an RTO(recovery time object) of < 1 minute

 

 

반응형

'infra & cloud > AWS' 카테고리의 다른 글

[AWS] 5-1. Route 53  (0) 2021.03.24
[AWS] 4-3. ElastiCache, Redis, MemCached  (0) 2021.03.23
[AWS] 4-1. RDS, Read Replicas, DR  (0) 2021.03.22
[AWS] 3-2. EBS Snapshots, EFS, Instance Storage  (0) 2021.03.20
[AWS] 3-1. EBS  (0) 2021.03.19

+ Recent posts