ปัจจุบันลูกค้าที่ใช้ SAP ใน AWS จะใช้ประโยชน์จาก Native cloud Services รวมกับบริการแบบดั้งเดิมเช่น compute, storage, and databases เช่นเดียวกับเทคโนโลยีที่เกิดขึ้นใหม่เช่น IoT

หนึ่งในคุณสมบัติหลักที่ลูกค้าใช้คือการเปลี่ยน Instance Type เช่น การเปลี่ยนแปลง Workloads ที่ลูกค้าพบว่ากรณีของพวกเขาอาจจะ overutilized หรือ underutilized

แนวคิดของการAuto-Scaling คือความสามารถของระบบที่จะรองรับปริมาณงานที่เพิ่มขึ้นเพียงโดยการเพิ่มทรัพยากร

แน่นอน scalability Scale Up สำหรับ SAP เป็นสิ่งสำคัญ แต่หากเป็น Application Layer ล่ะ?เราไม่สามารถสร้างแอพพลิเคชันเซิร์ฟเวอร์เพื่อรองรับปริมาณงานทั้งหมดของเรา แม้ว่าเราจะสามารถทำได้ก็อาจจะไม่เสถียร ดังนั้น SAP ออกแบบแอพพลิเคชันเซิร์ฟเวอร์ในแบบ Scale Out ด้วย นี่คือที่แนวคิดของการปรับอัตโนมัติที่มักใช้กัน

สำหรับการปรับขยายในแบบ Scale out ลูกค้าดำเนินการปรับขนาดและใช้ข้อมูลทางประวัติศาสตร์ในการกำหนดวิธีการหลายแอพพลิเคชันเซิร์ฟเวอร์ที่พวกเขาต้องการที่จะสนับสนุน Workloads ของพวกเขา ทีมักนำไปสู่ทรัพยากร ที่underutilized หรือเช่นการขายการตลาด และการทำ Big Data สำหรับการรายงาน

เมื่อพูดถึงการ scale out ทีม DevOps อาจแนะนำ Amazon EC2 Autoscaling แต่ที่เราทุกคนรู้ว่า SAP บางครั้งอาจ ไม่ง่ายต่อการความยืดหยุ่น

AWS สามารถช่วยให้เราสร้างสะพานเชื่อมต่อระหว่างความยืดหยุ่นของ SAP on-premises และ Cloud-native autoscaling group

ภาพรวมของการแก้ปัญหา

“การautoscaling แบบดั้งเดิมใช้ จำนวน CPU ในการคำนวณ balancer
แต่มันไม่ได้สะท้อนให้เห็นถึงรูปแบบพฤติกรรมบางใน SAP”

ในทุกแอพพลิเคชันเซิร์ฟเวอร์ของ SAP ประกอบด้วยกระบวนการทำงานทของ SAP Kernel สิ่งนี้จะทำให้ SAP นั้นไม่ซ้ำกัน กระบวนการทำงานในแต่ละนั้นทำงานอยู่ในชั้นของระบบปฎิบัติการ OS CPU หน่วยความจำ, เครือข่ายและอื่น ๆ เมื่อเช็คขนาดแอพพลิเคชันเซิร์ฟเวอร์ใน SAP, ความสมดุลและการกระจายของเหล่านี้มีความสำคัญกับระบบ SAP อย่างมาก

สำหรับ microservices และแอปพลิเคชันต่างๆ SAPจะต้องพิจารณากระบวนการทำงานโดยเฉพาะอย่างยิ่งการใช้งานเหลือเท่าไหร่หรือใช้ไปแล้วเท่าไหร่

ดังนั้นวิธีการที่เราจะปรับขนาดอัตโนมัติที่จะต้องพิจารณาการใช้งาน CPU และการใช้งานหรือไม่? นั่นคือสิ่งที่AWS Professional Services SAP Application Auto Scaling นำมาใช้

วิธีการแก้ปัญหานี้จะช่วยให้ผู้ประกอบการและผู้ดูแลระบบ SAP สามารถตรวจสอบปริมาณการใช้ SAP แอพพลิเคชันเซิร์ฟเวอร์โดยอัตโนมัติตามตัวชี้วัดต่างๆเช่น dialog, Batch, enqueue และ Printwork Process การแก้ปัญหานี้สามารถปรับให้เข้ากับ spikes และ dips สำหรับการเข้าสู่ระบบของผู้ใช้พร้อมกันและความหลากหลายของทั้งปริมาณงานที่คาดการณ์และคาดเดาไม่ได้

โซลูชั่นที่ใช้สำหรับ On-demand คลาวด์เซิร์ฟเวอร์แอพลิเคชันที่คุณต้องการ การ Auto-scaling เป็นแบบ Scale out หมือนวิธีการที่คุณปรับรักษาอุณหภูมิของคุณที่บ้าน คุณเลือกอุณหภูมิและทอร์โมสตัทจัดการในส่วนที่เหลือ

แผนภาพต่อไปนี้ แสดงให้เห็นถึงวิธีที่สถาปัตยกรรมนี้กำหนดค่า:

แต่เดี๋ยวก่อน เมื่อเราบอกว่าการ Scale นี้ไม่เพียงแต่ Scale Out แต่ยัง scale In เราจะปิดเซิร์ฟเวอร์แอพลิเคชันที่มีผู้ใช้งานได้หรือไม่ นี่เป็นอีกหนึ่งความท้าทายของ SAP ไม่ใช่ SAP ทุกตัวจะถูกส่งผ่าน load balancer บางส่วนมีการใช้ SAPGUI หรือจากระบบอื่น ๆ เรียกระบบของคุณผ่าน SAP RFC

การจะจัดการกับ SAP native ไม่ว่าจะเป็น Soft Shutdown หรือ Graceful Shutdown AWS lambda สามรถแก้ไขปัญหานี้ได้ เราจะมั่นใจได้ว่า จะไม่มีข้อมูลที่เสียหายใน SAP Instance และลดค่าใช้จ่ายของ TCO อีกด้วย

Soft Shutdown จะรอการทำธุรกรรมเสร็จสมบูรณ์ในการสั่งซื้อที่เฉพาะเจาะจง จากนั้นจะรวมกันด้วยAPI ใน EC2 เพื่อประสานการใช้งานของ EC2 แอพลิเคชันเซิร์ฟเวอร์

โซลูชันของ AWS Professional Services ที่ใช้คอมพิวเตอร์ที่ปราศจากเซิฟเวอร์ของ AWS ตลอดจนพื้นที่จัดเก็บและการวิเคราะห์ จะช่วยให้ลูกค้าเชื่อม on-premises และสถาปัตยกรรม SAP ที่มีความยืดหยุ่น ทำให้สามารถเรียกใช้ SAP ในรูปแบบที่ยืดหยุ่น สามารถปรับขนาดที่เหมาะสม และประหยัดค่าใช้จ่ายมากขึ้น

ข้อสรุป

ด้วย AWS Auto Scaling, คุณจ่ายเฉพาะสิ่งที่คุณต้องการเพื่อช่วยลดค่าใช้จ่ายในการดำเนินงาน เช่นเดียวกับเทอร์โมสตัทที่คุณเลือกตัวชี้วัด คุณตั้งค่าและตัวแก้ปัญหาจัดการให้คุณทั้งหมด