Tupperware: นักฆ่า Kubernetes ของ Facebook?

การจัดการคลัสเตอร์ทุกขนาดอย่างมีประสิทธิภาพและเชื่อถือได้ด้วย Tupperware

วันนี้ที่ การประชุม Systems@Scale เราเปิดตัว Tupperware ซึ่งเป็นระบบการจัดการคลัสเตอร์ของเราที่ประสานคอนเทนเนอร์บนเซิร์ฟเวอร์หลายล้านเครื่องที่ใช้บริการเกือบทั้งหมดของเรา เราปรับใช้ Tupperware เป็นครั้งแรกในปี 2011 และตั้งแต่นั้นมาโครงสร้างพื้นฐานของเราก็เติบโตขึ้นมา ศูนย์ข้อมูล 1 แห่ง ไปจนถึงทั้งหมด ศูนย์ข้อมูลที่กระจายตามภูมิศาสตร์ 15 แห่ง. ตลอดเวลาที่ผ่านมา ทัปเปอร์แวร์ไม่ได้หยุดนิ่งและพัฒนาร่วมกับเรา เราจะแสดงให้คุณเห็นว่า Tupperware มอบการจัดการคลัสเตอร์ระดับเฟิร์สคลาสได้อย่างไร รวมถึงการสนับสนุนที่สะดวกสบายสำหรับบริการ stateful แผงควบคุมเดียวสำหรับศูนย์ข้อมูลทั้งหมด และความสามารถในการกระจายความจุระหว่างบริการต่างๆ ในแบบเรียลไทม์ นอกจากนี้เรายังจะแบ่งปันบทเรียนที่เราได้เรียนรู้เมื่อโครงสร้างพื้นฐานของเราพัฒนาขึ้น

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

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

สถาปัตยกรรมทัปเปอร์แวร์

สถาปัตยกรรม Tupperware PRN เป็นหนึ่งในภูมิภาคของศูนย์ข้อมูลของเรา ภูมิภาคนี้ประกอบด้วยอาคารศูนย์ข้อมูลหลายแห่ง (PRN1 และ PRN2) ที่ตั้งอยู่ใกล้ๆ เราวางแผนที่จะสร้างแผงควบคุมเดียวที่จะจัดการเซิร์ฟเวอร์ทั้งหมดในภูมิภาคเดียว

ผู้พัฒนาแอพพลิเคชั่นนำเสนอบริการในรูปแบบของงานทัปเปอร์แวร์ งานประกอบด้วยหลายคอนเทนเนอร์ และโดยทั่วไปงานเหล่านั้นทั้งหมดจะเรียกใช้โค้ดแอปพลิเคชันเดียวกัน

Tupperware มีหน้าที่จัดเตรียมคอนเทนเนอร์และจัดการวงจรการใช้งาน ประกอบด้วยองค์ประกอบหลายประการ:

