RDS, Aurora & ElastiCache

RDS, Aurora & ElastiCache สำหรับ DVA-C02 — Managed Relational Databases และ In-Memory Caching

Database 28 นาที 22 คำถาม

01Amazon RDS Overview

Amazon RDS (Relational Database Service) คือบริการ managed database สำหรับฐานข้อมูลเชิงสัมพันธ์ (relational) ที่ใช้ SQL ในการ query ข้อมูล AWS จัดการงานหนัก (heavy lifting) ให้ เช่น การ provisioning, patching OS, backup, monitoring และ scaling โดยที่เราไม่ต้องดูแล infrastructure เอง

Database Engines ที่รองรับ

PostgreSQL
MySQL
MariaDB
Oracle
Microsoft SQL Server
IBM Db2
Aurora (AWS proprietary database — MySQL/PostgreSQL compatible)

ข้อดีของ RDS เทียบกับการ deploy DB เองบน EC2

Automated provisioning และ OS patching
Continuous backups และ restore ไปยังจุดเวลาที่กำหนด (Point in Time Restore)
Monitoring dashboards ดูสุขภาพของ DB
Read Replicas เพื่อ scale การอ่าน (read scalability)
Multi-AZ setup สำหรับ Disaster Recovery (DR)
Maintenance windows สำหรับ upgrades
Storage และ compute scaling ได้
สามารถ encryption และ network isolation ผ่าน VPC ได้

กับดักข้อสอบ: เข้า SSH ไม่ได้

เพราะ RDS เป็น managed service เราจึง ไม่สามารถ SSH เข้าไปยัง instance ของ RDS ได้ (ยกเว้น RDS Custom สำหรับ Oracle/SQL Server) ถ้าโจทย์ต้องการสิทธิ์ระดับ OS หรือต้องลง software เพิ่มบนเครื่อง DB ต้องไป deploy DB บน EC2 เองแทน

02RDS Storage Auto Scaling

RDS Storage Auto Scaling ช่วยเพิ่มพื้นที่จัดเก็บ (storage) ของ RDS instance ให้โดยอัตโนมัติเมื่อพื้นที่ใกล้เต็ม โดยที่เราไม่ต้องเข้าไปปรับขนาดด้วยมือ (no manual intervention)

ทำงานเมื่อ RDS ตรวจพบว่าพื้นที่ว่างเหลือน้อย
เราตั้งค่า Maximum Storage Threshold (เพดานสูงสุดที่ยอมให้ขยายได้)
เพิ่ม storage อัตโนมัติเมื่อ: free storage เหลือ น้อยกว่า 10%, สถานะ low-storage นานเกิน 5 นาที, และผ่านการ modify storage ครั้งล่าสุดมาแล้วอย่างน้อย 6 ชั่วโมง
มีประโยชน์มากกับ workload ที่คาดเดาไม่ได้ (unpredictable)
รองรับทุก database engine ของ RDS

Tip ข้อสอบ

ถ้าโจทย์บอกว่า application มี traffic ที่คาดเดาไม่ได้ และทีมไม่อยากมานั่งเฝ้าเพิ่ม storage เอง คำตอบคือเปิด RDS Storage Auto Scaling และกำหนด Maximum Storage Threshold

03Read Replicas vs Multi-AZ

นี่เป็นหัวข้อที่ออกสอบบ่อยที่สุดของ RDS ต้องแยกให้ชัดว่า Read Replicas มีไว้เพื่อ scale การอ่าน (read scalability) ส่วน Multi-AZ มีไว้เพื่อ disaster recovery / high availability ไม่ใช่เพื่อ scaling

RDS Read Replicas

ใช้สำหรับ scale การอ่าน — รองรับสูงสุด 15 Read Replicas ต่อ instance ใช้ asynchronous replication ดังนั้นการอ่านจาก replica อาจเป็นแบบ eventually consistent Replica สามารถถูก promote ให้เป็น database ของตัวเองได้ application ต้อง อัปเดต connection string เองเพื่อกระจาย query การอ่านไปยัง replicas สร้างได้ทั้ง within-AZ, cross-AZ และ cross-region

RDS Multi-AZ (Disaster Recovery)

