Make Sandbox Epoch: ใช้ Fencing Token ป้องกันความเสียหายบน Free Compute

ในงานทางสถาปัตยกรรมระบบ มักจะมีข้อผิดพลาดคลาสสิกที่เกิดขึ้นเมื่อมีคนมองว่า Free Sandbox เป็นที่เก็บข้อมูลถาวร เมื่อ Planner ส่งคำขอ apply_patch ไปยังแซนด์บ็อกซ์และได้รับสถานะ 200 กลับมา ระบบมักจะดำเนินกระบวนการถัดไปราวกับการเขียนข้อมูลนั้นถูกป้องกันไว้เรียบร้อยแล้ว แต่หากหลังจากนั้น Replica เกิดถูกเรียกคืน การลองส่งซ้ำ (Retry) อาจตกลงไปบนดิสก์เปล่า และไฟล์ข้อมูลทั้งหมดก็จะหายไปทันที

คำถามคือ โพรเซสนี้ควรยอมให้ Planner ทำการ Commit ขั้นตอนนี้หรือไม่ คำตอบคือไม่ควร โดยเฉพาะบน Replica ที่สามารถหายไปได้ทุกเมื่อโดยไม่มี Fencing Token แม้คอมพิวต์ฟรีจะมีประโยชน์ แต่สิ่งนั้นคือ Preemptable Replica ไม่ใช่ดิสก์ส่วนตัวของคุณ บทความนี้จึงเป็นการรีวิวสถาปัตยกรรมเพื่อรับมือกับข้อจำกัดดังกล่าวโดยเฉพาะ ไม่ใช่เรื่องเล่าจากโปรดักชันหรือ Benchmark ทั่วไป

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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

หลักการสำคัญคือ Planner ห้ามทำการ Commit ขั้นตอนเครื่องมือที่มีการเปลี่ยนแปลงข้อมูล (Mutating Tool Step) จนกว่าใบเสร็จการเขียน (Write Receipt) จะเชื่อมโยงเข้ากับ Live Sandbox Epoch ที่ยังคงทำหน้าที่เป็น Fencing Token ของ Replica นั้น หาก Epoch มีการเปลี่ยนแปลง ระบบจะต้องปฏิเสธหรือทำการชดเชย (Compensate) ทันที เพราะการเล่นซ้ำ (Replay) โดยไม่มีรั้วกั้นคือวิธีสร้างข้อมูลซ้ำซ้อน

"Are you measuring liveness of the replica, or are you hoping the next tool call will notice the disk is empty? Hope is not a fence."

Robin

การออกแบบนี้แบ่งระบบออกเป็นสี่โดเมนเพราะพวกมันล้มเหลวเป็นอิสระต่อกัน จุดชนวนที่น่าสนใจคือการที่ Replica ถูกยึดคืน (Preemption) ควบคู่ไปกับการตอบกลับสถานะ 200 ที่มาถึงช้า Planner จะเห็นความสำเร็จจากเจนเนอเรชันที่ไม่มีอยู่แล้ว หากคุณ Commit ข้อมูลในจุดนั้น คุณจะสูญเสียการอัปเดตไปโดยที่หน้า Dashboard ยังคงแสดงสถานะสีเขียว

ที่มา: Dev.to