การประหยัดเงินบน Amazon Web Services (AWS) Spot Instances อาจเป็นงานที่ท้าทาย โปรดจำไว้ว่านี่คือการประมูลโดยพื้นฐาน แม้ว่าราคาจะไม่ผันผวนอย่างรวดเร็วเหมือนในตลาดแลกเปลี่ยน แต่ก็ยังสามารถเพิ่มขึ้นจนถึงอัตรา on-demand ได้ บางครั้งอาจเกิดขึ้นเป็นเวลาหนึ่งหรือสองวัน แต่บางครั้ง — นานถึงหลายเดือน ซึ่งอาจทำให้ต้นทุนเพิ่มขึ้นเป็นสองเท่า

คุณจะหลีกเลี่ยงสถานการณ์ที่ทุกอย่างเป็นไปด้วยดีในเดือนพฤศจิกายน แต่ในเดือนธันวาคม ราคากลับเพิ่มขึ้นเป็นสองเท่าท่ามกลางความคึกคักของช่วงวันหยุด — และคุณได้ระบบที่ไม่เพียงแต่แพง แต่ยังมีการหยุดชะงักด้วยได้อย่างไร? มาดูว่าทำไมสิ่งนี้ถึงเกิดขึ้น สำหรับเรื่องนี้ เรามาดูวิธีการจัดสรร Spot Instance และดูว่าคุณจะใช้ Terraform module ได้อย่างไรโดยไม่มีปัญหาและประหยัดเงินไปพร้อมกัน

FirstImage

Spot Instance คือทรัพยากร EC2 (Elastic Compute Cloud) ที่ไม่ได้ใช้งานซึ่งถูกนำมาประมูลในราคาต่ำ จุดด้อยหลักคือการหยุดชะงัก ดังนั้นเตรียมตัวให้พร้อม การหยุดชะงักของ Spot Instance ไม่ใช่เรื่องผิดปกติ — เป็นส่วนหนึ่งของกระบวนการทำงานมากกว่าที่จะเป็นเหตุการณ์บางอย่าง

มีสามเหตุผลหลักสำหรับการหยุดชะงัก:

  • ราคาปัจจุบันสูงกว่าที่คุณยินดีจ่าย
  • ไม่มี Spot Instances ของประเภทที่คุณใช้งานเหลืออยู่
  • คุณตั้งข้อจำกัดเพิ่มเติม — เช่น เมื่อคุณตั้งค่า Availability Zones ทั้งหมดในตอนแรก แต่หลังจากนั้นเหลือเพียงหนึ่งเดียว ข้อมูลการหยุดชะงักจะถูกส่งผ่าน EC2 Metadata Service และ EventBridge บริการเหล่านี้จะช่วยให้คุณสามารถประมวลผลบางอย่างได้ แต่ควรทราบว่า AWS SLA สำหรับ instance เดียวมีเพียง 90% ดังนั้นคุณควรคาดหวังการหยุดชะงักในทุก instance ไม่ใช่แค่ใน spots เท่านั้น

วิธีง่ายๆ ในการจัดการกับการหยุดชะงัก ลิงก์ไปยังหัวข้อ

เพิ่มความเสถียรและความยืดหยุ่น ลิงก์ไปยังหัวข้อ

เพื่อทำให้ Spot Instances ของคุณมีความเสถียรและทนทานมากขึ้น ให้ใช้ Auto Scaling Group จากนั้นหากคุณประสบกับการหยุดชะงัก คุณจะสามารถทำงานบางอย่างให้เสร็จ หรืออย่างน้อยก็ได้รับ instance ใหม่มาแทนที่ตัวเก่า

เพิ่มโอกาสในการเปิดใช้งาน ลิงก์ไปยังหัวข้อ

AWS ใช้ Instance Types ที่แตกต่างกันโดยค่าเริ่มต้น แต่ถ้าคุณสร้าง Auto Scaling Group ด้วยตนเอง คุณจะเห็นรายการ Instance Types ทั้งหมดที่เป็นไปได้ และถ้าคุณไม่มีประเภทใดประเภทหนึ่ง คุณสามารถใช้ประเภทอื่นได้ ในบางกรณี คุณยังสามารถใช้รุ่นก่อนหน้าของพวกมันได้ AWS มีสถิติสำหรับ Instance Types ทั้งหมดที่ติดตามความน่าจะเป็นของการหยุดชะงักในแต่ละภูมิภาค ดังนั้นจึงควรเลือก Instance Type จากบริการ Spot Instance Advisor ที่นี่คุณจะเห็นว่าแต่ละประเภทเหมาะสมกับภูมิภาคใดบ้าง คุณยังสามารถจัดเรียงอย่างรวดเร็วในหน้าเดียวกันได้ เช่น จัดเรียงตามประเภทที่ได้รับผลกระทบน้อยที่สุดจากการหยุดชะงักในเดือนที่ผ่านมา

