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

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

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

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

ความสามารถในการปรับขนาดของซอฟต์แวร์คืออะไร?

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

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

• ผู้ใช้จำนวนมากที่เข้าใช้งานระบบพร้อมกัน
• ความต้องการด้านความจุในการขยายพื้นที่จัดเก็บ
• จำนวนธุรกรรมที่กำลังดำเนินการเพิ่มขึ้น

ประเภทความสามารถในการปรับขนาดของซอฟต์แวร์

คุณสามารถปรับขนาดแอปพลิเคชันได้ทั้งแนวนอนและแนวตั้ง มาดูกันว่าแต่ละวิธีมีข้อดีข้อเสียอย่างไร

ความสามารถในการปรับขนาดของซอฟต์แวร์ในแนวนอน (การปรับขนาดออก)

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

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

ประโยชน์:

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

ข้อจำกัด:

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

ความสามารถในการปรับขนาดของซอฟต์แวร์ในแนวตั้ง (ขยายขนาดขึ้น)

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

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

ประโยชน์:

• ไม่จำเป็นต้องเปลี่ยนการกำหนดค่าหรือตรรกะของแอปพลิเคชันเพื่อปรับให้เข้ากับโครงสร้างพื้นฐานที่อัปเดต
• ลดค่าใช้จ่าย เนื่องจากค่าใช้จ่ายในการอัพเกรดน้อยกว่าการเพิ่มเครื่องจักรอีกเครื่อง

ข้อจำกัด:

• มีการหยุดทำงานระหว่างกระบวนการอัปเกรด
• เครื่องที่อัพเกรดยังคงมีข้อผิดพลาดเพียงจุดเดียว
• มีขีดจำกัดในการอัปเกรดอุปกรณ์หนึ่งเครื่อง

ความสามารถในการปรับขนาดของซอฟต์แวร์ในแนวตั้งและแนวนอน

ต่อไปนี้เป็นตารางเปรียบเทียบที่ให้ภาพรวมด้านต่างๆ ของซอฟต์แวร์ทั้งสองประเภทที่สามารถขยายขนาดได้

คุณต้องการความสามารถในการขยายขนาดเมื่อใด

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

เมื่อไม่จำเป็นต้องปรับขนาดซอฟต์แวร์:

• หากซอฟต์แวร์เป็นเครื่องพิสูจน์แนวคิด (PoC) หรือต้นแบบ
• เมื่อพัฒนาซอฟต์แวร์ภายในสำหรับบริษัทขนาดเล็กที่ใช้โดยพนักงานเท่านั้น
• แอพมือถือ/เดสก์ท็อปที่ไม่มีส่วนหลัง

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

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

เคล็ดลับในการสร้างซอฟต์แวร์ที่ปรับขนาดได้สูง

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

คุณจะพบเคล็ดลับ 8 ข้อด้านล่างที่จะช่วยให้คุณสร้างซอฟต์แวร์ที่ปรับขนาดได้ง่ายขึ้นในอนาคต ตารางด้านล่างแบ่งเคล็ดลับออกเป็นขั้นตอนการพัฒนาซอฟต์แวร์ต่างๆ

เคล็ดลับ #1: เลือกโฮสต์ในระบบคลาวด์เพื่อความสามารถในการปรับขนาดซอฟต์แวร์ที่ดีขึ้น

คุณมีสองตัวเลือกในการโฮสต์แอปพลิเคชันของคุณ ทั้งในระบบคลาวด์หรือในสถานที่ หรือคุณสามารถใช้วิธีการแบบผสมผสาน

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

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

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

หากคุณทำงานในอุตสาหกรรมการดูแลสุขภาพ คุณสามารถดูบทความของเราเกี่ยวกับการประมวลผลแบบคลาวด์ในภาคการแพทย์

เคล็ดลับ #2: ใช้การโหลดบาลานซ์

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

เมื่อมีการเชื่อมต่อโหนดใหม่ โหนดนั้นจะกลายเป็นส่วนหนึ่งของการตั้งค่าโดยอัตโนมัติและจะเริ่มรับคำขอด้วย

เคล็ดลับ #3: แคชให้มากที่สุด

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

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

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

เคล็ดลับ #4: เปิดใช้งานการเข้าถึงผ่าน API

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

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

เคล็ดลับ #5: ได้รับประโยชน์จากการประมวลผลแบบอะซิงโครนัส

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

