05. ​การหมดเวลา​และ​การลอง​ใหม่ — ​ยา​ที่​กลายเป็น​ต้นเหตุ​ของ​โรค

​ปฏิทรรศน์​ของ​ตรรกะ​การกู้​คืน

​การลอง​ใหม่​กลายเป็น​ตัวเร่ง​หลัก​ที่​ทำให้​ระบบ​ล่ม​ทั้ง​ระบบ​อยู่​บ่อยครั้ง ​ทั้งที่​มัน​ถูก​ออกแบบ​มา​เพื่อ​เพิ่ม​ความน่าเชื่อถือ ​ด้วย​การกลบ​ความผิดพลาด​ชั่วคราว​ใน​ระบบ​กระจาย​ศูนย์​ไว้ ​ปี 2015 ​ระบบ DynamoDB ​ขัดข้อง ​และ Amazon Web Services ​บันทึก​ไว้​เอง​ว่า​ตรรกะ​การลอง​ใหม่​แบบ​อัตโนมัติ​เปลี่ยน​ปัญหา​เฉพาะ​จุด​ให้​กลายเป็น​บริการ​ล้มเหลว​ทั่ว​ทั้ง​ระบบ​อย่าง​ยืดเยื้อ ​โดย​ไม่​มี​ใคร​ตั้งใจ ​เซิร์ฟเวอร์​จัดเก็บ​ข้อมูล​แต่ละ​เครื่องส่ง​คำร้องขอ​สมาชิกภาพ​ซ้ำ​ไป​ยัง​บริการ​เม​ทา​ดา​ตา​ที่​รับภาระ​เกินกำลัง​อยู่แล้ว ​ผล​คือ​วงจร​ป้อน​กลับ​เชิง​บวก ​ที่​ถาโถม​ใส่​ส่วนประกอบ​ของ​โครงสร้างพื้นฐาน​ที่​กำลัง​แย่​อยู่​ก่อน​แล้ว ​เหตุการณ์​นี้​ชี้​ว่า​ตรรกะ​การลอง​ใหม่​นั่นเอง​คือ​กลไก​ที่​ตรึง​ระบบ​ไว้​ใน​สภาวะ​เสื่อม​ประสิทธิภาพ ​ไม่​ใช่​สะพาน​ไป​สู่​การกู้​คืน ​อัตรา​ข้อผิดพลาด​ค้าง​อยู่​ที่ ~55% ​สำหรับ​ลูกค้า ​ตัวเลข​นั้น​บอก​ว่าการ​ส่ง​คำร้องขอ​ซ้ำ​โดย​ไม่​ดู​สภาพ​ระบบ ​อาจ​ทำให้​ทรัพยากร​ที่​ขาดแคลน​อยู่แล้ว​ยิ่ง​ขาด​หนัก​ขึ้น ​แทนที่จะ​แก้​ให้หาย

​ความล้มเหลว​แบบ​กึ่ง​เสถียร​และ​การลด​ภาระ​งาน

​ความล้มเหลว​แบบ​กึ่ง​เสถียร​คือ​ระบบ​ที่​ยัง​ติด​อยู่​ใน​สภาวะ​หน่วง​สูง​หรือ​ผิดพลาด​สูง ​ทั้งที่​เงื่อนไข​ที่​จุดชนวน​ถูก​กำจัด​ไป​นาน​แล้ว Nathan Bronson, Abutalib Aghayev, Aleksey Charapko ​และ Timothy Zhu ​โต้แย้ง​ไว้​ใน​เอกสาร HotOS ​ปี 2021 ​ว่า​วงจร​ที่​ขับเคลื่อนด้วย​การลอง​ใหม่​แบบนี้​คือ​ลักษณะเฉพาะ​ที่​นิยาม​ระบบ​กระจาย​ศูนย์​สมัยใหม่ ​กรณีศึกษา​ที่​ชัด​ที่สุด​คือ​รายงาน​ชันสูตร​เหตุขัดข้อง​ของ AWS DynamoDB ​ปี 2015 ​บริการ​เม​ทา​ดา​ตา​กู้​คืน​ได้​ก็ต่อเมื่อ​ทีมงาน​ลงมือ​ระงับ​คำร้องขอ​ขาเข้า​ทั้งหมด​ด้วยมือ​เท่านั้น ​นั่น​คือ​การลด​ภาระ​งาน ​ปฏิเสธ​งาน​โดยตั้งใจ​เพื่อ​รักษา​บริการ​ไว้ ​และ​มัน​ได้ผล​กว่า​การลอง​ใหม่​แบบ​อัตโนมัติ​ที่​ต่อ​ลมหายใจ​ให้​เหตุขัดข้อง​มา​ก่อนหน้า​นั้น​มาก ​ปัญหา​อีก​รูปแบบ​หนึ่ง​คือ​ฝูงชน​แห่​เข้ามา​พร้อมกัน ​วิศวกร​มัก​กัน​ไว้​ด้วย​การถอย​เวลา​แบบ​ทวีคูณ​พร้อม​การสุ่ม​เต็ม​รูปแบบ ​คือ​หน่วงเวลา​เท่ากับ random(0,1) ​คูณ​ด้วย min(cap, base x 2^attempt) Marc Brooker ​เขียน​ไว้​ใน AWS Architecture Blog ​ปี 2015 ​และ​วาง​สูตร​นี้​เป็นมาตร​ฐาน​การบรรเทา​ปัญหา​ของ​อุตสาหกรรม ​เพื่อ​กัน​ไม่​ให้​ไคลเอนต์​ลอง​ใหม่​พร้อมกัน​เป็นจังหวะ​เดียว

