ประหยัดค่าใช้จ่าย EC2 ให้ได้ผลจริง ด้วย AWS Compute Optimizer

หนึ่งในวิธีที่ทำให้การลงทุนใช้ Amazon EC2 คุ้มค่าที่สุด คือการ "จัดขนาดให้พอดี" หรือที่เรียกกันว่า right-sizing นั่นคือการเลือกประเภทและขนาดของอินสแตนซ์ให้ตรงกับปริมาณงานจริง ไม่มากไม่น้อยเกินไป แต่ปัญหาคือถ้าองค์กรมีอินสแตนซ์เป็นร้อยเป็นพันตัว การไล่เช็คทีละตัวด้วยมือนั้นทั้งเสียเวลาและเสี่ยงต่อความผิดพลาดสูงมาก

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

ปัญหาที่องค์กรส่วนใหญ่เจอ

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

Compute Optimizer จะวิเคราะห์ข้อมูลการใช้งานย้อนหลังจาก Amazon CloudWatch ได้ยาวนานถึง 93 วัน แล้วจัดกลุ่มคำแนะนำตามโอกาสในการประหยัดและความเสี่ยงด้านประสิทธิภาพ เพื่อให้ตอบคำถามเหล่านี้ได้ง่ายขึ้น

Compute Optimizer วิเคราะห์อะไรบ้าง

เครื่องมือนี้จะดูตัวชี้วัดหลายด้านจาก CloudWatch แบบอัปเดตทุกวัน ได้แก่ การใช้งาน CPU, การใช้งานหน่วยความจำ (ถ้าเปิดใช้งานไว้), ปริมาณการรับส่งข้อมูลผ่านเครือข่าย, การอ่านเขียนดิสก์ รวมถึง throughput และ IOPS ของ EBS และการใช้งาน GPU สำหรับอินสแตนซ์ที่มีการ์ดจอ

จากข้อมูลเหล่านี้ ระบบจะจัดประเภทอินสแตนซ์แต่ละตัวออกเป็น 4 กลุ่มคือ Over-provisioned (ทรัพยากรเกินความต้องการ มีโอกาสลดขนาดได้), Under-provisioned (ทรัพยากรไม่พอ เสี่ยงเรื่องประสิทธิภาพ), Optimized (ขนาดเหมาะสมดีแล้ว) และ Idle (แทบไม่ได้ใช้งานเลย ควรพิจารณาปิดหรือรวมเข้ากับตัวอื่น) สำหรับแต่ละอินสแตนซ์ ระบบจะเสนอคำแนะนำสูงสุด 3 ตัวเลือก เรียงตามมูลค่าที่ประหยัดได้ ความเสี่ยงด้านประสิทธิภาพ และความยากง่ายในการย้าย

นอกจาก EC2 แล้ว Compute Optimizer ยังให้คำแนะนำกับ Auto Scaling groups, EBS volumes, Lambda, ECS บน Fargate, ซอฟต์แวร์เชิงพาณิชย์บางประเภท และฐานข้อมูล Aurora/RDS ด้วยเช่นกัน

แนวทางปฏิบัติที่ควรทำ

1. เปิดใช้ Cost Optimization Hub เพื่อดูตัวเลขประหยัดที่แม่นยำ หากองค์กรมีส่วนลดจากการซื้อ Savings Plans หรือ Reserved Instances อยู่แล้ว การเปิดใช้ Cost Optimization Hub จะทำให้ Compute Optimizer คำนวณตัวเลขประหยัดโดยอ้างอิงจากส่วนลดจริงที่มี ไม่ใช่ราคาแบบ On-Demand เฉยๆ ซึ่งอาจสูงเกินจริงไปมากสำหรับองค์กรที่มีสัญญาระยะยาวเยอะ

2. เปิดเก็บข้อมูลหน่วยความจำเพิ่มเติม ตามปกติ CloudWatch จะไม่เก็บข้อมูลการใช้หน่วยความจำให้อัตโนมัติ การติดตั้ง CloudWatch Agent หรือเชื่อมต่อกับเครื่องมือ observability ภายนอกอย่าง Datadog, Dynatrace, Instana หรือ New Relก จะช่วยให้ Compute Optimizer เห็นภาพครบทั้ง CPU เครือข่าย ดิสก์ และหน่วยความจำ ซึ่งสำคัญมากสำหรับงานที่กินแรมเยอะ เช่น ฐานข้อมูลหรือแอปพลิเคชันแบบ JVM