การประมวลผลแบบอะซิงโครนัสยังเกี่ยวกับการกระจายกระบวนการออกเป็นขั้นตอนเมื่อไม่จำเป็นต้องรอให้ขั้นตอนหนึ่งเสร็จสิ้นก่อนที่จะเริ่มขั้นตอนถัดไปหากสิ่งนี้ไม่สำคัญสำหรับระบบ การตั้งค่านี้ช่วยให้สามารถกระจายกระบวนการหนึ่งไปยังหลาย ๆ เธรดการดำเนินการ ซึ่งยังอำนวยความสะดวกในการปรับขยาย

การประมวลผลแบบอะซิงโครนัสทำได้ที่ระดับโค้ดและโครงสร้างพื้นฐาน ในขณะที่การจัดการคำขอแบบอะซิงโครนัสคือระดับโค้ด

เคล็ดลับ #6: เลือกใช้ประเภทฐานข้อมูลที่ปรับขนาดได้ง่ายกว่า เมื่อเป็นไปได้

ฐานข้อมูลบางฐานข้อมูลปรับขนาดได้ง่ายกว่าฐานข้อมูลอื่นๆ ตัวอย่างเช่น ฐานข้อมูล NoSQL เช่น MongoDB สามารถปรับขนาดได้มากกว่า SQL MongoDB ดังกล่าวเป็นโอเพ่นซอร์ส และโดยทั่วไปจะใช้สำหรับการวิเคราะห์ข้อมูลขนาดใหญ่แบบเรียลไทม์ ตัวเลือก NoSQL อื่นๆ ได้แก่ Amazon DynamoDB และ Google Bigtable

SQL ทำงานได้ดีเมื่อต้องปรับขนาดการดำเนินการอ่าน แต่หยุดการดำเนินการเขียนเนื่องจากสอดคล้องกับหลักการของกรด (ความเป็นอะตอม ความสม่ำเสมอ การแยก และความทนทาน) ดังนั้น หากหลักการเหล่านี้ไม่ใช่ประเด็นหลัก คุณก็เลือกใช้ NoSQL เพื่อการปรับขนาดที่ง่ายขึ้นได้ หากคุณต้องการพึ่งพาฐานข้อมูลเชิงสัมพันธ์ เพื่อความสอดคล้องกันหรือเรื่องอื่นๆ คุณยังคงสามารถปรับขนาดได้โดยใช้การแบ่งกลุ่มและเทคนิคอื่นๆ

เคล็ดลับ #7: เลือก microservices มากกว่าสถาปัตยกรรม monolith หากมี

สถาปัตยกรรมเสาหิน

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

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

สถาปัตยกรรมไมโครเซอร์วิส

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

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

เคล็ดลับ #8: ตรวจสอบประสิทธิภาพเพื่อกำหนดว่าจะปรับขนาดเมื่อใด

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

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

• เวลาตอบสนองเฉลี่ย
• ทรูพุต ซึ่งเป็นจำนวนคำขอที่ประมวลผลในเวลาที่กำหนด
• จำนวนผู้ใช้พร้อมกัน
• เมตริกประสิทธิภาพของฐานข้อมูล เช่น เวลาตอบสนองของแบบสอบถาม
• การใช้ทรัพยากร เช่น CPU, การใช้หน่วยความจำ, GPU
• อัตราความผิดพลาด
• ค่าใช้จ่ายต่อผู้ใช้

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

ตัวอย่างโซลูชันซอฟต์แวร์ที่ปรับขนาดได้จากพอร์ตโฟลิโอ ITRex

กระจกฟิตเนสอัจฉริยะพร้อมโค้ชส่วนตัว

คำอธิบายโครงการ

ลูกค้าต้องการสร้างกระจกฟิตเนสแบบยาวเต็มผนังที่จะช่วยให้ผู้ใช้ออกกำลังกายเป็นประจำ สามารถตรวจสอบฟอร์มของผู้ใช้ระหว่างออกกำลังกาย นับจำนวนครั้ง และอื่นๆ ระบบนี้ควรมีซอฟต์แวร์ที่ช่วยให้ผู้ฝึกสอนสร้างและอัปโหลดวิดีโอ และผู้ใช้สามารถบันทึกและจัดการการออกกำลังกายของตนได้

สิ่งที่เราทำเพื่อให้แน่ใจว่าซอฟต์แวร์สามารถปรับขนาดได้