ใช้ synchronous replication ไปยัง standby instance ในอีก AZ หนึ่ง มี DNS name เดียว และทำ automatic failover ไปยัง standby เมื่อ master ล่ม โดย application ไม่ต้องแก้อะไร standby ใช้สำหรับ failover เท่านั้น (ไม่สามารถอ่านหรือเขียนได้) — เพิ่ม availability ไม่ได้ scale

มิติ	Read Replicas	Multi-AZ
จุดประสงค์หลัก	Scale การอ่าน (read scaling)	High Availability / DR / failover
ชนิด Replication	Asynchronous (eventually consistent)	Synchronous
จำนวน	สูงสุด 15	1 standby (Multi-AZ instance) หรือหลาย readable standby (Multi-AZ cluster)
อ่าน/เขียนจาก replica/standby	อ่านได้ (read-only)	อ่านไม่ได้ (เฉพาะ failover)
ขอบเขต	Within-AZ / Cross-AZ / Cross-Region	ภายใน Region เดียว (ข้าม AZ)
Connection string	ต้องแก้เองให้ชี้ไป replica	ไม่ต้องแก้ (DNS เดียว, failover อัตโนมัติ)

การเปลี่ยน Single-AZ เป็น Multi-AZ

การเปลี่ยนจาก Single-AZ ไปเป็น Multi-AZ ทำได้แบบ zero downtime เพียงกด "modify" บน RDS database โดยไม่ต้องหยุด DB เบื้องหลัง AWS จะถ่าย snapshot ของ master นำไป restore สร้าง standby แล้วทำ synchronization ให้

กับดักข้อสอบ: Cross-Region replication cost

Read Replica ภายใน Region เดียว (across AZ) การโอนข้อมูล replication ฟรี แต่ถ้าเป็น Cross-Region Read Replica จะมี ค่า network transfer ของ replication ข้าม region ระวังโจทย์ที่ถามเรื่องค่าใช้จ่าย network

04RDS Security

Encryption

At-rest encryption ใช้ AWS KMS (AES-256) ต้องเลือกตอนสร้าง database (launch time)
In-flight / in-transit encryption ใช้ SSL/TLS เพื่อเข้ารหัสข้อมูลที่วิ่งระหว่าง client กับ DB
ถ้า master ไม่ได้เข้ารหัส Read Replica ก็ ไม่สามารถเข้ารหัสได้
วิธีเข้ารหัส DB ที่ไม่ได้เข้ารหัสตอนแรก: ทำ snapshot ของ DB แล้ว copy snapshot โดยเปิด encryption จากนั้น restore จาก encrypted snapshot นั้น

Access Management

Security Groups ควบคุม network access (เปิด/ปิด port และ IP/SG ที่เข้าถึงได้)
IAM Database Authentication — ใช้ได้กับ MySQL, PostgreSQL และ MariaDB: ดึง authentication token ที่มีอายุ 15 นาที จาก IAM แทนการใช้ username/password
IAM policies ควบคุมว่าใครจัดการ RDS (management actions) ได้
ค่า traditional username/password ยังใช้ login เข้า DB ได้ตามปกติ

Tip ข้อสอบ: IAM Authentication กับ EC2/Lambda

ข้อดีของ IAM Database Authentication คือ network traffic ไป-มากับ RDS ถูกเข้ารหัสด้วย SSL, สามารถ จัดการ users แบบรวมศูนย์ผ่าน IAM แทนที่จะกระจาย credentials ในหลายที่ และใช้ IAM Roles ของ EC2 ในการ authenticate เข้า DB ได้ ทำให้ไม่ต้อง hardcode password — โจทย์มักถามว่าจะหลีกเลี่ยงการเก็บ DB password อย่างไร

กับดักข้อสอบ: ลืมเรื่อง encrypt replica

จำให้แม่น: encrypted master => encrypted replica ได้ แต่ unencrypted master => ทำให้ replica encrypted ไม่ได้ และไม่สามารถเปลี่ยน DB ที่ไม่เข้ารหัสให้กลายเป็นเข้ารหัสได้โดยตรง ต้องไปผ่าน snapshot + copy with encryption เท่านั้น

05RDS Proxy

RDS Proxy เป็น fully managed database proxy สำหรับ RDS ที่ช่วยทำ connection pooling โดยรวม connection จากหลาย application มา share กัน ทำให้ลดจำนวน connection ที่กระแทกตรงไปยัง database ลดการใช้ CPU/RAM ของ DB