• ส่วนหน้าของ Tupperware มี API สำหรับอินเทอร์เฟซผู้ใช้, CLI และเครื่องมืออัตโนมัติอื่นๆ ซึ่งคุณสามารถโต้ตอบกับ Tupperware ได้ พวกเขาซ่อนโครงสร้างภายในทั้งหมดไม่ให้เจ้าของงานทัปเปอร์แวร์
• Tupperware Scheduler เป็นแผงควบคุมที่รับผิดชอบในการจัดการคอนเทนเนอร์และวงจรการใช้งาน มีการปรับใช้ในระดับภูมิภาคและระดับโลก โดยที่ตัวกำหนดเวลาระดับภูมิภาคจะจัดการเซิร์ฟเวอร์ในภูมิภาคหนึ่ง และผู้กำหนดเวลาส่วนกลางจะจัดการเซิร์ฟเวอร์จากภูมิภาคที่ต่างกัน ตัวกำหนดเวลาแบ่งออกเป็นส่วนต่างๆ และแต่ละส่วนจะจัดการชุดงาน
• Scheduler Proxy ของ Tupperware ซ่อนการแบ่งส่วนภายในและให้บานหน้าต่างเดียวที่สะดวกสบายสำหรับผู้ใช้ Tupperware
• ตัวจัดสรร Tupperware กำหนดคอนเทนเนอร์ให้กับเซิร์ฟเวอร์ ตัวกำหนดเวลาจัดการการหยุด การเริ่มต้น การอัปเดต และการเฟลโอเวอร์ของคอนเทนเนอร์ ในปัจจุบัน ผู้จัดสรรหนึ่งรายสามารถจัดการทั้งภูมิภาคได้โดยไม่ต้องแบ่งออกเป็นส่วนย่อย (สังเกตความแตกต่างในคำศัพท์ ตัวอย่างเช่น ตัวกำหนดเวลาใน Tupperware สอดคล้องกับแผงควบคุม Kubernetesและตัวจัดสรร Tupperware เรียกว่าตัวกำหนดเวลาใน Kubernetes)
• นายหน้าทรัพยากรจัดเก็บแหล่งที่มาของความจริงสำหรับเหตุการณ์เซิร์ฟเวอร์และการบริการ เราดำเนินการนายหน้าทรัพยากรหนึ่งรายสำหรับศูนย์ข้อมูลแต่ละแห่ง และจะจัดเก็บข้อมูลทั้งหมดเกี่ยวกับเซิร์ฟเวอร์ในศูนย์ข้อมูลนั้น นายหน้าทรัพยากรและระบบการจัดการความจุ หรือระบบการจัดเตรียมทรัพยากร จะตัดสินใจแบบไดนามิกว่าการส่งมอบตัวกำหนดตารางเวลาใดจะควบคุมเซิร์ฟเวอร์ใด บริการตรวจสุขภาพจะตรวจสอบเซิร์ฟเวอร์และจัดเก็บข้อมูลเกี่ยวกับความสมบูรณ์ของพวกเขาในตัวกลางทรัพยากร หากเซิร์ฟเวอร์มีปัญหาหรือจำเป็นต้องบำรุงรักษา นายหน้าทรัพยากรจะแจ้งให้ผู้จัดสรรและผู้กำหนดเวลาหยุดคอนเทนเนอร์หรือย้ายคอนเทนเนอร์ไปยังเซิร์ฟเวอร์อื่น
• Tupperware Agent เป็น daemon ที่ทำงานบนเซิร์ฟเวอร์แต่ละเครื่องที่จัดการการจัดเตรียมและการลบคอนเทนเนอร์ แอปพลิเคชันทำงานภายในคอนเทนเนอร์ ซึ่งช่วยให้แยกและทำซ้ำได้มากขึ้น บน การประชุม Systems @Scale เมื่อปีที่แล้ว เราได้อธิบายไปแล้วว่าแต่ละคอนเทนเนอร์ Tupperware ถูกสร้างขึ้นโดยใช้อิมเมจ, btrfs, cgroupv2 และ systemd ไปแล้ว

คุณสมบัติเด่นของทัปเปอร์แวร์

Tupperware มีความคล้ายคลึงในหลายๆ ด้านกับระบบการจัดการคลัสเตอร์อื่นๆ เช่น Kubernetes และ เมโสแต่ก็มีความแตกต่างเช่นกัน:

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

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

การสนับสนุนในตัวสำหรับบริการ stateful

Tupperware ดำเนินบริการ stateful ที่สำคัญหลากหลายซึ่งจัดเก็บข้อมูลผลิตภัณฑ์ถาวรสำหรับ Facebook, Instagram, Messenger และ WhatsApp สิ่งเหล่านี้อาจเป็นที่เก็บคู่คีย์-ค่าขนาดใหญ่ (เช่น ZippyDB) และการตรวจสอบที่เก็บข้อมูล (เช่น โอดีเอส กอริลลา и Scuba). การดูแลรักษาบริการ stateful ไม่ใช่เรื่องง่าย เนื่องจากระบบจะต้องตรวจสอบให้แน่ใจว่าการจ่ายตู้คอนเทนเนอร์สามารถทนต่อการหยุดชะงักในวงกว้าง รวมถึงการหยุดทำงานของเครือข่ายหรือไฟฟ้าดับ และในขณะที่เทคนิคทั่วไป เช่น การกระจายคอนเทนเนอร์ข้าม Fault Domain จะทำงานได้ดีสำหรับบริการไร้สถานะ แต่บริการแบบมีสถานะจำเป็นต้องได้รับการสนับสนุนเพิ่มเติม

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