3. ปรับแต่งค่ากลยุทธ์การจัดขนาดให้ตรงกับความเสี่ยงที่ยอมรับได้ ค่าเริ่มต้นของระบบ เช่น เกณฑ์การใช้ CPU ที่ P99.5 และการเผื่อพื้นที่เพิ่มอีก 20% เหมาะกับงานทั่วไป แต่หากเป็นสภาพแวดล้อม dev/test ที่ยอมรับการเกิด spike บ้างได้ ก็สามารถลดเกณฑ์ลงมาที่ P90 เพื่อให้ได้คำแนะนำที่ประหยัดกว่าเดิม ส่วนช่วงเวลาย้อนหลังที่ใช้วิเคราะห์ก็ปรับได้ตั้งแต่ 14 วันไปจนถึง 93 วัน เพื่อจับรูปแบบการใช้งานตามฤดูกาลหรือรายไตรมาส ค่าพวกนี้สามารถตั้งได้ทั้งระดับองค์กร ระดับบัญชี หรือระดับภูมิภาค

4. พิจารณาคำแนะนำเรื่อง Graviton อย่างรอบคอบ Compute Optimizer อาจแนะนำให้ย้ายจากอินสแตนซ์ตระกูล x86 ไปเป็น AWS Graviton (สถาปัตยกรรม ARM64) ซึ่งให้ประสิทธิภาพต่อราคาดีขึ้นได้มาก แต่การย้ายแบบนี้ต่างจากการปรับขนาดปกติ เพราะเป็นการเปลี่ยนสถาปัตยกรรม CPU จึงควรตรวจสอบก่อนว่าซอฟต์แวร์และไลบรารีที่ใช้รองรับ ARM64 หรือไม่ ทดสอบใน staging ก่อน แล้วค่อยทำ load test เพื่อยืนยันว่าประสิทธิภาพไม่ตกลง งานที่เหมาะกับ Graviton มักเป็นระบบที่รันบน Linux และมีซอร์สโค้ดที่ควบคุมเองได้ ส่วนแอปเก่าที่คอมไพล์เฉพาะ x86 หรือมีสัญญาซอฟต์แวร์ผูกกับสถาปัตยกรรมเดิม ควรชะลอการย้ายไว้ก่อน

5. สร้างขั้นตอนการทำงานที่เป็นระบบ ควรกำหนดรอบการทบทวนคำแนะนำอย่างสม่ำเสมอ เช่น ทุกสัปดาห์หรือทุกสองสัปดาห์ โดยให้ความสำคัญกับอินสแตนซ์ที่ประหยัดได้เยอะและมีความเสี่ยงต่ำก่อน จากนั้นควรตรวจสอบกับเจ้าของระบบก่อนดำเนินการจริง เพราะบางครั้งตัวเลขการใช้งานเพียงอย่างเดียวอาจไม่สะท้อนบริบท เช่น งานที่มีการใช้งานเฉพาะช่วงเทศกาลหรือ batch job ที่รันเป็นรอบ นอกจากนี้การติด tag ให้อินสแตนซ์อย่างสม่ำเสมอ เช่น Environment, Application และ Owner จะช่วยให้จัดลำดับความสำคัญและส่งคำแนะนำถึงทีมที่รับผิดชอบได้ตรงจุดมากขึ้น สำหรับองค์กรที่พร้อมไปอีกขั้น AWS ยังมีแนวทางการทำงานอัตโนมัติผ่าน Step Functions, EventBridge และ Lambda เพื่อให้กระบวนการปรับขนาดเกิดขึ้นต่อเนื่องโดยไม่ต้องรอทีมงานมานั่งรีวิวทุกครั้ง

สรุป

AWS Compute Optimizer ช่วยให้การตัดสินใจปรับขนาด EC2 อ้างอิงจากข้อมูลจริงแทนการเดา การเปิดใช้ Cost Optimization Hub เพื่อดูตัวเลขประหยัดที่แม่นยำ การเก็บข้อมูลหน่วยความจำเพิ่มเติม การปรับค่ากลยุทธ์ให้เหมาะกับความเสี่ยงที่ยอมรับได้ การประเมิน Graviton อย่างรอบคอบ และการวางขั้นตอนทบทวนอย่างเป็นระบบ ทั้งหมดนี้จะช่วยให้องค์กรลดค่าใช้จ่ายด้าน EC2 ได้จริง โดยไม่กระทบต่อประสิทธิภาพของระบบที่ใช้งานอยู่