Google เล่าประสบการณ์ แปลงระบบทั้งหมดให้รันได้ทั้ง Arm และ x86 นับแสนแอป ด้วยพลัง AI

Google Cloud logo

Google Axion และ CogniPort เบื้องหลังโครงการ multiarch ที่ใช้ AI และระบบอัตโนมัติขับเคลื่อนการพอร์ตโค้ดระดับองค์กร


การย้ายโค้ดระดับองค์กรอาจเป็นเรื่องปกติสำหรับบริษัททั่วไป แต่สำหรับ Google ที่มีแอปพลิเคชันภายในกว่า 100,000 ตัว มันคือ “การย้ายภูเขา” จริง ๆ บริษัทเผยว่าได้เริ่มแผนใหญ่เพื่อทำให้ระบบทั้งหมดรันได้ทั้งบนซีพียู x86 และ Arm หรือที่เรียกว่า multiarch โดยมี AI และระบบอัตโนมัติเป็นหัวใจสำคัญของการเปลี่ยนผ่านครั้งนี้

แนวคิดนี้เริ่มชัดเจนขึ้นหลังการเปิดตัว Google Axion ซีพียูสถาปัตยกรรม Arm ที่ออกแบบเองสำหรับ Google Cloud ซึ่งให้ ประสิทธิภาพต่อราคาดีกว่า 65% และประหยัดพลังงานกว่า 60% เมื่อเทียบกับ instance มาตรฐาน ความสำเร็จของ Axion กลายเป็นจุดเปลี่ยนสำคัญที่ผลักดันให้ Google ต้องทำให้บริการทั้งหมดทำงานได้บนทั้งสองสถาปัตยกรรม

ในช่วงเริ่มต้น ทีม multiarch ของ Google เริ่มจากบริการขนาดใหญ่ที่มีผลกระทบมากที่สุด เช่น F1, Spanner, และ Bigtable โดยใช้แนวทางดั้งเดิม — ทีมวิศวกรเฉพาะด้านประชุมทุกสัปดาห์เพื่อแก้ไขปัญหาไปทีละขั้น

สิ่งที่พบคือ ปัญหาทางสถาปัตยกรรมอย่าง floating-point drift หรือ concurrency มีน้อยกว่าที่คาด เครื่องมืออย่าง compiler และ sanitizer ช่วยได้มาก แต่สิ่งที่กินเวลาจริงกลับเป็นเรื่อง “น่าเบื่อ” เช่น การแก้ระบบทดสอบที่ผูกกับ x86 เดิม การอัปเดตระบบ build และ release ที่ซับซ้อน และการคอนฟิกระบบ production ให้เสถียร

หลังผ่านอุปสรรคเหล่านี้ บริการชุดแรกก็สามารถรันบนเครื่อง Arm ผ่านระบบจัดการคลัสเตอร์ Borg ได้สำเร็จ ทว่าการพอร์ตเพียงสิบกว่าบริการไม่เพียงพอ เพราะถึงแม้แอปยอดนิยม 50 ตัวจะกินสัดส่วนการใช้งานกว่า 60% แต่เพื่อประสิทธิภาพการกระจายโหลดสูงสุด Google จำเป็นต้องพอร์ต “ทุกอย่าง”

Proportion of Commits by Category Over Time (normalized)
Proportion of Commits by Category Over Time (normalized)
ภาพ: กราฟแสดงสัดส่วนของคอมมิตแต่ละประเภทในโครงการย้ายระบบของ Google ไปสู่สถาปัตยกรรมแบบหลายชุดคำสั่ง (multiarch) ทั้ง x86 และ Arm โดยแสดงการเปลี่ยนแปลงตามเวลาในลักษณะ normalized พบว่าช่วงต้นของโครงการส่วนใหญ่เป็นงานด้าน build และโครงสร้างพื้นฐาน ก่อนที่ช่วงกลางจะเน้นการปรับโค้ดและระบบทดสอบ และช่วงท้ายกลับมาเน้นการจัดการคอนฟิกและกระบวนการสนับสนุนเพื่อขยายระบบสู่ระดับองค์กร

