ลดเวลาบูตของ EC2

 (depot.dev)
14 คะแนน โดย GN⁺ 2024-05-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สามารถลดเวลาบูตของ EC2 อินสแตนซ์จาก 40 วินาทีเหลือ 5 วินาทีได้
  • เรื่องนี้สำคัญมากเมื่อจำเป็นต้องใช้ EC2 อินสแตนซ์ใหม่เพื่อประมวลผลงานเฉพาะอย่าง

เหตุผลที่เวลาในการบูตนาน

  • เมื่อร้องขอ EC2 อินสแตนซ์ใหม่ AWS ต้องทำหลายขั้นตอน:
    • สร้างรูท EBS โวลุมจาก AMI ที่เลือก
    • จัดสรรที่อยู่ IP ภายในให้กับอินสแตนซ์
    • เลือกโฮสต์สำหรับอินสแตนซ์
    • บูตเครื่องจริง
  • แม้หลังจากฮาร์ดแวร์เปิดขึ้นแล้ว ก็ยังต้องเริ่ม bootloader, kernel และโปรเซสใน user space อีกด้วย

วิธีหลีกเลี่ยงปัญหา

  • ดูแลพูลคอมพิวต์ที่อยู่ในสถานะพร้อมใช้งาน แล้วส่งคำขอบิลด์ไปยัง EC2 อินสแตนซ์ที่กำลังรันอยู่แล้ว
  • แต่แนวทางนี้ไม่คุ้มค่าในเชิงเศรษฐกิจสำหรับทุกงาน
  • ในกรณีของ GitHub Actions runner แต่ละงานจะถูกส่งไปยัง EC2 อินสแตนซ์แบบเฉพาะ
  • การต้องคง EC2 อินสแตนซ์ 50 เครื่องให้ออนไลน์เพื่อรองรับงานขนาน 50 งานนั้นไม่สมจริง

เวลาในการบูตที่เร็วขึ้น

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

การสตรีม EBS รูทโวลุม

  • การเตรียม EBS รูทโวลุมมีผลอย่างมากต่อเวลาบูตของ EC2 อินสแตนซ์และประสิทธิภาพของแอปพลิเคชัน
  • เมื่อสร้าง EBS โวลุมจาก AMI บล็อกข้อมูลจะต้องถูกดึงมาจาก S3 ในครั้งแรกที่มีการเข้าถึง
  • AWS แนะนำให้โหลดบล็อกข้อมูลทั้งหมดล่วงหน้า

บูตอินสแตนซ์เพียงครั้งเดียว

  • อินสแตนซ์ที่รองรับ EBS สามารถหยุดแล้วเริ่มใหม่ได้
  • อินสแตนซ์ที่ถูกหยุดจะเก็บเฉพาะการตั้งค่าไว้ และจ่ายค่าใช้จ่ายเฉพาะรูท EBS โวลุม
  • หากบูตอินสแตนซ์หนึ่งครั้งเพื่อทำงานเริ่มต้นให้เสร็จแล้วหยุดไว้ จะได้ EBS รูทโวลุมที่ถูก "วอร์ม" แล้ว

Auto Scaling warm pool

  • AWS มี warm pool สำหรับ EC2 Auto Scaling
  • แต่ออโตสเกลลิงกรุ๊ปใช้เวลาระยะหนึ่งกว่าจะตอบสนองต่อคำขอ
  • เพื่อให้ได้ประสิทธิภาพสูงสุด จึงเริ่ม EC2 อินสแตนซ์โดยตรงผ่านการเรียก API LaunchInstances และ StartInstances

การปรับขนาดอินสแตนซ์

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

โฟลว์ทั้งหมด

  • GitHub Actions runner อินสแตนซ์จะผ่านโฟลว์ดังนี้:
    • สร้างเป็นอินสแตนซ์ t3.large
    • จัดสรรที่อยู่ IP ภายในให้กับ VPC เป้าหมาย
    • เริ่ม kernel และโปรเซสใน user space หนึ่งครั้ง
    • หยุดอินสแตนซ์
    • เมื่อมีคำของานเข้ามา ให้อัปเดตประเภทอินสแตนซ์เป็น m7a แล้วเริ่มทำงาน
    • หากไม่มีความจุของอินสแตนซ์ m7a ให้เปลี่ยนเป็นประเภทสำรองแล้วเริ่มใหม่
  • ด้วยโฟลว์นี้ เวลาเตรียมอินสแตนซ์สำหรับงานลดลงจาก 40 วินาทีเหลือ 5 วินาที

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-28
ความคิดเห็นบน Hacker News

สรุป

  • เวลาในการบูต: เป็นปัจจัยสำคัญต่อความสำเร็จของการทำ auto scaling ยิ่งบูตเร็ว หน้าต่างการคาดการณ์ก็ยิ่งสั้นลง ทำให้การคาดการณ์แม่นยำขึ้น และเพื่อประหยัดค่าใช้จ่าย การเตรียม EBS volume ไว้ล่วงหน้าอาจเป็นทางเลือกที่สมเหตุสมผล
  • การปรับแต่งของ Amazon: Amazon ทำให้การบูตเร็วมากได้ด้วยเทคโนโลยีอย่าง Firecracker และมีความเป็นไปได้ว่าอาจมีฟีเจอร์ลักษณะใกล้เคียงกันใน EC2 ด้วย
  • การตั้งค่าแบบ immutable: สามารถเพิ่มประสิทธิภาพได้ด้วยการตั้งค่าแบบ immutable/atomic เพื่อแชร์ EBS volume และใช้ AMI สำหรับบูตขั้นต่ำ
  • การวัดเวลาในการบูต: เวลาในการบูตของ EC2 instance แสดงรูปแบบแบบสองกลุ่ม โดยกระจายอยู่ที่ 15-20 วินาที หรือ 80 วินาที จึงจำเป็นต้องหาสาเหตุ
  • GitHub Actions: แม้จะปรับปรุงการบูตของ GitHub Actions runner แล้ว แต่เวลาในการส่งต่องานยังยาวอยู่ จึงยังต้องปรับแต่งเพิ่มเติม
  • การเปรียบเทียบกับ AWS: มีการเปรียบเทียบเวลาในการบูตของ AWS กับผู้ให้บริการคลาวด์รายอื่น โดย Hetzner สามารถสร้าง instance ได้ภายในไม่กี่วินาที
  • ตัว autoscaler ของ EC2: มีการกล่าวถึงข้อจำกัดของ autoscaler สำหรับ EC2 และความจำเป็นในการปรับปรุง โดย autoscaler ที่ AWS จัดให้ยังช้าและมีข้อจำกัด
  • เหตุผลที่ใช้ EBS: EBS ยอมแลกต้นทุนและประสิทธิภาพเพื่อความทนทาน เนื่องจากเป็น volume ที่เชื่อมต่อผ่านเครือข่ายจึงช้า การติดตั้ง Linux แบบขั้นต่ำและใช้ local storage ที่เร็วอาจเหมาะสมกว่า
  • การขาดการรองรับ Copy-On-Write ของ EBS: EBS ไม่รองรับ Copy-On-Write และ snapshot ถูกเก็บไว้ใน S3 ทำให้การจัดสรร IOPS มีความล่าช้า
  • การย้ายไปยังฮาร์ดแวร์ on-premises: Depot อาจย้ายไปใช้ฮาร์ดแวร์ on-premises เพื่อเพิ่มประสิทธิภาพและลดต้นทุน และการบูตงาน CI ของลูกค้าโดยตรงบน hypervisor เองอาจเป็นแนวทางที่ดีกว่า