Siasatan terperinci sepanjang 23 muka surat oleh seorang CTO syarikat permulaan terhadap apa yang mereka percayai sebagai pepijat kritikal platform AWS Lambda telah mencetuskan perbincangan meluas dalam komuniti pembangun. Kes ini menyerlahkan cabaran memahami model pelaksanaan tanpa pelayan dan kepentingan pengetahuan platform yang betul semasa membina sistem pengeluaran.
Pembangun tersebut menghabiskan tujuh minggu menyiasat apa yang mereka gambarkan sebagai kerosakan senyap dalam fungsi AWS Lambda yang menjalankan Node.js dalam VPC yang membuat panggilan HTTPS keluar. Mereka mendokumentasikan penemuan mereka secara ekstensif, meningkatkan isu melalui pelbagai saluran sokongan AWS , dan mengkritik secara terbuka respons Amazon apabila kebimbangan mereka tidak ditangani mengikut kepuasan mereka.
Isu Sebenar: Salah Faham Model Pelaksanaan
Analisis komuniti terhadap kes ini mendedahkan bahawa kerosakan yang dilaporkan sebenarnya adalah tingkah laku Lambda yang dijangka. Kod pembangun tersebut cuba melakukan tugas latar belakang selepas mengembalikan respons HTTP, yang melanggar model pelaksanaan asas Lambda . Apabila fungsi Lambda mengembalikan respons, persekitaran pelaksanaan digantung, dan sebarang proses latar belakang yang berterusan akan ditamatkan.
Tingkah laku ini didokumentasikan dalam dokumentasi rasmi AWS Lambda , yang menyatakan bahawa fungsi berjalan sehingga pengendali mengembalikan respons, keluar, atau tamat masa. Komuniti dengan cepat mengenal pasti ini sebagai punca akar, dengan beberapa pembangun berkongsi pengalaman serupa dan menerangkan pendekatan yang betul untuk mengendalikan senario sedemikian.
Perkara Utama Model Pelaksanaan AWS Lambda:
- Fungsi berjalan sehingga pengendali memulangkan respons, keluar, atau tamat masa
- Tugas latar belakang selepas respons dikembalikan tidak dijamin akan selesai
- Penggantungan MicroVM berlaku selepas respons, mengganggu permintaan yang sedang berjalan
- Fasa selepas pemanggilan wujud tetapi terhad dan tidak boleh dipercayai untuk kerja yang besar
Kerosakan Komunikasi Sokongan
Walaupun isu teknikal berpunca daripada salah faham platform, kes ini juga menyerlahkan cabaran komunikasi antara penyedia awan dan pelanggan. Sokongan AWS nampaknya bergelut untuk menerangkan dengan jelas had model pelaksanaan kepada pembangun, yang membawa kepada kekecewaan yang semakin meningkat di kedua-dua pihak.
Saya tidak pasti mengapa Sokongan AWS tidak dapat menyampaikan ini kepada OP, kata seorang ahli komuniti, mencerminkan sentimen umum tentang keperluan komunikasi teknikal yang lebih jelas.
Beberapa ahli komuniti menunjukkan bahawa sokongan AWS biasanya tidak menyediakan penyahpepijatan kod aplikasi yang terperinci, sebaliknya memberi tumpuan kepada isu peringkat platform. Ketidakselarasan dasar ini mungkin telah menyumbang kepada siasatan yang berpanjangan dan kekecewaan yang semakin meningkat.
Penyelesaian Teknikal dan Amalan Terbaik
Komuniti pembangun menawarkan beberapa penyelesaian praktikal untuk mengendalikan tugas latar belakang dalam persekitaran tanpa pelayan. Pendekatan yang disyorkan melibatkan penggunaan baris gilir mesej seperti Amazon SQS untuk mencetuskan fungsi Lambda berasingan untuk pemprosesan latar belakang, daripada cuba menjalankan tugas selepas mengembalikan respons HTTP.
Sesetengah pembangun menyebut bahawa Lambda memang menyediakan fasa pasca-panggilan yang ringkas untuk tugas pembersihan, tetapi ini terhad dan tidak boleh dipercayai untuk kerja latar belakang yang besar. Konsensusnya jelas: jika anda memerlukan pemprosesan latar belakang yang terjamin, gunakan perkhidmatan pengkomputeran khusus seperti EC2 atau platform bekas seperti Fargate .
Penyelesaian yang Disyorkan untuk Pemprosesan Latar Belakang:
- Gunakan Amazon SQS untuk mengatur giliran tugas latar belakang
- Picu fungsi Lambda yang berasingan untuk kerja latar belakang
- Pertimbangkan EC2 atau Fargate untuk pemprosesan latar belakang yang terjamin
- Laksanakan pengendalian tugas tak segerak yang betul dengan baris gilir mesej
Pengajaran untuk Komuniti Pembangun
Kes ini berfungsi sebagai peringatan tentang kepentingan memahami asas platform sebelum membina sistem pengeluaran. Pendekatan dokumentasi dan ujian yang teliti oleh pembangun adalah terpuji, tetapi ia digunakan untuk menyelesaikan masalah yang salah. Isu sebenar bukanlah pepijat platform tetapi salah faham asas tentang bagaimana fungsi tanpa pelayan beroperasi.
Insiden ini juga menunjukkan bagaimana bias kognitif boleh menghalang kita daripada menerima maklum balas yang mencabar andaian kita. Walaupun terdapat beberapa percubaan oleh sokongan AWS untuk mengalihkan hala siasatan, pembangun tetap yakin mereka telah menemui kegagalan peringkat platform.
Bagi pembangun yang bekerja dengan platform tanpa pelayan, kes ini menekankan keperluan untuk memahami sepenuhnya model pelaksanaan, sempadan pengebilan, dan had platform sebelum mereka bentuk seni bina aplikasi. Apa yang kelihatan seperti pepijat mungkin sebenarnya tingkah laku yang didokumentasikan yang memerlukan pendekatan berbeza untuk mencapai hasil yang diinginkan.
Rujukan: AWS Lambda Silent Crash - A Platform Failure, Not an Application Bug