การย้ายไปยัง workspace ที่ใหญ่ขึ้นโดยไม่ทำให้ใครต้องรอ

ทุกโปรเจกต์ Mythex ได้รับ workspace ของตัวเอง คือคอมพิวเตอร์คลาวด์ขนาดเล็กที่เอเจนต์เขียนโค้ดและพรีวิวของแอปรันอยู่ เราเคยเพิ่ม memory ของ workspace ใหม่จาก 1 GB เป็น 2 GB แต่ workspace เก่ายังคงอยู่ที่ 1 GB ในวันที่เราตรวจสอบ ประมาณหนึ่งในสี่ยังเป็นขนาดเดิม การแก้ครั้งแรกของเราคือย้ายโปรเจกต์ไปยัง workspace ที่ใหญ่กว่าเมื่อมีการเปิดโปรเจกต์ในครั้งถัดไป ในวันแรกที่ใช้งานจริง การแก้นั้นทำให้คนหนึ่งต้องรอเจ็ดนาที เราจึงตั้งขีดจำกัดเวลาตายตัวให้กับมัน และสุดท้ายก็นำการย้ายออกจากการเปิดโปรเจกต์ไปเลย

ทำไม workspace เก่าจึงยังเล็กอยู่

ผู้ให้บริการ sandbox ของเรากำหนดขนาดของ workspace ตอนที่สร้าง และคงขนาดนั้นไว้ผ่านทุกการพักและการกลับมาทำงาน การเปลี่ยน template ซึ่งเป็นสูตรที่ใช้สร้าง workspace ใหม่ มีผลเฉพาะ workspace ที่สร้างหลังการเปลี่ยนแปลงเท่านั้น ไม่มีอะไรปรับขนาดของ workspace ที่มีอยู่แล้ว

เรื่องนี้สำคัญ เพราะ workspace ขนาดเล็กตัวหนึ่งหน่วยความจำหมดระหว่าง git push ขณะที่พรีวิวกำลังเริ่มทำงาน และไม่ตอบสนองไปถึง 11 นาที การ publish จึงล้มเหลวเพราะเรื่องนี้

ความพยายามแรก: ย้ายโปรเจกต์ตอนปลุก

Workspace จะพักเมื่อไม่มีใครใช้ และปลุกเมื่อเปิดโปรเจกต์ การปลุกดูเหมือนเป็นจังหวะที่เหมาะในการย้ายโปรเจกต์ เพราะยังไม่มีใครทำงานในนั้น

การย้ายทำงานดังนี้:

1. ตรวจขนาด หาก workspace เล็กกว่า 2 GB ให้ย้าย หากไม่ทราบขนาด ไม่ต้องทำอะไร
2. ไม่รบกวนการ publish การ publish อ่านไฟล์ของ workspace ดังนั้นหากกำลังมีการ publish อยู่ ให้ข้ามการย้าย
3. แพ็กโปรเจกต์ เก็บถาวรทุกอย่างในโปรเจกต์ รวมถึง git history ซึ่งคือทุก checkpoint ของโปรเจกต์ และไฟล์ .env ของแอปซึ่งเป็นของเจ้าของ แต่ไม่รวม dependency ที่ติดตั้งแล้ว (node_modules) ซึ่งติดตั้งใหม่ได้
4. คัดลอกตรงๆ สตรีมไฟล์เก็บถาวรจาก workspace เก่าไปยัง workspace 2 GB ใหม่ ทำให้ไม่ต้องใส่ทั้งหมดในหน่วยความจำของเซิร์ฟเวอร์ของเราเอง
5. เปรียบเทียบก่อนสลับ นับจำนวนไฟล์ อ่าน checkpoint ล่าสุด และนับ checkpoint ทั้งหมด ในทั้งสอง workspace สลับก็ต่อเมื่อทั้งสามอย่างตรงกัน
6. เก็บ workspace เดิมไว้เมื่อมีความล้มเหลว ข้อผิดพลาดหรือความไม่ตรงกันใดๆ จะลบ workspace ใหม่ทิ้ง และเปิดโปรเจกต์ใน workspace เดิมเหมือนเดิม

รายละเอียดหนึ่งในการเปรียบเทียบมีความสำคัญกว่าที่เห็น การตรวจทำงานในบัญชีผู้ดูแลระบบ และ git ปฏิเสธที่จะอ่าน repository ที่เป็นของผู้ใช้อีกคน มันพิมพ์อะไรออกมาไม่ได้ทั้งสองฝั่ง และ "ไม่มีอะไร" ตรงกับ "ไม่มีอะไร" ดังนั้นการตรวจจึงผ่านโดยไม่ได้เปรียบเทียบประวัติเลยแม้แต่น้อย เราบอก git ให้เชื่อถือไดเรกทอรีนั้น และเพิ่ม test เพื่อไม่ให้สิ่งนี้หลุดกลับมาอีก

