Stephane Maarek의 「Ultimate AWS Certified Developer Associate 2021 - NEW!」 강의 내용 정리

1. AWS RDS

RDS stands for Relational Database Service
It’s managed DB service for DB which uses SQL as a query language
It allows you to create databases in the cloud that are managed by AWS

Advantage Over Using RDS vs Deploying DB on EC2

RDS is a managed service

• automated provisioning, OS patching
• continuous backups and restore to specific timestamp
• monitoring dashboards
• read replicas for improved read performance
• multi AZ setup for disaster recovery
• maintenance windows for upgrade
• scaling capability(both vertical and horizontal)
• storage backed by EBS

➜ but you can’t SSH into your instances

RDS Backups

Backups are automatically enabled in RDS
Automated backups:

• daily full backup of the database
• transaction logs are backed-up by REES every 5 minutes → ability to restore to any point in time
• 7 days retention(can be increased to 35 days)

DB snapshots

• manually triggered by the user
• retention of backup for as long as you want

2. RDS Read Replicas vs Multi AZ

Read Replicas

Help you to scale your reads
Up to 5 read replicas
Within AZ, Cross AZ or Cross Region
Replication is ASYNC so reads are eventually consistent
Replicas can be promoted to their own DB
Applications must update the connection string to leverage read replicas
Read replicas are used for SELECT only

Network Cost

In AWS there’s a network cost when data goes from one AZ to another
If the read replica is in the same AZ with main DB, it’s free
To reduce the cost, you can have your Read Replicas in the same AZ

RDS Multi AZ(Disaster Recovery) ➜ standby

SYNC replication
When your application writes to the master, that change needs to be replicated to the standby to be accepted
One DNS name -> automatic app failover to standby(Failover in case of loss of AZ, loss of network, instance or storage failure)
Increase availability
No manual intervention in apps
➜ The read replicas can be setup as Multi AZ for Disaster Recovery

3. RDS Security - Encryption

At rest encryption

• possibility to encrypt the master & read replicas with AWS KMS
• encryption has to be defined at launch time
• if the master is not encrypted, the read replicas cannot be encrypted
• Transparent Data Encryption(TDE) available for Oracle and SQL server

In-flight encryption

• SSL certificates to encrypt data to RDS in flight
• provide SSL options with trust certificate when connecting to database
• to enforce SSL:
  • PostgreSQL: parameter groups
  • MySQL: SQL command within the database

RDS Encryption Operations

Encrypting RDS backups

• snapshots of un-encrypted RDS databases are un-encrypted
• snapshots of encrypted RDS databases are encrypted
• can copy a snapshot into an encrypted one

To encrypt an un-encrypted RDS database:
create a snapshot of the un-encrypted db → copy the snapshot and enable encryption → restore the db from the encrypted snapshot → migrate applications into new db and delete the old one

RDS Security - Network & IAM

Network Security

• RDS db are usually deployed within a private subnet, not in a public one
• RDS security works by leveraging security groups

Access MGMT

• IAM policies help control who can manage RDS
• traditional Username and Password can be used or IAM-based authentication can be used to login into RDS MySQL & PostgreSQL

RDS - IAM Authentication

You don’t need a pw, just an authentication token obtained through IAM & RDS API calls
Auth token has a lifetime of 15 minutes

4. Amazon Aurora

Aurora is a proprietary technology from AWS(not an open source)
Postgre and MySQL are both supported as Aurora DB
Better performance than MySQL & Postgre on RDS

Aurora High Availability and Read Scaling

6 copies of your data across 3 AZ
One Aurora Instance takes writes(only one master!)
Automated failover for master in less than 30 secs
Master(writer endpoint) + up to 15 read replicas(auto scaling.. -> reader endpoint) => shared storage volume(auto expanding from 10GB to 64 TB)
Support for Cross Region Replication

Features of Aurora

• automatic failover
• backup and recovery
• isolation and security
• industry compliance
• push-button scaling
• automated patching with zero downtime
• advanced monitoring
• routine maintenance
• backtrack: restore data at any point of time without using backups

Aurora Security -> similar to RDS

Aurora Serverless

Automated database instantiation and auto scaling based on actual usage
Good to infrequent, intermittent or unpredictable workloads
No capacity planning needed
Pay per second -> cost effective

Global Aurora

Aurora Cross Region Read Replicas:

• useful for disaster recover
• simple to put in place

Aurora Global Database

• 1 primary region
• up to 5 secondary regions
• up to 16 read replicas per secondary region
• helps for decreasing latency

5. ElastiCache(RDS for caches)

The same way RDS is to get managed Relational DB, ElastiCache is to get managed Redis or Memcached
Caches are in-memory databases with really high performance, low latency
Helps reduce load off of databases for read intensive workloads
Helps make your application stateless
Write scaling using sharing
Read scaling using read replicas
Multi AZ capability

ElastiCache Solution Architecture

1. DB Cache -> to relieve load off a database
   Applications queries ElastiCache first(-> the retrieval will be quick & fast). If not available, then get from RDS and store in ElastiCache
   Helps relieve load in RDS
   Only the most current and relevant data is in the cache
2. User Session Store -> to share some states
   When user logs in, the application writes the session data into ElastiCache
   The user hits another instance of our application, the instance retrieves the data and make sure user don’t have to log in agin

Redis vs Memcached

1. Redis
   multi AZ with auto failover
   read replicas to scale reads and have high availability
   data durability using AOF persistence
   backup and restore features
   very similar to RDS
2. Memcached(pure cache)
   multi-node for partitioning of data
   non persistent
   no backup and restore
   multi-threaded architecture

Lazy Loading / Cache-Aside / Lazy Population

DB cache

Pros:

• only requested data is cached(the cache isn’t filled up with unused data)
• node failures are not fatal(just increased latency to warm the cache)

Cons:

• cache miss penalty that results in 3 round trips(cache miss, read from DB, write to cache)
  → noticeable delay for the request
• stale data: data can be updated in the db but outdated in the cache(make sure they are consistent)

Write Through - add or update cache when db is updated

Pros:

• data in cache is never stale, reads are quick
• write penalty vs read penalty(each writerequires 2 calls → one to db, one to cache)

Cons:

• missing data until it is added / updated in the db
  → implement lazy loading strategy as well
• cache churn → a lot of the data will never be read

Cache Evictions and Time-to-live(TTL)

Cache eviction can occur in three ways:

• you delete the item explicitly in the cache
• item is evicted because the memory is full
• you set an item time-to-live

TTL can range from few seconds to hours or days(set it to a sensible value) If too many evictions happen due to memory, you should scale up or out