ทำ connection pooling ลดจำนวน open connections ไปยัง DB
เป็น Serverless, autoscaling, Highly Available (ทำงานข้ามหลาย AZ)
ลด failover time ลงได้ถึง 66%
รองรับ RDS (MySQL, PostgreSQL, MariaDB), Aurora (MySQL, PostgreSQL) และ MS SQL Server
ไม่มี code changes ฝั่ง application (แค่เปลี่ยน endpoint ไปชี้ที่ proxy)
บังคับใช้ IAM Authentication และเก็บ credentials ใน AWS Secrets Manager ได้
ไม่สามารถเข้าถึงได้จาก public internet (เข้าถึงผ่าน VPC เท่านั้น)

Tip ข้อสอบ: RDS Proxy + Lambda

ถ้าโจทย์มี AWS Lambda ที่ scale ขึ้นจำนวนมากแล้วเปิด connection ถล่ม RDS จน "too many connections" หรือ DB connection หมด คำตอบคือ RDS Proxy เพราะมันรวม (pool) และ reuse connections ระหว่าง Lambda invocations หลายตัว ลด failover time และจัดการ IAM auth ให้ด้วย

06Amazon Aurora

Amazon Aurora เป็น database technology แบบ proprietary ของ AWS ที่ compatible กับ PostgreSQL และ MySQL Aurora ถูกออกแบบมาให้ cloud-optimized โดย AWS เคลมว่าเร็วกว่า MySQL บน RDS ประมาณ 5 เท่า และเร็วกว่า PostgreSQL บน RDS ประมาณ 3 เท่า ในราคาที่สูงกว่า RDS ประมาณ 20% แต่คุ้มค่ากว่าในระดับ scale ใหญ่

Storage & High Availability

Storage auto-grow ทีละ 10GB ได้สูงสุดถึง 128 TB
เก็บข้อมูล 6 copies ข้าม 3 Availability Zones
เขียนสำเร็จเมื่อได้ ack จาก 4 ใน 6 copies (write), อ่านจาก 3 ใน 6 copies (read)
Storage มี self-healing อัตโนมัติด้วย peer-to-peer replication
รองรับ Read Replicas ได้สูงสุด 15 ตัว และ failover แทบจะทันที (instantaneous) — เร็วกว่า Multi-AZ ของ RDS

Aurora Endpoints

Writer Endpoint (Cluster Endpoint) — ชี้ไปยัง master เสมอ ใช้สำหรับ write; เมื่อ failover จะชี้ไป master ใหม่อัตโนมัติ จึงไม่ต้องแก้ connection string
Reader Endpoint — ทำ connection load balancing กระจาย read ไปยัง read replicas ทั้งหมดอัตโนมัติ
Custom Endpoints — กำหนด subset ของ instances เองได้

Aurora Replica Auto Scaling

Aurora สามารถ auto scaling จำนวน read replicas ขึ้น-ลงตาม load ได้ และ Reader Endpoint จะรวม replicas ใหม่เข้า load balancing ให้อัตโนมัติ

Aurora Global Database

1 Primary Region (read/write) และมากสุด 5 secondary regions (read-only) replication lag ต่ำกว่า 1 วินาที เพิ่ม secondary region ได้สูงสุด 16 read replicas ใช้ promote secondary เป็น primary ได้ภายใน RTO < 1 นาที — ตอบโจทย์ disaster recovery ระดับ cross-region

Aurora Serverless

Automated database instantiation และ auto-scaling ตาม load จริง ไม่ต้อง provision capacity ล่วงหน้า จ่ายตามที่ใช้ (per-second) เหมาะกับ workload ที่ไม่สม่ำเสมอ ไม่ต่อเนื่อง หรือคาดเดายาก (intermittent/unpredictable)

Aurora Backtrack

ย้อนเวลา (rewind) ฐานข้อมูลกลับไปยังจุดเวลาใดก็ได้โดย ไม่ต้อง restore จาก backup เหมาะกับการกู้คืนจากความผิดพลาด เช่น เผลอลบข้อมูล (เฉพาะ Aurora MySQL)

Tip ข้อสอบ: Writer vs Reader Endpoint