• เราเลือกใช้สถาปัตยกรรมไมโครเซอร์วิส
• ใช้ความสามารถในการปรับขนาดแนวนอนสำหรับการกระจายโหลด โหนดใหม่ถูกเพิ่มเมื่อใดก็ตามที่โหลดมากเกินไปในโหนดที่มีอยู่ ดังนั้น เมื่อใดก็ตามที่การใช้งาน CPU เกิน 90% ของความจุและอยู่ที่นั่นตามระยะเวลาที่กำหนด โหนดใหม่จะถูกเพิ่มเพื่อแบ่งเบาภาระ
• เราต้องปรับใช้ฐานข้อมูลเชิงสัมพันธ์ เช่น SQL และ PostgreSQL ด้วยเหตุผลทางสถาปัตยกรรม แม้ว่าฐานข้อมูลเชิงสัมพันธ์จะปรับขนาดได้ยาก แต่ก็ยังมีหลายตัวเลือก ในตอนแรก เนื่องจากฐานผู้ใช้ยังค่อนข้างเล็ก เราจึงเลือกใช้การปรับขนาดแนวตั้ง หากผู้ชมมีขนาดใหญ่ขึ้น เรากำลังวางแผนที่จะปรับใช้แนวทางมาสเตอร์-สเลฟ — กระจายข้อมูลไปยังฐานข้อมูลต่างๆ
• ได้รับประโยชน์อย่างมากจากการแคช เนื่องจากระบบนี้มีข้อมูลคงที่จำนวนมาก เช่น ชื่อผู้ฝึกสอน ชื่อการออกกำลังกาย เป็นต้น
• ใช้ RestAPI สำหรับการประมวลผลคำขอแบบอะซิงโครนัสระหว่างแอปออกกำลังกายและเซิร์ฟเวอร์
• อาศัยสถาปัตยกรรมไร้เซิร์ฟเวอร์ เช่น AWS Lambda สำหรับการประมวลผลแบบอะซิงโครนัสประเภทอื่นๆ ตัวอย่างหนึ่งคือการประมวลผลวิดีโอแบบอะซิงโครนัส หลังจากที่เทรนเนอร์โหลดวิดีโอออกกำลังกายใหม่และแบ่งส่วนออกเป็นการออกกำลังกายต่างๆ พวกเขากด "บันทึก" และเซิร์ฟเวอร์จะเริ่มประมวลผลวิดีโอนี้สำหรับการสตรีมแบบสด HTTP เพื่อสร้างวิดีโอต้นฉบับสี่เวอร์ชันที่มีความละเอียดต่างกัน ผู้ฝึกสอนสามารถอัปโหลดวิดีโอใหม่พร้อมกัน
• ในอีกตัวอย่างหนึ่ง ระบบทำการตัดแต่งวิดีโอของผู้ใช้อย่างชาญฉลาดแบบอะซิงโครนัสเพื่อลบส่วนที่ผู้ใช้ไม่ได้ใช้งานออก

ระบบความปลอดภัยทางไซเบอร์ที่ใช้ไบโอเมตริกซ์

คำอธิบายโครงการ

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

วิธีที่เรามั่นใจว่าซอฟต์แวร์นี้สามารถปรับขนาดได้

• เราใช้สถาปัตยกรรมไมโครเซอร์วิสแบบกระจายอำนาจ
• ปรับใช้โหลดบาลานเซอร์สามตัวเพื่อกระจายโหลดระหว่างไมโครเซอร์วิสต่างๆ
• บางส่วนของแพลตฟอร์มนี้สามารถปรับขนาดได้โดยอัตโนมัติตามการออกแบบ หากโหลดเกินเกณฑ์ที่กำหนด อินสแตนซ์ใหม่ของไมโครเซอร์วิสจะถูกสร้างขึ้นโดยอัตโนมัติ
• เราใช้ฐานข้อมูลที่แตกต่างกันหกฐานข้อมูล — PostgreSQL สี่รายการและ MongoDB สองรายการ ฐานข้อมูล PostgreSQL ถูกปรับขนาดในแนวตั้งเมื่อจำเป็น ในขณะที่ออกแบบสถาปัตยกรรม เราตระหนักว่าฐานข้อมูลบางส่วนจะต้องมีการปรับขนาดค่อนข้างบ่อย ดังนั้นเราจึงนำ MongoDB มาใช้เพื่อจุดประสงค์นั้น เนื่องจากง่ายต่อการปรับขนาดในแนวนอน
• ใช้การประมวลผลแบบอะซิงโครนัสเพื่อประสบการณ์ผู้ใช้ที่ดีขึ้น ตัวอย่างเช่น การประมวลผลภายหลังวิดีโอทำแบบอะซิงโครนัส
• เราเลือกใช้อัลกอริธึมการจดจำใบหน้าของผู้ให้บริการบุคคลที่สาม ดังนั้นเราจึงเลือกโซลูชันที่สามารถปรับขนาดได้อยู่แล้วและรวมเข้ากับแพลตฟอร์มของเราผ่าน API

