ปรับมาตราส่วนทรัพยากร
- 11 นาที
ข้อดีประการหนึ่งที่สําคัญของระบบคลาวด์คือความสามารถในการปรับขนาดทรัพยากรลงในระบบตามความต้องการ การปรับขนาด (จัดเตรียมทรัพยากรขนาดใหญ่) หรือปรับมาตราส่วนออก (จัดเตรียมทรัพยากรเพิ่มเติม) สามารถช่วยในการลดภาระทรัพยากรเดียวโดยการลดการใช้งานเนื่องจากความจุที่เพิ่มขึ้นหรือการกระจายปริมาณงานที่กว้างขึ้น
การปรับมาตราส่วนสามารถช่วยในการปรับปรุงประสิทธิภาพโดยการเพิ่มปริมาณงานเนื่องจากขณะนี้สามารถให้บริการคําขอจํานวนมากได้ นอกจากนี้ยังสามารถช่วยในการลดเวลาแฝงในระหว่างการโหลดสูงสุดเนื่องจากจํานวนคําขอที่ลดลงจะถูกจัดคิวในระหว่างการโหลดสูงสุดบนทรัพยากรเดียว นอกจากนี้ยังสามารถช่วยในการปรับปรุงความน่าเชื่อถือของระบบโดยการลดการใช้ทรัพยากรเพื่อให้ห่างจากจุดแตกแยกของทรัพยากร
สิ่งสําคัญคือต้องทราบว่าแม้ว่าระบบคลาวด์ช่วยให้เราสามารถเตรียมใช้งานทรัพยากรที่ใหม่กว่าหรือดีกว่าได้อย่างง่ายดาย แต่ค่าใช้จ่ายก็เป็นปัจจัยตรงกันข้ามที่จําเป็นต้องพิจารณาเสมอ ดังนั้น แม้ว่าจะเป็นประโยชน์ในการปรับเพิ่ม/ออก แต่ก็เป็นสิ่งสําคัญที่ต้องรับรู้เมื่อต้องลดขนาด/เพื่อประหยัดค่าใช้จ่าย ในแอปพลิเคชันแบบ n-tier มันเป็นสิ่งสําคัญที่จะระบุตําแหน่งที่คอขวดอยู่และระดับใดที่จะปรับขนาดไม่ว่าจะเป็นระดับข้อมูลหรือระดับเซิร์ฟเวอร์
การปรับมาตราส่วนทรัพยากรได้รับการอํานวยความสะดวกโดยการปรับสมดุลโหลด (เรากล่าวถึงก่อนหน้านี้) ซึ่งช่วยในการมาสก์มุมมองการปรับมาตราส่วนของระบบโดยการซ่อนหลังจุดสิ้นสุดที่สอดคล้องกัน
กลยุทธ์การปรับมาตราส่วน
การปรับมาตราส่วนแนวนอน (ปรับมาตราส่วนออกและใน)
การปรับมาตราส่วนแนวนอนเป็นกลยุทธ์ที่สามารถเพิ่มทรัพยากรเพิ่มเติมในระบบหรือทรัพยากรที่ไม่เกี่ยวข้องสามารถลบออกจากระบบได้ มาตราส่วนประเภทนี้จะเป็นประโยชน์สําหรับระดับเซิร์ฟเวอร์เมื่อโหลดในระบบไม่สามารถคาดเดาได้และมีความผันผวนอย่างไม่สอดคล้องกัน ลักษณะของโหลดที่ผันผวนทําให้จําเป็นต้องจัดหาปริมาณทรัพยากรที่ถูกต้องเพื่อจัดการกับโหลดตลอดเวลาได้อย่างมีประสิทธิภาพ
ข้อควรพิจารณาที่ทําให้งานที่ท้าทายนี้คือเวลาในการปั่นปวนของอินสแตนซ์ แบบจําลองการกําหนดราคาของผู้ให้บริการระบบคลาวด์ และโอกาสในการสูญเสียรายได้จากคุณภาพการบริการ (QoS) ที่ลดลงโดยไม่ปรับขนาดในเวลา ตัวอย่างเช่น เรามาพิจารณารูปแบบการโหลดต่อไปนี้:
รูปที่ 6: ตัวอย่างคําขอคําขอรูปแบบการโหลด
ให้เราจินตนาการว่าเรากําลังใช้ Amazon Web Services ให้เราจินตนาการว่าแต่ละหน่วยของเวลาจะเทียบเท่ากับ 3 ชั่วโมงของเวลาจริง และเราต้องการหนึ่งเซิร์ฟเวอร์เพื่อให้บริการคําขอ 5k หากคุณพิจารณาโหลดระหว่างหน่วยเวลา 16 ถึง 22 มีความผันผวนอย่างมากในโหลด เราสามารถตรวจพบความต้องการลดลงในเวลาประมาณ 16 หน่วยและเริ่มลดจํานวนทรัพยากรที่จัดสรร เนื่องจากเรากําลังเดินทางจากคําขอประมาณ 50k จนถึงคําขอเกือบ 0 รายการในพื้นที่ 3 ชั่วโมง ทางวิชาการ เราสามารถประหยัดค่าใช้จ่ายสําหรับอินสแตนซ์ 10 รายการที่จะเพิ่มขึ้นในเวลา 16 อินสแตนซ์
ตอนนี้ให้เราลองจินตนาการแทนว่าแต่ละหน่วยเวลาจะเท่ากับ 20 นาทีของเวลาจริง ในกรณีนี้ การปั่นทรัพยากรทั้งหมดในหน่วยเวลา 16 เพื่อปั่นทรัพยากรใหม่หลังจากผ่านไป 20 นาทีจะเพิ่มค่าใช้จ่ายแทนการประหยัด เนื่องจาก AWS จะคํานวณแต่ละอินสแตนซ์เป็นรายชั่วโมง
นอกเหนือจากข้อควรพิจารณาสองข้อข้างต้นแล้ว ผู้ให้บริการจะต้องประเมินความสูญเสียดังกล่าวโดยการให้ QoS ลดลงในระหว่างหน่วยเวลา 20 ถ้ามีความจุสําหรับคําขอเพียง 90k แทนที่จะเป็นคําขอ 100k
การปรับขนาดขึ้นอยู่กับลักษณะของปริมาณการใช้งานและภาระของการตามมาตราส่วนที่สร้างขึ้นที่บริการเว็บ ถ้าปริมาณการใช้งานเป็นไปตามรูปแบบที่คาดการณ์ได้ (ตัวอย่างเช่น ตามพฤติกรรมของมนุษย์ เช่น การสตรีมภาพยนตร์จากบริการบนเว็บในช่วงเย็น) การปรับขนาดสามารถ คาดการณ์ได้เพื่อรักษา QoS อย่างไรก็ตามในหลาย ๆ กรณี การรับส่งข้อมูลไม่สามารถคาดการณ์ได้และระบบการปรับมาตราส่วนจําเป็นต้อง เปิดใช้งานใหม่ตามเกณฑ์ที่แตกต่างกันตามตัวอย่างที่แสดงข้างต้น
การปรับมาตราส่วนแนวตั้ง (ปรับมาตราส่วนขึ้นและลง)
มีการโหลดบางประเภทสําหรับผู้ให้บริการที่สามารถคาดการณ์ได้มากกว่าชนิดอื่น ตัวอย่างเช่น หากคุณทราบจากรูปแบบในอดีตว่าจํานวนคําขอจะเป็น 10k-15k เสมอ จากนั้นคุณสามารถสันนิษฐานได้อย่างสะดวกสบายว่าเซิร์ฟเวอร์หนึ่งที่สามารถตอบสนองคําขอ 20k จะดีเพียงพอสําหรับวัตถุประสงค์ของผู้ให้บริการ การโหลดเหล่านี้อาจเพิ่มขึ้นในอนาคต แต่ตราบใดที่พวกเขาเพิ่มขึ้นในลักษณะที่สอดคล้องกัน บริการสามารถถูกย้ายไปยังอินสแตนซ์ที่มีขนาดใหญ่กว่าที่สามารถตอบสนองคําขอได้มากขึ้น ซึ่งเหมาะสําหรับการใช้งานขนาดเล็กที่ประสบกับปริมาณการใช้งานต่ํา
ความท้าทายในการปรับมาตราส่วนแนวตั้งคือมักจะมีการเปลี่ยนผ่านไปตามช่วงเวลาที่สามารถพิจารณาได้ว่าเป็นการหยุดทํางาน ทั้งนี้เนื่องจากเพื่อย้ายการดําเนินการทั้งหมดจากอินสแตนซ์ที่มีขนาดเล็กกว่าไปยังอินสแตนซ์ที่ใหญ่กว่า แม้ว่าการเปลี่ยนผ่านเวลาเป็นเพียงนาที เท่านั้น QoS จะลดลงในช่วงเวลานั้น
นอกจากนี้ ผู้ให้บริการระบบคลาวด์ส่วนใหญ่ยังมีทรัพยากรคํานวณในการเพิ่มกําลังการประมวลผลโดยเพิ่มกําลังการคํานวณของทรัพยากรเป็นเท่าๆ ดังนั้นกรานูลาริตี้ในการปรับมาตราส่วนขึ้นไม่สามารถทําได้เหมือนกับการปรับมาตราส่วนในแนวนอน ดังนั้นแม้ว่าโหลดสามารถคาดการณ์ได้และเพิ่มขึ้นอย่างต่อเนื่องเนื่องจากความนิยมของบริการเพิ่มขึ้น ผู้ให้บริการจํานวนมากเลือกที่จะปรับขนาดแนวนอนแทนการปรับมาตราส่วนแนวตั้ง
ข้อควรพิจารณาสําหรับการปรับมาตราส่วน
ตรวจ สอบ
การตรวจสอบเป็นหนึ่งในองค์ประกอบสําคัญที่สุดสําหรับการปรับมาตราส่วนทรัพยากรอย่างมีประสิทธิภาพเนื่องจากช่วยให้คุณสามารถมีเมตริกที่สามารถใช้ในการแปลความหมายชิ้นส่วนของระบบที่จําเป็นต้องปรับขนาดและเมื่อจําเป็นต้องปรับขนาด การตรวจสอบช่วยให้สามารถวิเคราะห์รูปแบบการรับส่งข้อมูลหรือการใช้ทรัพยากรเพื่อทําให้การประเมินมีการศึกษาเกี่ยวกับช่วงเวลาและปริมาณทรัพยากรในการปรับขนาดเพื่อเพิ่ม QoS พร้อมกับกําไร
มีหลายแง่มุมของทรัพยากรที่ได้รับการตรวจสอบเพื่อทริกเกอร์การปรับมาตราส่วนของทรัพยากร เมตริกที่พบบ่อยที่สุดคือ การใช้ทรัพยากร ตัวอย่างเช่น บริการการตรวจสอบสามารถติดตามการใช้งาน CPU ของแต่ละโหนดทรัพยากรและปรับขนาดทรัพยากรหากการใช้งานมากเกินไปหรือต่ําเกินไป ตัวอย่างเช่น ถ้าการใช้งานสําหรับแต่ละทรัพยากรสูงกว่า 95%อาจเป็นความคิดที่ดีที่จะเพิ่มทรัพยากรเพิ่มเติมเนื่องจากระบบทํางานหนัก ผู้ให้บริการมักจะตัดสินใจเลือกจุดทริกเกอร์เหล่านี้โดยการวิเคราะห์จุดแยกของโหนดทรัพยากรโดยพิจารณาว่าพวกเขาจะเริ่มล้มเหลวเมื่อใดและการแมปพฤติกรรมของพวกเขาภายใต้การโหลดในระดับต่างๆ แม้ว่าด้วยเหตุผลด้านค่าใช้จ่ายเป็นสิ่งสําคัญที่จะต้องใช้ประโยชน์จากทรัพยากรแต่ละรายการอย่างมากแนะนําให้ออกจากห้องบางห้องสําหรับระบบปฏิบัติการเพื่ออนุญาตให้มีกิจกรรมค่าใช้จ่าย ในทํานองเดียวกันหากการใช้งานต่ํากว่าที่ระบุ 50%อาจเป็นไปได้ว่าไม่จําเป็นต้องใช้โหนดทรัพยากรทั้งหมดและบางส่วนสามารถยกเลิกการเตรียมใช้งานได้
ในทางปฏิบัติ ผู้ให้บริการมักจะตรวจสอบการรวมกันของเมตริกต่าง ๆ ของโหนดทรัพยากรเพื่อประเมินว่าเมื่อใดที่ควรปรับมาตราส่วนทรัพยากร บางส่วนรวมถึงการใช้งาน CPU, ปริมาณการใช้หน่วยความจํา, ปริมาณงาน และเวลาแฝง Azure ให้บริการ Azure Monitor เป็นบริการเพิ่มเติมที่สามารถตรวจสอบทรัพยากร Azure ใด ๆ และให้เมตริกดังกล่าวได้
สถานะการไร้สถาปนิก
การออกแบบบริการที่ไม่สะดือให้ยืมสถาปัตยกรรมที่ปรับขนาดได้ บริการที่ไม่มีสถานะหลัก ๆ หมายความว่าคําขอของไคลเอ็นต์ประกอบด้วยข้อมูลทั้งหมดที่จําเป็นในการให้บริการตามคําขอโดยเซิร์ฟเวอร์ เซิร์ฟเวอร์ไม่จัดเก็บข้อมูลที่เกี่ยวข้องกับไคลเอนต์ใด ๆ บนอินสแตนซ์ และจัดเก็บข้อมูลที่เกี่ยวข้องกับเซสชันใด ๆ บนอินสแตนซ์ของเซิร์ฟเวอร์
การมีบริการที่ไม่มีสถานะจะช่วยในการเปลี่ยนทรัพยากรตามที่ต้องการ โดยไม่ต้องกําหนดค่าใด ๆ เพื่อรักษาบริบท (สถานะ) ของการเชื่อมต่อไคลเอ็นต์สําหรับคําขอที่ตามมา หากบริการนี้มีความสมบูรณ์ การปรับมาตราส่วนทรัพยากรจําเป็นต้องมีกลยุทธ์ในการถ่ายโอนบริบทจากการกําหนดค่าโหนดที่มีอยู่ไปยังการกําหนดค่าโหนดใหม่ โปรดทราบว่ามีเทคนิคในการใช้งานบริการที่สเตทฟูล ตัวอย่างเช่น การรักษาแคชเครือข่ายด้วย Memcached เพื่อให้สามารถแชร์บริบทข้ามเซิร์ฟเวอร์ได้
ตัดสินใจว่าจะปรับมาตราส่วนอะไร
ขึ้นอยู่กับลักษณะของบริการ, ทรัพยากรที่แตกต่างกันจะต้องมีการปรับขนาดขึ้นอยู่กับความต้องการ. สําหรับระดับเซิร์ฟเวอร์เมื่อปริมาณงานเพิ่มขึ้น โดยขึ้นอยู่กับชนิดของแอปพลิเคชัน อาจเพิ่มการช่วงชิงทรัพยากรสําหรับ CPU หน่วยความจํา แบนด์วิดธ์เครือข่าย หรือทั้งหมดข้างต้น การตรวจสอบการรับส่งข้อมูลช่วยให้เราสามารถระบุทรัพยากรที่ได้รับการจํากัดและปรับขนาดทรัพยากรเฉพาะได้อย่างเหมาะสม ผู้ให้บริการระบบคลาวด์ไม่จําเป็นต้องให้กรานูลาริตี้ของการคํานวณหรือหน่วยความจําเท่านั้น แต่มีอินสแตนซ์การคํานวณชนิดต่าง ๆ ที่รองรับการคํานวณภาระหนักหรือหน่วยความจํามากโดยเฉพาะ ตัวอย่างเช่น สําหรับแอปพลิเคชันที่มีปริมาณงานที่มีหน่วยความจํามาก ขอแนะนําให้ปรับขนาดทรัพยากรไปยังอินสแตนซ์ที่ปรับให้เหมาะสมกับหน่วยความจํา สําหรับแอปพลิเคชันที่จําเป็นต้องให้บริการตามคําขอจํานวนมากที่ไม่จําเป็นต้องคํานวณงานหนักหรือหน่วยความจํามาก และปรับขนาดอินสแตนซ์การคํานวณมาตรฐานหลายอินสแตนซ์อาจเป็นกลยุทธ์ที่ดีกว่า
การเพิ่มทรัพยากรฮาร์ดแวร์อาจไม่เป็นทางออกที่ดีที่สุดเสมอไปสําหรับการเพิ่มประสิทธิภาพของบริการ การเพิ่มประสิทธิภาพของอัลกอริทึมที่ใช้ในบริการยังสามารถช่วยในการลดการคัดเลือกทรัพยากรและปรับปรุงการใช้งาน เพื่อลดความต้องการปรับขนาดทรัพยากรทางกายภาพ
ปรับมาตราส่วนระดับข้อมูล
ในแอปพลิเคชันเชิงข้อมูล ซึ่งมีการอ่านและเขียนจํานวนมาก (หรือทั้งสองอย่าง) ไปยังฐานข้อมูลหรือระบบการจัดเก็บข้อมูล เวลาไปกลับสําหรับแต่ละคําขอมักจะจํากัดโดยเวลาการอ่านและการเขียนของฮาร์ดดิสก์ อินสแตนซ์ที่ใหญ่กว่าช่วยให้ประสิทธิภาพ I/O สูงขึ้นสําหรับการอ่านและเขียนซึ่งสามารถปรับปรุงเวลาในการค้นหาบนฮาร์ดดิสก์ซึ่งจะส่งผลให้มีการปรับปรุงเวลาแฝงของบริการอย่างมาก การมีอินสแตนซ์ข้อมูลหลายรายการในระดับข้อมูลสามารถปรับปรุงความน่าเชื่อถือและความพร้อมใช้งานของแอปพลิเคชันโดยการให้ข้อมูลที่ซ้ําซ้อน การจําลองข้อมูลข้ามหลายอินสแตนซ์มีข้อดีเพิ่มเติมในการลดเวลาแฝงบนเครือข่ายถ้าไคลเอ็นต์ถูกบริการโดยศูนย์ข้อมูลโดยตรงใกล้กับข้อมูลดังกล่าว การแชร์หรือการแบ่งพาร์ติชันของข้อมูลข้ามทรัพยากรหลายรายการเป็นอีกกลยุทธ์การปรับมาตราส่วนข้อมูลแนวนอนซึ่งแทนที่จะจําลองข้อมูลข้ามหลายอินสแตนซ์ ข้อมูลจะถูกแบ่งพาร์ติชันลงในหลายพาร์ติชันและจัดเก็บไว้ในเซิร์ฟเวอร์ข้อมูลหลายตัว
ความท้าทายเพิ่มเติมเมื่อพูดถึงการปรับมาตราส่วนข้อมูลคือการรักษาความสอดคล้องกัน (การดําเนินการอ่านบนแบบจําลองทั้งหมดเหมือนกัน) ความพร้อมใช้งาน (อ่านและเขียนสําเร็จเสมอ) และ การยอมรับพาร์ติชัน (คุณสมบัติที่รับประกันในระบบจะเก็บรักษาไว้เมื่อเกิดความล้มเหลวป้องกันการสื่อสารทั่วโหนด) ซึ่งมักจะเรียกว่าทฤษฎี CAP ซึ่งระบุว่าภายในระบบฐานข้อมูลแบบกระจายเป็นเรื่องยากมากที่จะได้รับคุณสมบัติทั้งสามอย่างสมบูรณ์และดังนั้นระบบจึงอาจมีการผสมผสานของคุณสมบัติสองอย่างมากที่สุด คุณจะได้เรียนรู้เพิ่มเติมเกี่ยวกับกลยุทธ์การปรับมาตราส่วนฐานข้อมูลและทฤษฎี CAP ในมอดูลในภายหลัง