การออกแบบแอปพลิเคชันที่ทนทานต่อความล้มเหลวบน AWS

การพัฒนาแอปพลิเคชันบน AWS

Ricardo Sueiras

Principal Technologist

การสร้างเพื่อความยืดหยุ่น

ความล้มเหลวชั่วคราว

 

• ทำความเข้าใจรูปแบบความล้มเหลวที่พบบ่อย:
• ข้อผิดพลาดชั่วคราวจะหายไปเอง โดยปกติสามารถลองใหม่ได้อย่างปลอดภัย

Timeout

 

• ทำความเข้าใจรูปแบบความล้มเหลวที่พบบ่อย:
• ข้อผิดพลาดชั่วคราวจะหายไปเอง โดยปกติสามารถลองใหม่ได้อย่างปลอดภัย
• Timeout: บริการภายนอกใช้เวลาตอบสนองนานเกินไป

ข้อผิดพลาดถาวร

 

• ทำความเข้าใจรูปแบบความล้มเหลวที่พบบ่อย:
• ข้อผิดพลาดชั่วคราวจะหายไปเอง โดยปกติสามารถลองใหม่ได้อย่างปลอดภัย
• Timeout: บริการภายนอกใช้เวลาตอบสนองนานเกินไป
• ข้อผิดพลาดถาวร: คำขอมีปัญหาพื้นฐาน การลองใหม่ไม่มีประโยชน์

ขีดจำกัด API

 

• ทำความเข้าใจรูปแบบความล้มเหลวที่พบบ่อย:
• ข้อผิดพลาดชั่วคราวจะหายไปเอง โดยปกติสามารถลองใหม่ได้อย่างปลอดภัย
• Timeout: บริการภายนอกใช้เวลาตอบสนองนานเกินไป
• ข้อผิดพลาดถาวร: คำขอมีปัญหาพื้นฐาน การลองใหม่ไม่มีประโยชน์
• ขีดจำกัด API rate: คำขอมากเกินไป คาดว่าจะได้รับ HTTP 429 Too Many Requests

กลยุทธ์การ retry

• ความล้มเหลวในระบบกระจายมักเป็นเพียงชั่วคราว
• การส่งคำขอซ้ำมักประสบความสำเร็จ
• เพิ่ม retry logic อย่างรอบคอบ การ retry แบบสุ่มสี่สุ่มห้าอาจทำให้แย่ลง
• Exponential backoff: เพิ่มเวลาหน่วงระหว่างการ retry
• Jitter: เพิ่มความสุ่มเพื่อหลีกเลี่ยง retry spike
• Retry limit: ป้องกันการวนซ้ำไม่สิ้นสุด

 

ความสามารถในตัวของ AWS SDK

• AWS SDK จัดการ retry logic โดยอัตโนมัติ
• มี exponential backoff และ jitter ในตัว
• คำขอที่ล้มเหลวหรือถูก throttle จะถูก retry โดยเพิ่มเวลาหน่วงขึ้นเรื่อย ๆ
• ลดปริมาณโค้ดจัดการข้อผิดพลาดที่ต้องเขียนเอง

 

การจัดการ retry logic

 

• Retry logic ไม่ใช่คำตอบเสมอไป
• HTTP 4xx: เซิร์ฟเวอร์เข้าใจแต่ปฏิเสธคำขอ
• คำขอที่ไม่ใช่ idempotent: การ retry อาจก่อให้เกิดการกระทำซ้ำหรือไม่สอดคล้องกัน

การจัดการ timeout

 

• การ retry ไม่จำกัดอาจขยายปัญหาเมื่อโหลดสูง
• ใช้ retry ร่วมกับ timeout
• Timeout กำหนดเวลาสูงสุดที่จะรอการตอบสนอง
• การเรียกบริการภายนอกทุกครั้งควรมี timeout

Circuit breaker

• เมื่อบริการล้มเหลวซ้ำ ๆ การ retry เพียงอย่างเดียวไม่เพียงพอ
• การส่งคำขอต่อไปอาจทำให้บริการที่มีปัญหาโอเวอร์โหลด
• รูปแบบ circuit breaker จะหยุดส่งคำขอไปยัง dependency ที่ไม่ปกติชั่วคราว
• สถานะ Closed: คำขอไหลผ่านตามปกติ

 

Circuit breaker

• เมื่อความล้มเหลวเกินเกณฑ์ที่กำหนด วงจรจะเปิด
• คำขอถัดไปจะถูกบล็อก

 

Circuit breaker

• หลังช่วง cooldown วงจรจะเข้าสู่สถานะ half-open เพื่อทดสอบการฟื้นตัว
• บริการตอบสนองสำเร็จ: กลับสู่การทำงานปกติ
• ยังล้มเหลวอยู่: วงจรยังคงเปิด
• ติดตั้ง circuit breaker ในระดับแอปพลิเคชัน

 

Dead Letter Queue

 

• ข้อความที่ล้มเหลวซ้ำ ๆ อาจบล็อกระบบได้
• ย้ายออกจากกระบวนการหลัก
• ข้อความที่ล้มเหลวจะถูกส่งไปยัง Dead Letter Queue
• เป็นส่วนสำคัญในการสร้างแอปพลิเคชันที่ยืดหยุ่น
• อย่างไรก็ตาม ต้องเข้าใจข้อแลกเปลี่ยนด้วย

ขีดจำกัด API ของ AWS

 

• การโต้ตอบกับบริการ AWS ทำผ่าน API
• แต่ละบริการกำหนดขีดจำกัด API rate ของตนเอง
• การเกินขีดจำกัดจะทริกเกอร์ throttling (HTTP 429 Too Many Requests)
• ออกแบบแอปพลิเคชันให้รับมือกับ throttling ได้อย่างราบรื่น

การเชื่อมต่อกับบริการของบุคคลที่สาม

• บริการของบุคคลที่สามนำมาซึ่งความไม่แน่นอน
• ไม่มีการควบคุมประสิทธิภาพหรือความพร้อมใช้งานของบริการเหล่านั้น
• ตั้ง timeout เพื่อป้องกันการรอนาน
• ใช้ retry กับ backoff สำหรับปัญหาชั่วคราว
• แยก dependency เพื่อจำกัดขอบเขตผลกระทบ

 

การเชื่อมต่อกับบุคคลที่สาม

• พิจารณาเปลี่ยนจากการสื่อสารแบบ synchronous เป็น asynchronous
• ระบบยังคงประมวลผลต่อได้แม้บริการภายนอกล่าช้า

 

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

การพัฒนาแอปพลิเคชันบน AWS