โจทย์มักถามว่า application ควรเชื่อมต่อ endpoint ไหน: write queries => Writer/Cluster Endpoint, read queries => Reader Endpoint (ได้ load balancing อัตโนมัติ) ห้ามใช้ instance endpoint ตรง ๆ ของ replica แต่ละตัวเพราะจะไม่รองรับ failover/auto scaling

07Amazon ElastiCache Overview (Redis vs Memcached)

Amazon ElastiCache เป็น managed in-memory cache (Redis หรือ Memcached) ที่ให้ performance สูง latency ระดับ sub-millisecond ช่วยลดภาระของ database โดยเก็บผลลัพธ์ query ที่อ่านบ่อย ๆ ไว้ใน memory เหมือน RDS ที่ AWS จัดการ maintenance/patching/backups/recovery ให้

มุมมอง Developer: ทำไมต้องใช้ Cache

Cache database query — ลด load บน DB โดยเก็บผลลัพธ์ query ที่ใช้บ่อยไว้ใน cache
Store session / user state — เก็บ session ไว้ใน ElastiCache เพื่อให้ application เป็น stateless (ไม่ว่า request จะวิ่งไป instance ไหนก็เห็น session เดียวกัน)
การใช้ cache บังคับให้เราคิดเรื่อง data invalidation (ทำให้ข้อมูลเก่าหายไปเมื่อ source เปลี่ยน)

มิติ	Redis	Memcached
Multi-AZ / Failover	รองรับ (Multi-AZ with auto-failover)	ไม่รองรับ
Replication (Read Replicas)	รองรับ (read replicas เพื่อ scale อ่าน + HA)	ไม่มี replication
Data Persistence (AOF)	รองรับ persistence / backup & restore	ไม่มี persistence (in-memory ล้วน)
Data structures	หลากหลาย: Sets, Sorted Sets, Lists ฯลฯ	เป็น object cache แบบเรียบง่าย
Architecture	ออกแบบมาเพื่อ HA และ durability	Multi-node sharding (partition ข้อมูล), multi-threaded
เหมาะกับ	ต้องการ HA, durability, leaderboards, pub/sub	cache ที่ไม่ต้อง persistent, ต้องการ scale horizontally แบบ sharded

Tip ข้อสอบ: เลือก Redis หรือ Memcached

จำง่าย ๆ: ต้องการ High Availability / replication / persistence / advanced data structures (เช่น sorted set ทำ leaderboard) => Redis ต้องการ cache แบบเรียบ ๆ ที่ multi-threaded และ sharded หลาย nodes โดยยอมให้ข้อมูลหายได้ (no persistence) => Memcached

08ElastiCache Caching Strategies

developer ต้องเข้าใจว่าจะเอาข้อมูลเข้า cache อย่างไร 2 กลยุทธ์หลักคือ Lazy Loading (Cache-Aside) และ Write-Through พร้อมกับการจัดการ TTL (Time To Live) และ eviction

Lazy Loading (Cache-Aside / Lazy Population)

application อ่านจาก cache ก่อน ถ้า cache hit ก็คืนค่าทันที ถ้า cache miss จะไปอ่านจาก DB แล้วค่อยเขียนกลับลง cache ข้อดี: cache เฉพาะข้อมูลที่ถูกร้องขอจริง (ไม่เปลือง memory) node ล่มไม่ทำให้ระบบพัง ข้อเสีย: ครั้งแรกที่ miss จะมี read penalty (3 trips: cache->DB->cache) และอาจเกิด stale data (ข้อมูลใน cache เก่ากว่า DB)

Write-Through

ทุกครั้งที่ เขียน DB จะ update cache ไปพร้อมกันด้วย ข้อดี: ข้อมูลใน cache ไม่เคย stale และ read เร็ว ข้อเสีย: มี write penalty (เขียน 2 ที่) และมี missing data สำหรับข้อมูลที่ยังไม่เคยถูกเขียน (ต้องอาศัย lazy loading ร่วมด้วย) รวมถึงข้อมูลส่วนใหญ่ที่ cache อาจไม่ถูกอ่านเลย (cache churn)

