การจัดการ event lifecycle: retries, DLQs และ destinations

Serverless Applications with AWS Lambda

Claudio Canales

Senior DevOps Engineer

ภาพรวม event lifecycle

Lambda เรียก handler ของคุณ
handler จะสำเร็จหรือล้มเหลว
เมื่อล้มเหลว retries และ routing จะกำหนดขั้นตอนถัดไป

ขั้นตอน event lifecycle

ความล้มเหลวมี 2 รูปแบบ

Synchronous

ผู้เรียกรอและรับการตอบกลับข้อผิดพลาด

Asynchronous

ผู้เรียกได้รับการยืนยันก่อน
Lambda retry ในเบื้องหลัง
การจัดการความล้มเหลวขึ้นอยู่กับโหมดการเรียกใช้

เส้นทางความล้มเหลวแบบ sync และ async

Retries เป็นเรื่องปกติ

Retries มักเป็นฟีเจอร์ ไม่ใช่ข้อบกพร่อง
ความล้มเหลวชั่วคราวอาจสำเร็จในการลองครั้งถัดไป
Retries อาจทำให้เกิดการประมวลผลซ้ำ handler ต้องรองรับสิ่งนี้

การเปรียบเทียบ retry กับการโทรซ้ำ

Retries ตามช่วงเวลา

Retries ช่วยกู้คืนจากปัญหาชั่วคราวได้
แต่ event เดียวกันอาจทำงานหลายครั้ง
Idempotency และการจัดการข้อผิดพลาดที่ชัดเจนเป็นสิ่งจำเป็น

ไทม์ไลน์การ retry

เมื่อ retries อาจเป็นอันตราย

Retries มีความเสี่ยงเมื่องานไม่รองรับ idempotency
ตัวอย่าง: การตัดบัตรเครดิต การส่งอีเมล
ใช้ idempotency key และการอัปเดตที่ปลอดภัยเพื่อป้องกันความเสียหายจากการซ้ำ

แผนภาพเป้าหมาย idempotency

DLQ (Dead-Letter Queue)

ที่เก็บที่ปลอดภัยสำหรับ event ที่ยังล้มเหลวหลัง retry ครบแล้ว
มักเป็น SQS queue ซึ่งเป็น message queue ที่ AWS จัดการให้
ตรวจสอบ payload แก้ปัญหา แล้ว re-drive

การเปรียบเทียบ DLQ กับของหาย

DLQ กับ Destinations

การเปรียบเทียบ DLQ กับของหาย

เก็บ event ที่ล้มเหลวหลัง retry ครบ
ใช้สำหรับการตรวจสอบ

แผนภาพ routing ของ Destinations

กำหนดเส้นทาง outcome เมื่อสำเร็จหรือล้มเหลว
สร้างเส้นทางสำเร็จและล้มเหลวที่ชัดเจน

Destinations: เส้นทางสำเร็จและล้มเหลว

เมื่อสำเร็จ ส่งผลลัพธ์ไปยัง onSuccess
เมื่อล้มเหลว ส่งรายละเอียดไปยัง onFailure
ทำให้ขั้นตอนถัดไปชัดเจน

แผนภาพ routing ของ Destinations

การปรับแต่ง retry policy

ปรับจำนวนครั้งที่ Lambda retry
จำกัดอายุ event เพื่อหลีกเลี่ยงการประมวลผลข้อมูลเก่า
Retry มากขึ้นเพิ่มความน่าเชื่อถือ แต่เพิ่มการซ้ำและความล่าช้า

การควบคุม retry policy

อายุ event สูงสุด: วันหมดอายุของ event

อายุ event สูงสุดคือนโยบายหมดอายุ
หาก event เก่าเกินไป การประมวลผลอาจไม่มีประโยชน์
การแลกเปลี่ยน: event ล่าช้าน้อยลง พฤติกรรมทันเวลามากขึ้น

การเปรียบเทียบ event age กับวันหมดอายุ

Observability: ดูที่ไหน

Log ตอบว่าเกิดอะไรขึ้น
Metrics ตอบว่าเกิดบ่อยแค่ไหน
Alarm ช่วยตรวจจับความผิดปกติได้รวดเร็ว

Log กับ Metrics

จัดการ event ที่ล้มเหลวอย่างไร

ตรวจสอบ payload และข้อผิดพลาด
แก้ที่ต้นเหตุ
Re-drive event แล้วติดตาม error และ throughput

วงจรการกู้คืน event ที่ล้มเหลว

สรุปสำคัญ

ความน่าเชื่อถือมาจาก retries, routing และ observability
ข้อผิดพลาดแบบ synchronous ส่งถึงผู้เรียก
ข้อผิดพลาดแบบ asynchronous ต้องใช้ retries ร่วมกับ DLQ หรือ destinations
ทำให้ความล้มเหลวมองเห็นได้

แผนภาพสูตรความน่าเชื่อถือ

มาฝึกกันเถอะ!

Serverless Applications with AWS Lambda