Amazon ElastiCache
ระบบแคชในหน่วยความจำ คืนค่าข้อมูลแบบพริบตาเดียว
การให้แอปพลิเคชันไปถามข้อมูลฐานข้อมูล RDS ทุกรอบ เหมือนการต้องลุกเดินไปค้นแฟ้มหลังห้องตลอดเวลา (ช้า!). ElastiCache เหมือนคุณเอากระดาษจดโน้ตบนโต๊ะไปคัดลอกคำตอบที่ค้นเจอบ่อยๆ (เช่น ตารางจัดอันดับ) มาแปะบนโต๊ะ พอมีคนถามปุ๊บก็อ่านโน้ตตอบกลับได้ทันทีโดยไม่ต้องลุกเดิน
ElastiCache (ระบบแคชข้อมูลในหน่วยความจำ) คือบริการที่ยกเอาเครื่องมือเก็บข้อมูลลง RAM ยอดฮิตอย่าง Redis หรือ Memcached มาทำงานแบบ Managed
- มันไม่ใช่ฐานข้อมูลหลัก (เพราะถ้าไฟดับ ข้อมูลใน RAM สามารถหายได้) แต่มันถูกสร้างมาทำงานเป็น "ตัวบัฟเฟอร์ (Cache Layer)" อยู่หน้าฐานข้อมูลหลัก เพื่อลดภาระ (Offload) การอ่านข้อมูลหนักๆ
- เหมาะมากสำหรับเว็บที่ข้อมูลมีการดึงซ้ำๆ ถี่ๆ แต่การเปลี่ยนแปลงต่ำ เช่น หน้าแคตตาล็อกสินค้า, ผลฟุตบอลสด, การจัดเซสชั่นล็อกอิน (Session store)
- เวลาตอบสนองของ Cache ระดับ RAM จะอยู่ที่ความเร็ว ไมโครวินาที (Microsecond) ซึ่งเร็วกว่ามิลลิวินาทีของฐานข้อมูลปกติอีกหนึ่งระดับ!
สรุป Key Takeaways
- ElastiCache = บริการ Redis / Memcached แบบ Managed
- เก็บข้อมูลที่อ่านซ้ำ ๆ ลง RAM คืนค่าไวระดับไมโครวินาที
- ใช้ลดโหลด (offload) ให้กับฐานข้อมูลหลัก
คำถามที่พบบ่อย
Redis กับ Memcached เลือกยังไง
Memcached = เรียบง่าย ไม่มี persistence เหมาะกับแคชล้วนๆ ที่หายแล้วสร้างใหม่ได้ ส่วน Redis = ฟีเจอร์ครบ — โครงสร้างข้อมูลหลากหลาย, persistence, replication + failover, pub/sub, sorted set (ทำ leaderboard เกมได้) ข้อสอบส่วนใหญ่เอียงไปทาง Redis เมื่อโจทย์ต้องการ HA หรือฟีเจอร์พิเศษ
แคชกับฐานข้อมูลข้อมูลไม่ตรงกัน (stale data) จัดการยังไง
เป็น trade-off ของการแคช — แนวทางหลักคือตั้ง TTL ให้ข้อมูลหมดอายุเอง, ใช้ lazy loading (อ่านไม่เจอค่อยไปดึงจากฐานข้อมูลมาใส่แคช) หรือ write-through (เขียนฐานข้อมูลพร้อมอัปเดตแคชทุกครั้ง) เลือกตามว่างานทนข้อมูลเก่าได้แค่ไหน
ElastiCache ใช้เก็บ session ของเว็บได้ไหม
ได้และเป็น use case คลาสสิก — เว็บที่รันหลายเครื่องหลัง Load Balancer ควรเก็บ session ไว้ที่กลาง (ElastiCache หรือ DynamoDB) แทนที่จะเก็บในเครื่องใดเครื่องหนึ่ง จะได้ไม่ต้องพึ่ง sticky session และเครื่องพังก็ไม่เสีย session
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที

