ระวัง! API ภายนอกล่ม ดึงระบบแอปพลิเคชันพังยกแผง
ปัญหา API ผู้ให้บริการขนส่งช้าผิดปกติ ส่งผลให้ PHP-FPM ล่มและระบบล่มทั้งแอป แต่วิธีแก้ใช้โค้ดเพียงไม่กี่บรรทัด

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- API ขนส่งตอบสนองช้า 40 วินาที ส่งผลให้แอปพลิเคชันพังทั้งระบบ
- คำขอค้างเติ่งทำให้คิวลูกค้าอุดตันและ PHP-FPM เชื่อมต่อเต็ม
- Laravel HTTP Client มีตัวช่วยจัดการ timeout และ retry ป้องกันปัญหานี้
- ระวังการใช้ retry กับระบบชำระเงินเพราะอาจทำให้เกิดการตัดเงินซ้ำซ้อน
เกิดเหตุการณ์ไม่คาดฝันเมื่อผู้ให้บริการขนส่งประสบปัญหาขัดข้อง ทำให้ API ของพวกเขาทำงานช้าลงอย่างมาก โดยใช้เวลาตอบสนองนานถึง 40 วินาที แทนที่จะเป็นความเร็วปกติเพียง 200 มิลลิวินาที ซึ่งแม้จะเป็นปัญหาฝั่งผู้ให้บริการภายนอก แต่ผลลัพธ์ที่ตามมากลับกลายเป็นความโกลาหลในระบบของเราเอง
ทุกคำขอจากแอปพลิเคชันที่ส่งไปเพื่อคำนวณค่าจัดส่งต้องค้างรอนาน ส่งผลให้ระบบคิว (Workers) เกิดการอุดตัน และทรัพยากรการเชื่อมต่อของ PHP-FPM เต็มขีดจำกัดอย่างรวดเร็ว ภายในเวลาเพียงไม่กี่นาที แอปพลิเคชันทั้งหมดของเราก็หยุดตอบสนองการทำงานไปโดยสิ้นเชิง ไม่ใช่แค่หน้าจอเช็คเอาต์เท่านั้นที่ใช้งานไม่ได้ แต่ล่มไปทั้งหมดทั้งระบบ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ปัญหาที่ควรจะเป็นเรื่องของคนอื่นกลับกลายเป็นภาระของเรา และที่แย่ไปกว่านั้นคือมันเป็นเรื่องที่สามารถป้องกันได้ง่ายๆ ด้วยการตั้งค่าโค้ดเพียงสามบรรทัด การเรียกใช้งาน API ภายนอกเปรียบเสมือนการฝากความหวังไว้กับเซิร์ฟเวอร์ที่เราไม่ได้เป็นเจ้าควบคุม โดยคาดหวังว่ามันจะตอบกลับอย่างรวดเร็วและไร้ข้อผิดพลาดเสมอ แต่ในความเป็นจริงมันไม่ได้เป็นเช่นนั้น
โชคดีที่เครื่องมือ HTTP Client ของ Laravel มีฟีเจอร์กู้ภัยเตรียมไว้ให้พร้อมใช้งาน เพียงแค่เขียนโค้ดต่อยอดก็ช่วยป้องกันหายนะได้ โดยมีเทคนิคสำคัญที่ควรทราบ:
- การใช้คำสั่ง retry มีประโยชน์มากกับงานประเภทอ่านข้อมูลหรือค้นหาข้อมูล เช่น การเรียกดูราคาค่าส่ง หรือเช็คข้อมูลรหัสไปรษณีย์ ซึ่งสามารถทำซ้ำได้โดยไม่มีผลเสีย
- ต้องระวังกรณีการทำธุรกรรม เช่น การตัดเงิน หาก API ประมวลผลการจ่ายเงินสำเร็จแต่การตอบกลับสูญหายระหว่างทาง ฟังก์ชัน retry จะทำงานซ้ำและอาจทำให้ลูกค้าถูกหักเงินเบิ้ลสองครั้ง
การพึ่งพาบริการภายนอก (Third-party API) มักมีความเสี่ยงด้านเสถียรภาพที่อยู่นอกเหนือการควบคุมของเรา นักพัฒนาจึงควรออกแบบสถาปัตยกรรมระบบให้มีระบบป้องกันความเสียหายลูกโซ่ (Circuit Breaker หรือ Timeout Strategy) เสมอ เพื่อไม่ให้ความล่าช้าของบริการภายนอกมาดึงให้ระบบหลักของเราล่มตามไปด้วย
การเปลี่ยนมาใช้ฟังก์ชัน Http:: ของ Laravel แทนการเรียกใช้งาน Guzzle แบบดิบๆ ไม่ได้มีดีแค่เรื่องไวยากรณ์ที่เขียนง่ายขึ้นเท่านั้น แต่ยังมาพร้อมกับระบบ timeout, retry, throw รวมถึงความสามารถในการจำลองข้อมูลสำหรับการทดสอบผ่าน Http::fake() ได้ทันทีโดยไม่ต้องเชื่อมต่อ API ของจริง
หากระบบของคุณกำลังใช้งานการเชื่อมต่อภายนอกที่สำคัญโดยไม่มีการตั้งค่า timeout นี่คือการบ้านชิ้นสำคัญที่คุณต้องรีบจัดการ เพื่อไม่ให้ API ที่ทำงานเชื่องช้าจากภายนอกสามารถเข้ามาทำลายแอปพลิเคชันภายในของคุณได้
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น