วิธีรันคอนเทนเนอร์อิมเมจก่อนดาวน์โหลดครบ: เจาะลึก AWS SOCI

บทความนี้อธิบายการทำงานภายในของ AWS SOCI (Seekable OCI) ที่ทำให้คอนเทนเนอร์อิมเมจสามารถ “รันได้ก่อนดาวน์โหลดครบ” โดยอธิบายผ่านมุมมองของ HTTP Range Request / FUSE / zTOC (ดัชนี)

ที่มาของแนวคิด (อินไซต์จากงานวิจัย Slacker)

• Slacker: Fast Distribution with Lazy Docker Containers (USENIX FAST ’16) เริ่มจากการวัดให้เห็นก่อนว่าเหตุใด “cold start” ของคอนเทนเนอร์จึงช้า
• ได้สร้างเบนช์มาร์กชื่อ HelloBench และวัดเวลาสำหรับเวิร์กโหลดคอนเทนเนอร์ 57 แบบ ตั้งแต่ “เริ่ม deploy” จนถึง “พร้อมทำงานที่มีความหมายจริง (service ready)”
• ข้อสังเกต 1) เวลาส่วนใหญ่ตอนเริ่มต้นถูกใช้ไปกับ ‘pull/copy อิมเมจและแพ็กเกจ’
  • pulling packages (การคัดลอกข้อมูลแพ็กเกจ/อิมเมจ) กินเวลาถึง 76% ของเวลาเริ่มคอนเทนเนอร์
• ข้อสังเกต 2) แต่ข้อมูลที่ถูกอ่านจริงทันทีหลังเริ่ม มีเพียงส่วนน้อยมากของทั้งหมด
  • โดยเฉลี่ยมีเพียง 6.4% ของข้อมูลที่ถูก pull/คัดลอกเท่านั้น ที่ถูกอ่านจริง “ก่อนที่คอนเทนเนอร์จะเริ่มทำงานที่มีความหมาย”
• ข้อสังเกต 3) อิมเมจต่าง ๆ มี “ข้อมูลร่วม/ข้อมูลซ้ำ” มากกว่าที่คิด
  • รายงานระบุว่า เมื่อเทียบกับการบีบอัด gzip ระดับอิมเมจ การ dedup แบบง่ายในระดับบล็อกที่หาบล็อกร่วมกันระหว่างอิมเมจ ให้ประสิทธิภาพการบีบอัดดีกว่า
• ข้อสรุป (แก่นของปัญหา): วิธี “ดาวน์โหลดทั้งหมดก่อนแล้วค่อยรัน” มีความสูญเปล่าสูง และ
  วิธีที่ดึงเฉพาะสิ่งจำเป็นต่อการเริ่มต้นก่อน (รันทันที) แล้วค่อยดึงส่วนที่เหลือตามต้องใช้ (lazy) อาจได้ผลดีกว่า
• จากข้อสังเกตเหล่านี้ จึงได้ออกแบบ Docker storage driver ชื่อ Slacker
• โดยให้ Docker worker/registry ทั้งหมดใช้สตอเรจกลางร่วมกัน และลดต้นทุนการ provision ระบบไฟล์ด้วย snapshot/clone ของ backend storage
• ข้อมูลคอนเทนเนอร์จะถูกดึงแบบ lazy “เมื่อจำเป็น” และรายงานว่าช่วยลดเวลาของวงจร push/pull และพัฒนา/ดีพลอยได้มาก

SOCI Snapshotter (AWS)

• ใน README ของ SOCI snapshotter ก็อ้างถึงข้อสังเกต “76% vs 6.4%” จาก Slacker (FAST ’16) โดยตรง ว่าเป็นเหตุผลที่ lazy loading ใช้ได้ผล
• หาก Slacker เป็นแนวทางที่พึ่งพา “Docker driver + ความสามารถเฉพาะของสตอเรจ (เซิร์ฟเวอร์)” ค่อนข้างมาก
  SOCI คือการทำให้แนวคิดนี้เป็นแบบทั่วไปขึ้นในระบบนิเวศ OCI โดยกลายเป็น “lazy loading จาก registry (เช่น ECR)”
• ตอนรันคอนเทนเนอร์ SOCI จะไม่รับอิมเมจมาทั้งหมดก่อน
  แต่จะใช้ดัชนีแยกต่างหาก (zTOC/Index Manifest) เพื่อรู้ตำแหน่งไฟล์และข้อมูล span ก่อน แล้วดึงเฉพาะชิ้นที่ต้องใช้ก่อนแบบ on-demand เพื่อเร่งการเริ่มต้น
  จากนั้นจึง prefetch ส่วนที่เหลือต่อในฉากหลัง เป็นกลยุทธ์แบบไฮบริด

องค์ประกอบหลักของ SOCI

• HTTP Range Request: ดึงเฉพาะช่วงไบต์ที่ต้องใช้จาก registry (ECR) ด้วย 206 Partial Content
• zTOC: เก็บออฟเซ็ต/เมทาดาทาของไฟล์ พร้อม compression checkpoint (zInfo) เพื่อให้คลายบีบอัดได้ “จากตรงกลาง”
• FUSE: เมานต์เลเยอร์ให้เหมือนระบบไฟล์ แล้วดักจับ open/read เพื่อ fetch span ที่จำเป็น (ค่าเริ่มต้น 4MB) แบบ on-demand

ลำดับการทำงาน (อิง ECS Fargate)

• ตรวจสอบดัชนี (manifest) → ดาวน์โหลด zTOC → เมานต์ FUSE → รันคอนเทนเนอร์
• เมื่อมีการเข้าถึงไฟล์ จะดาวน์โหลดเฉพาะ span นั้นทันทีด้วย Range Request แล้วคลายบีบอัดก่อนส่งต่อ
• ขณะเดียวกันก็ยังคงดาวน์โหลดอิมเมจทั้งหมดต่อในฉากหลัง เป็นกลยุทธ์ “ไฮบริด”

ข้อจำกัด/จุดแลกเปลี่ยน

• มีโอเวอร์เฮดจากดัชนี/การเมานต์ ทำให้อิมเมจขนาดเล็ก (เช่น ต่ำกว่า 250MB) อาจไม่คุ้ม
• ประสิทธิผลไม่ได้ไวต่อขนาดอิมเมจเท่ากับ “รูปแบบการเข้าถึงไฟล์ในช่วงเริ่มต้น”
• ยังมีพื้นที่ให้ปรับแต่งขนาด span (จำนวน request เทียบกับการดาวน์โหลดส่วนเกิน) และมีการกล่าวถึงแนวทางปรับปรุงอย่าง LOD (Load Order Document)