มิติ	Lazy Loading (Cache-Aside)	Write-Through
เขียน cache เมื่อ	ตอนเกิด cache miss (อ่าน)	ตอนเขียน DB
Stale data	เป็นไปได้ (ต้องใช้ TTL ช่วย)	ไม่ stale
Penalty	Read penalty ตอน miss	Write penalty ทุกครั้งที่เขียน
ข้อมูลใน cache	เฉพาะที่ถูกร้องขอ (ประหยัด memory)	ทุกอย่างที่ถูกเขียน (อาจมีของไม่ถูกอ่าน)
Missing data หลัง node restart	ทยอยเติมเมื่อมีการอ่าน	ข้อมูลที่ยังไม่เคยเขียนจะหาย ต้องผสม lazy loading

TTL และ Cache Eviction

TTL (Time To Live) กำหนดอายุของ key ใน cache เมื่อหมดอายุ key จะถูกลบ ช่วยลดปัญหา stale data ส่วน cache eviction เกิดได้จาก: key หมดอายุตาม TTL, key ถูกลบเอง, หรือ memory เต็มจน cache ต้องไล่ของออก (เช่น policy แบบ LRU - Least Recently Used) ถ้า eviction สูงผิดปกติ ควร scale up/out cache

กับดักข้อสอบ: Write-Through ไม่ได้แก้ stale ทุกกรณี

ข้อสอบชอบถามว่ากลยุทธ์ไหน ลด stale data: คำตอบคือ Write-Through (เพราะ cache ถูก update พร้อม DB เสมอ) แต่ในทางปฏิบัติมักใช้ Write-Through ผสมกับ TTL/Lazy Loading เพราะ Write-Through อย่างเดียวจะมีปัญหา missing data หลัง cache node ใหม่/restart

09Redis Replication, Auth & MemoryDB

Redis Cluster Mode

Cluster Mode Disabled — มี 1 primary node และมากสุด 5 replicas, replication แบบ async, primary ใช้ read/write ส่วน replicas ใช้ read + standby สำหรับ failover; รองรับ Multi-AZ
Cluster Mode Enabled — แบ่งข้อมูลเป็น shards (สูงสุด 500 nodes ต่อ cluster) แต่ละ shard มี primary + replicas เหมาะกับ scaling แบบ horizontal และ data partitioning

ElastiCache Security & Auth

IAM Authentication รองรับเฉพาะ ElastiCache for Redis (ไม่รองรับ Memcached)
IAM policies บน ElastiCache ใช้ได้กับ AWS API-level security เท่านั้น
Redis AUTH — ตั้ง password/token ตอนสร้าง cluster เพิ่มความปลอดภัยนอกเหนือจาก Security Groups และรองรับ SSL in-flight encryption
Memcached รองรับ SASL-based authentication

Amazon MemoryDB for Redis

Redis-compatible, durable, in-memory database service ต่างจาก ElastiCache ตรงที่ MemoryDB เป็น primary database ที่ durable ในตัว (ไม่ใช่แค่ cache) ให้ความเร็วระดับ in-memory แต่มี durability ด้วย Multi-AZ transaction log รองรับข้อมูลตั้งแต่ระดับ tens of GB ถึง 100s TB เหมาะกับ workload ที่ต้องการทั้ง ultra-fast performance และ durability เช่น web/mobile apps, online gaming, media streaming

Tip ข้อสอบ: ElastiCache vs MemoryDB

ถ้าโจทย์ต้องการ in-memory cache วางหน้า database ที่มีอยู่ => ElastiCache แต่ถ้าต้องการ Redis ที่เป็น primary database ในตัว มี durability (ไม่ใช่แค่ cache ที่ข้อมูลหายได้) => Amazon MemoryDB for Redis

คำถามทบทวน

ทดสอบความเข้าใจหัวข้อ RDS, Aurora & ElastiCache

22 ข้อ · เลือกคำตอบเพื่อดูเฉลยและคำอธิบาย

ทำแล้ว 0/22คะแนน 0