กลยุทธ์การจัดสรร Spot Instance ลิงก์ไปยังหัวข้อ

มีกลยุทธ์การจัดสรรหลายแบบ ซึ่งจะส่งผลต่อที่มาของ Spot Instance ที่จะถูกเปิดใช้งานและ Spot Pool (ชุดของ EC2 ที่ไม่ได้ใช้งานภายใน Availability Zone และ Instance Type เดียวกัน)

กลยุทธ์เริ่มต้น ลิงก์ไปยังหัวข้อ

กลยุทธ์การจัดสรรเริ่มต้นคือ capacity-optimized ซึ่งช่วยให้คุณได้รับ Spot Instance จาก Spot Instance Pool ที่มีความจุว่างมากที่สุด นอกจากนี้ เมื่อรวมกับ Auto Scaling Group จะมีการเลือก Instance Type เพียงประเภทเดียวต่อ Availability Zone — ซึ่งมีโอกาสล้มเหลวน้อยกว่า นี่เป็นกลยุทธ์ที่ดีมากสำหรับโหลดที่มีค่าใช้จ่ายสูงในการหยุดชะงัก แต่ถ้าคุณต้องการประหยัดมากขึ้น ก็มีทางเลือกอื่น

ราคาต่ำสุด ลิงก์ไปยังหัวข้อ

กลยุทธ์นี้จะเลือก Spot Instance จากหลาย Spot Instance Pools ในแต่ละ Availability Zone ที่มีราคาต่อ spot ต่ำที่สุด คุณยังสามารถระบุจำนวน spots ที่ต้องการเลือกได้ ค่าเริ่มต้นคือสอง แต่คุณสามารถตั้งได้สูงสุดถึง 20 วิธีนี้ยังทำงานได้ดีร่วมกับ Auto Scaling Group และ instances หลายประเภท ซึ่งหมายความว่าเราสามารถรับ instance ประเภทต่างๆ ใน Availability Zones ต่างกันได้ แม้ว่าจะสะดวก แต่คุณควรจำไว้ว่าราคาต่ำสุดมักจะมาพร้อมกับการหยุดชะงักมากที่สุด เพราะเราไม่สามารถบ่งชี้ได้ว่า Spot Pool ใดมีโอกาสหยุดชะงักน้อยที่สุด

ความยั่งยืนด้วย Capacity Rebalancing ลิงก์ไปยังหัวข้อ

วิธีการปรับปรุงความทนทานของ spot ด้วยสัญญาณใหม่ EC2 Rebalance Recommendation เปิดให้ใช้งานในปี 2020 ซึ่งสามารถมาถึงได้เร็วกว่าการแจ้งเตือนการหยุดชะงัก Spot Instance ปกติสองนาที ดังนั้น EC2 Auto Scaling จึงเปิดตัวฟีเจอร์ Capacity Rebalancing:

FirstImage

EC2 Auto Scaling Capacity Rebalancing ลิงก์ไปยังหัวข้อ

มาดูรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้ เพราะมันเพิ่มความเสถียรให้กับ spots ก่อนอื่น คุณจะได้รับข้อความแจ้งเตือนสัญญาณ Capacity Rebalancing จากนั้น Auto Scaling Group (หรือสคริปต์ของบุคคลที่สามที่ได้รับสัญญาณนี้) จะเริ่ม instance ใหม่ที่กำลังทำงานผ่านกระบวนการทั้งหมด หลังจากนั้น instance ที่มีความเสี่ยงสูงต่อการหยุดชะงักและได้รับสัญญาณ Capacity Rebalancing จะเริ่มถูกยุติ

ในที่สุดก็มีวิธีจัดการการยุติ Spot Instance อย่างถูกต้อง คุณสามารถเพิ่ม Lifecycle hooks สำหรับ Auto Scaling Group ของคุณ วาง instance ในสถานะ terminating หรือรับเหตุการณ์จาก EventBridge และเรียกใช้ Lambda function พร้อมตรรกะบางอย่าง เช่น ในกรณีของ containerization (ECS หรือ EKS) คุณสามารถลบ Pods/ECS Tasks ทั้งหมดออกจาก instance นี้และหลีกเลี่ยงการหยุดชะงักของโหลดได้เลย คำแนะนำง่ายๆ เหล่านี้อาจเพียงพอสำหรับบางคน แต่เรามาดูต่อว่า คุณจะประหยัดเงินได้อย่างไรในขณะที่ยังคงประสิทธิภาพสูง

Spot Instance มีค่าใช้จ่ายเท่าไหร่? ลิงก์ไปยังหัวข้อ

นี่อาจเป็นคำถามที่สำคัญที่สุด เพื่อหาคำตอบ เราจะใช้เครื่องมือสองอย่าง:

  • Cost Explorer แบบเก่าที่มีข้อมูลพื้นฐานและเข้าถึงง่าย
  • ข้อมูล Spot Instance data feed เพิ่มเติม — รายงานรายละเอียดใน S3 ซึ่งเปิดใช้งานได้ในตั้งค่า มาดูวิธีใช้ Cost Explorer ก่อน เราได้จัดกลุ่ม spots ตาม Instance Type กรองตาม Usage Type Group EC2 Running Hours และตั้งค่าตัวเลือกสำคัญที่เรียกว่า Purchase Option Spot ผลลัพธ์คือกราฟสองอัน: Costs และ Usage:

FirstImage

ทางเทคนิคแล้ว สามารถใช้เพื่อกำหนดราคาเฉลี่ยต่อวันได้ — เพียงแค่หารอันหนึ่งด้วยอีกอันหนึ่ง หากคุณเพิ่มตัวกรองตามแท็ก คุณจะได้ภาพรวมของสิ่งที่เกิดขึ้น แต่เมื่อมี Instance Types หลายประเภทในผลลัพธ์ จะยากขึ้น นอกจากนี้ยังไม่มีการจัดสรรรายละเอียดตามชั่วโมงโดยค่าเริ่มต้น แน่นอนว่าสามารถเพิ่มใน Cost Explorer ได้ แต่ไม่จำเป็นสำหรับงานนี้ และไม่ฟรีด้วย ดังนั้น มาดู Spot Instance data feed กัน ข้อมูลใหม่จะถูกเพิ่มทุกชั่วโมงแต่มีความล่าช้า การทดสอบแสดงว่าความล่าช้าอาจอยู่ระหว่าง 15 นาทีถึงหลายชั่วโมง:

FirstImage

สิ่งสำคัญที่สุดที่คุณจะได้รับจาก Spot Instance data feed คือข้อมูลรายละเอียดพร้อมประเภท instance ราคาสูงสุด ราคาตลาดปัจจุบัน และสุดท้ายราคาที่คุณจ่าย (คอลัมน์ Charge) สำหรับกระบวนการตั้งค่า คุณจะต้องมี ACL สำหรับ S3 ที่ปรับแต่งเล็กน้อย แม้ว่าจะไม่มีปัญหาใดๆ กับเรื่องนี้

การตั้งค่า Spot Instance Data Feed ลิงก์ไปยังหัวข้อ

ราคาปัจจุบันเรียกว่า Spot Price (คอลัมน์ Charge) ราคานี้ตั้งตาม Availability Zone และ Instance Type โดยอิงตาม อุปสงค์และอุปทานบน Amazon ราคาจะถูกปรับอย่างค่อยเป็นค่อยไปตามการพยากรณ์ระยะยาว อย่างไรก็ตาม ควรสังเกตว่าการเปลี่ยนแปลงราคาขึ้นและลงมีความนุ่มนวล — หมายความว่าราคาจะไม่เปลี่ยนแปลงทุกชั่วโมง และถ้าวันหนึ่งราคาอยู่ที่ $1 วันถัดไปจะไม่เป็น $3

ดังนั้น คุณสามารถใช้การตั้งค่าที่สำคัญแต่ไม่ค่อยมีคนรู้จักที่เรียกว่า Spot Max Price ซึ่งเป็นราคาสูงสุดที่คุณยินดีจ่ายสำหรับ Spot Instance ทันทีที่ราคาถึงระดับสูงกว่านี้ คุณก็หยุดจ่าย คนมักล้มเหลวในการตั้งค่า Spot Max Price เพราะไม่ได้รวมไว้ใน UI และผู้ใช้ต้องตั้งผ่าน SLA แต่ตั้งแต่นั้นมา ก็ได้เพิ่มเข้าไปในคำขอ Spot แล้ว

การตั้งค่า Spot Max Price มีความสำคัญมาก หากคุณไม่ระบุค่าใดๆ คุณจะยอมรับที่จะจ่ายราคาทุกระดับจนถึง on-demand (ซึ่งเป็นเพดานราคาจริงๆ) ตัวอย่างเช่น ดูการเปลี่ยนแปลงราคาช่วงวันหยุดเดือนธันวาคมสำหรับ Instance Types สามประเภท:

FirstImage

ในตอนแรก ประเภทที่คุ้มค่าที่สุดคือ t3a เพราะถูกกว่าประมาณ 10% โดยเฉลี่ย ความต้องการจึงเริ่มเพิ่มขึ้นอย่างรวดเร็ว ผู้คนเริ่มซื้ออย่างรวดเร็ว และในบางจุด t3 กลายเป็นตัวเลือกที่คุ้มค่ากว่า และเมื่อคนซื้อหมด c5 ก็กลายเป็นถูกกว่า ซึ่งค่อนข้างไม่คาดคิด

โปรดจำไว้ว่าประเภท Spot Instance แบบ A มักจะแพงกว่าปกติ เหตุผลทั่วไปคือความนิยม — พวกมันถูกกว่า on-demand และถูกซื้อบ่อยกว่า คุณอาจคิดว่า — แล้วควรทำอย่างไร? เลิกใช้ Spot Instances เลยหรือ? อย่าเพิ่งรีบ มีทางแก้ — Terraform module จะช่วยแก้ปัญหาส่วนใหญ่โดยไม่ต้องคอยติดตามประวัติราคาสปอตอย่างต่อเนื่อง

Terraform Module ลิงก์ไปยังหัวข้อ

โมดูลนี้แก้ปัญหาเรื่องการคำนวณ Spot Max Price อัตโนมัติ มีพฤติกรรมหลายแบบที่อาจเป็นประโยชน์:

  • spot_price_current_min — อย่างน้อยหนึ่ง Instance Type ในอย่างน้อยหนึ่ง AZ;
  • spot_price_current_optimal — อย่างน้อยหนึ่ง Instance Type ในทุก AZ;
  • spot_price_current_max — ทุก Instance Types ในทุก AZ;
  • spot_price_current_max_mod — ทุก Instance Types ในทุก AZ พร้อมความน่าเชื่อถือที่เพิ่มขึ้น เราจะไล่ดูจากง่ายไปซับซ้อนโดยใช้ price matrix เป็นตัวอย่าง:

FirstImage

ก่อนอื่น เราจะได้ spot_price ปัจจุบันโดยไม่ต้องเปิด UI และดูประวัติ Spot price นี่คือตัวอย่างที่ง่ายที่สุด:

FirstImage

ราคาต่ำสุด ลิงก์ไปยังหัวข้อ

นี่คือตัวอย่างที่ซับซ้อนขึ้นเล็กน้อย หากเป้าหมายของคุณคือการรัน instance ที่ถูกที่สุดเท่าที่จะเป็นไปได้ ในสถานการณ์นี้ ใช้พฤติกรรม spot_price_current_min:

FirstImage

ในกรณีนี้ instances อย่างน้อยหนึ่ง Instance Type จะถูกเปิดใช้งานในหนึ่ง Availability Zone แม้ว่าจะผ่านหลาย Availability Zones แต่ instances ทั้งหมดจะอยู่ในโซนเดียวกันเพราะเลือกเพียงโซนเดียว จำไว้ว่ามีเพียง instance เดียวที่ถูกที่สุดเสมอ

ดูจากตาราง เราจะเห็นว่า instance ประเภท r5a ใน Availability Zone 1b มีราคาต่ำสุดที่ 0.10 เมื่อราคามีการเปลี่ยนแปลง คุณจะได้รับราคาต่ำสุดทุกครั้ง เช่น หากราคาเริ่มเพิ่มขึ้นใน Availability Zone หนึ่ง ครั้งถัดไปที่ใช้ terraform apply คุณจะได้ราคาต่ำสุดจาก Availability Zone อื่น แน่นอนว่าพฤติกรรมนี้จะทำให้เกิดการหยุดชะงักบ่อยที่สุด และถ้าราคาเพิ่มขึ้นแม้เพียงเล็กน้อย คุณจะสูญเสีย instance นี้ทันที ดังนั้น พฤติกรรมนี้จึงไม่ค่อยมีประสิทธิภาพ วิธีที่ดีกว่าคือมองหาสมดุลระหว่างราคาและความพร้อมใช้งาน

ราคาที่เหมาะสม ลิงก์ไปยังหัวข้อ

FirstImage