​ฉันทา​มติ​เกี่ยวกับ​ความเสี่ยง​ของ​การลอง​ใหม่

​อันตราย​ของ​วงจร​ลอง​ใหม่​ที่​ไร้​การควบคุม​ไม่​มี​ข้อโต้แย้ง​ที่​สำคัญ​เหลืออยู่ ​หลักฐาน​จาก​งานวิจัย​ทางวิชาการ​และ​รายงาน​ชันสูตร​เหตุขัดข้อง​จาก​หน้า​งาน​ตรงกัน​ทั้งหมด Bronson ​และ​คณะ ​อ้าง​ถึง​เหตุการณ์​ใน​อุตสาหกรรม​หลายครั้ง​ที่​ซ้ำรอย​ความล้มเหลว​ของ DynamoDB ​และ​ยืนยัน​ว่าการ​ขยายตัว​ของ​การลอง​ใหม่​เป็น​ปรากฏการณ์​เชิง​ระบบ​ที่เกิด​ซ้ำ​ได้ ​ปัจจุบัน​สาขา​นี้​ยอมรับ​แล้ว​ว่าความ​ปลอดภัย​เป็นปัญหา​เชิง​ควบคุม ​ต้อง​จัดการ​ภาระ​งาน​อย่าง​ชัดแจ้ง ​ไม่​ใช่​ปัญหา​ของ​ส่วนประกอบ​ชิ้น​เดียว​ที่​ลอง​ใหม่​แล้ว​จบ

​ตัวอย่าง: ​ส่ง​คำร้องขอ​ที่​ล้มเหลว​ซ้ำ​ใน​ระบบ​ที่​ภาระ​งาน​ล้นมือ ​ก็​เหมือน​เท​น้ำ​เพิ่ม​ลง​ท่อระบายน้ำ​ที่​ตัน ​แล้ว​หวัง​ว่า​แรงดัน​จะ​ดัน​สิ่ง​อุดตัน​ให้​หลุด

​คำตัดสิน. ​ตรรกะ​การลอง​ใหม่​ที่​ก้าวร้าว​เกินไป​คือ​สาเหตุ​อันดับ​ต้น​ของ​เหตุขัดข้อง​ขนาดใหญ่​ที่​หล่อเลี้ยง​ตัวเอง​ได้ ​และ​ควร​ถูก​แทนที่​ด้วย​การลด​ภาระ​งาน​ใน​ช่วง​ที่​แย่งชิง​ทรัพยากร​กัน​สูง

​จะ​พลิก​คำตัดสิน​ได้​เมื่อ: ​มีระบบ​ขนาดใหญ่​แสดงให้เห็น​ว่าการ​ลอง​ใหม่​โดย​ไร้​การควบคุม​ภายใต้​ภาระ​งาน​สุดขั้ว ​กู้​คืน​ได้​เร็ว​กว่า​การลด​ภาระ​งาน​หรือ​กลยุทธ์​การถอย​เวลา​อย่าง​สม่ำเสมอ

​แหล่ง​อ้างอิง. 2021 · Nathan Bronson, Abutalib Aghayev, Aleksey Charapko, Timothy Zhu, "Metastable Failures in Distributed Systems" — paper PDF · 2015 · Amazon Web Services, "Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region" — AWS postmortem