การปรับขนาดตามกำหนดเวลาและการปรับขนาดเชิงคาดการณ์

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

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

การดำเนินการตามกำหนดการใช้ รูปแบบ cron ของ Unix: minute hour day-of-month month day-of-week เวลาทั้งหมดเป็นเวลา UTC รูปแบบที่ใช้บ่อย ได้แก่ 0 8 * * 1-5 (เช้าวันธรรมดาเวลา 08:00 UTC) สำหรับการเพิ่มขนาด และ 0 20 * * * (ทุกคืนเวลา 20:00 UTC) สำหรับการลดขนาด คุณสามารถสร้างการดำเนินการตามกำหนดการหลายรายการใน ASG เดียวกันได้ เช่น รายการหนึ่งสำหรับเพิ่มขนาด และอีกรายการสำหรับลดขนาดกลับลงในแต่ละวัน

การดำเนินการตามกำหนดการอาจเป็นแบบ ครั้งเดียว (ดำเนินการหนึ่งครั้ง ณ เวลาเริ่มต้นที่ระบุ) หรือแบบ เกิดซ้ำ (ดำเนินการตามกำหนดการ cron) การดำเนินการแบบครั้งเดียวเหมาะอย่างยิ่งสำหรับเหตุการณ์ในอนาคตที่ทราบล่วงหน้า เช่น การเปิดตัวผลิตภัณฑ์ ส่วนการดำเนินการแบบเกิดซ้ำเหมาะสำหรับรูปแบบที่เกิดเป็นประจำ เช่น รอบปริมาณการใช้งานรายวันหรือรายสัปดาห์ นอกจากนี้ คุณยังสามารถกำหนด เวลาเริ่มต้น และ เวลาสิ้นสุดให้กับการดำเนินการแบบเกิดซ้ำ เพื่อเปิดใช้และปิดใช้กำหนดการโดยอัตโนมัติภายในช่วงวันที่ที่กำหนดได้

การดำเนินการตามกำหนดการและนโยบายการปรับขนาดแบบไดนามิกสามารถทำงานร่วมกันได้ การดำเนินการตามกำหนดการจะกำหนด ความจุพื้นฐานใหม่ ณ เวลาที่กำหนด หลังจากนั้น นโยบายแบบไดนามิก (การติดตามเป้าหมายหรือการปรับขนาดแบบขั้น) จะปรับความจุต่อไปภายในขอบเขตต่ำสุดและสูงสุดที่อัปเดตแล้ว ตัวอย่างเช่น การดำเนินการตามกำหนดการในตอนเช้ากำหนด min=4 และ desired=8 ระหว่างวัน การติดตามเป้าหมายเพิ่มขนาดเป็น 15 เมื่อมีโหลดสูง และการดำเนินการตามกำหนดการในตอนเย็นจะรีเซ็ตค่าเป็น min=2 และ desired=2

Predictive Scaling ใช้การเรียนรู้ของเครื่องเพื่อวิเคราะห์รูปแบบโหลดในอดีตจากเมตริกของ CloudWatch และคาดการณ์ความต้องการความจุในอนาคต ระบบจะกำหนดเวลาการดำเนินการเพิ่มขนาดล่วงหน้า ก่อนที่โหลดตามการคาดการณ์จะมาถึง โดยทั่วไปล่วงหน้า 5-60 นาที Predictive Scaling เหมาะที่สุดสำหรับเวิร์กโหลดที่มีรอบการใช้งานรายวันหรือรายสัปดาห์ซ้ำกัน ระบบจะอัปเดตการคาดการณ์อย่างต่อเนื่องเมื่อรวบรวมข้อมูลได้มากขึ้น