1.Application ใช้ RDS MySQL และมี read traffic หนักมากจน CPU ของ primary instance สูง ทีม developer ต้องการ scale การอ่านโดยกระทบ write performance ให้น้อยที่สุด ควรทำอย่างไร?
2.ทีมต้องการเพิ่ม high availability ให้ RDS database โดยให้ failover เป็นอัตโนมัติเมื่อ AZ ล่ม และ application ไม่ต้องแก้ connection string ควรใช้อะไร?
3.AWS Lambda functions ของระบบ scale ขึ้นพร้อมกันจำนวนมาก ทำให้ RDS เกิด error "too many connections" เป็นประจำ วิธีแก้ที่เหมาะสมที่สุดคือ?
4.บริษัทมี RDS database ที่ตอนสร้างไม่ได้เปิด encryption ตอนนี้ต้องการให้ข้อมูล at-rest ถูกเข้ารหัส วิธีที่ถูกต้องคือ?
5.Aurora cluster มี writer และ reader instances หลายตัว application ส่วน reporting ต้องการ query แบบ read-only และอยากได้ load balancing ข้าม read replicas อัตโนมัติ ควรเชื่อมต่อ endpoint ใด?
6.Developer ต้องการ caching strategy ที่ cache เฉพาะข้อมูลที่ถูกร้องขอจริง เพื่อประหยัด memory และยอมรับได้ว่าครั้งแรกที่ขอข้อมูลจะช้าหน่อย ควรใช้กลยุทธ์ใด?
7.ระบบ leaderboard ของเกมต้องการ in-memory store ที่รองรับ sorted sets, high availability ด้วย Multi-AZ failover และ data persistence ควรเลือกอะไร?
8.Application ต้องการ cache แบบ multi-threaded ที่ scale แบบ horizontal ด้วย sharding กระจายข้อมูลข้ามหลาย nodes และไม่ต้องการ persistence หรือ HA ควรเลือกอะไร?
9.ทีมต้องการให้ EC2 instances authenticate เข้า RDS MySQL โดยไม่ต้อง hardcode database password และจัดการ users แบบรวมศูนย์ ควรใช้ฟีเจอร์ใด?
10.บริษัทต้องการ disaster recovery แบบ cross-region สำหรับ database ที่มี read/write ใน region หลัก และมี read-only ในหลาย region โดย replication lag ต่ำกว่า 1 วินาที และ promote secondary เป็น primary ได้เร็ว ควรใช้อะไร?
11.Workload ของ database ไม่สม่ำเสมอและคาดเดายาก (intermittent) ทีมไม่อยากจ่ายค่า capacity ตลอดเวลาและไม่อยากบริหาร capacity เอง ควรใช้อะไร?
12.Developer เผลอรัน DELETE ผิดทำให้ข้อมูลใน Aurora MySQL หายบางส่วน ต้องการย้อนข้อมูลกลับไปยังจุดเวลาก่อนเกิดเหตุอย่างรวดเร็วโดยไม่ต้อง restore จาก backup ควรใช้อะไร?
13.RDS database ของระบบมี free storage เหลือน้อยลงเรื่อย ๆ จาก unpredictable growth ทีมไม่อยากเฝ้าปรับขนาด storage เอง ควรทำอย่างไร?
14.ทีมต้องการ caching strategy ที่ลด stale data ให้มากที่สุด โดยให้ข้อมูลใน cache ตรงกับ DB เสมอ ควรใช้กลยุทธ์ใด (อาจผสมกับ TTL)?
15.ระบบต้องการ Redis ที่เป็น primary database ในตัว มีความ durable (ข้อมูลไม่หายแม้ node ล่ม) ไม่ใช่แค่ cache วางหน้า DB ควรเลือกบริการใด?
16.ข้อใดถูกต้องเกี่ยวกับ Aurora storage architecture?
17.Application แบบ stateless ต้องการให้ user session คงอยู่แม้ request จะถูก route ไปยัง EC2 instance ตัวใดก็ได้หลัง load balancer ควรเก็บ session ไว้ที่ไหน?
18.เกี่ยวกับ RDS Read Replicas ข้อใดถูกต้องเรื่อง consistency และ connection?
19.ข้อใดเป็นข้อจำกัดด้านความปลอดภัยของ RDS ในฐานะ managed service?
20.การ migrate RDS database จาก Single-AZ ไปเป็น Multi-AZ ส่งผลอย่างไรต่อ availability ระหว่างดำเนินการ?
21.ข้อใดถูกต้องเกี่ยวกับ Aurora Writer (Cluster) Endpoint เมื่อเกิด failover?
22.IAM Database Authentication ของ RDS รองรับ engine ใดบ้าง?

ก่อนหน้า04 · ELB & Auto Scaling Groups ถัดไป 06 · Route 53