อินเทอร์เฟซ TaskControl ช่วยให้บริการ stateful มีอิทธิพลต่อการตัดสินใจที่ส่งผลต่อความพร้อมใช้งานของข้อมูล เมื่อใช้อินเทอร์เฟซนี้ ตัวกำหนดเวลาจะแจ้งเตือนแอปพลิเคชันภายนอกเกี่ยวกับการทำงานของคอนเทนเนอร์ (รีสตาร์ท อัปเดต การย้ายข้อมูล การบำรุงรักษา) บริการ stateful จะใช้ตัวควบคุมที่จะแจ้งให้ Tupperware ทราบว่าจะดำเนินการแต่ละอย่างได้อย่างปลอดภัยเมื่อใด และการดำเนินการเหล่านี้สามารถสลับหรือล่าช้าได้ชั่วคราว ในตัวอย่างด้านบน ตัวควบคุมฐานข้อมูลสามารถบอกให้ Tupperware อัปเดตเซิร์ฟเวอร์ 49 รายการจากทั้งหมด 50 เซิร์ฟเวอร์ แต่ปล่อยให้เซิร์ฟเวอร์เฉพาะ (X) อยู่คนเดียวในตอนนี้ ด้วยเหตุนี้ หากเลยช่วงการอัปเดตเคอร์เนลไปแล้ว และฐานข้อมูลยังคงไม่สามารถกู้คืนแบบจำลองที่มีปัญหาได้ Tupperware จะยังคงอัปเดตเซิร์ฟเวอร์ X

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

การจัดการเซิร์ฟเวอร์ในศูนย์ข้อมูล

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

เราสร้างนายหน้าทรัพยากรเพื่อแก้ไขปัญหาการรื้อถอนคลัสเตอร์และประสานงานงานบำรุงรักษาประเภทอื่นๆ นายหน้าทรัพยากรติดตามข้อมูลทางกายภาพทั้งหมดที่เกี่ยวข้องกับเซิร์ฟเวอร์ และตัดสินใจแบบไดนามิกว่าตัวกำหนดตารางเวลาใดควบคุมแต่ละเซิร์ฟเวอร์ การเชื่อมโยงเซิร์ฟเวอร์เข้ากับตัวกำหนดเวลาแบบไดนามิกช่วยให้ตัวกำหนดเวลาสามารถจัดการเซิร์ฟเวอร์ในศูนย์ข้อมูลที่แตกต่างกัน เนื่องจากงาน Tupperware ไม่ได้จำกัดอยู่เพียงคลัสเตอร์เดียวอีกต่อไป ผู้ใช้ Tupperware จึงสามารถระบุวิธีกระจายคอนเทนเนอร์ข้าม Fault Domain ได้ ตัวอย่างเช่น นักพัฒนาสามารถประกาศเจตนาของเขา (เช่น "รันงานของฉันบนโดเมนข้อบกพร่อง 2 โดเมนในภูมิภาค PRN") โดยไม่ต้องระบุโซนความพร้อมใช้งานเฉพาะ ทัปเปอร์แวร์เองจะค้นหาเซิร์ฟเวอร์ที่เหมาะสมเพื่อดำเนินการตามความตั้งใจนี้ แม้ว่าคลัสเตอร์หรือบริการจะถูกเลิกใช้งานก็ตาม

ปรับขนาดได้เพื่อรองรับระบบทั่วโลกทั้งหมด

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

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

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

ปรับปรุงประสิทธิภาพการใช้งานด้วยคอมพิวเตอร์แบบยืดหยุ่น

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

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

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


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

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

บทเรียนที่ได้รับและการวางแผนสำหรับอนาคต

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

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

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

ที่มา: will.com