AWS Lambda และ Serverless
รันโค้ดโดยไม่ต้องดูแลเซิร์ฟเวอร์ จ่ายตามที่ใช้จริง
Lambda เหมือนการจ้างคนแบบฟรีแลนซ์ทำงานเป็นรายชิ้น — มีงานส่งเข้ามาก็เรียกเค้ามาทำชิ้นนั้นแล้วจ่ายเงินเป็นรอบๆ พอไม่มีงานฟรีแลนซ์ก็กลับบ้าน ไม่ต้องจ่ายเงินเลย! ซึ่งต่างจากการเช่า EC2 ที่เหมือนจ้างพนักงานรายเดือน มาถึงก็นั่งเปิดเครื่องรอทั้งวัน (ถึงไม่มีลูกค้าเข้าเราก็ต้องจ่ายเงินเดือน)
AWS Lambda คือบริการประมวลผลหลักของโลกไร้เซิร์ฟเวอร์ (Serverless Computing) คุณแค่นำ Source Code ของคุณ (เช่น Python, Node.js) ไปแปะไว้ แล้ว Lambda จะตื่นมารันโค้ดก็ต่อเมื่อมีเหตุการณ์ (Event) มากระตุ้นเท่านั้น โดย AWS จะเป็นคนจัดการเครื่องเซิร์ฟเวอร์ที่อยู่เบื้องหลังให้ทั้งหมด
- จ่ายตามเวลาทำงานจริง (Pay-per-use): ไม่มี Event เข้ามา = ไม่เสียเงินสักบาท
- เหมาะสำหรับสคริปต์สั้นๆ งานประเภท Event-driven (Lambda หนึ่งรอบรันได้นานสูงสุดจำกัดที่ 15 นาที เท่านั้น ถ้าโค้ดรันนานกว่านี้ต้องกลับไปใช้ EC2)
- สเกล (ขยาย) ปริมาณการรันอัตโนมัติเพื่อรองรับคำขอพร้อมๆ กันได้เป็นพันตัวทันที
- ระบบสถาปัตยกรรม Serverless นิยมใช้ Lambda เข้าคู่กับ API Gateway, S3 และ DynamoDB
import boto3
import json
def lambda_handler(event, context):
# ดึงชื่อไฟล์ที่เพิ่งอัปโหลดเข้ามาจาก Event
bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
print(f"ได้รับไฟล์ {key} จากถัง {bucket} แล้ว!")
# ส่งต่อให้โค้ดย่อขนาดรูปทำงาน...
return {
'statusCode': 200,
'body': json.dumps('Success')
}สรุป Key Takeaways
- Lambda = รันโค้ดแบบ serverless ตาม event จ่ายตามใช้จริง
- สเกลเอง ไม่มี event ไม่จ่าย เหมาะงานสั้น event-driven
- หัวใจของสถาปัตยกรรม serverless ร่วมกับ API Gateway/S3/DynamoDB
คำถามที่พบบ่อย
Lambda เหมาะและไม่เหมาะกับงานแบบไหน
เหมาะ: งาน event-driven ชิ้นสั้น (ประมวลไฟล์ที่อัปโหลด, API backend, งานตามคิว) โหลดผันผวน — จ่ายตามที่รันจริง ส่วนไม่เหมาะ: งานรันยาวเกิน 15 นาที (limit ตายตัว), ต้องการ GPU/สเปกพิเศษ, หรือโหลดหนักนิ่งตลอด 24/7 ที่ container/EC2 ถูกกว่า — เลข 15 นาทีออกสอบบ่อยมาก
Cold start คืออะไร ลดยังไง
ครั้งแรกที่เรียก (หรือหลังว่างนาน) Lambda ต้องเตรียม environment ก่อนรัน ทำให้ request แรกช้ากว่าปกติ — ลดได้ด้วย provisioned concurrency (อุ่นเครื่องรอไว้ เสียเงินเพิ่ม), ลดขนาดแพ็กเกจ, เลี่ยง VPC ถ้าไม่จำเป็น — โจทย์ "latency-sensitive + serverless" ให้นึกถึง provisioned concurrency
Lambda ต่อกับ RDS ตรงๆ มีปัญหาอะไร
Lambda scale เป็นร้อย instance พร้อมกัน แต่ละตัวเปิด connection ใหม่จนฐานข้อมูล connection เต็ม — ทางแก้มาตรฐานคือ RDS Proxy ทำ connection pooling ตรงกลาง หรือใช้ฐานข้อมูลที่เกิดมาเพื่อ serverless อย่าง Aurora Serverless/DynamoDB
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที