[AWS Database] AWS RDS (part 2)

Posted by MinhHungTrinh on 2021-02-20
Estimated Reading Time 8 Minutes
Words 1.4k In Total
Viewed Times

Sau bài viết [AWS Database] Mở bát (part 1) tổng quan về database. Ở bài này mình sẽ đi chi tiết vào 1 service trong top phổ biến nhất của AWS là RDS. Nếu bạn phải làm việc với Relational Database, bạn nên tìm hiểu về nó nhé. RDS có nhiều thứ để nói lắm, vì vậy ở bài này mình sẽ nói tổng quan nhất để bạn có thể tiếp cận và có định hướng sử dụng về nó, ở phần sau có lẽ mình sẽ nói chi tiết hơn nữa nhé.

main

RDS Tổng quan

  • RDS Relational Database Service
  • Sử dụng SQL (Structured Query Language)
  • Supported Engines: PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server, Aurora
  • Là một service để quản lý DB
  • Được launch trên 1 VPC, thường thì nằm trong private subnet, control network access dựa trên security group
  • Storage sử dụng EBS (gp2 or io1), có thể tăng volume size manual hoặc auto-scaling
  • Backups: tự động với point-in-time recovery. Ngoài việc khôi phục data từ bản daily backup. Vì RDS lưu transaction log mỗi 5 phút và đẩy lên S3 nên chúng ta có thể khôi phục lại data bất cứ lúc nào theo thời gian chỉ định. [Tham khảo] (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html). Ngoài ra việc Backups expire (thời gian do mình chọn, 7-35 ngày).
  • Snapshots: thực hiện manual, Với snapshot này, bạn có thể copy sang region khác
  • Monitoring thông qua CloudWatch (Cái này cung cấp khá nhiều metric sẵn có)
  • RDS Events: dùng để lấy các event thực hiện notify bằng SNS phục vụ cho mục đích quản lý hệ thống
  • Supports Multi-AZ deployments (Hiểu đơn giản là deploy database trên 2 zone, 1 primary, và 1 backup realtime nằm ở zone còn lại, mục đích đảm bảo High Availability khi con primary có vấn đề)

Ngó qua có vẻ RDS support tận răng khá nhiều chức năng rồi. Nhưng ở đây mới chỉ là tổng quan thôi.

Tại sao sử dụng RDS

Khi bạn tự host 1 DB, bạn phải tự quản lý mọi thứ:

  • Bạn phải quản lý phần cứng (physical infrastructure)
  • Bạn phải quản lý software (OS)
  • Bạn phải quản lý ứng dụng (DB)

Khi bạn host DB trên AWS Cloud (tự cài trên EC2, không phải RDS), có một chút giảm tải:

  • AWS quản lý hardware cho bạn
  • Bạn tự quản lý software (OS)
  • Bạn phải quản lý ứng dụng (DB)

Khi bạn sử dụng RDS, AWS quản lý mọi thứ:

  • AWS quản lý hardware
  • AWS quản lý software (OS)
  • AWS quản lý ứng dụng (DB)

Từ đó thấy khi bạn mất thêm chút tiền, AWS với 1 bộ sậu to đùng sẽ chia sẽ trách nhiệm với bạn. Bạn sẽ để thời gian làm việc khác. Về vấn đề lâu dài, nhân sự bản chất là bạn đang đứng trên người khổng lồ, thực ra bạn đang tiết kiệm được nhiều chi phí.

So sánh sử dụng RDS và triển khai DB trên EC2

RDS là một service được quản lý:

  • Tự động đáp ứng các nhu cầu, tự cập nhật OS
  • Liên tục Backup và cho phép restore với chỉ rõ thời gian (point in time recovery)
  • Cung cấp dashboards để Monitoring, mình thấy khá là trực quan
  • Thêm các con Read replicas để cải thiện read performance
  • Có chức năng Multi AZ đối ứng với tình trạng Disaster Recovery
  • Maintenance windows, upgrades
  • Scaling capability (vertical and horizontal). Tức là có thể tăng size của Database cũng như tăng về số lượng Read Replica.
  • Storage thì sử dụng EBS (gp2 or io1)

NHƯNG không thể SSH vào RDS giống như bạn SSH tới các DB Instance.

Chi phí RDS

Có vài lưu ý về chi phí như sau:

  • Khi tạo 1 RDS, cần lựa chọn:
    • Instance type (on-demand and reserved)
    • Engine type (PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server, and Aurora)
    • DB instance class (dựa trên yêu cầu memory, CPU và I/O capacity)
  • Dùng bao nhiêu trả bấy nhiêu theo nhu cầu
  • Về Instance types:
    • On-demand (Trả tính phí theo giờ)
    • Reserved (discounted khá nhiều từ 30 => 70%, điều khoản cam kết từ 1-năm hoặc 3-năm)
  • Một số chi phí: Storage (GB/month) của database/ Backups (dung lượng số bản ghi backup) / Snapshot Export lên S3 (tính dung lượng lưu trữ trên S3)
  • I/O (per million requests)
  • Data transfer

Lựa chon Instance Class

Có vài loaị Instance class types lựa chon khi build RDS, ý nghĩa như tên của nó vậy:

  • Standard
  • Memory-optimized (memory-intensive, high performance workloads)
  • Burstable performance

Với Burstable performance instances

  • Có thể burst CPU performance cao hơn theo nhu cầu công việc, việc tính tiền việc burst này phụ thuộc vào việc bạn có vượt quá baseline (tức là có dùng hết lượng CPU Credit có sẵn 1 ngày, nếu hết sẽ bị tính tiền)
  • CPU credits (1 credit = 100% CPU Core utilization 1 minute)
  • Bạn sẽ nhận CPU Credit khi bạn không sử dụng CPU để tích luỹ.

Lựa chon Storage Type

General Purpose Storage (=cost-effective SSD storage):

  • Cần lựa chọn storage size
  • Bạn sẽ nhận giá trị baseline là 3 IOPS/GB. Đây là thông số liên quan tới khả năng throughput
  • Volumes dưới 1 TiB có thể burst burst tới 3,000 IOPS (sử dụng I/O credits)
  • Use with variable workloads
  • Thường sử dụng small và medium size cho DB ở môi trường DEV, TEST

Provisioned IOPS (=high-performance storage, recommended cho production):

  • Tự lựa chọn storage size và yêu cầu lượng IOPS riêng
  • Fast performance
  • Tối đa tới 80,000 IOPS max trên DB instance
  • Use when consistent high IOPS are required (I/O-intensive workloads)
  • Phù hợp với write-heavy workloads

Nếu instance chạy hết storage, tự động cấp phát storage.

Storage Auto Scaling trong RDS

main

  • Cả 2 loại storage types (gp2 & io1) đều support storage autoscaling
  • Tự động scale up storage dựa trên khối lượng công việc
  • Storage sẽ scale up tự động khi storage sử dụng gần tới ngưỡng yêu cầu trước đó.
  • Zero downtime: Bạn vừa tiết kiệm được chi phí khi không phải mua quá nhiều storage ngay từ đầu mà vẫn đạt được nhiệm vụ là Zero downtime, không bị tình trạng downtime do hết storage.
  • Phòng ngừa khối lượng công việc không lường trước, chúng ta cũng nên set max storage limit cho việc storage autoscaling.

Đây là Blog cá nhân của MinhHungTrinh, nơi mình chia sẻ, lưu giữ kiến thức. Nếu các bạn có góp ý, thắc mắc thì vui lòng comment bên dưới cho mình biết nhé. Mình luôn là người lắng nghe và ham học hỏi. Các vấn đề đặc biệt hoặc tế nhị mọi người có thể gửi email tới minhhungtrinhvn@gmail.com. Cảm ơn Mọi Người đã đọc Blog của mình. Yolo!