ความท้าทายที่คุณอาจพบขณะปรับขนาด

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

• หนี้ทางเทคนิคสะสม ผู้มีส่วนได้ส่วนเสียในโครงการอาจยังคงพยายามกีดกันความสามารถในการปรับขนาดโดยให้ความสำคัญกับต้นทุน ความเร็ว และอื่นๆ ที่ต่ำกว่า ความสามารถในการปรับขนาดไม่ใช่ข้อกำหนดด้านการทำงานและสามารถถูกบดบังด้วยคุณลักษณะที่จับต้องได้มากกว่า ผลที่ตามมาคือ แอปพลิเคชันจะสะสมคุณสมบัติทางเทคนิคที่เข้ากันไม่ได้กับความสามารถในการขยายขนาด
• ปรับขนาดด้วยวิธีการพัฒนา Agile วิธีการแบบอไจล์นั้นเกี่ยวกับการเปิดรับการเปลี่ยนแปลง อย่างไรก็ตาม เมื่อลูกค้าต้องการใช้การเปลี่ยนแปลงมากเกินไป บ่อยครั้งเกินไป ความสามารถในการปรับขยายซอฟต์แวร์สามารถถูกกันไว้เพื่อรองรับความต้องการที่เปลี่ยนแปลง
• การทดสอบความสามารถในการปรับขนาด เป็นการยากที่จะทำการทดสอบโหลดจริง สมมติว่าคุณต้องการทดสอบว่าระบบจะทำงานอย่างไรหากคุณเพิ่มขนาดฐานข้อมูล 10 ครั้ง คุณจะต้องสร้างข้อมูลที่เหมือนจริงจำนวนมาก ซึ่งตรงกับลักษณะข้อมูลดั้งเดิมของคุณ แล้วจึงสร้างปริมาณงานที่เหมือนจริงสำหรับทั้งการเขียนและการอ่าน
• ความสามารถในการปรับขนาดของบริการของบุคคลที่สาม ตรวจสอบให้แน่ใจว่าผู้ให้บริการบุคคลที่สามของคุณไม่จำกัดความสามารถในการปรับขนาด เมื่อเลือกผู้จำหน่ายเทคโนโลยี ให้ตรวจสอบว่าพวกเขาสามารถรองรับความสามารถในการขยายขนาดซอฟต์แวร์ในระดับที่ตั้งใจไว้ และผสานรวมโซลูชันได้อย่างถูกต้อง
• ทำความเข้าใจการใช้งานแอปพลิเคชันของคุณ คุณต้องมีมุมมองที่ชัดเจนว่าซอฟต์แวร์ของคุณจะทำงานอย่างไร และจำนวนคนที่จะใช้ซอฟต์แวร์นั้น ซึ่งแทบจะเป็นไปไม่ได้เลยที่จะประเมินได้อย่างแม่นยำ
• ข้อจำกัดทางสถาปัตยกรรม บางครั้งคุณมีตัวเลือกทางสถาปัตยกรรมที่จำกัด ตัวอย่างเช่น คุณอาจต้องใช้ฐานข้อมูลเชิงสัมพันธ์และจะต้องจัดการกับการปรับขนาดทั้งในแนวนอนและแนวตั้ง
• มีพรสวรรค์ที่เหมาะสม ในการออกแบบโซลูชันที่ปรับขนาดได้ซึ่งจะไม่ทำให้คุณปวดหัวในอนาคต คุณต้องมีสถาปนิกที่มีประสบการณ์ซึ่งเคยทำงานในโครงการที่คล้ายกันมาก่อน และผู้ที่เข้าใจความสามารถในการปรับขนาดของซอฟต์แวร์จากทั้งมุมมองด้านการเข้ารหัสและโครงสร้างพื้นฐาน ที่ ITRex Group เราได้ทำงานในโครงการต่างๆ มากมายและคำนึงถึงความสามารถในการปรับขนาดเสมอในระหว่างการพัฒนาซอฟต์แวร์

เพื่อสรุป

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

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

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

เผยแพร่ครั้งแรกที่ https://itrexgroup.com เมื่อวันที่ 24 กรกฎาคม 2023