พฤติกรรมนี้ช่วยให้สามารถรัน Instance Type อย่างน้อยหนึ่งประเภทในทุก Availability Zones ซึ่งแก้ปัญหาเรื่องการกำหนดว่า Instance Type ใดคุ้มค่ากว่ากัน: t3, t3a, c5 หรือบางประเภท r เมื่อราคามีการเปลี่ยนแปลง คุณจะสลับไปยัง Instance Types ที่คุ้มค่าที่สุดสำหรับแต่ละ Availability Zone หากราคาขึ้น คุณจะสูญเสีย Availability Zone ทีละโซน เหมือนกับการปิดใช้งานโซนเหล่านั้น กลับไปดูตาราง เราจะเห็นตัวเลือกมากขึ้น:

FirstImage

มีเพียง r5 instances เท่านั้นที่มีใน Availability Zone 1c ที่ราคา 0.20 แต่ถ้าราคาเพิ่มเป็น 0.30 คุณยังมี Availability Zones อีกสองโซนและ Instance Types อีกสองประเภท หมายเหตุสำคัญ: การเปลี่ยนแปลงนี้จะทำให้ instances ที่ราคาสูงขึ้นถูกหยุดชะงัก แต่สำหรับ spots คุณต้องพร้อมรับการหยุดชะงักและถือเป็นเรื่องปกติ ตัวเลือกก่อนหน้านี้ทั้งหมดเน้นการประหยัดสูงสุด แต่ถ้าคุณต้องการความเสถียรมากขึ้น พฤติกรรม spot_price_current_max จะเหมาะสม

ราคาปัจจุบันสูงสุด ลิงก์ไปยังหัวข้อ

FirstImage

ด้วยพฤติกรรมนี้ สามารถเปิดใช้งาน Instance Types ทั้งหมดในทุก Availability Zones ได้ ซึ่งแก้ปัญหาเรื่องไม่มี Spot Instances โดยกำหนดราคาสำหรับประเภทต่างๆ นอกจากนี้ พฤติกรรมนี้ยังช่วยให้มีความล่าช้าระหว่างการรัน terraform apply มากขึ้น และโมดูลไม่จำเป็นต้องรันบ่อยๆ ซึ่งสะดวกมากหากโมดูลบางครั้งรันด้วยตนเอง ไม่ใช่ใน CI/CD จากตารางนี้ สามารถเปิดใช้งาน Instance Type ใดก็ได้ใน AZ ใดก็ได้ เพราะไม่มีตัวใดเกินราคาสูงสุด หมายความว่าถ้าคุณรัน r5 ที่ 1a ซึ่งมีราคา 0.20 คุณจะจ่ายราคานั้นจนกว่าจะถึง 0.30 พฤติกรรมนี้ช่วยให้คุณเป็นอิสระจาก Instance Types และ Availability Zones ทั้งหมด หากเพิ่ม Instance Types หลายประเภท คุณจะครอบคลุมทุกกรณีและมี spots เสมอ

ราคาที่ปรับแต่ง ลิงก์ไปยังหัวข้อ

หากคุณต้องการความเสถียรมากขึ้น และพร้อมจ่ายเพิ่ม 5-10% บางครั้ง มีพฤติกรรม spot_price_current_max_mod:

FirstImage

พฤติกรรมนี้ลดโอกาสการหยุดชะงักจากความผันผวนของราคาเล็กน้อย และช่วยได้หาก Terraform รันน้อยมากหรือรันด้วยตนเอง คุณสามารถระบุว่าคุณยินดีจ่ายเพิ่มล่วงหน้า เช่น เพิ่ม 10% จากราคาปัจจุบัน คือ 0.33 แทน 0.30 นี่คือการจ่ายเพิ่มเล็กน้อยเพื่อแลกกับการหยุดชะงักที่ลดลง โปรดทราบว่าการจ่ายเพิ่มขึ้นอยู่กับจำนวน instances ที่คุณใช้ ความแตกต่าง +2¢ อาจเท่ากับ $14 ต่อเดือนสำหรับแต่ละ EC2 instance และถ้าคุณใช้ 100 instances อาจกลายเป็น $1,400 ดังนั้น คำนวณดูว่าการลดโอกาสหยุดชะงักคุ้มค่าหรือไม่ หากคุณยังคิดว่าคุ้มค่า คุณสามารถใช้พฤติกรรมนี้กับทุกสถานการณ์ผ่านตัวปรับแต่งราคาที่กำหนดเอง

การใช้งาน EC2 Spot Price Module ลิงก์ไปยังหัวข้อ

ปัญหาพื้นฐานที่สุดที่ Terraform module แก้ไขคือไม่ให้ราคาถึงเพดาน เพื่อไม่ให้คุณต้องจ่ายราคาเป็นสองเท่า ดังนั้นจึงสามารถใช้ได้ทุกที่ที่คุณ