ทดสอบว่าระบบคิวพังอย่างไรก่อนของจริงพัง: ใช้ AWS Fault Injection Service ตัดสิทธิ์ SQS เป็นช่วง ๆ แล้ววัดผล

ทีมส่วนใหญ่เชื่อว่าระบบของตัวเองรับมือได้เมื่อคิวข้อความใช้งานไม่ได้ แต่แทบไม่มีใครทดสอบจริง บทความจาก AWS Architecture Blog เสนอวิธีทดสอบที่ทำซ้ำได้ โดยใช้ AWS Fault Injection Service สั่งตัดสิทธิ์การเข้าถึงคิว Amazon SQS เป็นช่วงเวลาที่ยาวขึ้นเรื่อย ๆ แล้ววัดว่าระบบตอบสนองอย่างไรในแต่ละช่วง บทความนี้สรุปสถาปัตยกรรม ขั้นตอนการตั้งค่า ตัวชี้วัดที่ต้องดู และกับดักที่ทำให้การทดสอบล้มเหลวหรือกลับมาแก้เองไม่ได้

ปัญหาที่ต้องการแก้

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

สถาปัตยกรรมและเครื่องมือที่ใช้

โครงที่ใช้เป็นรูปแบบผู้ผลิตและผู้บริโภคมาตรฐาน มีบริการฝั่งผู้ผลิตส่งข้อความเข้าคิว SQS บริการฝั่งผู้บริโภครับไปประมวลผล มีคิวปลายทางสำหรับข้อความที่ล้มเหลวต่อจากคิวหลัก และมี CloudWatch เก็บตัวชี้วัดจากทุกส่วน AWS Fault Injection Service ทำหน้าที่ควบคุมลำดับการทดลอง โดยเรียก AWS Systems Manager Automation ให้เข้าไปใส่และถอดข้อจำกัดสิทธิ์

เอกสาร Automation ทำงานสี่ขั้น ขั้นแรกเรียก ListQueues เพื่อหาคิวที่ติดแท็กไว้ ขั้นที่สองใส่นโยบายปฏิเสธแบบจำกัดขอบเขต ซึ่งบล็อก SendMessage, ReceiveMessage, DeleteMessage, ChangeMessageVisibility และ Purge ขั้นที่สามรอจนครบระยะเวลาที่กำหนด และขั้นที่สี่ถอดนโยบายปฏิเสธออกเพื่อคืนสภาพ

ลำดับการทดลองแบบไต่ระดับ

การทดลองแบ่งเป็นสี่ช่วงที่ยาวขึ้นเรื่อย ๆ คั่นด้วยช่วงพักให้ระบบฟื้นตัว ช่วงแรกตัดสิทธิ์ 2 นาทีเพื่อดูว่าระบบล้มเหลวเร็วและตัวตัดวงจรทำงานหรือไม่ แล้วพัก 3 นาที ช่วงที่สองตัด 5 นาทีเพื่อให้เห็นการสะสมของงานค้าง แล้วพัก 3 นาที ช่วงที่สามตัด 7 นาทีเพื่อดูแรงกดดันต่อเธรดพูลและหน่วยความจำ แล้วพัก 2 นาที และช่วงที่สี่ตัด 15 นาทีเพื่อทดสอบขีดจำกัดของระบบเมื่อเหตุยืดเยื้อ

การไต่ระดับแบบนี้มีเหตุผล เพราะปัญหาแต่ละแบบโผล่ที่ระยะเวลาต่างกัน ตัวตัดวงจรเห็นผลในไม่กี่สิบวินาที แต่ปัญหาหน่วยความจำและงานค้างต้องใช้เวลาสะสม ถ้าทดสอบครั้งเดียวยาว ๆ จะแยกไม่ออกว่าอะไรเป็นสาเหตุของอะไร

ตัวชี้วัดที่ต้องเฝ้าดู

