การพิจารณาขนาด

เมื่อคุณพิจารณาสถาปัตยกรรมของแอพพลิเคชันของคุณ คุณควรถามคำถามต่อไปนี้

คุณกำลังพิจารณาสภาพแวดล้อมใด?

Production การกู้คืนความเสียหายหรือการทดสอบ Environment

แอพพลิเคชันเป็นระบบที่สำคัญหรือไม่?

หากแอพพลิเคชันของคุณเป็นระบบที่สำคัญ เช่น จำเป็นต้องออนไลน์ตลอด 24 ชั่วโมงทุกวัน เช่น การประมวลผลการชำระเงินหรือธุรกรรมที่สำคัญ คุณอาจต้องพิจารณา Active-Active หรือ Cluster Environment เพื่อให้แน่ใจว่าการดำเนินการของคุณสามารถทำงานได้อย่างต่อเนื่อง

ระบบนี้สามารถหยุดทำงานเพื่อการบำรุงรักษาได้หรือไม่? SLA คืออะไร?

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

คุณต้องการการ Disaster Recovery หรือไม่ RPO (Recovery Point Target) และ RTO (Recovery Time Target) ของคุณคืออะไร?

หากคุณต้องการ DR (Disaster Recovery) สำหรับแผนสำรองในกรณีที่คุณไม่สามารถใช้งาน Production Environment ได้ คุณต้องพิจารณา RPO (Recovery Point Objective) และ RTO (Recovery Time Objective) เพื่อเลือกโซลูชันที่เหมาะสมสำหรับ DR ของคุณ

มีผู้ใช้งานกี่คน?

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

สามารถเลือกแยกเซิร์ฟเวอร์ของคุณเป็นสถาปัตยกรรมแบบ Active-Active ด้วยโหลดบาลานเซอร์เพื่อกระจายภาระงานของคุณไปยังเซิร์ฟเวอร์หลายเครื่อง

จำนวนธุรกรรม (ต่อปีหรือต่อเดือน)?

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

จำนวนการทำธุรกรรมในช่วงเวลาสูงสุดหรือเหตุการณ์สูงสุด?

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

ข้อมูลของคุณจะถูกเก็บไว้ในระบบจำนวนเท่าใดและนานเท่าใด (ในแง่ของบันทึกและขนาด)

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