- It's a managed DB service for DB use SQL as a query language.
- It allows you to create databases in the cloud that are managed by AWS
MySQL, MariaDB, Aurora(AWS), Oracle...
# Advantage over using RDS versus deploying DB on EC2
DB를 EC2에서 직접 띄우지 않고 RDS를 사용했을 때의 이점
failover를 위한 replica 설정, 읽기 성능 향상을 위한 read replica 설정, 백업 및 특정 시점으로 복원 가능
RDS is a managed service
- Automated provisioning((대비)실시간으로 자원 할당하여 사용), OS patching
- Continuous backups and restore to specific timestamp (Point in Time Restore)
- Monitoring dashboards
- Read replicas for improved read performance
- Multi AZ setup for DR (Disaster Recovery)
- Maintenance windows for upgrades
- Scaling capability (vertical and horizontal)
- Storage backed by EBS (GP2 or IO1)
* But you can't SSH into your instances
# RDS Backups
자동 백업이 가능. Snapshot 사용 가능
1) Backups are automatically enabled in RDS
2) Automated backups :
- Daily full backup of the database (during the maintenance window)
- Transaction logs are backed-up by RDS every 5 minutes
=> ability to restore to any point in time (from oldest backup to 5 minutes ago)
- 7 days retention(보유) (can be increased to 35 days)
3) DB Snapshots :
- Manually triggered by the user
- Retention of backup for as long as you want
[ RDS - Read Replicas for read scalability ]
5개 까지 사용 가능, AZ/Region 상관없이 사용 가능, replica 가 master 가 될 수 있음
Async 비동기 방식
- 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
* Multi AZ keeps the same connection string regardless of which database is up. Read Replicas imply we need to reference them individually in our application as each read replica will have its own DNS name
Multi AZ 는 커넥션 스트링을 항상 같게 유지하지만 Read Replicas는 각각 자신만의 DNS 를 가지게 되므로 Read Replicas 에 대한 커넥션 스트링 앱에서 바꿔야함
# Read Replicas Use cases
분석 프로그램을 돌리기 위해 RDS read replica 를 생성하여 read replica 을 바라보게 설정.
원래의 app 엔 영향을 미치지 않음.
1) You have a production database that is taking on normal load
2) You want to run a reporting application to run some analytics
3) You create a Read Replica to run the new workload there
4) The production application is unaffected
5) Read replicas are used for SELECT only kind of state ments (NOT I/U/D)
# Read Replicas Network Cost
동일한 AZ내의 Replicas 에선 사용요금이 발생하지 않음.
In AWS there's a network cost when data goes from one AZ to another
To reduce the cost, you can have your Read Replicas in the same AZ (Free)
# RDS Multi AZ (Disaster Recovery)
싱크 복제
읽거나 쓰기 용도가 아닌 백업용도 (스케일링 용도 아님)
모든 데이터가 복제 slave 에도 쓰이게 됨.
마스터가 죽으면 slave가 마스터가 되어 failover.
복수개의 AZ 에서 세팅될 수 있음
- Sync replication
- One DNS name - automatic app failover to standby
- Increase availability
- Failover in case of loss of AZ, loss of network, instance or storage failure
- No manual intervention(끼어듬) in apps
- Not used for scaling
* The Read Replicas be setup as Multi AZ for Disaster Recovery(DR)***
[ RDS Security : 1. Encryption ]
RDS 보안 : 암호화
1. At rest encryption
KMS 를 사용하여 암호화 가능
런칭시 암호화 정의되어있어야함.
마스터가 암호화되어있지 않을 경우 Read Replica 또한 암호화 될 수 없음
- Possibility to encrypt the master & read replicas with AWS KMS - AES-256 encryption
- Encryption has to be defined at launch time
- If the master is not encrypted, the read replicas cannot be encrypted
- TDE(Transparent Data Encryption) available for Oracle and MS SQL Server
2. 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 : rds.force_ssl=1 in the AWS RDS Console (Parameter Groups)
-- MySQL : GRANT USAGE ON *.* TO 'mysqluser'@'%' REQUIRE SSL; (Within the DB)
# 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 :
1) Create a snapshot of the un-encrypted database
2) Copy the snapshot and enable encryption for the snapshot
3) Restore the database from the encrypted snapshot
4) Migrate applications to the new database, and delete the old database
: unencrypted DB => snapshot => copy snapshot as encrypted => create DB from snapshot
[ RDS Security : 2. Network & IAM ]
Network Security
- RDS databases are usually deployed within a private subnet, not in a public one
- RDS security works by leveraging security groups (the same concept as for EC2 instances) - it controls which IP/security group can communicate with RDS
Access Management
- IAM policies help control who can manage AWS RDS (through the RDS API)
- Traditional Username and Password can be used to login into the database
- IAM-based authentication can be used to login into RDS MySQL & PostgreSQL
# RDS - IAM Authentication
- IAM database authentication works with MySQL and PostgreSQL
- You don't need a password, just an authentication token obtained through IAM & RDS API calls
- Auth token has a lifetime of 15 minutes
* Benefits :
- Network in/out must be encrypted using SSL
- IAM to centrally manage users instead of DB
- Can leverage IAM Roles and EC2 Instance profiles for easy integration
로드밸런서의 인스턴스 갯수의 최소 최대 값을 정해놓고 사용. 설정값보다 수가 적은 경우 인스턴스 갯수를 확장(scale out), 적을 경우 축소(scale in)
In the cloud you can create and get rid of servers very quickly
The goal of an ASG is to :
1) Scale out (add EC2 instances) to match an increased load
2) Scale in (remove EC2 instances) to match a decreased load
3) Ensure we have a minimum and a maximum number of machines running
4) Automatically Register new instances to a load balancer
# ASGs have the follong attributes
- A launch configuration
1) AMI + Instance Type
2) EC2 User Data
3) EBS Volumes
4) Security Groups
5) SSH Key Pair
- Min Size/Max Size/Initial Capacity
- Network + Subnets Information
- Load Balancer Information
# Auto Scaling Alarms
CloudWatch alarm 을 이용하여 ASG 를 컨트롤 (Alarm 은 ASG 를 컨트롤 하기 위한 트리거 역할)
- It is possible to scale an ASG based on CloudWatch alarms
- An Alarm monitors a metric (such as Average CPU)
- Metrics are computed(집계/산정) for the overall ASG instances
- Based on the alarm :
-- We can create scale-out policies (increase the number of instances)
-- We can create scale-in policies (decrease the number of instances)
[ Auto Scaling New Rules ]
직접적으로 EC2 상태(CPU사용률 등)를 기반으로 확장 기준을 정의할 수 있음
- It is now possible to define "better" auto scaling rules that are directly managed by EC2
1) Target Average CPU Usage
2) Number of requests on the ELB per instance
3) Average Network In
4) Average Network Out
- These rules are easier to set up and can make more sense
[ Auto Scaling Custom Metric ]
사용자 정의 기준에 의해 확장 룰을 정할 수 있음.
We can auto scale based on a custom metric (eg. number of connected users)
1) Send custom metric from application on EC2 to CloudWatch
2) Create CloudWatch alarm to react to low/high values
3) Use the CloudWatch alarm as the scaling policy for ASG
# ASG Brain Dump
- Scaling policies can be on CPU, Network... and can even be on custom metrics or based on a schedule (if you know your visitors patterns)
- ASGs use Launch configurations or Launch Templates(newer)
- To update an ASG, you must provide a new launch configuration/launch template
- IAM roles attached to an ASG will get assigned to EC2 instances
- ASG are free. You pay for the underlying resources being launched
- Having instances under an ASG means that if they get terminated for whatever reason, the ASG will automatically create new ones as a replacement. (Extra safety)
- ASG can terminate instances marked as unhealthy by an LB (and hence replace them)
[ Scaling Policies of ASG ]
1. Target Tracking Scaling (타겟 기준점 정함)
- Most simple and easy to set-up
eg. I want the average ASG CPU to stay at around 40%
2. Simple/Step Scaling (상한 하한 기준 정함)
- When a CloudWatch alarm is triggered (example CPU > 70%), then add 2 units
- Whena CloudWatch alarm is triggered (example CPU < 30%), then remove 1 unit
3. Scheduled Actions (특정 스케쥴에 확장/축소)
- Anticipate a scaling based on known usage patterns
- eg. increase the min capacity to 10 at 5 PM on Fridays
# Simple Scaling vs Step Scaling :
보통 Step Scaling 사용을 추천
- Simple Scaling 은 Scaling 이 완료될 때 까지, 그리고 cooldown 시간을 기다린 후 Alarm 에 응답.
- Step Scaling 은 Scaling 이 진행 중일 때도 Alarm 에 응답. 경보 메시지 수신 가능
직전의 ASG에 의한 인스턴스 확장/축소가 실제로 효과를 내기 전에 추가적인 확장/축소가 일어나지 않도록 일정 시간 딜레이를 주는 옵션.
쿨다운 시간이 너무 길 경우 축소(scale in)시 바로 꺼져도 되는 인스턴스가 살아있어 무의미한 인스턴스 사용요금이 발생 할 수 있음. 이 경우 쿨다운 시간을 줄여 비용절감을 할 수 있음.
짧은 시간 동안 여러번의 확장/축소가 이뤄져야 할 경우 쿨다운 시간을 적게 주어야 함.
- The cooldown period helps to ensure that your Auto Scaling group doesn't launch or terminate additional instances before the previous scaling activity takes effect.
- In addition to default cooldown for Auto Scaling group, we can create cooldowns that apply to a specific simple scaling policy
- A scaling-specific cooldown period overrides the default cooldown period.
- One common use for scaling-specific cooldowns is with a scale-in policy-a policy that terminates instances based on a specific criteria or metric. Because this policy terminates instances, Amazon EC2 Auto Scaling needs less time to determine whether to terminate additional instances.
- If the default cooldown period of 300 secs is too long - you can reduce costs by applying a scaling-specific cooldown period of 180 secs to the scale-in policy.
- If your application is scaling up and down multiple times each hour, modify the ASG cool-down timers and the CloudWatch Alarm Period that triggers the scale in
[ ASG for Solutions Architects *** ]
ASG 축소시 인스턴스 제거 정책. 인스턴스가 가장 많은 AZ 를 찾은 후, 그 안에서 가장 오래된 런치 설정의 인스턴스를 찾아 제거
1. ASG Default Termination Policy :
1) Find the AZ which has the most number of instances
2) If there are multiple instances in the AZ to choose from, delete the one with the oldest launch configuration
* ASG tries the balance the number of instances across AZ by default.
2. Lifecycle Hooks
- You have the ability to perform extra steps before the instance goes in service (Pending state)
- You have the ability to perform some actions before the instance is terminated (terminating state)
eg. logging
3. Launch Template vs Launch Configuration
* Both :
ID of AMI, the instance type, the instance type, a key pair, security groups, and the other parameters that you use to launch EC2 instances (tags, EC2 user-data..)
* Differences :
1) Launch Configuration (legacy) :
- Must be re-created every time
2) Luanch Template (newer) :
- Can have multiple versions
- Create parameters subsets (partial configuration for re-use and inheritance)
- Provision using both On-Demand and Spot instances (or a mix)