Thursday 15 April 2021

AWS : Relational Database Service (RDS) - Basics Part 1

==============================================================
What is Amazon RDS?

• Managed relational database service in the AWS cloud
• Multi-engine support: Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL Server
• Automated provisioning, patching, scaling, replicas, backup/restore
• Easily scales to handle growth•High availability with Multi-AZ and Amazon Aurora

==============================================================

Why use Amazon RDS?

• Lower TCO because RDS manage “the muck”
    • Get more leverage from your teams
    • Focus on the things that differentiate you
• Built-in high availability and cross-region replication across multiple data centers
• Even a small startup can leverage multiple data centers to design highly available apps with over 99.95% availability

==============================================================
Which RDS engine should I use?

Amazon EBS-based Storage :
- Commercial : SQL Server and Oracle
- Open Source : MySQL , PostgreSQL and MariaDB
Aurora Storage System :
- AWS Cloud Native : MySQL CompatiblePostgreSQL Compatible

==============================================================
Which instance type should I choose?

- T2 Family
    • Burstable instances
    • 1 vCPU/1 GB RAM > 8  vCPU 32 GB RAM
    • Moderate networking performance
    • Good for smaller or variable workloads
    • Monitor CPU credit metrics in Amazon CloudWatch
    • T2.micro is eligible for free tier

- M3/M4 Family
    • General-purpose instances
    • 2 vCPU/8 GiB RAM > 64 vCPU 256 GiB RAM
    • High-performance networking
    • Good for running CPU intensive workloads (e.g., WordPress)

- R3/R4 Family
    • Memory-optimized instances
    • 2 vCPU/16 GiB RAM > 64 vCPU 488 GiB RAM
    • High-performance networking
    • Good for query-intensive workloads or high connection counts
==============================================================
Configuring DB Instance Class Processor ?

Modify processor features to optimize DB instance for specific workloads:
• Number of CPU Cores –Optimize licensing costs for instance with sufficient RAM for memory-intensive workloads, but fewer CPU cores
• Threads per Core –Disable Hyper-Threading for, e.g. HPC workloads

Changes can be applied when you:
• Create a DB instance
• Modify a DB instance
• Restore a DB instance from a snapshot
• Restore a DB instance to a point in time
==============================================================
Which AWS EBS storage type should I choose?

- General purpose (GP2)
    • SSD storage
    • Maximum of 16 TB
    • Leverages Amazon EBS Elastic Volumes
    • IOPS determined by volume size
    • Minimum of 100 IOPS (below 33.33GiB)
    • Bursts to 3,000 IOPS (applicable below 1.3 TB)
    • Baseline of 16,000 IOPS (at 3.3 TB and above)
    • Affordable performance

- Provisioned IOPS (IO1)
    • SSD storage•Maximum of 16 TB
    • Leverages Amazon EBS Elastic Volumes
    • Maximum of 40K IOPS (32K on SQL Server)
    • Delivers within 10% of the IOPS performance 99.9% of the time
    • High performance and consistency

- Magnetic
    • Magnetic storage
    • Maximum of 1 TB
    • Supported for legacy databases

- General purpose (GP3), is coming soon.
==============================================================
How do I decide between GP2 and IO1 AWS EBS Storage Type? Why am I not seeing less IOPS or only 30 K IOPS?

• GP2 is a great choice, but be aware of burst credits on volumes < 1 TB
    • Hitting credit-depletion results in IOPS drop—latency and queue depth metrics will spike until credits are replenished
    • Monitor BurstBalance to see percent of burst-bucket I/O credits available
    • Monitor read/write IOPS to see if average IOPS is greater than the baseline

==============================================================
How do I scale my database instance? Will there be downtime ?

• Scale compute/memory vertically up or down
    • Handle higher load to grow over time
    • Lower usage to control costs
    • New host is attached to existing storage with minimal downtime

• Scale up Amazon EBS storage (now up to 16 TB)
    • Amazon EBS engines now support Elastic Volumes for fast scaling (now including SQL Server)
    • No downtime for storage scaling
    • Initial scaling operation may take longer, because storage is reconfigured on older instances
    • Can re-provision IOPS on the fly

==============================================================

No comments:

Post a Comment