บิลด์ที่เผยแพร่

รายงานปัญหา ดูแหล่งที่มา

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

การแคชระยะไกล

ประเภทที่เผยแพร่ที่ง่ายที่สุดคือใช้ประโยชน์จากการแคชระยะไกลที่แสดงในรูปที่ 1

รูปที่ 1 อาคารแบบกระจายแสดงการแคชระยะไกล

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

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

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

การดําเนินการระยะไกล

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

รูปที่ 2 ระบบการดําเนินการระยะไกล

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

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

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

บิลด์ที่เผยแพร่ที่ Google

ตั้งแต่ปี 2008 เป็นต้นมา Google ใช้ระบบการสร้างแบบกระจายที่ใช้ทั้งการแคชระยะไกลและการดําเนินการระยะไกล ซึ่งแสดงในรูปที่ 3

รูปที่ 3 ระบบบิวด์แบบกระจายของ Google

แคชระยะไกลของ Google เรียกว่า ObjFS ซึ่งประกอบด้วยแบ็กเอนด์ที่จัดเก็บเอาต์พุตใน Bigtable ที่กระจายอยู่ทั่วทั้งเครื่องจักรที่ผลิตเองและ FUSE daemon ฟรอนท์เอนด์ชื่อ objfsd ที่ทํางานบนเครื่องของนักพัฒนาแอปแต่ละราย FUSE daemon ช่วยให้วิศวกรเลือกดูเอาต์พุตบิวด์ต่างๆ ได้เหมือนกับไฟล์ปกติที่เก็บไว้ในเวิร์กสเตชัน แต่ด้วยเนื้อหาไฟล์ที่ดาวน์โหลดมาแบบออนดีมานด์สําหรับเพียงไม่กี่ไฟล์ที่ผู้ใช้ขอโดยตรงเท่านั้น การแสดงเนื้อหาไฟล์แบบออนดีมานด์ช่วยลดทั้งการใช้งานเครือข่ายและดิสก์ได้อย่างมาก และระบบยังสร้างได้เร็วขึ้น 2 เท่าเมื่อเทียบกับเมื่อเราจัดเก็บเอาต์พุตบิวด์ทั้งหมดไว้ในดิสก์ในเครื่องของนักพัฒนาแอป

ระบบดําเนินการระยะไกลของ Google เรียกว่า Forge ไคลเอ็นต์ Forge ใน Blaze (เทียบเท่ากับ Bazel ภายใน) ที่เรียกว่า "ผู้จัดจําหน่าย" จะส่งคําขอสําหรับการดําเนินการแต่ละอย่างไปยังงานที่ทํางานในศูนย์ข้อมูลของเราที่เรียกว่า Scheduler เครื่องจัดตารางเวลาเก็บแคชของผลลัพธ์การดําเนินการ ซึ่งช่วยให้ระบบส่งคืนการตอบกลับได้ทันทีหากมีผู้ใช้สร้างระบบนั้นไว้แล้ว หากไม่เป็นเช่นนั้น ระบบจะวางการทํางานลงในคิว งาน Executer จํานวนมากจะอ่านการดําเนินการจากคิวนี้อย่างต่อเนื่อง เรียกใช้การดําเนินการ และจัดเก็บผลลัพธ์โดยตรงใน ObjFS Bigtable ผลลัพธ์เหล่านี้พร้อมใช้งานสําหรับผู้บริหารสําหรับการดําเนินการในอนาคต หรือจะดาวน์โหลดโดยผู้ใช้ปลายทางผ่าน Objfsd

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