การปรับสมดุลโหลด
- 15 นาที
ความจําเป็นสําหรับการปรับสมดุลโหลดในลําต้นคํานวณจากข้อกําหนดพื้นฐานสองประการ: อันดับแรก ความพร้อมใช้งานสูงสามารถปรับปรุงได้โดยการจําลองแบบ ประการที่สอง สามารถปรับปรุงประสิทธิภาพการทํางานได้ผ่านการประมวลผลแบบขนาน ความพร้อมใช้งานสูงคือคุณสมบัติของบริการที่พร้อมใช้งานเกือบ 100% เมื่อไคลเอ็นต์ใด ๆ พยายามเข้าถึงบริการ คุณภาพของบริการ (QoS) สําหรับบริการเฉพาะโดยทั่วไปแล้วมีข้อควรพิจารณาหลายข้อ เช่น ข้อกําหนดอัตราความเร็วและเวลาแฝง
การปรับสมดุลโหลดคืออะไร
รูปแบบที่รู้จักกันดีที่สุดของการปรับสมดุลการโหลดคือ "ROUND robin DNS" ซึ่งจ้างโดยบริการเว็บขนาดใหญ่จํานวนมากเพื่อโหลดบาลานซ์คําขอสมดุลในจํานวนเซิร์ฟเวอร์ โดยเฉพาะเว็บเซิร์ฟเวอร์ front-end หลายตัว ซึ่งแต่ละรายการมีที่อยู่ IP ที่ไม่ซ้ํากัน แชร์ชื่อ DNS เพื่อรักษาสมดุลจํานวนของคําขอบนแต่ละเซิร์ฟเวอร์เว็บเหล่านี้ บริษัทขนาดใหญ่เช่น Google บํารุงรักษาและจัดการกลุ่มที่อยู่ IP ที่เชื่อมโยงกับรายการ DNS เดียว เมื่อไคลเอ็นต์ร้องขอ (ตัวอย่างเช่น ไปยังโดเมน www.google.com) DNS ของ Google จะเลือกหนึ่งในที่อยู่ที่พร้อมใช้งานจากกลุ่มและส่งไปยังไคลเอ็นต์ กลยุทธ์ที่ง่ายที่สุดที่ใช้เพื่อส่งที่อยู่ IP คือการใช้คิวแบบกลมแบบกลมอย่างง่ายซึ่งหลังจากการตอบสนอง DNS แต่ละครั้งจะมีการแบ่งรายการของที่อยู่
ก่อนการถือกําเนิดของคลาวด์ การปรับสมดุลการโหลด DNS เป็นวิธีง่าย ๆ ในการจัดการเวลาแฝงของการเชื่อมต่อทางไกล ตัวจัดส่งที่เซิร์ฟเวอร์ DNS ถูกโปรแกรมให้ตอบสนองกับที่อยู่ IP ของเซิร์ฟเวอร์ที่ใกล้กับไคลเอ็นต์มากที่สุดทางภูมิศาสตร์ แผนการที่ง่ายที่สุดในการทําเช่นนี้พยายามตอบสนองต่อที่อยู่ IP จากพูลซึ่งเป็นตัวเลขที่ใกล้กับที่อยู่ IP ของไคลเอ็นต์มากที่สุด แน่นอนว่าวิธีนี้ไม่น่าเชื่อถือเนื่องจากที่อยู่ IP จะไม่ถูกแจกจ่ายในลําดับชั้นส่วนกลาง เทคนิคปัจจุบันมีความซับซ้อนมากขึ้นและพึ่งพาการแมปซอฟต์แวร์ของที่อยู่ IP ไปยังสถานที่ตามแผนที่จริงของผู้ให้บริการอินเทอร์เน็ต (ISP) เนื่องจากนี่ถูกนํามาใช้เป็นการค้นหาซอฟต์แวร์ที่มีค่าใช้จ่ายวิธีการนี้ให้ผลลัพธ์ที่ถูกต้องมากขึ้น แต่มีราคาแพงในการคํานวณ อย่างไรก็ตาม ค่าใช้จ่ายของการค้นหาที่ช้าเกิดขึ้นเนื่องจากการค้นหา DNS เกิดขึ้นเฉพาะเมื่อไคลเอ็นต์ทําการเชื่อมต่อครั้งแรกไปยังเซิร์ฟเวอร์เท่านั้น การสื่อสารที่ตามมาทั้งหมดเกิดขึ้นโดยตรงระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ที่เป็นเจ้าของที่อยู่ IP ที่ส่งไป ตัวอย่างของแบบแผนการปรับสมดุลการโหลด DNS จะแสดงในรูปต่อไปนี้
รูปที่ 4: การปรับสมดุลโหลดในสภาพแวดล้อมการโฮสต์บนคลาวด์
ข้อเสียของวิธีนี้คือในกรณีที่เซิร์ฟเวอร์ล้มเหลว สวิตช์โอเวอร์ไปยังที่อยู่ IP อื่นจะขึ้นอยู่กับการกําหนดค่าของเวลาในการถ่ายทอดสด (TTL) ของแคช DNS รายการ DNS เป็นที่ทราบว่ามีความยาวและการอัปเดตจะใช้เวลาในการเผยแพร่ผ่านอินเทอร์เน็ตเป็นเวลาหนึ่งสัปดาห์ ดังนั้น จึงเป็นการยากที่จะ "ซ่อน" ความล้มเหลวของเซิร์ฟเวอร์จากไคลเอ็นต์อย่างรวดเร็ว สิ่งนี้สามารถปรับปรุงได้โดยการลดความถูกต้อง (TTL) ของที่อยู่ IP ในแคช แต่สิ่งนี้เกิดขึ้นที่ต้นทุนของประสิทธิภาพการทํางานและเพิ่มจํานวนการค้นหา
การปรับสมดุลการโหลดที่ทันสมัยมักจะหมายถึงการใช้อินสแตนซ์เฉพาะ (หรืออินสแตนซ์คู่) ที่จะนําปริมาณการใช้งานขาเข้าไปยังเซิร์ฟเวอร์ Back-end สําหรับคําขอขาเข้าแต่ละตัวบนพอร์ตที่ระบุ ตัวปรับสมดุลการโหลดจะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังหนึ่งในเซิร์ฟเวอร์ back-end ตามกลยุทธ์การกระจาย ในการทําเช่นนั้น ตัวปรับสมดุลการโหลดจะรักษาเมตาดาต้าคําขอ รวมถึงข้อมูลเช่น ส่วนหัวของโพรโทคอลแอปพลิเคชัน (เช่น ส่วนหัว HTTP) ในสถานการณ์นี้ ไม่มีปัญหาของข้อมูลเก่าเนื่องจากคําขอทั้งหมดผ่านตัวปรับสมดุลการโหลด
แม้ว่าตัวปรับสมดุลการโหลดเครือข่ายทุกประเภทจะส่งต่อข้อมูลของผู้ใช้พร้อมกับบริบทใด ๆ ไปยังเซิร์ฟเวอร์ back-end เมื่อพูดถึงการให้บริการการตอบสนองกลับไปยังลูกค้าพวกเขาอาจใช้หนึ่งในสองกลยุทธ์พื้นฐาน:1
- พร็อกซี: ในวิธีนี้ตัวปรับสมดุลการโหลดได้รับการตอบสนองจากด้านหลังและถ่ายทอดกลับไปยังลูกค้า ตัวปรับสมดุลการโหลดทํางานเป็นเว็บพร็อกซีมาตรฐานและเกี่ยวข้องกับธุรกรรมเครือข่ายทั้งสองอย่าง คือส่งต่อคําขอไปยังลูกค้าและส่งการตอบสนองกลับมา
- TCP จะส่งต่อ ในวิธีนี้ การเชื่อมต่อ TCP กับไคลเอนต์จะถูกส่งไปยังเซิร์ฟเวอร์ส่วนหลัง ดังนั้นเซิร์ฟเวอร์ส่งการตอบสนองไปยังไคลเอ็นต์โดยตรงโดยไม่ต้องผ่านตัวปรับสมดุลการโหลด
รูปที่ 5: กลไกการแฮนด์ออฟ TCP จากตัวส่งไปยังเซิร์ฟเวอร์ back-end
ผลกระทบต่อความพร้อมใช้งานและประสิทธิภาพการทํางาน
การปรับสมดุลการโหลดเป็นกลยุทธ์ที่สําคัญในการปกปิดความล้มเหลวในระบบ ตราบใดที่ไคลเอ็นต์ของระบบถูกเปิดเผยไปยังจุดสิ้นสุดเดียวที่จะสมดุลโหลดข้ามทรัพยากรหลายแหล่ง ความล้มเหลวในแต่ละทรัพยากรสามารถซ่อนตัวจากลูกค้าโดยให้บริการคําขอที่มีทรัพยากรแตกต่างกัน อย่างไรก็ตาม สิ่งสําคัญคือต้องทราบว่าตัวปรับสมดุลการโหลดในขณะนี้เป็นจุดเดียวของความล้มเหลวสําหรับบริการ หากล้มเหลวด้วยเหตุผลใดก็ตามแม้ว่าเซิร์ฟเวอร์ back-end ทั้งหมดจะยังคงทํางานอยู่คําขอของลูกค้าจะไม่สามารถให้บริการได้ ดังนั้นเพื่อให้มีความพร้อมใช้งานสูงตัวปรับสมดุลการโหลดมักใช้ในคู่
การปรับสมดุลการโหลดช่วยให้บริการสามารถกระจายปริมาณงานข้ามทรัพยากรการคํานวณต่างๆ ในระบบคลาวด์ได้ การมีอินสแตนซ์การคํานวณเดียวในระบบคลาวด์มีข้อจํากัดหลายข้อ เราได้กล่าวถึงข้อจํากัดทางกายภาพเกี่ยวกับประสิทธิภาพการทํางานก่อนหน้านี้ ซึ่งจําเป็นต้องใช้ทรัพยากรมากขึ้นสําหรับการเพิ่มปริมาณงาน ด้วยการใช้การปรับสมดุลการโหลดปริมาณงานสามารถกระจายได้ทั่วทั้งแหล่งข้อมูลที่หลากหลายเพื่อให้แต่ละทรัพยากรสามารถตอบสนองคําขอได้อย่างอิสระและขนานจึงช่วยปรับปรุงปริมาณงานของแอปพลิเคชัน นอกจากนี้ยังช่วยปรับปรุงเวลาการบริการโดยเฉลี่ยเนื่องจากมีเซิร์ฟเวอร์ให้บริการปริมาณงานมากขึ้น
การตรวจสอบและการตรวจสอบบริการเป็นสิ่งสําคัญในการทําให้กลยุทธ์การปรับสมดุลโหลดประสบความสําเร็จ ตัวปรับสมดุลการโหลดจําเป็นต้องตรวจสอบให้แน่ใจว่าทุกคําขอได้รับการเติมข้อมูลด้วยการตรวจสอบให้แน่ใจว่าแต่ละโหนดทรัพยากรพร้อมใช้งาน ถ้าไม่เป็นเช่นนั้นปริมาณการใช้งานจะไม่นําไปยังโหนดเฉพาะนั้น การตรวจสอบ Ping-echo เป็นหนึ่งในกลยุทธ์ที่ได้รับความนิยมมากที่สุดเพื่อตรวจสอบสถานภาพของโหนดทรัพยากรเฉพาะ นอกเหนือจากสถานภาพของโหนด แล้ว กลยุทธ์การปรับสมดุลการโหลดบางตัวต้องการข้อมูลเพิ่มเติม เช่น อัตราความเร็ว เวลาแฝง และการใช้งาน CPU เพื่อประเมินทรัพยากรที่เหมาะสมที่สุดสําหรับการรับส่งข้อมูลโดยตรง
ตัวปรับสมดุลการโหลดมักจะต้องรับประกันความพร้อมใช้งานสูง วิธีที่ง่ายที่สุดในการทําเช่นนี้คือการสร้างอินสแตนซ์การปรับสมดุลการโหลดหลายรายการ (แต่ละรายการมีที่อยู่ IP ที่ไม่ซ้ํากัน) และเชื่อมโยงแต่ละอินสแตนซ์ไปยังที่อยู่ DNS เดียว เมื่อใดก็ตามที่อินสแตนซ์ของตัวสร้างสมดุลการโหลดล้มเหลวด้วยเหตุผลใดก็ตาม อินสแตนซ์นั้นจะถูกแทนที่ด้วยอินสแตนซ์ใหม่ และปริมาณการใช้งานทั้งหมดจะถูกส่งผ่านไปยังอินสแตนซ์การย้ายโหนดเมื่อเกิดข้อผิดพลาดที่มีผลกระทบด้านประสิทธิภาพการทํางานขนาดเล็ก ในเวลาเดียวกัน สามารถกําหนดค่าอินสแตนซ์ของตัวสร้างสมดุลการโหลดใหม่เพื่อแทนที่อินสแตนซ์ที่ล้มเหลวและระเบียน DNS ควรได้รับการอัปเดตทันที
กลยุทธ์การปรับสมดุลโหลด
มีกลยุทธ์การปรับสมดุลโหลดต่าง ๆ ในระบบคลาวด์
การจัดส่งส่วนของผู้ถือหุ้น
นี่คือวิธีการแบบคงที่ในการปรับสมดุลการโหลดซึ่งมีการใช้อัลกอริทึมแบบกลมแบบกลมแบบง่ายเพื่อแบ่งปริมาณการใช้งานระหว่างโหนดทั้งหมดอย่างสม่ําเสมอและไม่ได้คํานึงถึงการใช้งานโหนดทรัพยากรแต่ละรายการในระบบหรือเวลาการดําเนินการของคําขอใด ๆ วิธีการนี้พยายามทําให้ทุกโหนดในระบบไม่ว่างและเป็นหนึ่งในวิธีที่ง่ายที่สุดในการนําไปใช้ ข้อด้อยที่สําคัญของวิธีการนี้คือลูกค้าที่ร้องขอจํานวนมากอาจรวมและกระทบกับศูนย์ข้อมูลเดียวกันส่งผลให้โหนดไม่กี่โหนล่มในขณะที่คนอื่นยังคงต้องรับภาระหนักเกินไป อย่างไรก็ตาม การดําเนินการนี้จําเป็นต้องมีรูปแบบการโหลดที่เฉพาะเจาะจงมากและมีความน่าจะเป็นต่ําที่เกิดขึ้นในทางปฏิบัติกับลูกค้าและเซิร์ฟเวอร์จํานวนมากที่มีการกระจายการเชื่อมต่อและความจุที่ค่อนข้างสม่ําเสมอ อย่างไรก็ตามกลยุทธ์นี้ทําให้ยากต่อการใช้กลยุทธ์การแคชในศูนย์ข้อมูลที่คํานึงถึงการพิจารณาเช่น ตําแหน่งที่ตั้งเชิงพื้นที่ (ซึ่งคุณดึงข้อมูลล่วงหน้าและแคชใกล้กับข้อมูลที่รับเข้ามาในปัจจุบัน) เนื่องจากคําขอถัดไปที่ลูกค้ารายเดียวกันสร้างขึ้นบนเซิร์ฟเวอร์อื่น
AWS ใช้วิธีนี้ในข้อเสนอของ ELB (Elastic Load Balancer) AWS ELB เตรียมใช้งานตัวปรับสมดุลการโหลดที่สมดุลของปริมาณการใช้งานทั่วทั้งอินสแตนซ์ EC2 ที่แนบมา ตัวปรับสมดุลการโหลดโดยหลัก ๆ แล้วคืออินสแตนซ์ EC2 ด้วยตนเองพร้อมบริการสําหรับการรับส่งข้อมูลในเส้นทางโดยเฉพาะ เมื่อทรัพยากรเบื้องหลังตัวปรับสมดุลการโหลดถูกปรับขนาด ที่อยู่ IP ของทรัพยากรใหม่จะได้รับการอัปเดตบนระเบียน DNS ของตัวปรับสมดุลการโหลด กระบวนการนี้ใช้เวลาหลายนาทีในการดําเนินการให้เสร็จสมบูรณ์ เนื่องจากต้องอาศัยการตรวจสอบและเวลาในการเตรียมใช้งาน มาตราส่วนช่วงเวลานี้ (เวลาจนกว่าตัวปรับสมดุลโหลดสามารถรับโหลดที่สูงกว่า) เรียกว่า "การเพิ่มความอบอุ่น" ตัวปรับสมดุลโหลด
นอกจากนี้ ตัวปรับสมดุลการโหลดของ ELB จาก AWS ยังตรวจสอบแต่ละทรัพยากรที่แนบมาสําหรับการกระจายปริมาณงานเพื่อรักษาการตรวจสอบสถานภาพ กลไก ping-echo ถูกใช้เพื่อให้แน่ใจว่าทรัพยากรทั้งหมดมีสุขภาพดี ผู้ใช้ ELB สามารถกําหนดค่าพารามิเตอร์ของการตรวจสอบสุขภาพโดยระบุความล่าช้าและจํานวนการลองใหม่
การแจกแจงแบบใช้แฮช
วิธีการนี้พยายามทําให้แน่ใจว่า ไม่ว่าณ จุดใดก็ตาม คําขอที่ทําโดยไคลเอ็นต์ผ่านการเชื่อมต่อเดียวกันจะต้องจบลงบนเซิร์ฟเวอร์เดียวกันเสมอ นอกจากนี้ เพื่อรักษาสมดุลของการกระจายปริมาณการใช้งานของคําขอ จะทําตามลําดับแบบสุ่ม สิ่งนี้มีข้อดีหลายประการเหนือวิธีการแบบ round-robin เนื่องจากช่วยในการใช้งานเซสชันการคงอยู่ของสถานะและกลยุทธ์การแคชจะง่ายกว่ามาก นอกจากนี้ยังน้อยมีความเสี่ยงต่อรูปแบบการรับส่งข้อมูลที่จะทําให้เกิดการอุดตันบนเซิร์ฟเวอร์เดียวเนื่องจากการกระจายเป็นแบบสุ่ม แต่ยังมีความเสี่ยงอยู่ อย่างไรก็ตาม เนื่องจากคําขอทั้งหมดต้องได้รับการประเมินสําหรับเมตาดาต้าการเชื่อมต่อเพื่อกําหนดเส้นทางไปยังเซิร์ฟเวอร์ที่เกี่ยวข้อง จึงมีเวลาแฝงเพียงเล็กน้อยสําหรับทุกคําขอ
ตัวปรับสมดุลการโหลดของ Azure ใช้กลไกการกระจายตามแฮชเพื่อแจกจ่ายการโหลด กลไกนี้สร้างแฮชสําหรับทุกคําขอที่ยึดตาม IP ต้นทาง พอร์ตต้นทาง IP ปลายทาง พอร์ตปลายทาง และชนิดโพรโทคอลเพื่อให้แน่ใจว่าทุกแพ็กเก็ตจากการเชื่อมต่อเดียวกันลงเอยบนเซิร์ฟเวอร์เดียวกันเสมอ ฟังก์ชันแฮชถูกเลือก เพื่อให้การกระจายการเชื่อมต่อกับเซิร์ฟเวอร์ค่อนข้างสุ่ม
Azure มีการตรวจสอบสุขภาพผ่านโพรบสามประเภท: โพรบ Guest Agent (บน PaaS VMs), โพรบแบบกําหนดเองของ HTTP และโพรบแบบกําหนดเองของ TCP ทั้งสามโพรบให้การตรวจสอบสถานภาพสําหรับโหนดทรัพยากรผ่านกลไก ping-echo
กลยุทธ์ยอดนิยมอื่น ๆ
มีกลยุทธ์อื่น ๆ ที่ใช้ในการปรับสมดุลโหลดในแหล่งข้อมูลหลายแหล่ง แต่ละคนใช้เมตริกที่แตกต่างกันในการวัดโหนดทรัพยากรที่เหมาะสมที่สุดสําหรับคําขอเฉพาะ:
- กลยุทธ์ ขึ้นอยู่กับเวลาการดําเนินการตามคําขอ: กลยุทธ์เหล่านี้ใช้อัลกอริทึมการกําหนดตารางเวลาการจัดตารางเวลาลําดับความสําคัญโดยที่เวลาการดําเนินการคําขอจะถูกใช้เพื่อตัดสินลําดับการกระจายโหลดที่เหมาะสมที่สุด ความท้าทายหลักในการใช้วิธีนี้คือการคาดการณ์เวลาการดําเนินการของคําขอเฉพาะอย่างแม่นยํา
- กลยุทธ์ ที่ยึดตามการใช้ทรัพยากร: กลยุทธ์เหล่านี้ใช้ CPU ในแต่ละโหนดทรัพยากรเพื่อสมดุลการใช้ในแต่ละโหนด ตัวปรับสมดุลการโหลดจะรักษารายการทรัพยากรที่เรียงลําดับตามการใช้งานแล้วส่งคําขอไปยังโหนดที่โหลดน้อยที่สุด
สิทธิประโยชน์อื่น ๆ
การมีตัวปรับสมดุลการโหลดแบบรวมศูนย์ให้ยืมกลยุทธ์ต่าง ๆ ที่สามารถเพิ่มประสิทธิภาพของบริการได้ อย่างไรก็ตามสิ่งสําคัญคือต้องทราบว่ากลยุทธ์เหล่านี้ทํางานเฉพาะตราบเท่าที่ตัวปรับสมดุลการโหลดไม่ได้อยู่ภายใต้การโหลดแบบไม่ต่อเนื่อง มิฉะนั้น ตัวปรับสมดุลการโหลดจะกลายเป็นคอขวด กลยุทธ์เหล่านี้บางส่วนแสดงอยู่ด้านล่าง:
- การถ่ายข้อมูล SSL: ธุรกรรมเครือข่ายผ่าน SSL มีค่าใช้จ่ายเพิ่มเติมที่เชื่อมโยงเนื่องจากจําเป็นต้องมีการประมวลผลสําหรับการเข้ารหัสและการรับรองความถูกต้อง แทนที่จะให้บริการคําขอทั้งหมดผ่านทาง SSL การเชื่อมต่อไคลเอ็นต์ไปยังตัวปรับสมดุลการโหลดสามารถทําได้ผ่าน SSL ในขณะที่ทําการร้องขอเปลี่ยนเส้นทางไปยังแต่ละเซิร์ฟเวอร์สามารถทําผ่าน HTTP ได้ การดําเนินการนี้จะช่วยลดการโหลดบนเซิร์ฟเวอร์อย่างมาก นอกจากนี้ ระบบจะรักษาความปลอดภัยตลอดเวลาที่ไม่มีการร้องขอการเปลี่ยนเส้นทางผ่านเครือข่ายแบบเปิด
- การบัฟเฟอร์ TCP: นี่คือกลยุทธ์ในการถ่ายโหลดไคลเอ็นต์ที่มีการเชื่อมต่อช้าบนตัวปรับสมดุลการโหลดเพื่อบรรเทาเซิร์ฟเวอร์ที่ให้บริการการตอบสนองให้กับลูกค้าเหล่านี้
- การแคช: ในบางสถานการณ์ ตัวปรับสมดุลการโหลดสามารถเก็บแคชสําหรับคําขอที่ได้รับความนิยมมากที่สุด (หรือคําขอที่สามารถจัดการได้โดยไม่ต้องไปที่เซิร์ฟเวอร์เช่นเนื้อหาแบบคงที่) เพื่อลดภาระบนเซิร์ฟเวอร์
- การจัดรูปร่างปริมาณการใช้งาน: สําหรับแอปพลิเคชันบางตัว สามารถใช้ตัวปรับสมดุลการโหลดเพื่อหน่วงเวลา/ปรับปรุงโฟลว์ของแพ็คเก็ตเพื่อให้ปริมาณการใช้งานดังกล่าวสามารถขึ้นรูปเพื่อให้เหมาะกับการกําหนดค่าเซิร์ฟเวอร์ ซึ่งมีผลต่อ QoS สําหรับคําขอบางอย่าง แต่ตรวจสอบให้แน่ใจว่าสามารถให้บริการโหลดที่เข้ามาได้
อ้าง อิง
- Aron, Mohit และ Sanders, Darren และ Druschel, Peter และ Zwaenepoel, Willy (2000) การกระจายคําขอการรับรู้เนื้อหาที่ปรับขนาดได้ในเซิร์ฟเวอร์เครือข่ายแบบคลัสเตอร์ จากการดําเนินการของการประชุมทางเทคนิค USENIX ประจําปี 2000