Serverless และ caching patterns
ออกแบบแบบไม่มีเซิร์ฟเวอร์และวางแคชให้ถูกจุด
ถ้ามีคนมาถามคำถามเดิมๆ แทนที่จะเดินไปค้นแฟ้มเอกสารในตู้ (Database) ทุกรอบ เราก็เหลือบดูโพสต์อิตที่จดไว้ (Cache) แล้วตอบกลับได้ทันที ทำให้เร็วและไม่เหนื่อย
พื้นฐานที่ควรรู้: นอกจากการจัดการเซิร์ฟเวอร์แบบเดิมแล้ว ยังมีสถาปัตยกรรมแบบ Serverless (ไม่มีเซิร์ฟเวอร์ให้ดูแล) ที่นักพัฒนาแค่เขียนโค้ดแล้วให้ AWS จัดการรันให้ และจ่ายเงินตามปริมาณใช้งานจริง และเพื่อให้ระบบเร็วขึ้น เรามักจะนำระบบ Caching (การจดจำข้อมูลจำลอง) มาช่วยลดภาระการโหลดข้อมูลซ้ำๆ
สถาปัตยกรรม Serverless แบบมาตรฐานยอดฮิต: ผู้ใช้เข้าเว็บผ่าน CloudFront → วิ่งเข้า API Gateway → ประมวลผลด้วยฟังก์ชัน Lambda → เก็บข้อมูลลง DynamoDB — ข้อดีคือไม่ต้องเปิดเซิร์ฟเวอร์ทิ้งไว้ สเกลอัตโนมัติ 100%
วางแคช (Cache) ตรงไหนได้บ้าง
- CloudFront — แคชเนื้อหาเว็บไซต์ (Static/HTTP) ไว้ที่ปลายทาง (Edge) ให้ใกล้ผู้ใช้ที่สุด
- API Gateway Caching — แคชผลลัพธ์ของ API ที่ถูกเรียกซ้ำบ่อยๆ ลดการทำงานของ Backend
- ElastiCache / DynamoDB DAX — แคชข้อมูลในระดับฐานข้อมูล ลดความหน่วง (Latency) และลดภาระการค้นหา (Read load)
สรุป Key Takeaways
- Serverless ทั่วไป: CloudFront → API Gateway → Lambda → DynamoDB
- วางแคชหลายจุด: CloudFront (เนื้อหา), API GW (ผล API), ElastiCache/DAX (DB)
คำถามที่พบบ่อย
สถาปัตยกรรม serverless เต็มรูปแบบหน้าตาเป็นยังไง
ชุดมาตรฐาน: CloudFront + S3 (static) → API Gateway → Lambda → DynamoDB พร้อม SQS/EventBridge เชื่อมงาน async — ไม่มีเครื่องให้ดูแลสักตัว จ่ายตามใช้จริง scale อัตโนมัติ — โจทย์ "unpredictable traffic + minimal ops" มักจบที่ชุดนี้
ควรแคชที่ชั้นไหนบ้าง
ไล่จากนอกเข้าใน: CloudFront (static + API ที่แคชได้), API Gateway cache (response ซ้ำๆ), ElastiCache/DAX (หน้าฐานข้อมูล) — หลักคือแคชให้ใกล้ผู้ใช้ที่สุดก่อน เพราะตัด load ทุกชั้นข้างหลังพร้อมกัน โจทย์ "read-heavy + ลด latency + ลดโหลด DB" ให้มองหาแคชเสมอ
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที