ทำไม AWS Lambda ถึงฆ่าฐานข้อมูล RDS ของคุณเงียบๆ และวิธีแก้ด้วย RDS Proxy
เจาะลึกปัญหาคอขวด Connection ล้นตู้ในสถาปัตยกรรม Serverless เมื่อปริมาณทราฟฟิกพุ่งสูง และวิธีใช้ RDS Proxy จัดการ Connection Pooling อย่างมีประสิทธิภาพ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การทำงานแบบ Stateless ของ Lambda ทำให้เกิดการเปิดและปิด Connection ใหม่กับฐานข้อมูล RDS ทุกครั้งที่มีการเรียกใช้งาน
- เมื่อทราฟฟิกพุ่งสูง จะเกิดปัญหา ERROR 1040: Too many connections ทำให้ฐานข้อมูลล่มทันที
- การอัพเกรดขนาดอินสแตนซ์ RDS เป็นการแก้ที่ปลายเหตุและไม่ตอบโจทย์ในระยะยาว
- Amazon RDS Proxy ทำหน้าที่เป็นตัวกลางในการจัดการพูล Connection แบบถาวรและลดภาระให้ฐานข้อมูล
คุณสร้างระบบ API แบบ Serverless ขึ้นมาโดยใช้ AWS Lambda ร่วมกับ API Gateway และ RDS MySQL ที่หลังบ้าน มองดูผิวเผินแล้วโครงสร้างนี้ดูสะอาดตาและสามารถขยายขนาดได้โดยอัตโนมัติ ทว่าเมื่อมีทราฟฟิกมหาศาลหลั่งไหลเข้ามาพร้อมกัน เช่น มีการเรียกฟังก์ชัน Lambda 500 ตัวทำงานพร้อมกันในเสี้ยววินาที ฟังก์ชันแต่ละตัวจะทำการเปิดฐานข้อมูลใหม่ขึ้นมาทันที ส่งผลให้เกิดความต้องการ Connection จำนวนมากเกินกว่าที่ฐานข้อมูล RDS ของคุณจะรองรับได้ไหว เนื่องจากอินสแตนซ์ RDS ทั่วไปมีขีดจำกัดสูงสุดของ Connection ที่รองรับได้จำกัด
ผลลัพธ์ที่ตามมาคือข้อผิดพลาด ERROR 1040: Too many connections ทำให้ฐานข้อมูลหยุดทำงานในทันที แม้ว่าตัวฟังก์ชัน Lambda ของคุณจะยังคงทำงานปกติไม่มีข้อผิดพลาด แต่พวกมันกลับไม่มีช่องทางในการเชื่อมต่อไปยังฐานข้อมูลได้อีกต่อไป ปัญหานี้ถือเป็นหนึ่งในจุดพังทลายที่พบบ่อยและสร้างความปวดหัวมากที่สุดในสถาปัตยกรรมแบบ Serverless บน AWS และนั่นคือเหตุผลที่ Amazon RDS Proxy ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้โดยเฉพาะ
ความแตกต่างหลักอยู่ที่วิธีที่แอปพลิเคชันจัดการกับ Connection โดยเซิร์ฟเวอร์แอปพลิเคชันแบบดั้งเดิม เช่น อินสแตนซ์ EC2 จะทำการเปิดพูล Connection ของฐานข้อมูลไว้ตั้งแต่เริ่มต้นและนำกลับมาใช้ใหม่สำหรับทุกคำขอที่เข้ามา แต่ Lambda ทำงานต่างออกไปโดยสิ้นเชิง ทุกการเรียกใช้งานจะเป็นแบบชั่วคราวและไม่มีการเก็บสถานะ (Stateless และ Ephemeral) เมื่อ Lambda ต้องการคิวรีข้อมูล มันจะเปิด Connection ใหม่ และเมื่อการเรียกใช้งานสิ้นสุดลง Connection นั้นอาจถูกนำกลับมาใช้ใหม่หรือไม่ก็ได้ขึ้นอยู่กับว่าสภาพแวดล้อมการทำงานยังคงร้อนอยู่หรือไม่
เมื่อปริมาณทราฟฟิกอยู่ในระดับต่ำ ปัญหายังคงสามารถจัดการได้ แต่ภายใต้โหลดการทำงานที่หนักหน่วง จะเกิดอัตราส่วนการขยายตัวที่รวดเร็ว:
- การเรียก Lambda พร้อมกัน 100 ครั้ง สร้าง Connection ใหม่ 100 ช่องทางไปยัง RDS
- การเรียก Lambda พร้อมกัน 500 ครั้ง สร้าง Connection ใหม่ 500 ช่องทางไปยัง RDS
- การเรียก Lambda พร้อมกัน 1,000 ครั้ง สร้าง Connection ใหม่ 1,000 ช่องทางไปยัง RDS
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การเข้าใจกลไกการทำงานของ Connection Pool ถือเป็นหัวใจสำคัญในการออกแบบระบบ Cloud-native เนื่องจากข้อผิดพลาดประเภท Too many connections มักไม่แสดงอาการให้เห็นในช่วงทดสอบระบบที่มีผู้ใช้งานจำนวนน้อย แต่จะระเบิดขึ้นทันทีเมื่อระบบเจอภาระงานจริงหรือแคมเปญส่งเสริมการขาย การนำ RDS Proxy เข้ามาคั่นกลางจึงเปรียบเสมือนการสร้างด่านหน้าคอยพักโหลดและบริหารจัดการทราฟฟิกให้อยู่ในกรอบที่ฐานข้อมูลหลักจะรับไหวโดยไม่ต้องแก้โค้ดธุรกิจส่วนใหญ่
Amazon RDS Proxy ทำหน้าที่เป็นพร็อกซีฐานข้อมูลที่มีความพร้อมใช้งานสูงและจัดการเต็มรูปแบบ ซึ่งจะวางตัวอยู่ระหว่างฟังก์ชัน Lambda และอินสแตนซ์ RDS ของคุณ แทนที่ฟังก์ชัน Lambda แต่ละตัวจะเปิด Connection ตรงไปยัง RDS พวกมันทั้งหมดจะเชื่อมต่อผ่าน Proxy แทน ซึ่ง Proxy นี้จะรักษาพูลของ Connection ที่ถาวรและสามารถนำกลับมาใช้ใหม่ได้กับฐานข้อมูล โดยช่วยลดปัญหาการสร้างและทำลาย Connection ซ้ำๆ ได้อย่างเด็ดขาด
นอกจากเรื่องการจัดการพูล Connection แล้ว RDS Proxy ยังมอบประโยชน์เพิ่มเติมอีกสามประการ ได้แก่ การทำ Failover ที่รวดเร็วยิ่งขึ้นโดยลดเวลาลงเหลือต่ำกว่า 10 วินาที, การยืนยันตัวตนผ่าน IAM ที่ปลอดภัยโดยไม่ต้องฝังรหัสผ่านไว้ในโค้ดหรือ Environment Variables, และระบบความปลอดภัยที่เพิ่มขึ้นโดยปิดกั้นไม่ให้ RDS เข้าถึงได้จากภายนอกโดยตรง ปิดท้ายด้วยการอ้างอิงแหล่งข้อมูลสำหรับผู้ที่ต้องการศึกษาเพิ่มเติมในเชิงลึก
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น