การสืบสวนแบบละเอียดยาว 23 หน้าของ CTO สตาร์ทอัปเกี่ยวกับสิ่งที่เขาเชื่อว่าเป็นบั๊กสำคัญในแพลตฟอร์ม AWS Lambda ได้จุดประกายการพูดคุยอย่างกว้างขวางในชุมชนนักพัฒนา กรณีนี้เน้นย้ำถึงความท้าทายในการทำความเข้าใจรูปแบบการทำงานของ serverless และความสำคัญของความรู้เกี่ยวกับแพลตฟอร์มที่เหมาะสมเมื่อสร้างระบบการผลิต
นักพัฒนาใช้เวลาเจ็ดสัปดาห์ในการสืบสวนสิ่งที่เขาอธิบายว่าเป็นการล่มแบบเงียบใน AWS Lambda functions ที่รัน Node.js ใน VPC ทำการเรียก HTTPS ขาออก เขาบันทึกผลการค้นพบอย่างละเอียด ส่งเรื่องผ่านช่องทางสนับสนุนของ AWS หลายช่องทาง และวิจารณ์การตอบสนองของ Amazon ต่อสาธารณะเมื่อความกังวลของเขาไม่ได้รับการแก้ไขอย่างที่พอใจ
ปัญหาที่แท้จริง: ความเข้าใจผิดเกี่ยวกับรูปแบบการทำงาน
การวิเคราะห์ของชุมชนเกี่ยวกับกรณีนี้เผยให้เห็นว่าการล่มที่รายงานนั้นเป็นพฤติกรรมปกติของ Lambda จริงๆ โค้ดของนักพัฒนาพยายามทำงานในพื้นหลังหลังจากส่งคืนการตอบสนอง HTTP ซึ่งละเมิดรูปแบบการทำงานพื้นฐานของ Lambda เมื่อฟังก์ชัน Lambda ส่งคืนการตอบสนอง สภาพแวดล้อมการทำงานจะถูกระงับ และกระบวนการในพื้นหลังที่กำลังดำเนินอยู่จะถูกยุติ
พฤติกรรมนี้ได้รับการบันทึกไว้ในเอกสารอย่างเป็นทางการของ AWS Lambda ซึ่งระบุว่าฟังก์ชันจะทำงานจนกว่า handler จะส่งคืนการตอบสนอง ออก หรือหมดเวลา ชุมชนระบุสาเหตุนี้เป็นต้นตอของปัญหาอย่างรวดเร็ว โดยนักพัฒนาหลายคนแบ่งปันประสบการณ์ที่คล้ายกันและอธิบายวิธีการที่เหมาะสมในการจัดการกับสถานการณ์เช่นนี้
จุดสำคัญของโมเดลการทำงานของ AWS Lambda :
- ฟังก์ชันจะทำงานต่อไปจนกว่า handler จะส่งคืนการตอบสนอง ออกจากระบบ หรือหมดเวลา
- งานที่ทำงานในพื้นหลังหลังจากส่งคืนการตอบสนองแล้วไม่ได้รับการรับประกันว่าจะเสร็จสมบูรณ์
- การหยุดชั่วคราวของ MicroVM เกิดขึ้นหลังจากการตอบสนอง ซึ่งจะขัดจังหวะคำขอที่กำลังดำเนินอยู่
- มีเฟสหลังการเรียกใช้งานอยู่ แต่มีข้อจำกัดและไม่น่าเชื่อถือสำหรับงานที่มีความสำคัญ
ปัญหาการสื่อสารกับฝ่ายสนับสนุน
แม้ว่าปัญหาทางเทคนิคจะเกิดจากความเข้าใจผิดเกี่ยวกับแพลตฟอร์ม แต่กรณีนี้ยังเน้นย้ำถึงความท้าทายในการสื่อสารระหว่างผู้ให้บริการคลาวด์และลูกค้า ฝ่ายสนับสนุนของ AWS ดูเหมือนจะมีปัญหาในการอธิบายข้อจำกัดของรูปแบบการทำงานให้นักพัฒนาเข้าใจอย่างชัดเจน นำไปสู่ความหงุดหงิดที่เพิ่มขึ้นในทั้งสองฝ่าย
ฉันไม่แน่ใจว่าทำไม AWS Support ไม่สามารถสื่อสารเรื่องนี้กับ OP ได้ สมาชิกชุมชนคนหนึ่งกล่าว สะท้อนความรู้สึกทั่วไปเกี่ยวกับความจำเป็นในการสื่อสารทางเทคนิคที่ชัดเจนยิ่งขึ้น
สมาชิกชุมชนหลายคนชี้ให้เห็นว่าฝ่ายสนับสนุนของ AWS โดยทั่วไปไม่ให้การดีบั๊กโค้ดแอปพลิเคชันแบบละเอียด แต่จะมุ่งเน้นไปที่ปัญหาระดับแพลตฟอร์มแทน การขาดการเชื่อมต่อนโยบายนี้อาจมีส่วนทำให้การสืบสวนยืดเยื้อและความหงุดหงิดเพิ่มขึ้น
โซลูชันทางเทคนิคและแนวปฏิบัติที่ดี
ชุมชนนักพัฒนาเสนอโซลูชันที่ใช้งานได้จริงหลายแบบสำหรับการจัดการงานในพื้นหลังในสภาพแวดล้อม serverless วิธีการที่แนะนำคือการใช้คิวข้อความเช่น Amazon SQS เพื่อเรียกใช้ฟังก์ชัน Lambda แยกต่างหากสำหรับการประมวลผลในพื้นหลัง แทนที่จะพยายามรันงานหลังจากส่งคืนการตอบสนอง HTTP
นักพัฒนาบางคนกล่าวถึงว่า Lambda มีเฟสหลังการเรียกใช้สั้นๆ สำหรับงานทำความสะอาด แต่สิ่งนี้มีข้อจำกัดและไม่น่าเชื่อถือสำหรับงานในพื้นหลังที่สำคัญ ฉันทามติชัดเจน: หากคุณต้องการการประมวลผลในพื้นหลังที่รับประกันได้ ให้ใช้บริการคอมพิวต์เฉพาะเช่น EC2 หรือแพลตฟอร์มคอนเทนเนอร์เช่น Fargate
โซลูชันที่แนะนำสำหรับการประมวลผลเบื้องหลัง:
- ใช้ Amazon SQS เพื่อจัดคิวงานเบื้องหลัง
- เรียกใช้ฟังก์ชัน Lambda แยกต่างหากสำหรับงานเบื้องหลัง
- พิจารณาใช้ EC2 หรือ Fargate สำหรับการประมวลผลเบื้องหลังที่รับประกันได้
- ใช้งานการจัดการงานแบบอะซิงโครนัสอย่างเหมาะสมด้วย message queues
บทเรียนสำหรับชุมชนนักพัฒนา
กรณีนี้เป็นการเตือนใจเกี่ยวกับความสำคัญของการทำความเข้าใจพื้นฐานของแพลตฟอร์มก่อนสร้างระบบการผลิต วิธีการบันทึกและทดสอบอย่างละเอียดของนักพัฒนาน่าชื่นชม แต่มันถูกนำไปใช้เพื่อแก้ปัญหาที่ผิด ปัญหาที่แท้จริงไม่ใช่บั๊กของแพลตฟอร์ม แต่เป็นความเข้าใจผิดพื้นฐานเกี่ยวกับวิธีการทำงานของฟังก์ชัน serverless
เหตุการณ์นี้ยังแสดงให้เห็นว่าอคติทางความคิดสามารถป้องกันไม่ให้เรายอมรับข้อเสนอแนะที่ท้าทายสมมติฐานของเราได้อย่างไร แม้จะมีความพยายามหลายครั้งจากฝ่ายสนับสนุนของ AWS ในการเปลี่ยนทิศทางการสืบสวน นักพัฒนายังคงเชื่อมั่นว่าเขาค้นพบความล้มเหลวระดับแพลตฟอร์ม
สำหรับนักพัฒนาที่ทำงานกับแพลตฟอร์ม serverless กรณีนี้เน้นย้ำถึงความจำเป็นในการทำความเข้าใจรูปแบบการทำงาน ขอบเขตการเรียกเก็บเงิน และข้อจำกัดของแพลตฟอร์มอย่างเต็มที่ก่อนออกแบบสถาปัตยกรรมแอปพลิเคชัน สิ่งที่ดูเหมือนบั๊กอาจเป็นพฤติกรรมที่มีการบันทึกไว้จริงๆ ซึ่งต้องใช้วิธีการที่แตกต่างเพื่อให้ได้ผลลัพธ์ที่ต้องการ
อ้างอิง: AWS Lambda Silent Crash - A Platform Failure, Not an Application Bug