คุณเปิดใช้ Predictive Scaling ได้โดยแนบนโยบาย PredictiveScaling เข้ากับ ASG คุณต้องระบุคู่เมตริก ได้แก่ เมตริกโหลด (สิ่งที่ขับเคลื่อนการปรับขนาด เช่น CPU หรือจำนวนคำขอของ ALB) และ เมตริกการปรับขนาด (สิ่งที่คุณติดตามในแต่ละอินสแตนซ์ จากนั้น AWS จะคาดการณ์เมตริกโหลดและคำนวณจำนวนอินสแตนซ์ที่จำเป็น เพื่อรักษาเมตริกการปรับขนาดให้อยู่ที่ค่าเป้าหมายของคุณ

Predictive Scaling มีสองโหมด ได้แก่ ForecastOnly ซึ่งสร้างการคาดการณ์โดยไม่เปลี่ยนความจุจริง เหมาะสำหรับตรวจสอบการคาดการณ์ก่อนยืนยันการปรับขนาดอัตโนมัติ และ ForecastAndScale ซึ่งทั้งสร้างการคาดการณ์และใช้การเปลี่ยนแปลงความจุโดยอัตโนมัติ เริ่มด้วย ForecastOnly สักสองสามสัปดาห์เพื่อตรวจสอบความแม่นยำ จากนั้นจึงเปลี่ยนเป็น ForecastAndScale AWS ต้องมีข้อมูลเมตริกอย่างน้อย 24 ชั่วโมงก่อนสร้างการคาดการณ์ครั้งแรก

Predictive Scaling จะดำเนินการเพิ่มขนาดล่วงหน้า แต่คุณสามารถกำหนดค่า SchedulingBufferTime เพื่อเตรียมอินสแตนซ์ให้พร้อมเร็วกว่านั้นได้ หาก SchedulingBufferTime เท่ากับ 5 นาที ระบบจะเพิ่มความจุก่อนเวลาที่การคาดการณ์ระบุว่าจำเป็น 5 นาที นอกจากนี้ คุณยังสามารถกำหนด MaxCapacityBuffer เพื่ออนุญาตให้ ASG ปรับขนาดเกินความต้องการที่คาดการณ์ไว้ตามเปอร์เซ็นต์ที่กำหนด ซึ่งจะเป็นพื้นที่สำรองเพื่อรองรับความคลาดเคลื่อนของการคาดการณ์

รูปแบบที่แนะนำสำหรับเวิร์กโหลดที่ผันผวนแต่คาดการณ์ได้ คือการใช้ทั้งสองอย่างร่วมกัน ได้แก่ Predictive Scaling จัดการโหลดตามรอบที่คาดการณ์ไว้ด้วยการเตรียมความจุให้พร้อมล่วงหน้า ขณะที่ Target Tracking Scaling จัดการการเพิ่มขึ้นอย่างฉับพลันที่ไม่คาดคิดและเกินกว่าการคาดการณ์ ทั้งสองอย่างร่วมกันจึงให้การรองรับทั้งเชิงรุกและเชิงตอบสนอง ASG จะใช้คำแนะนำการเพิ่มขนาดที่ระมัดระวังที่สุดจากทั้งสองนโยบายอย่างปลอดภัย

ใช้ Scheduled Scaling เมื่อการเพิ่มขึ้นของปริมาณการใช้งานคาดการณ์ได้อย่างสมบูรณ์และคุณทราบเวลาที่แน่นอน (รูปแบบตามเหตุการณ์หรือตามเวลาทำการ) ใช้ Predictive Scaling เมื่อรูปแบบเกิดซ้ำแต่เวลาที่แน่นอนอาจเปลี่ยนแปลงได้ โดยการเรียนรู้ของเครื่องจะเรียนรู้รูปแบบโดยอัตโนมัติ ใช้ Target Tracking เป็นกลไกสำรองแบบไดนามิกที่ทำงานตลอดเวลาสำหรับโหลดที่ไม่คาดคิด หากโหลดเกิดขึ้นแบบสุ่มโดยสิ้นเชิง ให้ใช้การติดตามเป้าหมายหรือการปรับขนาดแบบขั้นเพียงอย่างเดียว ในการสอบ SAA-C03 มักถามให้เลือกแนวทางที่มีประสิทธิภาพด้านการปฏิบัติงานมากที่สุด และ Predictive Scaling เป็นตัวเลือกที่ดีที่สุดสำหรับเวิร์กโหลดที่มีรอบซ้ำ

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Scheduled Scaling ใช้นิพจน์ cron เพื่อเปลี่ยนความจุของ ASG ตามเวลาที่ทราบ เหมาะสำหรับเหตุการณ์ที่คาดการณ์ได้หรือรูปแบบตามเวลาทำการที่เกิดซ้ำ Predictive Scaling ใช้การเรียนรู้ของเครื่องกับข้อมูล CloudWatch ในอดีตเพื่อเพิ่มขนาดเชิงรุกก่อนที่โหลดจะมาถึง และการผสาน Predictive + Target Tracking ให้การรองรับทั้งเชิงรุกและเชิงตอบสนอง เพื่อกลยุทธ์การปรับขนาดที่ทนทานที่สุด ต่อไปเราจะศึกษา Instance Refresh และ Lifecycle Hooks สำหรับการนำไปใช้งานที่ควบคุมได้