การติดต่อทีมเจ้าของแอปกว่าแสนทีมแทบเป็นไปไม่ได้ จึงต้องพึ่งระบบอัตโนมัติเต็มรูปแบบ Google ใช้ระบบภายในหลายตัวช่วยงานนี้ เช่น

  • Rosie: สร้างและส่งคอมมิตจำนวนมากเข้ารีวิวอัตโนมัติ เช่น เพิ่มบรรทัดเปิดใช้งาน Arm ใน Blueprint
  • Sanitizers และ Fuzzers: ตรวจจับความแตกต่างของการทำงานระหว่าง x86 กับ Arm ก่อนจะเกิดบั๊กจริง
  • CHAMP (Continuous Health Monitoring Platform): เฝ้าระวังและจัดการงาน multiarch โดยอัตโนมัติ หากพบการล่มหรือประสิทธิภาพตก ระบบจะถอดออกเพื่อปรับแก้

และที่สำคัญที่สุดคือ CogniPort ระบบ AI ที่สามารถ “แก้โค้ดเอง” ได้เมื่อเจอปัญหาการ build หรือ test ล้มเหลว

CogniPort: ตัวช่วย AI ในการพอร์ตโค้ด

CogniPort ประกอบด้วยวงรอบการทำงานสามชั้น โดยใช้โมเดลภาษา (LLM) เป็นตัวประสานระหว่างขั้นตอน reasoning และการเรียกใช้เครื่องมือจริง

  • Build-fixer agent: พยายามแก้ปัญหาการคอมไพล์ล้มเหลว
  • Test-fixer agent: รันเทสต์และแก้ไขจนผ่านได้
  • Orchestrator agent: ควบคุมลูปทั้งหมดให้ทำงานสอดคล้องกัน

Google ทดสอบ CogniPort ด้วยการย้อนกลับคอมมิตจริงจำนวน 245 รายการ แล้วให้ระบบพยายามแก้ใหม่ พบว่า CogniPort แก้เทสต์สำเร็จได้ราว 30% โดยเฉพาะปัญหาเกี่ยวกับ test failure, เงื่อนไขเฉพาะแพลตฟอร์ม และการแปลงข้อมูล

google CogniPort
ภาพ: โครงสร้างการทำงานของระบบ CogniPort ที่ Google ใช้ในการพอร์ตโค้ดจาก x86 ไปยัง Arm โดยอัตโนมัติ ระบบนี้ประกอบด้วย 3 ตัวแทนหลักคือ Orchestrator Agent ที่ควบคุมกระบวนการหลัก, Build Fixer Agent ที่แก้ปัญหาการคอมไพล์, และ Test Fixer Agent ที่ทดสอบและแก้โค้ดจนผ่าน โดยทั้งหมดทำงานร่วมกับเครื่องมือภายใน เช่น Code Search, Build Target และ Run Test เพื่อให้การย้ายโค้ดเป็นไปอย่างต่อเนื่องและแม่นยำ

นอกจากเครื่องมืออัตโนมัติแล้ว Google ยังใช้โมเดล Gemini Flash LLM วิเคราะห์คอมมิตกว่า 38,156 รายการ ที่เกิดขึ้นระหว่างการย้ายโค้ด รวมกว่า 700,000 บรรทัด เพื่อจัดหมวดหมู่เป็น 16 ประเภท

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

แม้จะยังเหลืออีกหลายหมื่นแอปที่ต้องพอร์ต แต่ Google มั่นใจว่าทิศทางนี้ถูกต้อง โค้ดใหม่ทั้งหมดในอนาคตจะเป็น multiarch-native โดยตั้งแต่ต้น ระบบอย่าง Rosie, CHAMP และ CogniPort จะยังคงทำงานต่อเนื่องเพื่อลดภาระของทีมพัฒนา

Google ระบุว่าความสำเร็จครั้งนี้เกิดจากการผสานกันของระบบ monorepo ขนาดใหญ่, เครื่องมืออัตโนมัติที่สั่งสมมานาน และความก้าวหน้าของ AI ซึ่งทั้งหมดนี้กำลังผลักดันให้บริษัทเข้าใกล้เป้าหมายของ Google multiarch fleet ที่แท้จริง

ที่มา – Google

About modify 6603 Articles
สามารถนำบทความไปเผยแพร่ได้อย่างอิสระ โดยกล่าวถึงแหล่งที่มา เป็นลิงค์กลับมายังบทความนั้นๆ บทความอาจมีการพิมพ์ตกเรื่องภาษาไปบ้าง ต้องขออภัย พยามจะพิมพ์ผิดให้น้อยที่สุด (ทำเว็บคนเดียวไม่มีคนตรวจทาน) บทความที่สอนเรื่องต่างๆ กรุณาอ่านบทความให้เข้าใจก่อนโพสต์ถาม ติดตรงไหนสามารถถามได้ที่โพสต์นั้นๆ

Be the first to comment

Leave a Reply

Your email address will not be published.