สิ่งที่ผิดพลาดในวันแรก

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

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

ความพยายามที่สอง: งบประมาณตายตัว

ในวันเดียวกันเราเปลี่ยนสี่อย่าง:

• หนึ่งนาทีสำหรับการย้ายทั้งหมด ทุกขั้นตอน ได้แก่ ตรวจขนาด แพ็ก สร้าง workspace ใหม่ คัดลอก แตกไฟล์ และเปรียบเทียบ ใช้งบประมาณ 60 วินาทีร่วมกัน เมื่อหมดเวลา โปรเจกต์จะเปิดใน workspace เดิม
• หยุดการทำงาน ไม่ใช่แค่การรอ การหยุดรอฝั่งเราไม่พอ หากการเก็บถาวรยังทำงานอยู่ภายใน workspace ที่เจ้าของกำลังจะใช้ ดังนั้นคำสั่งเก็บถาวรแต่ละคำสั่งตอนนี้จะถูกฆ่าภายใน workspace นั้นเองไม่นานก่อนงบประมาณจะหมด หาก workspace ใหม่มาถึงหลังจากที่เราเลิกรอแล้ว มันจะถูกทิ้ง
• ไม่ให้เจ้าของรอการทำความสะอาด การลบไฟล์เก็บถาวรชั่วคราวตอนนี้เกิดขึ้นในเบื้องหลัง
• ไม่ลองซ้ำทุกครั้งที่เปิด โปรเจกต์ที่ย้ายไม่สำเร็จจะถูกปล่อยไว้ 24 ชั่วโมง ดังนั้นความล้มเหลวจะทำให้ล่าช้าได้มากที่สุดหนึ่งครั้งต่อวัน ไม่ใช่หนึ่งครั้งต่อการเปิดทุกครั้ง

ความพยายามที่สาม: เอาออกจากการปลุก

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

ตอนนี้ไม่มี workspace ใดถูกสร้างที่ 1 GB อีกแล้ว ดังนั้นนี่จึงไม่ใช่กระบวนการต่อเนื่อง แต่เป็นงานครั้งเดียวที่มีรายการ workspace ตายตัว การทำมันในการปลุกหมายความว่ามีคนจริงๆ จ่ายราคาสำหรับการย้ายที่ช้าทุกครั้ง และวิธีเดียวที่เราจะรู้ว่า workspace ไหนย้ายไม่ได้ คือมีคนเพิ่งรอมันอยู่

ดังนั้นเราจึงนำการย้ายออกจากการปลุกทั้งหมด การเปิดโปรเจกต์ทำงานเหมือนเดิมก่อนหน้านี้ workspace เล็กที่เหลือถูกจัดการเป็นชุดงานที่มีผู้ดูแลแทน ไม่มีใครรอ และ workspace ที่ย้ายไม่ได้จะปรากฏในรายงานของชุดงาน ซึ่งเราสามารถดูได้ แทนที่จะปรากฏต่อหน้าเจ้าของ

สิ่งที่เราได้เรียนรู้

• การปรับขนาดไม่ได้ทำได้เสมอไป เมื่อแพลตฟอร์มกำหนดขนาดตอนสร้าง การเพิ่มค่าเริ่มต้นจะช่วยเฉพาะสิ่งใหม่ ต้องวางแผนสำหรับของเก่าด้วย
• "ยังไม่มีใครใช้" ก็ยังหมายความว่ามีคนรออยู่ งานที่ทำระหว่างที่ผู้ใช้กำลังเข้าสู่ผลิตภัณฑ์ คืองานที่มีคนเฝ้ามอง
• ตั้งงบประมาณให้ทุกอย่างที่อยู่ในเส้นทางของผู้ใช้ และหยุดงานเมื่องบหมด การหมดเวลาฝั่งเราในขณะที่คำสั่งยังทำงานอยู่ที่อื่น เป็นเพียงการย้ายปัญหาไปที่อื่น
• การย้ายครั้งเดียวควรอยู่ในงานครั้งเดียว การซ่อนมันไว้ในการกระทำประจำวันทำให้เขียนง่ายขึ้น แต่รันแพงขึ้น
• ทดสอบการตรวจความปลอดภัยของคุณ การเปรียบเทียบที่ไม่ได้เปรียบเทียบอะไรเลยดูเหมือนการเปรียบเทียบที่ผ่านทุกประการ

หากคุณสร้างบน Mythex ไม่มีอะไรที่คุณต้องทำ เป้าหมายคือ workspace ที่หน่วยความจำหมดน้อยลง และการเปิดโปรเจกต์ที่เร็วเท่าเดิม การพักและการปลุก workspace อยู่ในเอกสารภายใต้ private workspace สำหรับเรื่องราวหน่วยความจำหมดอีกเรื่อง ดู บั๊กหน่วยความจำรั่วที่ซ่อนอยู่ในป้ายความคืบหน้า