ฝั่งคิวให้ดูตัวชี้วัดของ CloudWatch ได้แก่ NumberOfMessagesSent ที่ควรตกลงเป็นศูนย์ระหว่างช่วงตัดสิทธิ์ ApproximateNumberOfMessagesVisible ที่บอกปริมาณงานค้าง ApproximateAgeOfOldestMessage ที่บอกว่าข้อความเก่าสุดค้างมานานเท่าไร รวมถึง NumberOfMessagesReceived, NumberOfMessagesDeleted และ ApproximateNumberOfMessagesNotVisible ส่วนฝั่งแอปให้ดูอัตราข้อผิดพลาดแยกตามชนิด สถานะของตัวตัดวงจร จำนวนข้อความที่ส่งไม่สำเร็จหรือถูกทิ้ง และเวลาประมวลผลตั้งแต่ต้นจนจบ

กับดักที่ทำให้การทดสอบเสียของ

กับดักแรกคือการตั้งเงื่อนไขหยุดผิดตัว บทความเตือนตรง ๆ ว่าการตั้งสัญญาณเตือนบนตัวชี้วัดของคิวอย่าง ApproximateAgeOfOldestMessage หรือ NumberOfMessagesSent เป็นเงื่อนไขหยุดนั้นผิด เพราะค่าเหล่านั้นถูกออกแบบให้ขยับอยู่แล้วระหว่างการทดลอง เงื่อนไขหยุดที่ถูกต้องควรอิงอัตราข้อผิดพลาดของแอปที่สะท้อนผลกระทบต่อลูกค้า จำนวนการตอบกลับ 5xx ที่ตัวกระจายโหลด หรือความลึกของคิวปลายทางสำหรับข้อความที่ล้มเหลว

กับดักที่อันตรายกว่าคือการล็อกตัวเองออกจากคิว บทความระบุว่านโยบายปฏิเสธที่ครอบคลุม sqs:SetQueueAttributes, sqs:AddPermission และ sqs:RemovePermission อาจทำให้แม้แต่บทบาทที่ใส่นโยบายนั้นเองก็เข้าไปถอดออกไม่ได้ จึงต้องกำหนดขอบเขตของนโยบายให้ชัดเจนและเตรียมขั้นตอนย้อนกลับไว้เป็นลายลักษณ์อักษรก่อนเริ่ม

แนวปฏิบัติที่บทความแนะนำ

ให้เขียนสมมติฐานลงกระดาษก่อนเริ่มทุกครั้ง ในรูปแบบว่าเมื่อระบบเข้าถึงคิวไม่ได้เป็นเวลาเท่าใด เราคาดว่าจะเกิดพฤติกรรมอะไร ช่องว่างระหว่างสิ่งที่เขียนไว้กับสิ่งที่เกิดขึ้นจริงคือจุดที่ระบบต้องแก้ ด้านการลองใหม่ให้ใช้การถอยแบบทวีคูณพร้อมสุ่มค่าเพื่อไม่ให้ทุกตัวลองใหม่พร้อมกัน และควรใช้กลไกลองใหม่ของ SDK แทนการเขียนเอง ส่วนคิวปลายทางสำหรับข้อความที่ล้มเหลวให้ตั้งจำนวนครั้งที่รับซ้ำไว้ราว 3 ถึง 5 ครั้ง และตั้งอายุการเก็บให้ยาวกว่าคิวต้นทาง โดยต้องจำไว้ว่าอายุนับจากเวลาที่เข้าคิวครั้งแรก ไม่ได้เริ่มนับใหม่เมื่อย้ายมา

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

สำหรับทีมในไทยที่ใช้คิวข้อความในระบบสั่งซื้อ ระบบแจ้งเตือน หรือระบบเชื่อมต่อกับคู่ค้า การทดลองแบบนี้เริ่มได้โดยไม่ต้องใช้เครื่องมือของ AWS ก็ได้ หลักการเดียวกันคือกำหนดสมมติฐาน สร้างความล้มเหลวในสภาพแวดล้อมทดสอบก่อน วัดผลด้วยตัวชี้วัดที่สะท้อนผลกระทบต่อลูกค้า และเตรียมทางถอยไว้เสมอ ทีมงาน Smart Cyber Tech รับย้ายระบบขึ้นคลาวด์และวางสถาปัตยกรรม พร้อมออกแบบการทดสอบความทนทานให้เหมาะกับขนาดของทีมและระบบที่ใช้จริง ปรึกษาได้ที่ แบบฟอร์มติดต่อ